Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group