Horton

Re: pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Noah Misch <noah@leadboat.com>
Cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Date: 2011-04-21T02:02:50Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix pg_dump to handle collations applied to columns of composite types.

On Wed, Apr 20, 2011 at 6:36 PM, Noah Misch <noah@leadboat.com> wrote:
> On Wed, Apr 20, 2011 at 01:10:19PM -0400, Robert Haas wrote:
>> On Wed, Apr 20, 2011 at 9:57 AM, Noah Misch <noah@leadboat.com> wrote:
>> > On Tue, Apr 19, 2011 at 10:36:14PM -0400, Robert Haas wrote:
>> >> On Mon, Apr 18, 2011 at 7:50 PM, Noah Misch <noah@leadboat.com> wrote:
>> >> > On Fri, Apr 15, 2011 at 11:58:30AM -0400, Noah Misch wrote:
>> >> >> When we're done with the relkind-restriction patch, I'll post a new version of
>> >> >> this one. ?It will remove the circularity check and add a relkind check.
>> >> >
>> >> > Here it is. ?Changes from tt1v1-alter-of.patch to tt1v2-alter-of.patch:
>> >> > * Use transformOfType()'s relkind check in ATExecAddOf()
>> >> > * Remove circularity check
>> >> > * Open pg_inherits with AccessShareLock
>> >> > * Fix terminology in ATExecDropOf() comment
>> >> > * Rebase over pgindent changes
>> >> >
>> >> > Changes from tt2v1-binary-upgrade.patch to tt2v2-binary-upgrade.patch:
>> >> > * Rebase over dumpCompositeType() changes from commit acfa1f45
>> >>
>> >> I think there's a bug in the tt1v1 patch. ?I'm getting intermittent
>> >> regression test failures at this point:
>
> It neglected to call CatalogUpdateIndexes(); attached new version fixes that.
> The failure was intermittent due to HOT; stubbing out HeapSatisfiesHOTUpdate()
> with "return false" made the failure appear every time.
>
> Thanks for the failure data.

Thanks for the patch!

I've now committed this part; the actual fix for pg_dump is still
outstanding.  I am not too in love with the syntax you've chosen here,
but since I don't have a better idea I'll wait and see if anyone else
wants to bikeshed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company