Re: commit_delay, siblings

From: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: commit_delay, siblings
Date: 2005-06-23 08:11:16
Message-ID: d9dqv9$2eg3$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes
>
>
> together with some kind of IPC to waken backends once xlog was flushed
> past the point they needed. (Designing that is the hard part.)
>

I think we could use ProcSendSignal()/ProcWaitForSignal() mechanism to cope
with the problem, because they won't lost any wake-ups.

So there will be a MaxBackend sized shared memory arrary with each cell is a

XLogRecPtr recptr; /* record request */
bool status; /* execution results */

structure. The initial value of the cell is <(0, 0), *doesn't matter*>.
Also, we need a spinlock to protect "recptr" value since it is not a
sig_atomic_t value.

A backend requests a xlogflush will do:
spinlock_acquire;
fill in the XLogRecPtr value;
spinlock_release;
ProcWaitForSignal();
After waken up, it will examine the "status" value and acts accordingly.

The xlog-writer is the only one who does real xlog write in postmaster mode.
It does not work in standalone mode or recovery mode. It works based on a
periodical loop + waken up when the xlog buffer is 70% full. A cancel/die
interrupts could happen during wait, so we will plug in a
ProcCancelWaitForSignal() at AbortTransaction() or error handling in
xlog-writer loop. There also could be various error conditions in its life.
Any error happened during xlogflush will be PANIC. Some small errors in the
loop will be hopefully recoverable. If everything is good, it would scan the
arrary, for each cell do:

spinlock_acquire;
make a local copy of XLogRecPtr;
spinlock_release;

if (recptr is (0, 0))
nothing to do; /* no request at all */

if (recptr is satisfied)
set XLogRecPtr to (0, 0);
status = true; /* successfully done */
ProcSendSignal(targetbackendid);
else
check if the recptr is passed the end of xlog file, if so
set XLogRecPtr to (0, 0);
set status = false; /* bad request */
ProcSendSignal(targetbackendid);

I am not sure how to check bad recptr. Currently we could do this by
comparing request and real flush point after xlogwrite(request). However,
seems this is not a solution for the xlog writer case.

Regards,
Qingqing

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message laser 2005-06-23 08:13:24 Re: Strange logic for partial index proving
Previous Message Oleg Bartunov 2005-06-23 07:05:14 Re: GiST rtree logic is not right