Re: PG 9.6.20 -- query misbehaves in replica

Поиск
Список
Период
Сортировка
От Ernesto Hernández-Novich
Тема Re: PG 9.6.20 -- query misbehaves in replica
Дата
Msg-id 9da8208c61333d155a7328b107f75b85a0bf832e.camel@gmail.com
обсуждение исходный текст
Ответ на Re: PG 9.6.20 -- query misbehaves in replica  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: PG 9.6.20 -- query misbehaves in replica  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-bugs
On Sat, 2020-11-14 at 00:59 +0100, Magnus Hagander wrote:
> On Sat, Nov 14, 2020 at 12:17 AM Ernesto Hernández-Novich <
> emhnemhn@gmail.com> wrote:
[...]
> > After updating from 9.6.19 to 9.6.20, we noticed the query was not
> > working on D.
[...]
> > Looks like a the 9.6.20 over Debian 10 is the culprit, but I have
> > nothing else to work on.
> 
> These issues are almost certainly because of the glibc locale changes
> between Debian 9 and Debian 10, and not because of the PostgreSQL
> upgrade.
>
> If you have master and standby on different glibc versions (so debian
> 9 vs 10), all text based indexes can behave differently. All the
> nodes must run the same version for this to work. So in this
> scenario, you need to reinstall B and D with debian 9, or you need to
> upgrade your other nodes to debian 10 (and if you do that, then you
> have to reindex the master node once it has been upgraded).

I agree on the locale matching and will try your suggestion.

I must say the Debian 10 machines were working just fine with PG 9.6.19
for over two months or so. We noticed the issue *just* this week after
upgrading from 9.6.19 onto 9.6.20.

Regards,
-- 
Ernesto Hernández-Novich - @iamemhn - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can't aptitude it, it isn't useful or doesn't exist.
GPG Key Fingerprint = 0064 ADF5 EB5C DE16 99C1 6C56 F2A3 86B5 A757 E5A1




В списке pgsql-bugs по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: PG 9.6.20 -- query misbehaves in replica
Следующее
От: Andres Freund
Дата:
Сообщение: Re: BUG #16714: INSERT ON CONFLICT DO UPDATE fails to infer constraint if it's not at top-level partition