Re: pg_dump bug for extension owned tables
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Fabrízio de Royes Mello <fabriziomello@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-10-06T21:19:53Z
Lists: 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
Commits
-
Rethink recent fix for pg_dump's handling of extension config tables.
- 710c0a66d6e9 9.6.20 landed
- 0bfe356c5594 9.5.24 landed
- f2c6e94f0790 11.10 landed
- 0c79dcb36c52 10.15 landed
- d8c2a2199867 12.5 landed
- 2ea624b4b51c 13.1 landed
- 9e5f1f21ad6a 14.0 landed