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
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 |
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 |