On Fri, Jun 20, 2025 at 02:16:46PM -0500, Nathan Bossart wrote:
> On Fri, Jun 20, 2025 at 10:34:19AM +0900, Michael Paquier wrote:
>> However, Option 1) would be my go-to option for HEAD (as of v19
>> opening for business), but I think that we should harden the code more
>> than suggested and treat
On Fri, Jun 20, 2025 at 10:34:19AM +0900, Michael Paquier wrote:
> Hmm. I like the simplicity of option 2) for the purpose the back
> branches and the post-feature-freeze v18.
Yeah, let's do this for now.
> However, Option 1) would be my go-to option for HEAD (as of v19
> opening for business),
>> It's a bit odd that we have both `VacuumParams *params` and
>> `struct VacuumParams *params`.
Thanks for pointing that out, the attached new version fixed that.
>> I'd suggest just marking the VacuumParams *params with const...
I initially considered that approach. However, the current code p
On Fri, Jun 20, 2025 at 10:14 PM shihao zhong wrote:
>
> >> However, Option 1) would be my go-to option for HEAD ...
>
> Updated my patch to apply the same rules to all VacuumParams. Also I
> am seeing clusterParams as a pass reference, not sure if we should
> also change that to prevent future is
On Fri, Jun 20, 2025 at 9:34 AM Michael Paquier wrote:
>
> On Thu, Jun 19, 2025 at 03:30:26PM -0500, Nathan Bossart wrote:
> > After thinking about this some more, I'm wondering if it would be better to
> > pursue option (2) because it's a little less invasive (which is important
> > because this
>> However, Option 1) would be my go-to option for HEAD ...
Updated my patch to apply the same rules to all VacuumParams. Also I
am seeing clusterParams as a pass reference, not sure if we should
also change that to prevent future issues. But that should be another
patch.
vacuum_tables_options_4
On Thu, Jun 19, 2025 at 03:30:26PM -0500, Nathan Bossart wrote:
> After thinking about this some more, I'm wondering if it would be better to
> pursue option (2) because it's a little less invasive (which is important
> because this will need to be back-patched). In any case, we have a similar
> p
On Wed, Jun 18, 2025 at 02:48:16PM -0400, shihao zhong wrote:
>>> That leads me to think (1) might be the better option, although I'm not too
>>> wild about the subtlety of the fix.
>
> Thanks for your feedback. New patch is attached. I also updated the
> signature of do_analyze_rel for the same r
>> That leads me to think (1) might be the better option, although I'm not too
>> wild about the subtlety of the fix.
Thanks for your feedback. New patch is attached. I also updated the
signature of do_analyze_rel for the same reason.
On Wed, Jun 18, 2025 at 12:31 PM Nathan Bossart
wrote:
>
> On
On Wed, Jun 18, 2025 at 11:15:31AM -0400, shihao zhong wrote:
> I investigated the code and found a small bug with how we're passing
> the VacuumParams pointer.
>
> The call flow is
> ExecVacuum -> vacuum -> vacuum_rel
>
> The initial VaccumParams pointer is set in ExecVacuum
> In vacuum_rel, thi
Hi team,
One of our customers recently encountered an issue with PostgreSQL's
pg_cron and VACUUM ANALYZE. They had configured a table with
vacuum_truncate=false to prevent exclusive lock contention, assuming
this would apply globally. However, VACUUM ANALYZE executed across the
entire database doe
11 matches
Mail list logo
