From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Philip Warner <pjw(at)rhyme(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Transaction ID wraparound: problem and proposed solution |
Date: | 2000-11-05 13:48:13 |
Message-ID: | 3A05651D.47B18E2F@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
One simple way - start a new pg_log file at each wraparound and encode
the high 4 bytes in the filename (or in first four bytes of file)
> > 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.
Do you mean that each _field_ will take more space, not each _record_ ?
> 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...
The pg_log should be rotated anyway either with long xids or long-long
xids.
-----------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2000-11-05 14:00:31 | Re: Transaction ID wraparound: problem and proposed solution |
Previous Message | Peter Eisentraut | 2000-11-05 13:08:29 | Re: Summary: what to do about INET/CIDR |