From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Unlogged relation copy is not fsync'd |
Date: | 2023-09-15 11:22:18 |
Message-ID: | 784b637f-303e-1168-f966-9f7a22505009@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 04/09/2023 16:59, Melanie Plageman wrote:
> The patch looks reasonable to me. Is this [1] case in hash index build
> that I reported but didn't take the time to reproduce similar?
>
> [1] https://www.postgresql.org/message-id/CAAKRu_bPc81M121pOEU7W%3D%2BwSWEebiLnrie4NpaFC%2BkWATFtSA%40mail.gmail.com
Yes, I think you're right. Any caller of smgrwrite() must either:
a) Call smgrimmedsync(), after smgrwrite() and before the relation is
visible to other transactions. Regardless of the 'skipFsync' parameter!
I don't think this is ever completely safe unless it's a new relation.
Like you pointed out with the hash index case. Or:
b) Hold the buffer lock, so that if a checkpoint happens, it cannot
"race past" the page without seeing the sync request.
The comment on smgwrite() doesn't make this clear. It talks about
'skipFsync', and gives the impression that as long as you pass
'skipFsync=false', you don't need to worry about fsyncing. But that is
not true. Even in these bulk loading cases where we currently call
smgrimmedsync(), we would *still* need to call smgrimmedsync() if we
used 'skipFsync=false'.
--
Heikki Linnakangas
Neon (https://neon.tech)
From | Date | Subject | |
---|---|---|---|
Next Message | Aleksander Alekseev | 2023-09-15 11:32:44 | Re: POC: Extension for adding distributed tracing - pg_tracing |
Previous Message | vignesh C | 2023-09-15 11:21:57 | Re: pg_upgrade and logical replication |