Tom Lane <tgl@sss.pgh.pa.us> writes:
> Ian Lance Taylor <ian@airs.com> writes:
> > I described myself unclearly. I was suggesting an addition to what
> > you are suggesting. The worst case can not be worse.
>
> Then I didn't (and still don't) understand your suggestion. Want to
> try again?
Your suggestion requires an obligatory fsync at an occasional
transaction start.
I was observing that in most cases, that fsync is not needed. It can
be avoided with a bit of additional bookkeeping.
I was assuming, incorrectly, that you would not want to allocate that
many XIDs at once. If you allocate 1000s of XIDs at once, the
obligatory fsync is not that bad, and my suggestion should be ignored.
> > If you are going to allocate a few thousand XIDs each time, then I
> > agree that my suggested addition is not worth it. But how do you deal
> > with XID wraparound on an unstable system?
>
> About the same as we do now: not very well. But if your system is that
> unstable, XID wrap is the least of your worries, I think.
>
> Up through 7.0, Postgres allocated XIDs a thousand at a time, and not
> only did the not-yet-used XIDs get lost in a crash, they'd get lost in
> a normal shutdown too. What I propose will waste XIDs in a crash but
> not in a normal shutdown, so it's still an improvement over prior
> versions as far as XID consumption goes.
I find this somewhat troubling, since I like to think in terms of
long-running systems--like, decades. But I guess it's OK (for me) if
it is fixed in the next couple of years.
Ian
