Re: check point segments leakage ?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rod Taylor <pg(at)rbt(dot)ca>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, Gaetano Mendola <mendola(at)bigfoot(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: check point segments leakage ?
Date: 2004-07-22 02:01:21
Message-ID: 29032.1090461681@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> ...
>> Would that prevent VACUUM from doing its work? It should be able to
>> check the last startup xid to check that isn't the case, but suppose a
>> backend had exited without taking down the postmaster.

There is no such thing as a backend crashing without the postmaster
noticing (at least not unless your kernel is seriously broken).

It is entirely possible for a backend not to log xact commit or abort,
though --- in fact I think that is the normal case for a read-only
transaction (no point in writing a clog entry if no one will ever
consult it, eh?). This is not unsafe because the actual logic for
such things is:

1. Transaction still running? (check shared memory PGPROC array to
see if any backend claims to be running it)

2. Transaction committed or aborted according to pg_clog?

3. If none of the above, it must have crashed --- mark it aborted in
pg_clog.

Also, VACUUM's pruning logic does not depend at all on whether individual
transactions are still running or not. The issue there is the oldest
xid that is still shown as running in the shared-memory PGPROC array.
AFAIK this is highly reliable.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2004-07-22 02:03:05 Re: Sorting out acl fixes
Previous Message Mark Kirkwood 2004-07-22 01:51:04 Re: [HACKERS] Point in Time Recovery