Re: PATCH: track last known XLOG segment in control file

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: PATCH: track last known XLOG segment in control file
Дата
Msg-id 566C9F91.60809@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: PATCH: track last known XLOG segment in control file  (Andres Freund <andres@anarazel.de>)
Ответы Re: PATCH: track last known XLOG segment in control file  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers

On 12/12/2015 11:20 PM, Andres Freund wrote:
> Hi,
>
> On 2015-12-12 22:14:13 +0100, Tomas Vondra wrote:
>> this is the second improvement proposed in the thread [1] about ext4 data
>> loss issue. It adds another field to control file, tracking the last known
>> WAL segment. This does not eliminate the data loss, just the silent part of
>> it when the last segment gets lost (due to forgetting the rename, deleting
>> it by mistake or whatever). The patch makes sure the cluster refuses to
>> start if that happens.
>
> Uh, that's fairly expensive. In many cases it'll significantly
> increase the number of fsyncs.

It should do exactly 1 additional fsync per WAL segment. Or do you think 
otherwise?
> I've a bit of a hard time believing this'll be worthwhile.

The trouble is protections like this only seem worthwhile after the 
fact, when something happens. I think it's reasonable protection against 
issues similar to the one I reported ~2 weeks ago. YMMV.
> Additionally this doesn't seem to take WAL replay into account?

I think the comparison in StartupXLOG needs to be less strict, to allow 
cases when we actually replay more WAL segments. Is that what you mean?

regards

--
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: PATCH: track last known XLOG segment in control file
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Using quicksort for every external sort run