| From: | Pavan Kumar <pavan(dot)dba27(at)gmail(dot)com> |
|---|---|
| To: | Sbob <sbob(at)quadratum-braccas(dot)com> |
| Cc: | pgsql-admin(at)lists(dot)postgresql(dot)org |
| Subject: | Re: vacuum process running for more than 2 days, still in scanning heap phase |
| Date: | 2025-11-12 18:59:36 |
| Message-ID: | CA+M0sHE3aEbH1ZyO_zczkEHM5tnQx1guv4nSoLpRmsdSbPwz1w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Hello Sbob,
try to use pg_repack. you need to install extension in the database.
SET maintenance_work_mem = '2GB';
VACUUM (VERBOSE, PARALLEL 4) my_table; >> adjust parallel based on your
CPU's
I hope this helps
On Wed, Nov 12, 2025 at 12:33 PM Sbob <sbob(at)quadratum-braccas(dot)com> wrote:
>
> On 11/12/25 11:26 AM, Álvaro Herrera wrote:
> > On 2025-Nov-12, Sbob wrote:
> >
> >> We have a vacuum process that has been running for 2 days, the table
> >> is 12GB in total size and vacuum_cost_delay is at 0
> > Is it autovacuum? Because if so, the autovacuum_vacuum_cost_delay
> > setting would be used instead of this one. Also check the table config
> > (\d+) in case there are autovacuum settings there, which could make
> > vacuum slower on this particular table.
> >
> > What PG version again?
> >
> > This is not autovacuum, we ran a vacuum freeze manyally
> >
> > Version 15
>
>
>
> >> heap_blks_total | 571437
> >> heap_blks_scanned | 344577
> >> heap_blks_vacuumed | 0
> >> index_vacuum_count | 0
> >> max_dead_tuples | 155388267
> >> num_dead_tuples | 199013
> > Yeah, this seems really slow. Maybe have a look at the wait events in
> > pg_stat_activity to see if you can figure out what is holding it back.
> pg_stat_activity shows no wait events and shows state as active
> >> We actually tried a pg_terminate_backend on it and it does not die
> > Hmm, maybe there's something going wrong with it. I've seen corrupted
> > btree indexes make a vacuum go into infinite loops because of loops in
> > the index structure. I would take a few backtraces with gdb or such.
> > Maybe if an index is corrupt in that way, it would also explain why it
> > doesn't interrupt.
>
>
> I'll give it a shot, thanks
>
>
>
>
>
>
--
*Regards,#! Pavan Kumar----------------------------------------------*-
*Sr. Database Administrator..!*
*NEXT GENERATION PROFESSIONALS, LLC*
*Cell # 267-799-3182 # pavan.dba27 (Gtalk) *
*India # 9000459083*
*Take Risks; if you win, you will be very happy. If you lose you will be
Wise *
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Álvaro Herrera | 2025-11-12 19:01:15 | Re: vacuum process running for more than 2 days, still in scanning heap phase |
| Previous Message | Sbob | 2025-11-12 18:33:00 | Re: vacuum process running for more than 2 days, still in scanning heap phase |