From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: psql: Add test for query canceling |
Date: | 2021-08-25 12:02:05 |
Message-ID: | BED350D9-9AD3-47E0-A370-99B90DE754C2@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
> On 25 Aug 2021, at 07:37, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>
>
>> That looks pretty solid to me, and I can confirm that it passes
>> on wrasse's host. The only nit I can find to pick is that this:
>>
>> + usleep(10_000) until -s "$tempdir/psql.pid" or ($count++ > 180 * 100 and die 'pid file did not appear');
>>
>> basically assumes that psql.pid will be written atomically.
>
>> It'd be marginally safer to wait till psql.pid can be seen to
>> contain a newline. I don't think that would be too hard to do,
>> if you put the slurp_file call inside the wait loop and inspect
>> its result.
>
> I finally came around to have a look at the patch.
>
> For the issue raised above, I can see that the file could be created but not yet written, but as the patch waits for the file to be non zero, ISTM that the probability of a torn write of a single integer by echo is so remote that we could let it as that?
>
> Attached a version with the slurping in the loop anyway.
It might be that the risk of a torn write is close to negligible, but that just
means that it’s bound to happen, and pretty soon too =) Checking with slurping
in the loop seems like a good idea to me.
--
Daniel Gustafsson https://vmware.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2021-08-25 12:19:20 | Re: Separate out FileSet from SharedFileSet (was Re: pgsql: pgstat: Bring up pgstat in BaseInit() to fix uninitialized use o) |
Previous Message | Peter Eisentraut | 2021-08-25 10:16:36 | pgsql: psql: Make cancel test more timing robust |