Re: Shared row locking, revisited

Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Shared row locking, revisited
Дата
Msg-id 20050407121126.GB3391@dcc.uchile.cl
обсуждение исходный текст
Ответ на Re: Shared row locking, revisited  ("Qingqing Zhou")
Список pgsql-hackers
On Thu, Apr 07, 2005 at 02:34:03PM +0800, Qingqing Zhou wrote:
> 
> "Alvaro Herrera" <> writes
> > Because we can't reuse MultiXactIds at system crash (else we risk taking
> > an Id which is already stored in some tuple), we need to XLog it.  Not
> > at the locking operation, because we don't want to log that one (too
> > expensive.)  We can log the current value of MultiXactId counter once in
> > a while; say, one each (say) 1000 acquisitions.  Following a crash, the
> > value is restored to the last one logged + 1000.  (I think this can be a
> > problem if we log one acquisition, then write some tuples, and then
> > crash, without flushing the acquisition logged.  Maybe a solution is to
> > force a flush after logging an acquisition.)
> 
> Does Oid have a similar problem?

Good question.  Yes, and in fact the solution is similar; see
XLogPutNextOid().  I think we could do the same for MultiXactId.

-- 
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"La soledad es compañía"


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

Предыдущее
От: Karel Zak
Дата:
Сообщение: 'now' runtime
Следующее
От: Tom Lane
Дата:
Сообщение: Re: About index_build