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

On Wed, Apr 20, 2011 at 9:57 AM, Noah Misch <noah(at)leadboat(dot)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(at)leadboat(dot)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:
>>
>> ALTER TABLE tt7 OF tt_t1;                       -- reassign an
>> already-typed table
>> server closed the connection unexpectedly
>>         This probably means the server terminated abnormally
>>         before or while processing the request.
>> connection to server was lost
>>
>> In src/test/regress/log/postmaster.log:
>>
>> TRAP: FailedAssertion("!(((bool)((relation)->rd_refcnt == 0)))", File:
>> "relcache.c", Line: 1756)
>
> How frequently does it happen for you?  I ran `make check' about fifteen times
> without hitting an error.  I ran the new test cases under valgrind, and that
> also came out clean.
>
> Could you try a fresh build and see if it still happens?  If it does, could you
> grab a "bt full" and "p *relation->rd_rel" in gdb?

I reproduced it this morning after git clean -dfx, updating to the
latest master branch, and re-applying your patch. The most recent
time I reproduced it, it took 7 tries, but I think the average
frequency of failure is around 25%.

gdb info attached, courtesy of defining SLEEP_ON_ASSERT to 1 in
pg_config_manual.h

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