From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Legacy GiST invalid tuples |
Date: | 2018-07-06 04:09:37 |
Message-ID: | 68874.1530850177@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-07-04 17:02:01 -0400, Alvaro Herrera wrote:
>> On 2018-Jul-04, Andres Freund wrote:
>>> I don't think we can easily require that everyone pg_upgrading to v13+
>>> upgrades to v12 first?
>> We've never done that, I don't know if we can get away with it.
>> Upgrades with pg_upgrade are not cheap enough for that, methinks.
>> Maybe I'm wrong, but people complain even at a *single* pg_upgrade --
>> seems everybody wants in-place upgrades nowadays ...
> Right. That's why I was wondering about making the "last full scan"
> feature backpatchable...
ISTM this is closely related to the business about on-line checksum
enabling that Magnus et al have been working on. In general, we have a
lot of pent-up demand for changes that require on-disk data modification,
so it seems like it's time to design a generic mechanism for doing that
in a nice way (ie without downtime or huge performance penalties).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-07-06 05:21:48 | Re: [HACKERS] Replication status in logical replication |
Previous Message | Kyotaro HORIGUCHI | 2018-07-06 04:07:47 | Re: Non-reserved replication slots and slot advancing |