Re: walmethods.c/h are doing some strange things - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: walmethods.c/h are doing some strange things
Date
Msg-id b72eb948-a239-6467-6817-d70e5fa7d3d9@enterprisedb.com
Whole thread Raw
In response to walmethods.c/h are doing some strange things  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 02.09.22 17:52, Robert Haas wrote:
> Attached are a couple of hastily-written patches implementing this.
> There might be good arguments for more thoroughly renaming some of the
> things these patches touch, but I thought that doing any more renaming
> would make it less clear what the core of the change is, so I'm
> posting it like this for now. One thing I noticed while writing these
> patches is that the existing code isn't very clear about whether
> "Walfile" is supposed to be an abstraction for a pointer to the
> implementation-specific struct, or the struct itself. From looking at
> walmethods.h, you'd think it's a pointer to the struct, because we
> declare typedef void *Walfile. walmethods.c agrees, but receivelog.c
> takes a different view, declaring all of its variables as type
> "Walfile *". This doesn't cause a compiler error because void * is
> just as interchangeable with void ** as it is with DirectoryMethodFile
> * or TarMethodFile *, but I think it is clearly a mistake, and the
> approach I'm proposing here makes such mistakes more difficult to
> make.

This direction does make sense IMO.



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Add tracking of backend memory allocated to pg_stat_activity
Next
From: Peter Eisentraut
Date:
Subject: Re: Can we avoid chdir'ing in resolve_symlinks() ?