Re: Online enabling of checksums
| От | Magnus Hagander |
|---|---|
| Тема | Re: Online enabling of checksums |
| Дата | |
| Msg-id | CABUevEwkVo-i=oFoaFMMbBoJJDn0+KRbw1Fu20oaWRiAKsEnNA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Online enabling of checksums (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Online enabling of checksums
|
| Список | pgsql-hackers |
On Thu, Apr 5, 2018 at 11:23 PM, Andres Freund <andres@anarazel.de> wrote:
Hi,
On 2018-04-05 22:06:36 +0200, Magnus Hagander wrote:
> I have now pushed this latest version with some minor text adjustments and
> a catversion bump.
Is there any sort of locking that guarantees that worker processes see
an up2date value of
DataChecksumsNeedWrite()/ControlFile->data_checksum_ version? Afaict
there's not. So you can afaict end up with checksums being computed by
the worker, but concurrent writes missing them. The window is going to
be at most one missed checksum per process (as the unlocking of the page
is a barrier) and is probably not easy to hit, but that's dangerous
enough.
So just to be clear of the case you're worried about. It's basically:
Session #1 - sets checksums to inprogress
Session #1 - starts dynamic background worker ("launcher")
Launcher reads and enumerates pg_database
Launcher starts worker in first database
Worker processes first block of data in database
And at this point, Session #2 has still not seen the "checksums inprogress" flag and continues to write without checksums?
That seems like quite a long time to me -- is that really a problem? I'm guessing you're seeing a shorter path between the two that I can't see right now (I'll blame the late evning...)?
В списке pgsql-hackers по дате отправления: