Hi,
On 2018-10-19 10:36:59 -0400, Stephen Frost wrote:
> * Michael Paquier (michael@paquier.xyz) wrote:
> > On Wed, Oct 17, 2018 at 05:30:05PM -0400, Andrew Dunstan wrote:
> > > Fine by me.
> >
> > Thanks. This is now committed after some tweaks to the comments, a bit
> > earlier than I thought first.
>
> I just saw this committed and I'm trying to figure out why we are
> creating yet-another-list when it comes to deciding what should be
> checksum'd and what shouldn't be.
I'm not sure it's fair to blame Michael here. He's picking up slack,
because the original authors of the tool didn't even bother to reply to
the issue for quite a while. pg_verify_checksum was obviously never
tested on windows, it just didn't have tests showing that.
> I also categorically disagree with the notion that it's ok for
> extensions to dump files into our tablespace diretories or that we
> should try to work around random code dumping extra files in the
> directories which we maintain- it's not like this additional code will
> actually protect us from that, after all, and it's foolish to think we
> really could protect against that.
I'm unconvinced. There already are extensions doing so, and it's not
like we've given them any sort of reasonable alternative. You can't just
create relations in a "registered" / "supported" kinda way right now, so
uh, yea, extension gotta make do. And that has worked for many years.
Also, as made obvious here, it's pretty clear that there's platform
differences about which files exists and which don't, so it's not that a
blacklist approach automatically is more maintainable.
And I fail to see why a blacklist is architecturally better. There's
plenty cases where we might want to create temporary files,
non-checksummed data or such that we'd need a teach a blacklist about,
but there's far fewer cases where add new checksummed files. Basically
never since checksums have been introduced. And if checksums were
introduced for something new, say slrus, we'd ceertainly use
pg_verify_checksum during development.
Greetings,
Andres Freund
