Re: WAL-based allocation of XIDs is insecure

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> After thinking about this for a little, it seems to me that XID
> assignment should be handled more like OID assignment: rather than
> handing out XIDs one-at-a-time, varsup.c should allocate them in blocks,
> and should write an XLOG record to reflect the allocation of each block
> of XIDs. Furthermore, the above example demonstrates that *we must
> flush that XLOG entry to disk* before we can start to actually hand out
> the XIDs. This ensures that the next system cycle won't re-use any XIDs
> that may have been in use at the time of a crash.

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.

For each buffer, heap_update could record the last XID stored into
that buffer. When a buffer is forced out to disk, Postgres could make
sure that the XLOG entry which uses the XID is previously forced out
to disk.

A simpler and less accurate approach: when any dirty buffer is forced
to disk in order to allocate a buffer, make sure that any XLOG entry
which allocates new XIDs is flushed to disk first.

I don't know if these are better. I raise them because you are
suggesting putting an occasional fsync at transaction start to avoid
an unlikely scenario. A bit of bookkeeping can be used instead to
notice the unlikely scenario when it occurs.

Ian