Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So we've got two problems: SA_RESTART is preventing some EINTRs from
>> happening when we'd like, and yet it seems we are at risk of unwanted
>> EINTRs anyway.
>>
>> The only really clean solution I can see is to stop using SA_RESTART
Tom Lane wrote:
> So we've got two problems: SA_RESTART is preventing some EINTRs from
> happening when we'd like, and yet it seems we are at risk of unwanted
> EINTRs anyway.
>
> The only really clean solution I can see is to stop using SA_RESTART
> and try to make all our syscalls EINTR-proof.
Added to TODO:
* Research use of signals and sleep wake ups
http://archives.postgresql.org/pgsql-hackers/2007-07/msg3.php
---
Tom Lane wrote:
> While poking at the vacuum-launcher issue currently under discussion,
>
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Lane wrote:
> While poking at the vacuum-launcher issue currently under discussion,
> I got annoyed again at the
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> One other possiblity is using something like nanosleep():
> But I don't know if that would help on your HPUX box though...
Doesn't help ... the function exists but it seems to have the identical
restarting behavior to select :-(
I had previousl
On Sun, Jul 01, 2007 at 12:11:26PM -0400, Tom Lane wrote:
> To me, this calls into question whether we should try to avoid using
> SA_RESTART at all. The reason for doing it of course is to avoid
> unexpected syscall EINTR failures as well as short read/short write
> behaviors during disk I/O.
Hr
While poking at the vacuum-launcher issue currently under discussion,
I got annoyed again at the behavior we've known for a long while that
on some platforms pg_usleep() won't be interrupted by signals. (In
particular I see this on HPUX, though not on Linux or Darwin. Anyone
know if it happens on
