Re: XLogFlush

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: XLogFlush
Date: 2009-08-21 14:18:51
Message-ID: 3371.1250864331@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> Maybe this is one of those things that is obvious when someone points
> it out to you, but right now I am not seeing it. If you look at the
> last eight lines of this snippet from XLogFlush, you see that if we
> obtain WriteRqstPtr under the WALInsertLock, then we both write and
> flush up to the highest write request. But if we obtain it under the
> info_lck, then we write up to the highest write request but flush only
> up to our own records flush request. Why the disparate treatment?

I think the point of the check within the info_lck section is that the
global Write pointer must not be allowed to go backward. It's likely
unnecessary though, since there is probably a defense against that
in XLogWrite (or if not there should be).

The other bit of the reasoning that doesn't seem well commented is
that if we can't find out what the global status is (because of failure
to acquire the insert lock), we should just do the work we know we need,
not guess at some greater requirement.

regards, tom lane

In response to

  • XLogFlush at 2009-08-21 08:18:46 from Jeff Janes

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-08-21 14:26:50 Re: GRANT ON ALL IN schema
Previous Message Martijn van Oosterhout 2009-08-21 14:07:03 Re: Geometric Elimination