Re: VM corruption on standby
От | Aleksander Alekseev |
---|---|
Тема | Re: VM corruption on standby |
Дата | |
Msg-id | CAJ7c6TOtYagmAm+f4B3JEWoahG3bocoBNe1Gvdrjejo5MMMC1g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: VM corruption on standby (Aleksander Alekseev <aleksander@tigerdata.com>) |
Список | pgsql-hackers |
Hi, > If my understanding is correct, we should make a WAL record with the > XLH_LOCK_ALL_FROZEN_CLEARED flag *before* we modify the VM but within > the same critical section [...] > > A draft patch is attached. It makes the test pass and doesn't seem to > break any other tests. > > Thoughts? In order not to forget - assuming I'm not wrong about the cause of the issue, we might want to recheck the order of visibilitymap_* and XLog* calls in the following functions too: - heap_multi_insert - heap_delete - heap_update - heap_lock_tuple - heap_lock_updated_tuple_rec By a quick look all named functions modify the VM before making a corresponding WAL record. This can cause a similar issue: 1. VM modified 2. evicted asynchronously before logging 3. kill 9 4. different state of VM on primary and standby
В списке pgsql-hackers по дате отправления: