Re: BUG #16045: vacuum_db crash and illegal memory alloc after pg_upgrade from PG11 to PG12

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, buschmann(at)nidsa(dot)net, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16045: vacuum_db crash and illegal memory alloc after pg_upgrade from PG11 to PG12
Date: 2019-10-10 16:33:50
Message-ID: 20191010163350.2rtcjtje6tkgilqi@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs pgsql-hackers

On Thu, Oct 10, 2019 at 10:19:12AM -0400, Tom Lane wrote:
>Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
>> Fair enough, attached is a patch doing that, I think. Maybe the file
>> should be named differently, as it contains other objects than just
>> tables.
>Seems about right, though I notice it will not detect domains over
>sql_identifier. How much do we care about that?
>To identify such domains, I think we'd need something like
>WHERE attypid IN (recursive-WITH-query), which makes me nervous.
>We did support those starting with 8.4, which is as far back as
>pg_upgrade will go, so in theory it should work. But I think we
>had bugs with such cases in old releases. Do we want to assume
>that the source server has been updated enough to avoid any such
>bugs? The expense of such a query might be daunting, too.

Not sure.

Regarding bugs, I think it's fine to assume the users are running
sufficiently recent version - they may not, but then they're probably
subject to various other bugs (data corruption, queries). If they're
not, then they'll either get false positives (in which case they'll be
forced to update) or false negatives (which is just as if we did

For the query cost, I think we can assume the domain hierarchies are not
particularly deep (in practice I'd expect just domains directly on the
sql_identifier type). And I doubt people are using that very widely,
it's probably more like this report - ad-hoc CTAS, so just a couple of
items. So I wouldn't expect it to be a huge deal in most cases. But even
if it takes a second or two, it's a one-time cost.


Tomas Vondra
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2019-10-10 17:04:17 Re: please help, my postgress page can't be uploaded perfectly
Previous Message Andres Freund 2019-10-10 15:25:15 Re: BUG #16039: PANIC when activating replication slots in Postgres 12.0 64bit under Windows

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-10-10 18:26:09 Re: pgsql: Remove pqsignal() from libpq's official exports list.
Previous Message Andres Freund 2019-10-10 16:05:42 Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)