Thread: pgsql: Track the current XID wrap limit (or more accurately, the oldest
pgsql: Track the current XID wrap limit (or more accurately, the oldest
From
tgl@postgresql.org (Tom Lane)
Date:
Log Message:
-----------
Track the current XID wrap limit (or more accurately, the oldest unfrozen
XID) in checkpoint records. This eliminates the need to recompute the value
from scratch during database startup, which is one of the two remaining
reasons for the flatfile code to exist. It should also simplify life for
hot-standby operation.
To avoid bloating the checkpoint records unreasonably, I switched from
tracking the oldest database by name to tracking it by OID. This turns
out to save cycles in general (everywhere but the warning-generating
paths, which we hardly care about) and also helps us deal with the case
that the oldest database got dropped instead of being vacuumed. The prior
coding might go for a long time without updating the wrap limit in that case,
which is bad because it might result in a lot of useless autovacuum activity.
Modified Files:
--------------
pgsql/src/backend/access/transam:
varsup.c (r1.84 -> r1.85)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/varsup.c?r1=1.84&r2=1.85)
xlog.c (r1.349 -> r1.350)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlog.c?r1=1.349&r2=1.350)
pgsql/src/backend/commands:
vacuum.c (r1.390 -> r1.391)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/vacuum.c?r1=1.390&r2=1.391)
pgsql/src/backend/utils/init:
flatfiles.c (r1.38 -> r1.39)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/init/flatfiles.c?r1=1.38&r2=1.39)
pgsql/src/backend/utils/misc:
guc.c (r1.512 -> r1.513)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.512&r2=1.513)
pgsql/src/bin/pg_controldata:
pg_controldata.c (r1.43 -> r1.44)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_controldata/pg_controldata.c?r1=1.43&r2=1.44)
pgsql/src/bin/pg_resetxlog:
pg_resetxlog.c (r1.74 -> r1.75)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_resetxlog/pg_resetxlog.c?r1=1.74&r2=1.75)
pgsql/src/include/access:
transam.h (r1.68 -> r1.69)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/transam.h?r1=1.68&r2=1.69)
pgsql/src/include/catalog:
pg_control.h (r1.43 -> r1.44)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_control.h?r1=1.43&r2=1.44)
Re: pgsql: Track the current XID wrap limit (or more accurately, the oldest
From
Heikki Linnakangas
Date:
Tom Lane wrote: > Log Message: > ----------- > Track the current XID wrap limit (or more accurately, the oldest unfrozen > XID) in checkpoint records. This eliminates the need to recompute the value > from scratch during database startup, which is one of the two remaining > reasons for the flatfile code to exist. 1. Cluster is close to the stop limit. 2. Autovacuum runs, updates pg_database and advances oldestXid. Phew! 3. Crash. After recovery, oldestXid is reset to the old value, and you start getting warnings again. However, everything seems fine in pg_database, all the databases have been recently vacuumed. Does autovacuum ever run to fix that? ISTM it won't. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> 1. Cluster is close to the stop limit.
> 2. Autovacuum runs, updates pg_database and advances oldestXid. Phew!
> 3. Crash.
> After recovery, oldestXid is reset to the old value, and you start
> getting warnings again. However, everything seems fine in pg_database,
> all the databases have been recently vacuumed. Does autovacuum ever run
> to fix that? ISTM it won't.
Autovacuum will certainly run, it's more a question of will it fix
oldestXid. I think we could deal with this by having the just-added
function TransactionIdLimitIsValid() return false if the oldestXid is
far enough back to cause warnings.
(Probably that wasn't the best choice of name, since we now have some
cases where the XID limit data isn't really "invalid" but we want to
force an update anyway. I'm inclined to rename it to something like
ForceTransactionIdLimitUpdate, with inversion of the result sense.)
regards, tom lane