| 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: | Whole Thread | Raw Message | 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? |