Re: WAL-based allocation of XIDs is insecure

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ian Lance Taylor <ian(at)airs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: WAL-based allocation of XIDs is insecure
Date: 2001-03-05 20:02:36
Message-ID: 20451.983822556@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ian Lance Taylor <ian(at)airs(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ian Lance Taylor 2001-03-05 20:07:28 Re: WAL-based allocation of XIDs is insecure
Previous Message Tom Lane 2001-03-05 19:43:20 Re: How to handle waitingForLock in LockWaitCancel()