From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Steven Lembark <lembark(at)wrkhors(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Move vs. copy table between databases that share a tablespace? |
Date: | 2019-04-03 15:19:29 |
Message-ID: | 15464.1554304769@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2019-Apr-03, Tom Lane wrote:
>> Actually, thinking about that a bit harder: there's one aspect of
>> what pg_upgrade does that's really hard to control from userspace,
>> and that's forcing tables to have the same OIDs as before. In this
>> context, that means you're probably out of luck if the table has a
>> TOAST table, unless the TOAST table is empty. There wouldn't be
>> any good way to keep TOAST pointers valid across the move.
> Hmm, couldn't you use the binary-upgrade support functions just prior to
> creating the table in the target database?
Yeah, in theory you could do that, if the OID isn't already in use for
a table. But that just added several more steps and more ways to
shoot yourself in the foot. I'm starting to think this wouldn't really
be worth the risk.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | rihad | 2019-04-03 15:42:03 | Re: Recommendation to run vacuum FULL in parallel |
Previous Message | Alvaro Herrera | 2019-04-03 15:12:46 | Re: Move vs. copy table between databases that share a tablespace? |