Re: pg_dump bug for extension owned tables
От | Andrew Dunstan |
---|---|
Тема | Re: pg_dump bug for extension owned tables |
Дата | |
Msg-id | 8f30cf19-efa4-f0b0-15e0-5533aae6509d@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: pg_dump bug for extension owned tables (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_dump bug for extension owned tables
|
Список | pgsql-hackers |
On 10/6/20 5:19 PM, Tom Lane wrote: > 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". Yes, I see the issue. Mea culpa :-( > > 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"? It looks like you've since discovered the cause here. Do you need me to dig more? cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: