Re: pg_walinspect - a new extension to get raw WAL data and WAL stats
От | Bharath Rupireddy |
---|---|
Тема | Re: pg_walinspect - a new extension to get raw WAL data and WAL stats |
Дата | |
Msg-id | CALj2ACXPncnUSS-k0g-9Amo5_jDn-pyG9oT4d+roPjXAkTZyFA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_walinspect - a new extension to get raw WAL data and WAL stats (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Wed, Feb 16, 2022 at 1:57 AM Robert Haas <robertmhaas@gmail.com> wrote: > > 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. Agreed, I will remove pg_verify_raw_wal_record function in the next version of the patch set. Thanks. Regards, Bharath Rupireddy.
В списке pgsql-hackers по дате отправления: