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
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
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
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
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
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
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
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
Hello!
We reproduced these errors on out buildfarm and my windows workstation.
We used small TAP test that restarts PostgresNode in loop. Additionally,
constant WAITS_PER_SEC in the pg_ctl.c file has been increased 1000
times.
There are two different problems with pg_ctl:
1 - share access to
Hi Tom,
This is a great catch. I am looking into it: I will start by reproducing the
error as you suggested.
Thanks,
Badrul
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Saturday, March 10, 2018 2:48 PM
To: pgsql-hackers@lists.postgresql.org
Subject: Intermittent
12 matches
Mail list logo
