Re: BUG #16461: Segfault in autovacuum process

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: mschanne(at)kns(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16461: Segfault in autovacuum process
Date: 2020-05-26 10:21:02
Message-ID: CAApHDvrj1ZcLwjDgRPXJS9qet8N7iAtkz-B4j8RBvGJBGh6vyA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, 26 May 2020 at 21:53, PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
> Core was generated by `postgres: autovacuum worker process postgres '.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x0000555c1183877b in pfree ()

> I attempted to reproduce the issue with a manual "ANALYZE" of the table in
> question, but it did not segfault again.

That does not really mean that autovacuum is to blame. Both
autovacuum analyze and manual ANALYZE just take random samples of rows
to include in the statistics. You may just not have hit the same rows
with the manual ANALYZE as autovacuum did.

I'd suggest checking that you can read all rows and columns from the
table without getting a crash.

So, providing you can tolerate another crash, you could do:

COPY myschema.mytable TO stdout;

If that crashes then it seems unlikely that what autovacuum is doing
is to blame for your issue. Or if the table is large then you might
want to try pg_dump.

> Please let me know if there is any additional information I can provide for
> this.

It would be good if you could report back to mention if the COPY
crashed the server again or if it worked without any error.

David

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Eisentraut 2020-05-26 10:44:25 Re:
Previous Message Andrey Klychkov 2020-05-26 09:49:32