Re: pg_walinspect - a new extension to get raw WAL data and WAL stats

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Ashutosh Sharma <ashu.coek88@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, Greg Stark <stark@mit.edu>, Jeremy Schneider <schneider@ardentperf.com>, Bruce Momjian <bruce@momjian.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>, marvin_liang@qq.com, actyzhang@outlook.com
Date: 2022-02-15T20:27:43Z
Lists: pgsql-hackers
On Tue, Feb 15, 2022 at 2:31 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
> > +/*
> > + * Verify the authenticity of the given raw WAL record.
> > + */
> > +Datum
> > +pg_verify_raw_wal_record(PG_FUNCTION_ARGS)
> > +{
> >
> >
> > Do we really need this function? I see that whenever the record is
> > read, we verify it. So could there be a scenario where any of these
> > functions would return an invalid WAL record?
>
> Yes, this function can be useful. Imagine a case where raw WAL records
> are fetched from one server using pg_get_wal_record_info and sent over
> the network to another server (for fixing some of the corrupted data
> pages or for whatever reasons), using pg_verify_raw_wal_record one can
> verify authenticity.

As I also said before, and so did Greg, I think giving the user a way
to supply WAL records that we will then try to decode is never going
to be OK. It's going to be a recipe for security bugs and crash bugs,
and there's no compelling use case for it that I can see. I support
this patch set only to the extent that it decodes locally generated
WAL read directly from the WAL stream.

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



Commits

  1. Doc build fix: remove tab from filelist.sgml.

  2. Add contrib/pg_walinspect.

  3. Simplify SRFs using materialize mode in contrib/ modules

  4. Invent "trusted" extensions, and remove the pg_pltemplate catalog.