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 по дате отправления:

Предыдущее
От: "Qingqing Zhou"
Дата:
Сообщение: Re: Did this issue ever get resolved?
Следующее
От: Alexey Slynko
Дата:
Сообщение: About index_build