Re: New pg_lsn type doesn't have hash/btree opclasses
| От | Andres Freund |
|---|---|
| Тема | Re: New pg_lsn type doesn't have hash/btree opclasses |
| Дата | |
| Msg-id | 20140510231713.GH16507@awork2.anarazel.de обсуждение исходный текст |
| Ответ на | Re: New pg_lsn type doesn't have hash/btree opclasses (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: New pg_lsn type doesn't have hash/btree opclasses
|
| Список | pgsql-hackers |
On 2014-05-10 19:08:48 -0400, Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: > > On Sun, May 11, 2014 at 12:27 AM, Andres Freund <andres@2ndquadrant.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. Yea, I posted that just to answer Magnus' question. I've argued that this omission should be fixed since tuesday. There's been a tested and reviewed patch since 20140506230722.GE24808@awork2.anarazel.de. Given how many changes went in since it certainly wouldn't have been a very destabilizing commit. Anyway. I accept it's too late for beta1 now. Let's commit it if there's another catversion bump. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: