Ian Lance Taylor <[EMAIL PROTECTED]> 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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
