Thread: pgstat.c: send/EINTR issue

pgstat.c: send/EINTR issue

From
"Ilja Golshtein"
Date:
Hello!

I've came across recent change of
postmaster/pgstat.c with comment
regarding send/EINTR issue.

Does it make sense to amend,
for example, secure_write() in
be_secure.c (part of libpq)
in the same way?
Am I right thinking it may
fail during reloading configuration?
Is it the only dangerous case?

--
Best regards
Ilja Golshtein

Re: pgstat.c: send/EINTR issue

From
Martijn van Oosterhout
Date:
On Wed, Aug 02, 2006 at 02:57:59PM +0400, Ilja Golshtein wrote:
> Hello!
>
> I've came across recent change of
> postmaster/pgstat.c with comment
> regarding send/EINTR issue.
>
> Does it make sense to amend,
> for example, secure_write() in
> be_secure.c (part of libpq)
> in the same way?
> Am I right thinking it may
> fail during reloading configuration?
> Is it the only dangerous case?

The point is that EINTR is not supposed to happen, at all, in the
backend. It should only happen with non-blocking sockets (not used in
backend) or interruption by a signal (disabled in the backend). My
understanding of the EINTR change is that it's a windows issue, which
doesn't totally follow the above rules.

BTW, be_secure is used in the backend, fe-secure is used in libpq and
does support non-blocking and EINTR.

If it possible for the system to return EINTR in
secure_read/secure_write, then we also need to worry about it during
disk access and many other places.

Hope this helps,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Attachment

Re: pgstat.c: send/EINTR issue

From
Tom Lane
Date:
"Ilja Golshtein" <ilejn@yandex.ru> writes:
> Does it make sense to amend,
> for example, secure_write() in
> be_secure.c (part of libpq)
> in the same way?

It's already done, see the only caller of secure_write ...

            regards, tom lane