Re: pg_stat_database.checksum_failures vs shared relations

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org, Magnus Hagander <magnus(at)hagander(dot)net>, Julien Rouhaud <rjuju123(at)gmail(dot)com>
Subject: Re: pg_stat_database.checksum_failures vs shared relations
Date: 2025-03-27 16:06:45
Message-ID: CA+TgmoaGN9QHF_rSLE94Gi6+apC4EpkbYY4mVvr0WDH=M8LaoQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 27, 2025 at 11:58 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> So, today we have the weird situation that *some* checksum errors on shared
> relations get attributed to the current database (if they happen in a backend
> normally accessing a shared relation), whereas others get reported to the
> "shared relations" "database" (if they happen during a base backup). That
> seems ... not optimal.
>
> One question is whether we consider this a bug that should be backpatched.

I think it would be defensible if pg_basebackup reported all errors
with OID 0 and backend connections reported all errors with OID
MyDatabaseId, but it seems hard to justify having pg_basebackup take
care to report things using the correct database OID and individual
backend connections not take care to do the same thing. So I think
this is a bug. If fixing it in the back-branches is too annoying, I
think it would be reasonable to fix it only in master, but
back-patching seems OK too.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jianghua Yang 2025-03-27 16:09:59 Re: Use CLOCK_MONOTONIC_COARSE for instr_time when available
Previous Message Dean Rasheed 2025-03-27 16:03:21 Docs and tests for RLS policies applied by command type