Re: BUG #13970: Vacuum hangs on particular table; cannot be terminated - requires `kill -QUIT pid` - Mailing list pgsql-bugs

From Brian Ghidinelli
Subject Re: BUG #13970: Vacuum hangs on particular table; cannot be terminated - requires `kill -QUIT pid`
Date
Msg-id C3F15AAD-8CFE-40C2-833B-C02624230DBE@vfive.com
Whole thread Raw
In response to Re: BUG #13970: Vacuum hangs on particular table; cannot be terminated - requires `kill -QUIT pid`  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: BUG #13970: Vacuum hangs on particular table; cannot be terminated - requires `kill -QUIT pid`
List pgsql-bugs
> On Mar 7, 2016, at 08:21, Alvaro Herrera <alvherre@2ndquadrant.com> =
wrote:
>=20
> Brian Ghidinelli wrote:
>> Any chance that a DDL modification like adding a column would effect =
an update of those values across the table?
>=20
> If a column is added without a default value, then the existing tuples
> are not touched.  If a default value is added, then the complete table
> is rewritten.  I suppose that the rewritten table would not include =
old
> Multixact values in XMAX, but I haven't checked.
>=20
> I wonder if it's possible for a column to be added in an operation =
that
> does not rewrite the table yet the relminmxid is advanced past the
> oldest multixact present.
>=20
> I assume, given the lack of traffic in this thread, that you have =
solved
> your problem already?

Thanks for the follow up Alvaro. I=E2=80=99m no longer on the bugs list =
so don=E2=80=99t know if this will make it through, but I went the route =
of recreating the table and updating all of the foreign key references =
and shared that on Feb 19th.=20

This seems to have fixed the problem with vacuuming the table however it =
did not update the multixact value which still reads 1. Any idea if this =
will still cause problems in the future?

# /usr/pgsql-9.4/bin/pg_controldata ~postgres/9.4/=20
pg_control version number:            942
Catalog version number:               201409291
Database system identifier:           6123001933830237052
Database cluster state:               in production
pg_control last modified:             Sat 12 Mar 2016 01:57:08 PM PST
Latest checkpoint location:           13A/54469E58
Prior checkpoint location:            13A/54129CC8
Latest checkpoint's REDO location:    13A/543F2908
Latest checkpoint's REDO WAL file:    000000010000013A00000054
Latest checkpoint's TimeLineID:       1
Latest checkpoint's PrevTimeLineID:   1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:          0/92143770
Latest checkpoint's NextOID:          5609664
Latest checkpoint's NextMultiXactId:  84435
Latest checkpoint's NextMultiOffset:  167731
Latest checkpoint's oldestXID:        654
Latest checkpoint's oldestXID's DB:   16416
Latest checkpoint's oldestActiveXID:  92143770
Latest checkpoint's oldestMultiXid:   1
Latest checkpoint's oldestMulti's DB: 16416
Time of latest checkpoint:            Sat 12 Mar 2016 01:56:19 PM PST




Brian

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #14017: strange syntax error
Next
From: Alexander Spiteri
Date:
Subject: Re: BUG #14009: pg_restore not restoring privilegs when one login/group role is missing