pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
Does raising maintenance_work_mem get seen by an already running aucovac?
3+ messages / 2 participants
[nested] [flat]

* Does raising maintenance_work_mem get seen by an already running aucovac?
@ 2023-01-25 17:50  Jerry Sievers <gsievers19@comcast.net>
  0 siblings, 1 reply; 3+ messages in thread

From: Jerry Sievers @ 2023-01-25 17:50 UTC (permalink / raw)
  To: pgsql-admin@lists.postgresql.org

Groovy admins,

This is on Pg11 (shameful, I know !).

There's a long running anti-wrap autovac that we'd rather let finish but
on the server instance, I found maintenance_work_mem rather low and thus
raised it in postgresql.comf, reloaded and confirmed that my interactive
session saw the change.

Can a running autovac make use of this or should I either wait it out or
cancel and let it restart when ready?

The vacuum progress view shows that it's finished the heap and I guess
toast, but is now working through the indexes.

Thx





^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re: Does raising maintenance_work_mem get seen by an already running aucovac?
@ 2023-01-25 21:36  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Jerry Sievers <gsievers19@comcast.net>
  0 siblings, 1 reply; 3+ messages in thread

From: Tom Lane @ 2023-01-25 21:36 UTC (permalink / raw)
  To: Jerry Sievers <gsievers19@comcast.net>; +Cc: pgsql-admin@lists.postgresql.org

Jerry Sievers <gsievers19@comcast.net> writes:
> There's a long running anti-wrap autovac that we'd rather let finish but
> on the server instance, I found maintenance_work_mem rather low and thus
> raised it in postgresql.comf, reloaded and confirmed that my interactive
> session saw the change.

> Can a running autovac make use of this or should I either wait it out or
> cancel and let it restart when ready?

Looks like an autovac worker will notice postgresql.conf changes once
per table:

    /*
     * Perform operations on collected tables.
     */
    foreach(cell, table_oids)
    {
        ...

        /*
         * Check for config changes before processing each collected table.
         */
        if (ConfigReloadPending)
            ProcessConfigFile(PGC_SIGHUP);

If it is stuck on a particularly enormous table, you might be best off
to kill it, but otherwise I'd let it go.

			regards, tom lane





^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re: Does raising maintenance_work_mem get seen by an already running aucovac?
@ 2023-01-25 23:28  Jerry Sievers <gsievers19@comcast.net>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 3+ messages in thread

From: Jerry Sievers @ 2023-01-25 23:28 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-admin@lists.postgresql.org

Tom Lane <tgl@sss.pgh.pa.us> writes:

> Jerry Sievers <gsievers19@comcast.net> writes:
>
>> There's a long running anti-wrap autovac that we'd rather let finish but
>> on the server instance, I found maintenance_work_mem rather low and thus
>> raised it in postgresql.comf, reloaded and confirmed that my interactive
>> session saw the change.
>
>> Can a running autovac make use of this or should I either wait it out or
>> cancel and let it restart when ready?
>
> Looks like an autovac worker will notice postgresql.conf changes once
> per table:
>
>     /*
>      * Perform operations on collected tables.
>      */
>     foreach(cell, table_oids)
>     {
>         ...
>
>         /*
>          * Check for config changes before processing each collected table.
>          */
>         if (ConfigReloadPending)
>             ProcessConfigFile(PGC_SIGHUP);
>
> If it is stuck on a particularly enormous table, you might be best off
> to kill it, but otherwise I'd let it go.
>
> 			regards, tom lane

Thanks Tom!

That's the situation, the >1TB table is just chugging along.

So, a live individual vacuum of a particulart table will not start using
more mwm but later tasks will.

In fact, the existing setting which I believed too small probably does
exceed the 1G limit of some kind that's explained in the docs and ps
shows that process having about 1G of memory allocated, so perhaps the
frobbling wasn't too useful a fix.

Ack'd

I'll keep an eye on things.





^ permalink  raw  reply  [nested|flat] 3+ messages in thread


end of thread, other threads:[~2023-01-25 23:28 UTC | newest]

Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-01-25 17:50 Does raising maintenance_work_mem get seen by an already running aucovac? Jerry Sievers <gsievers19@comcast.net>
2023-01-25 21:36 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-01-25 23:28   ` Jerry Sievers <gsievers19@comcast.net>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox