Re: Detecting File Damage & Inconsistencies

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Detecting File Damage & Inconsistencies
Date: 2020-12-29 07:40:13
Message-ID: CAD21AoD70XaLFfmptAacpw4=Vi=T15j864Q0ybF5NWq+xjWg+Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Simon,

On Wed, Nov 18, 2020 at 2:14 AM Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> On Fri, 13 Nov 2020 at 11:24, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> >
> > On Fri, 13 Nov 2020 at 00:50, tsunakawa(dot)takay(at)fujitsu(dot)com
> > <tsunakawa(dot)takay(at)fujitsu(dot)com> wrote:
> > >
> > > From: Simon Riggs <simon(at)2ndquadrant(dot)com>
> > > > If a rogue user/process is suspected, this would allow you to identify
> > > > more easily the changes made by specific sessions/users.
> > >
> > > Isn't that kind of auditing a job of pgAudit or log_statement = mod? Or, does "more easily" mean that you find pgAudit complex to use and/or log_statement's overhead is big?
> >
> > Well, I designed pgaudit, so yes, I think pgaudit is useful.
> >
> > However, pgaudit works at the statement level, not the data level. So
> > using pgaudit to locate data rows that have changed is fairly hard.
> >
> > What I'm proposing is an option to add 16 bytes onto each COMMIT
> > record, which is considerably less than turning on full auditing in
> > pgaudit. This option would allow identifying data at the row level, so
> > you could for example find all rows changed by specific sessions.
> > Also, because it is stored in WAL it will show updates that might no
> > longer exist in the database because the changed row versions might
> > have been vacuumed away. So pgaudit will tell you that happened, but
> > having extra info in WAL is important also.
> >
> > So thank you for the question because it has allowed me to explain why
> > it is useful and important.
>
> Patch attached to implement "wal_sessioninfo" option.

You sent in your patch, wal_sessioninfo.v2.patch to pgsql-hackers on
Nov 18, but you did not post it to the next CommitFest[1]. If this
was intentional, then you need to take no action. However, if you
want your patch to be reviewed as part of the upcoming CommitFest,
then you need to add it yourself before 2021-01-01 AoE[2]. Thanks for
your contributions.

Regards,

[1] https://commitfest.postgresql.org/31/
[2] https://en.wikipedia.org/wiki/Anywhere_on_Earth

--
Masahiko Sawada
EnterpriseDB: https://www.enterprisedb.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2020-12-29 07:42:33 Re: VACUUM (DISABLE_PAGE_SKIPPING on)
Previous Message Peter Geoghegan 2020-12-29 07:20:44 Re: New IndexAM API controlling index vacuum strategies