Re: Patch for fail-back without fresh backup

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Patch for fail-back without fresh backup
Дата
Msg-id CAMkU=1wW0-vz1KJMKRUbN6ctJxHjq5vG2SkqSDa7j0z9qq3_-w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Patch for fail-back without fresh backup  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: Patch for fail-back without fresh backup  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On Thu, Nov 21, 2013 at 12:31 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Bruce Momjian escribió:
> On Thu, Oct 24, 2013 at 11:14:14PM +0300, Heikki Linnakangas wrote:
> > On 24.10.2013 23:07, Josh Berkus wrote:

> > >What kind of overhead are we talking about here?
> >
> > One extra WAL record whenever a hint bit is set on a page, for the
> > first time after a checkpoint. In other words, a WAL record needs to
> > be written in the same circumstances as with page checksums, but the
> > WAL records are much smaller as they don't need to contain a full
> > page image, just the block number of the changed block.
> >
> > Or maybe we'll write the full page image after all, like with page
> > checksums, just without calculating the checksums. It might be
> > tricky to skip the full-page image, because then a subsequent change
> > of the page (which isn't just a hint-bit update) needs to somehow
> > know it needs to take a full page image even though a WAL record for
> > it was already written.
>
> Sorry to be replying late to this, but while I am not worried about the
> additional WAL volume, does this change require the transaction to now
> wait for a WAL sync to disk before continuing?

I don't think so.  There's extra WAL written, but there's no
flush-and-wait until end of transaction (as has always been).


But if the transaction would not have otherwise generated WAL (i.e. a select that did not have to do any HOT pruning, or an update with zero rows matching the where condition), doesn't it now have to flush and wait when it would otherwise not?

Cheers,

Jeff

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Patch for fail-back without fresh backup