Re: pg_dump bug for extension owned tables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump bug for extension owned tables
Date
Msg-id 2007143.1602019193@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump bug for extension owned tables  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: pg_dump bug for extension owned tables
List pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> Thanks, Committed. Further investigation shows this was introduced in
> release 12, so that's how far back I went.

Still further investigation shows that this patch caused bug #16655 [1].
It should *not* have been designed to unconditionally clear the
table's "interesting" flag, as there may have been other reasons
why that was set.  The right way to think about it is "if we are
going to dump the table's data, then the table certainly needs its
interesting flag set, so that we'll collect the per-attribute info.
Otherwise leave well enough alone".

The patches I proposed in the other thread seem like they really ought
to go all the way back for safety's sake.  However, I do not observe
any crash on the test case in v11, and I'm kind of wondering why not.
Did you identify exactly where this was "introduced in release 12"?

            regards, tom lane

[1] https://www.postgresql.org/message-id/flat/16655-5c92d6b3a9438137%40postgresql.org



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade analyze script
Next
From: Peter Smith
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions