Re: Detecting File Damage & Inconsistencies

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: Detecting File Damage & Inconsistencies
Дата
Msg-id CAD21AoD70XaLFfmptAacpw4=Vi=T15j864Q0ybF5NWq+xjWg+Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Detecting File Damage & Inconsistencies  (Simon Riggs <simon@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: New IndexAM API controlling index vacuum strategies
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: VACUUM (DISABLE_PAGE_SKIPPING on)