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

On Mon, Jan 31, 2022 at 4:40 PM Greg Stark <stark(at)mit(dot)edu> wrote:
> So I looked at this patch and I have the same basic question as Bruce.
> Do we really want to expose every binary tool associated with Postgres
> as an extension? Obviously this is tempting for cloud provider users
> which is not an unreasonable argument. But it does have consequences.
>
> 1) Some things like pg_waldump are running code that is not normally
> under user control. This could have security issues or reliability
> issues.

For what it's worth, I am generally in favor of having something like
this in PostgreSQL. I think it's wrong of us to continue assuming that
everyone has command-line access. Even when that's true, it's not
necessarily convenient. If you choose to use a relational database,
you may be the sort of person who likes SQL. And if you are, you may
want to have the database tell you what's going on via SQL rather than
command-line tools or operating system utilities. Imagine if we didn't
have pg_stat_activity and you had to get that information by running a
separate binary. Would anyone like that? Why is this case any
different?

A few years ago we exposed data from pg_control via SQL and similar
concerns were raised - but it turns out to be pretty useful. I don't
know why this shouldn't be equally useful. Sure, there's some
duplication in functionality, but it's not a huge maintenance burden
for the project, and people (including me) like having it available. I
think the same things will be true here.

If decoding WAL causes security problems, that's something we better
fix, because WAL is constantly decoded on standbys and via logical
decoding on systems all over the place. I agree that we can't let
users supply their own hand-crafted WAL records to be decoded without
causing more trouble than we can handle, but if it's not safe to
decode the WAL the system generated than we are in a lot of trouble
already.

I hasten to say that I'm not endorsing every detail or indeed any
detail of the proposed patch, and some of the concerns you mention
later sound well-founded to me. But I disagree with the idea that we
shouldn't have both a command-line utility that roots through files on
disk and an SQL interface that works with a running system.

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