Tom Lane <tgl@sss.pgh.pa.us> writes:
> Ian Lance Taylor <ian@airs.com> writes:
> > I think your example demonstrates something slightly different. I
> > think it demonstrates that Postgres must flush the XLOG entry to disk
> > before it flushes any buffer to disk which uses an XID which was just
> > allocated.
>
> That would be an alternative solution, but it's considerably more
> complex to implement and I'm not convinced it is more efficient.
>
> The above could result, worst case, in double the normal number of
> fsyncs --- each new transaction might need an fsync to dump its first
> few XLOG records (in addition to the fsync for its commit), if the
> shmem disk buffer traffic is not in your favor. This worst case is
> not even difficult to produce: consider a series of standalone
> transactions that each touch more than -B pages (-B = # of buffers).
>
> In contrast, syncing NEXTXID records will require exactly one extra
> fsync every few thousand transactions. That seems quite acceptable
> to me, and better than an fsync load that we can't predict. Perhaps
> the average case of fsync-on-buffer-flush would be better than that,
> or perhaps not, but the worst case is definitely far worse.
I described myself unclearly. I was suggesting an addition to what
you are suggesting. The worst case can not be worse.
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?
Ian
