Re: [HACKERS] Unlogged tables cleanup

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] Unlogged tables cleanup
Дата
Msg-id 20190523064248.GF5870@paquier.xyz
обсуждение исходный текст
Ответ на Re: [HACKERS] Unlogged tables cleanup  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Unlogged tables cleanup  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, May 21, 2019 at 08:39:18AM -0400, Robert Haas wrote:
> Yes.  I thought I had described it.  You create an unlogged table,
> with an index of a type that does not smgrimmedsync(), your
> transaction commits, and then the system crashes, losing the _init
> fork for the index.

The init forks won't magically go away, except in one case for empty
routines not going through shared buffers.

The empty routines writing pages which do not go through shared
buffers still log them, so those pages could go away when the host
crashes, and a checkpoint completed before calling smgrimmedsync() and
after the page has been logged.  Please note the logic in
spgbuildempty() as an example.

Then, empty routines going through shared buffers fill in one or more
buffers, mark it/them as empty, dirty it/them, log the page(s) and then
unlock the buffer(s).  If a crash happens after the transaction
commits, so we would still have the init page in WAL, and at the end
of recovery we would know about it.

Or is there something in log_newpage_buffer()/log_newpage() I am
missing but you foresee?
--
Michael

Вложения

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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: PostgreSQL 12 Beta 1 press release draft
Следующее
От: Paul A Jungwirth
Дата:
Сообщение: Re: docs about FKs referencing partitioned tables