Re: WAL-based allocation of XIDs is insecure

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