From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
---|---|
To: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Shared row locking, revisited |
Date: | 2005-04-07 12:11:26 |
Message-ID: | 20050407121126.GB3391@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 07, 2005 at 02:34:03PM +0800, Qingqing Zhou wrote:
>
> "Alvaro Herrera" <alvherre(at)dcc(dot)uchile(dot)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[(at)]dcc(dot)uchile(dot)cl>)
"La soledad es compañía"
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-04-07 14:11:55 | Re: About index_build |
Previous Message | Karel Zak | 2005-04-07 11:13:04 | 'now' runtime |