Re: BUG #16039: PANIC when activating replication slots in Postgres 12.0 64bit under Windows

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>

To: Michael Paquier <michael@paquier.xyz>

Cc: buschmann@nidsa.net, pgsql-bugs@lists.postgresql.org, Michael Paquier <michael.paquier@gmail.com>

Date: 2019-10-08T16:09:53Z

Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Flush logical mapping files with fd opened for read/write at checkpoint
- 59800f7cef55 9.4.25 landed
- c50f95272e5c 9.5.20 landed
- 4e7a8874a15a 9.6.16 landed
- fbfc835b463a 10.11 landed
- e34358c436c6 11.6 landed
- 07c314968712 12.1 landed
- b8e19b932a99 13.0 landed
Use a fd opened for read/write when syncing slots during startup, take 2.
- c025165da9da 12.1 landed
- a586cc4b6c56 13.0 landed
Tighten use of OpenTransientFile and CloseTransientFile
- 82a5649fb9db 12.0 cited
Use a fd opened for read/write when syncing slots during startup.
- dfbaed459754 9.5.0 cited

Hi,

On 2019-10-08 09:32:40 +0900, Michael Paquier wrote:
> On Sun, Oct 06, 2019 at 01:55:48PM +0900, Michael Paquier wrote:
> > It would have been nice to add some sanity checks based on fcntl() but
> > directory handling in pg_fsync() makes that annoying.

I wondered about adding something like that too. Not sure what you mean
by directory handling problems? Couldn't that just be solved by doing an
fstat()?

> > Anyway, I have checked the code with a little trick, and I have
> > spotted a second bug: CheckPointLogicalRewriteHeap() fsyncs a
> > logical rewrite mapping file with RDONLY.  This is incorrect since
> > b89e151.

Yuck :(. Luckily that's a pretty narrow case to hit.  We really need
windows coverage for this stuff. And also just general buildfarm
coverage, it's not like we're immune from bugs on unixoid OSs etiher.

> Andres, others, any thoughts about this issue?  Are there any
> objections if I just fix it?

Not here.

Greetings,

Andres Freund