Re: collateral benefits of a crash-safe visibility map

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: collateral benefits of a crash-safe visibility map
Дата
Msg-id BANLkTi=ccHhH_zu=1v3mVOjK=+1L-WD8+A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: collateral benefits of a crash-safe visibility map  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, May 10, 2011 at 6:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, May 10, 2011 at 12:57 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> Hmmm, do we really need to WAL log freezing?
>
>> That might solve the relfrozenxid problem - set the bits in the heap,
>> sync the heap, then update relfrozenxid once the heap is guaranteed
>> safely on disk - but it again seems problematic for Hot Standby.
>
> ... or even warm standby.  You basically *have to* WAL-log freezing
> before you can truncate pg_clog.  The only freedom you have here is
> freedom to mess with the policy about how soon you try to truncate
> pg_clog.
>
> (Doing an unlogged freeze operation first is right out, too, if it
> causes the system to fail to perform/log the operation later.)

Trying to think outside of the box from all these things we can't do.

Can we keep track of the relfrozenxid and then note when we fsync the
relevant file, then issue a single WAL record to indicate that? Still
WAL logging, but 1 record per table, not 1 record per tuple.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Formatting Curmudgeons WAS: MMAP Buffers
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Process wakeups when idle and power consumption