Re: Transaction ID wraparound: problem and proposed solution

Tom Lane wrote:
>
> Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> >> * 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.
>
> How's that going to improve matters? pg_log is ground truth for XIDs;
> if you can't distinguish two XIDs in pg_log, there's no point in
> distinguishing them elsewhere.
>
> > Maybe I'm really missing the amount of XID manipulation, but I'd be
> > surprised if 16-byte XIDs would slow things down much.
>
> It's not so much XIDs themselves, as that I think we'd need to widen
> typedef Datum too, and that affects manipulations of *all* data types.
>
> In any case, the prospect of a multi-gigabyte, ever-growing pg_log file,
> with no way to recover the space short of dump/initdb/reload, is
> awfully unappetizing for a high-traffic installation...

Agreed completely. I'd like to think I could have such an installation
in the next year or so :)

To prevent a performance hit to those who don't want, is there a
possibility of either a compile time option or 'auto-expanding' the
width of the XID's and other items when it becomes appropriate? Start
with int4, when that limit is hit goto int8, and should -- quite
unbelievibly so but there are multi-TB databases -- it be necessary jump
to int12 or int16? Be the first to support Exa-objects in an RDBMS.
Testing not necessary ;)

Compiletime option would be appropriate however if theres a significant
performance hit.

I'm not much of a c coder (obviously), so I don't know of the
limitations. plpgsql is my friend that can do nearly anything :)

Hmm... After reading the above I should have stuck with lurking.