Re: Detecting File Damage & Inconsistencies - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Detecting File Damage & Inconsistencies
Date
Msg-id CAD21AoD70XaLFfmptAacpw4=Vi=T15j864Q0ybF5NWq+xjWg+Q@mail.gmail.com
Whole thread Raw
In response to Re: Detecting File Damage & Inconsistencies  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Hi Simon,

On Wed, Nov 18, 2020 at 2:14 AM Simon Riggs <simon@2ndquadrant.com> wrote:
>
> On Fri, 13 Nov 2020 at 11:24, Simon Riggs <simon@2ndquadrant.com> wrote:
> >
> > On Fri, 13 Nov 2020 at 00:50, tsunakawa.takay@fujitsu.com
> > <tsunakawa.takay@fujitsu.com> wrote:
> > >
> > > From: Simon Riggs <simon@2ndquadrant.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
pgAuditcomplex 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/



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: New IndexAM API controlling index vacuum strategies
Next
From: Masahiko Sawada
Date:
Subject: Re: VACUUM (DISABLE_PAGE_SKIPPING on)