Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows

From: Pawel Kudzia <kudzia(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows
Date: 2021-07-25 20:47:43
Message-ID: CAJYBUS-Dp3wYR8A7JqO2UiY=0VapHW6SiY2UaOgHA3TcbjeGQQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sun, Jul 25, 2021 at 10:27 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> Just to make sure: are you using any kind of storage or other virtualization, or a SAN? And what is your approach to backups?
>
> Peter Geoghegan
> (Sent from my phone)

It's locally attached storage:

2x NVMe installed in the server
on them mdadm RAID1
on that LUKS full disk encryption
on that ext4

please note that exactly the same storage / partition holds also MySQL
and Sphinxsearch databases - all those run at the same server, under
different users. all of them [ PG, MySQL, Sphinx ] are under heavy
read traffic and update traffic comparable to one described above for
postgresql - there are no consistency issues in Sphinx, MySQL
databases.

postgresql backups are done with pg_dumpall every 24h, we also use
streaming replication so servers where inconsistencies were found are
also masters for 5 replicas.

--
regards,
Pawel Kudzia

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2021-07-26 03:31:32 Re: BUG #17122: panic on prepare with subsequent pg_advisory_lock() and pg_advisory_xact_lock_shared()
Previous Message Peter Geoghegan 2021-07-25 20:27:42 Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows