Re: Transaction ID wraparound: problem and proposed solution - Mailing list pgsql-hackers

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   |/