| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com> |
| Subject: | Re: pg_upgrade and rsync |
| Date: | 2015-01-27 15:20:48 |
| Message-ID: | CA+TgmoYJBArNKY82KZFAJU4k0SM=bxsOj8bf1rkqL2un3EOhug@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jan 27, 2015 at 9:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Jan 23, 2015 at 1:48 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>>> I don't understand why that'd be better than simply fixing (yes, that's
>>> imo the correct term) pg_upgrade to retain relfilenodes across the
>>> upgrade. Afaics there's no conflict risk and it'd make the clusters much
>>> more similar, which would be good; independent of rsyncing standbys.
>
>> +1.
>
> That's certainly impossible for the system catalogs, which means you
> have to be able to deal with relfilenode discrepancies for them, which
> means that maintaining the same relfilenodes for user tables is of
> dubious value.
Why is that impossible for the system catalogs?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-01-27 15:25:24 | Re: pg_upgrade and rsync |
| Previous Message | Robert Haas | 2015-01-27 15:20:21 | Re: pg_upgrade and rsync |