On Fri, 21 Mar 2025 at 04:30, Tom Lane wrote:
>
> Nathan Bossart writes:
> > Since there's presently no way to determine whether a Boolean
> > storage parameter is explicitly set or has just picked up the
> > default value, this commit also introduces an isset_offset member
> > to relopt_parse_el
Nathan Bossart writes:
> Since there's presently no way to determine whether a Boolean
> storage parameter is explicitly set or has just picked up the
> default value, this commit also introduces an isset_offset member
> to relopt_parse_elt.
Uh, what? Why is it a good idea to distinguish those s
On Sat, 22 Mar 2025 at 05:40, David G. Johnston
wrote:
> Not seeing much point in trying to get rid of the on/off switch. It just
> won't make sense to choose a tunable value of zero to disable something, and
> probably should be prohibited.
Can you explain what does not make sense about it?
On Thu, Mar 20, 2025 at 4:07 PM David Rowley wrote:
> On Fri, 21 Mar 2025 at 04:30, Tom Lane wrote:
> >
> > Nathan Bossart writes:
> > > Since there's presently no way to determine whether a Boolean
> > > storage parameter is explicitly set or has just picked up the
> > > default value, this co
Add vacuum_truncate configuration parameter.
This new parameter works just like the storage parameter of the
same name: if set to true (which is the default), autovacuum and
VACUUM attempt to truncate any empty pages at the end of the table.
It is primarily intended to help users avoid locking iss
On Thursday, March 20, 2025, Tom Lane wrote:
> Nathan Bossart writes:
> > Since there's presently no way to determine whether a Boolean
> > storage parameter is explicitly set or has just picked up the
> > default value, this commit also introduces an isset_offset member
> > to relopt_parse_elt.
