Re: Transaction ID wraparound: problem and proposed solution
От | Hannu Krosing |
---|---|
Тема | Re: Transaction ID wraparound: problem and proposed solution |
Дата | |
Msg-id | 3A05651D.47B18E2F@tm.ee обсуждение исходный текст |
Ответ на | Re: Transaction ID wraparound: problem and proposed solution (Philip Warner <pjw@rhyme.com.au>) |
Ответы |
Re: Transaction ID wraparound: problem and proposed solution
|
Список | pgsql-hackers |
Tom Lane wrote: > > Philip Warner <pjw@rhyme.com.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
В списке pgsql-hackers по дате отправления: