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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
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 14:19:12
Message-ID: 30706.1570717152@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2019-10-10 15:25:15 Re: BUG #16039: PANIC when activating replication slots in Postgres 12.0 64bit under Windows
Previous Message Tomas Vondra 2019-10-10 13:43:03 Re: BUG #16045: vacuum_db crash and illegal memory alloc after pg_upgrade from PG11 to PG12

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2019-10-10 14:40:37 Re: Transparent Data Encryption (TDE) and encrypted files
Previous Message Tomas Vondra 2019-10-10 14:05:08 Re: Remove size limitations of vacuums dead_tuples array