On Thu, Mar 20, 2025 at 11:13 AM Nathan Bossart
wrote:
>
> How does something like this look for the comment?
>
> /*
> * isset_offset is an optional offset of a field in the result
> struct
> * that stores whether the value is explicitly set for the
> relation or
>
On Thu, Mar 20, 2025 at 8:18 AM Nathan Bossart
wrote:
> Committed.
>
>
We added isset_offset to the public struct to introduce this new general
behavior of tracking whether any table reloption has been set (not just
vacuum_truncate) without any comments.
I get the need for this kind of logic, si
On Thu, Mar 20, 2025 at 02:18:33PM -0700, David G. Johnston wrote:
> So my concern about dump/restore seems to be alleviated but then, why can
> we not just do whatever pg_dump is doing to decide whether the current
> value for vacuum_truncate is its default (and thus would not be dumped) or
> not
On Thu, Mar 20, 2025 at 09:59:45AM -0700, David G. Johnston wrote:
> I get the need for this kind of logic, since we used a boolean for the
> table option, but as a self-proclaimed hack it seems worth more comments
> than provided here. Especially pertaining to whether this is indeed
> generic or
On Fri, Mar 21, 2025 at 08:54:55AM -0700, David G. Johnston wrote:
> I'm still partial to mine but yours probably fits the overall style of the
> codebase better.
Committed with some light edits.
--
nathan
On Thu, Mar 20, 2025 at 2:31 PM Nathan Bossart
wrote:
> On Thu, Mar 20, 2025 at 02:18:33PM -0700, David G. Johnston wrote:
> > So my concern about dump/restore seems to be alleviated but then, why can
> > we not just do whatever pg_dump is doing to decide whether the current
> > value for vacuum_
On Thu, Mar 20, 2025 at 11:13 AM Nathan Bossart
wrote:
> On Thu, Mar 20, 2025 at 09:59:45AM -0700, David G. Johnston wrote:
> > I get the need for this kind of logic, since we used a boolean for the
> > table option, but as a self-proclaimed hack it seems worth more comments
> > than provided her
Committed.
--
nathan
On Wed, Mar 19, 2025 at 10:40:31AM -0500, Nathan Bossart wrote:
> On Thu, Mar 20, 2025 at 12:34:59AM +0900, Fujii Masao wrote:
>> +# - Default Behavior -
>> +
>> +#vacuum_truncate = on # enable truncation after vacuum
>>
>> Since there's no existing GUC category that fits to
On 2025/03/19 10:42, Nathan Bossart wrote:
On Mon, Mar 17, 2025 at 10:14:51AM -0500, Nathan Bossart wrote:
Thank you all for the discussion. I've attempted to address the
outstanding feedback into the new version of the patch.
Here is a new version of the patch with tests and some other li
On Thu, Mar 20, 2025 at 12:34:59AM +0900, Fujii Masao wrote:
> +# - Default Behavior -
> +
> +#vacuum_truncate = on# enable truncation after vacuum
>
> Since there's no existing GUC category that fits to vacuum_truncate,
> I'm fine with adding a new category like "Vacuuming
On Mon, Mar 17, 2025 at 10:14:51AM -0500, Nathan Bossart wrote:
> Thank you all for the discussion. I've attempted to address the
> outstanding feedback into the new version of the patch.
Here is a new version of the patch with tests and some other light edits.
I feel like this is committable, bu
On Sun, Mar 16, 2025 at 06:24:59PM -0400, Robert Treat wrote:
> So if the general idea is a guc "vacuum_truncate" which sets a global
> default for whether vacuums and autovacuums should do truncation, and
> we then have the storage parameter which would override the global
> setting. And to be cle
On Sun, Mar 16, 2025 at 1:29 AM Laurenz Albe wrote:
>
> On Sat, 2025-03-15 at 17:14 -0700, Gurjeet Singh wrote:
> > > One other difference in my version of the patch [0] is to call this GUC
> > > vacuum_truncate and have it apply to both autovacuum and VACUUM. I did
> > > this for the following r
On Sat, 2025-03-15 at 17:14 -0700, Gurjeet Singh wrote:
> > One other difference in my version of the patch [0] is to call this GUC
> > vacuum_truncate and have it apply to both autovacuum and VACUUM. I did
> > this for the following reasons:
>
> +1 for the GUC name for the reasons you identified
+Andres Freund, since an old email of his is quoted here.
On Fri, Mar 14, 2025 at 8:45 AM Nathan Bossart wrote:
>
> On Thu, Mar 06, 2025 at 08:54:59AM +0900, Fujii Masao wrote:
> > +1 to having the reloption (if specified) override the GUC setting.
> > That is, I think that autovacuum_vacuum_trun
On Fri, 2025-03-14 at 10:42 -0500, Nathan Bossart wrote:
> One other difference in my version of the patch [0] is to call this GUC
> vacuum_truncate and have it apply to both autovacuum and VACUUM.
I agree that that is the way to go.
It makes no sense to restrict the feature to autovacuum.
Yours,
On 2025/03/15 0:42, Nathan Bossart wrote:
I should also mention that we just have a few weeks left in the v18
development cycle. The code itself seems pretty straightforward, so if we
can agree on behavior and nomenclature, I'll do my darndest to get this
responsibly committed in time.
+1
On Thu, Mar 06, 2025 at 08:54:59AM +0900, Fujii Masao wrote:
> +1 to having the reloption (if specified) override the GUC setting.
> That is, I think that autovacuum_vacuum_truncate as defining
> the default behavior for VACUUM truncation, and that the GUC should
> only apply when neither the TRUNC
On 2025/03/01 3:21, Nathan Bossart wrote:
On Thu, Feb 27, 2025 at 08:29:16PM -0800, Gurjeet Singh wrote:
On Mon, Jan 27, 2025 at 1:55 AM Laurenz Albe wrote:
I hope it is possible to override the global setting with the "vacuum_truncate"
option on an individual table.
Current patch behavio
On Thu, Feb 27, 2025 at 08:29:16PM -0800, Gurjeet Singh wrote:
> On Mon, Jan 27, 2025 at 1:55 AM Laurenz Albe wrote:
>> I hope it is possible to override the global setting with the
>> "vacuum_truncate"
>> option on an individual table.
>
> Current patch behaviour is that if the autovacuum_vacuu
On Thu, 2025-02-27 at 21:35 -0600, Nathan Bossart wrote:
> I spent some time on this one today. A couple of notes:
>
> * Since the reloption is a Boolean, there isn't a good way to tell whether
> it is actually set for the table or if it just inherited the default
> value. This is important
On Mon, Jan 27, 2025 at 1:55 AM Laurenz Albe wrote:
>
> On Thu, 2025-01-23 at 22:33 -0800, Gurjeet Singh wrote:
> > > > I am also wondering if having an autovacuum setting to control it would
> > > > be
> > > > a good idea for a feature.
> > >
> > > I'm all for that.
> >
> > Please see attached a
On Tue, Feb 18, 2025 at 01:56:09PM -0600, Nathan Bossart wrote:
> On Mon, Jan 27, 2025 at 03:38:39PM -0500, Robert Haas wrote:
>> Also, how sure are we that turning this off globally is a solid idea?
>> Off-hand, it doesn't sound that bad: there are probably situations in
>> which autovacuum never
On Mon, Jan 27, 2025 at 03:38:39PM -0500, Robert Haas wrote:
> Also, how sure are we that turning this off globally is a solid idea?
> Off-hand, it doesn't sound that bad: there are probably situations in
> which autovacuum never truncates anything anyway just because the tail
> blocks of the relat
On Mon, Jan 27, 2025 at 4:55 AM Laurenz Albe wrote:
> My suggestion for the parameter name is "autovacuum_disable_truncate".
Then it would have a different name than the reloption, and the
opposite sense. In most cases, we've been able to keep those matching
-- autovacuum vs. autovacuum_enabled b
On Thu, 2025-01-23 at 22:33 -0800, Gurjeet Singh wrote:
> > > I am also wondering if having an autovacuum setting to control it would be
> > > a good idea for a feature.
> >
> > I'm all for that.
>
> Please see attached an initial patch to disable truncation behaviour in
> autovacuum. This patch
(moving discussion to -hackers, for patch-review)
On Mon, Dec 16, 2024 at 11:30 PM Laurenz Albe wrote:
>
> On Mon, 2024-12-16 at 16:25 -0800, Will Storey wrote:
> > I would like to disable vacuum's truncate behaviour for autovacuum.
> > Previously I had an outage due to its access exclusive lock
28 matches
Mail list logo
