Re: Transaction ID wraparound: problem and proposed solution

At 17:47 3/11/00 -0500, Tom Lane wrote:
>* portability --- I don't believe long long int exists on all the
>platforms we support.

Are you sure of this, or is it just a 'last time I looked' statement. If
the latter, it might be worth verifying.

>* performance --- except on true 64-bit platforms, widening Datum to
>eight bytes would be a system-wide performance hit,

Yes, OIDs are used a lot, but it's not that bad, is it? Are there many
tight loops with thousands of OID-only operations? I'd guess it's only one
more instruction & memory fetch.

>* disk space --- letting pg_log grow without bound isn't a pleasant
>prospect either.

Maybe this can be achieved by wrapping XID for the log file only.

>I believe it is possible to fix these problems without widening XID,
>by redefining XIDs in a way that allows for wraparound. Here's my
>plan:

It's a cute idea (elegant, even), but maybe we'd be running through hoops
just for a minor performance gain (which may not exist, since we're adding
extra comparisons via the macro) and for possible unsupported OSs. Perhaps
OS's without 8 byte ints have to suffer a performance hit (ie. we declare a
struct with appropriate macros).

>are no longer simply "x < y", but need to be expressed as a macro.
>We consider x < y if (y - x) % WRAPLIMIT < WRAPLIMIT/2.

You mean you plan to limit PGSQL to only 1G concurrent transactions. Isn't
that a bit short sighted? ;-}

>2. To keep the system from having to deal with XIDs that are more than
>WRAPLIMIT/2 transactions old, VACUUM should "freeze" known-good old
>tuples.

This is a problem for me; it seems to enshrine VACUUM in perpetuity.

>4. With the wraparound behavior, pg_log will have a bounded size: it
>will never exceed WRAPLIMIT*2 bits = WRAPLIMIT/4 bytes. Since we will
>recycle pg_log entries every WRAPLIMIT xacts, during transaction start

Is there any was we can use this recycling technique with 8-byte XIDs?

Also, will there be a problem with backup programs that use XID to
determine newer records and apply/reapply changes?

>This scheme allows us to survive XID wraparound at the cost of slight
>additional complexity in ordered comparisons of XIDs (which is not a
>really performance-critical task AFAIK)

Maybe I'm really missing the amount of XID manipulation, but I'd be
surprised if 16-byte XIDs would slow things down much.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/