Re: VM corruption on standby - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: VM corruption on standby
Date
Msg-id CAJ7c6TMAOrXz-=SPvgW0JtFktxSDBTZ5GVRyZ=wT5MqkbFnMhQ@mail.gmail.com
Whole thread Raw
In response to Re: VM corruption on standby  (Aleksander Alekseev <aleksander@tigerdata.com>)
Responses Re: VM corruption on standby
Re: VM corruption on standby
Re: VM corruption on standby
List pgsql-hackers
Hi,

> This is a tricky bug. Do you also have a proposal of a particular fix?

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 (in order to avoid race conditions within
the same backend).

A draft patch is attached. It makes the test pass and doesn't seem to
break any other tests.

Thoughts?

Attachment

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: [PING] fallocate() causes btrfs to never compress postgresql files
Next
From: Aleksander Alekseev
Date:
Subject: Re: VM corruption on standby