Re: Shared row locking, revisited
От | Qingqing Zhou |
---|---|
Тема | Re: Shared row locking, revisited |
Дата | |
Msg-id | d32kcd$1lh7$1@news.hub.org обсуждение исходный текст |
Ответ на | Shared row locking, revisited (Alvaro Herrera <alvherre@dcc.uchile.cl>) |
Ответы |
Re: Shared row locking, revisited
|
Список | pgsql-hackers |
"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? Regards, Qingqing
В списке pgsql-hackers по дате отправления: