Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
От | Tom Lane |
---|---|
Тема | Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation |
Дата | |
Msg-id | 2393003.1725665829@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
|
Список | pgsql-hackers |
Noah Misch <noah@leadboat.com> writes: > On Fri, Sep 06, 2024 at 06:36:53PM -0400, Tom Lane wrote: >> I feel like all of these are leaning heavily on users to get it right, > What do you have in mind? I see things for the pg_upgrade implementation to > get right, but I don't see things for pg_upgrade users to get right. Well, yeah, if you are willing to put pg_upgrade in charge of executing ALTER EXTENSION UPDATE, then that would be a reasonably omission-proof path. But we have always intended the pg_upgrade process to *not* auto-update extensions, so I'm concerned about the potential side-effects of drilling a hole in that policy. As an example: even if we ensure that pg_trgm 1.6 to 1.7 is totally transparent except for this fix, what happens if the user's old database is still on some pre-1.6 version? Is it okay to force an update that includes feature upgrades? regards, tom lane
В списке pgsql-hackers по дате отправления: