From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Loaded footgun open_datasync on Windows |
Date: | 2018-09-10 14:46:40 |
Message-ID: | a3c9a12d4d146174b7fc3a742bd8f06278a20b78.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | Postg토토SQL : Postg토토SQL |
Noah Misch wrote:
> On Wed, Jun 27, 2018 at 12:09:24PM +0200, Laurenz Albe wrote:
> > Michael Paquier wrote:
> > > > I have added it to the July commitfest.
> > >
> > > Have you looked at the possibility of removing the log file constraints
> > > in pg_upgrade with the change you are doing here so as things would be
> > > more consistent with non-Windows platforms, simplifying some code on the
> > > way?
> >
> > Can you explain what the "log file constraints" are?
> > If it is in any way related, and I can handle it, sure.
>
> See this comment in pg_upgrade.h:
>
> /*
> * WIN32 files do not accept writes from multiple processes
> *
> * On Win32, we can't send both pg_upgrade output and command output to the
> * same file because we get the error: "The process cannot access the file
> * because it is being used by another process." so send the pg_ctl
> * command-line output to a new file, rather than into the server log file.
> * Ideally we could use UTILITY_LOG_FILE for this, but some Windows platforms
> * keep the pg_ctl output file open by the running postmaster, even after
> * pg_ctl exits.
> *
> * We could use the Windows pgwin32_open() flags to allow shared file
> * writes but is unclear how all other tools would use those flags, so
> * we just avoid it and log a little differently on Windows; we adjust
> * the error message appropriately.
> */
>
> If you grep src/bin/pg_upgrade for WIN32, roughly a third of the hits are
> workarounds for this problem. I agree with Michael that removing those
> workarounds would be a good test of frontend pgwin32_open() and worth
> including in the initial commit.
Thank you for the explanation.
I didn't get pg_upgrade to work without the log file hacks; I suspect that there
is more than just log file locking going on, but my Windows skills are limited.
How shall I proceed?
I think that it is important to get pg_test_fsync to work correctly on Windows,
and if my patch does not break the buildfarm, that's what it does.
I have attached a new version, the previous one was bit-rotted.
Yours,
Laurenz Albe
Attachment | Content-Type | Size |
---|---|---|
0001-Use-pgwin32_open-in-frontend-code-on-Windows_V3.patch | text/x-patch | 2.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Travers | 2018-09-10 14:53:24 | Re: Can I just reload the slave to change primary_conninfo? |
Previous Message | Alvaro Herrera | 2018-09-10 14:36:37 | Re: cache lookup failed for constraint when alter table referred by partition table |