On Fri, Jul 19, 2019 at 12:59:43AM -0400, Tom Lane wrote:
> Hm, I think 0ba06e0 is actually the relevant change here? Though
> 40cfe86 was a necessary cleanup fix.
Oops. Yes, I meant that.
> I'm too tired to dig in the buildfarm database to be sure, but my
> impression is that the failure rate
First time we found pg_ctl errors while testing our fork.
I reproduced them on REL_11_STABLE.
I found three problems with pg_ctl do_stop/do_restart:
1 - "old" fopen() function;
2 - "delete pending" problem rarely happens with "new" fopen() function when
pg_ctl tries to open postmaster.pid file;
3
Michael Paquier writes:
> On Thu, Jul 18, 2019 at 04:14:34PM +0700, Жарков Роман wrote:
>> I have tested clean REL_11_STABLE.
>> Commit f02259fe was reverted by df8b5f3e in this branch.
>> So pg_ctl uses “old” open() function.
> Yeah, that was a failure from me, so I tend to be rather very carefu
On Thu, Jul 18, 2019 at 04:14:34PM +0700, Жарков Роман wrote:
> I have tested clean REL_11_STABLE.
> Commit f02259fe was reverted by df8b5f3e in this branch.
> So pg_ctl uses “old” open() function.
Yeah, that was a failure from me, so I tend to be rather very careful
about anything related to Wind
I have tested clean REL_11_STABLE.
Commit f02259fe was reverted by df8b5f3e in this branch.
So pg_ctl uses “old” open() function.
regards, Roman
> 18 июля 2019 г., в 15:51, Michael Paquier написал(а):
>
>> On Wed, Jul 17, 2019 at 09:54:16PM +0700, r.zhar...@postgrespro.ru wrote:
>> You are righ
At Thu, 18 Jul 2019 14:04:34 +0700, Жарков Роман
wrote in
> Hello,
>
> Therefore, we suggest replace the deletion of a lock file by renaming it.
> unlink in windows is not an atomic operation.
> When we try to open the file between
> SetDispositionInformationFile and CloseFile we get ERROR_DEL
On Wed, Jul 17, 2019 at 09:54:16PM +0700, r.zhar...@postgrespro.ru wrote:
> You are right. I tested branch REL_11_STABLE and it is my mistake.
>
> [...]
>
> The probability is very small. In one of our tests pg_ctl fails with that
> error sometime.
> In a test with multiple frequent restarts the pr
On Wed, Jul 17, 2019 at 09:51:48AM -0400, Tom Lane wrote:
> r.zhar...@postgrespro.ru writes:
>> On Windows systems we cannot handle ERROR_DELETE_PENDING because
>> GetLastError() returns ERROR_ACCESS_DENIED instead.
>> So we rename the lock files before delete them.
>
> This seems improbably brok
On 2019-07-17 20:51, Tom Lane wrote:
r.zhar...@postgrespro.ru writes:
pg_ctl now opens the postmaster.pid file using pgwin32_open() function
to correctly handle share locks.
HEAD already does that, no? See f02259fe9.
You are right. I tested branch REL_11_STABLE and it is my mistake.
On W
r.zhar...@postgrespro.ru writes:
> pg_ctl now opens the postmaster.pid file using pgwin32_open() function
> to correctly handle share locks.
HEAD already does that, no? See f02259fe9.
> On Windows systems we cannot handle ERROR_DELETE_PENDING because
> GetLastError() returns ERROR_ACCESS_DENIE
Subject: Intermittent pg_ctl failures on Windows
The buildfarm's Windows members occasionally show weird pg_ctl
failures, for instance this recent case:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuildfarm.postgresql.org%2Fcgi-bin%2Fshow_log.pl%3Fnm%3Dbowerbird%26dt%3D2018-
pg_ctl failures on Windows
The buildfarm's Windows members occasionally show weird pg_ctl failures, for
instance this recent case:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuildfarm.postgresql.org%2Fcgi-bin%2Fshow_log.pl%3Fnm%3Dbowerbird%26dt%3D2018-03-10%252020%2
The buildfarm's Windows members occasionally show weird pg_ctl failures,
for instance this recent case:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2018-03-10%2020%3A30%3A20
### Restarting node "master"
# Running: pg_ctl -D
G:/prog/bf/root/HEAD/pgsql.build/src/test/recov
13 matches
Mail list logo
