Re: pg_dump bug for extension owned tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Cc: Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_dump bug for extension owned tables
Date: 2020-10-06 21:19:53
Message-ID: 2007143.1602019193@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2020-10-06 22:35:38 Re: [HACKERS] logical decoding of two-phase transactions
Previous Message Bruce Momjian 2020-10-06 20:49:33 Re: pg_upgrade analyze script