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