| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Magnus Hagander <magnus(at)hagander(dot)net> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com> |
| Subject: | Re: New pg_lsn type doesn't have hash/btree opclasses |
| Date: | 2014-05-10 23:08:48 |
| Message-ID: | 22548.1399763328@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Sun, May 11, 2014 at 12:27 AM, Andres Freund <andres(at)2ndquadrant(dot)com>wrote:
>> The problem is that once the beta is in progress (starting tomorrow),
>> the projects tries to avoid changes which require a dump and restore (or
>> pg_upgrade). Since the patch changes the catalog it'd require that.
> It would be pg_upgrade'able though, wouldn't it? Don't we have precedents
> for requiring pg_upgrade during beta? At least that's a smaller problem
> than requiring a complete dump/reload.
pg_upgrade makes the penalty for screwups smaller, but a post-beta1 initdb
is still the result of a screwup. None of the historical examples you
mention were planned in advance of beta.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2014-05-10 23:17:13 | Re: New pg_lsn type doesn't have hash/btree opclasses |
| Previous Message | Fujii Masao | 2014-05-10 23:08:16 | Re: postgresql.auto.conf read from wrong directory |