Re: commit_delay, siblings

Поиск
Список
Период
Сортировка
От Qingqing Zhou
Тема Re: commit_delay, siblings
Дата
Msg-id d9dqv9$2eg3$1@news.hub.org
обсуждение исходный текст
Ответ на commit_delay, siblings  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.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





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Oleg Bartunov
Дата:
Сообщение: Re: GiST rtree logic is not right
Следующее
От: Richard Huxton
Дата:
Сообщение: Re: Strange logic for partial index proving