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" <zhouqq@cs.toronto.edu>) |
Список | pgsql-hackers |
On Thu, Apr 07, 2005 at 02:34:03PM +0800, Qingqing Zhou wrote: > > "Alvaro Herrera" <alvherre@dcc.uchile.cl> 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 по дате отправления: