This patch has been withdrawn by the author.
---
Claudio Natoli wrote:
>
> For application to HEAD.
>
> This should take care of most, if not all, cases where a backend can be
> interrupted in a blocking socket operation b
> Your patch has been added to the PostgreSQL unapplied patches list at:
Bruce, please cancel the original patch.
The attached patch is for (possible) application to HEAD, following
meritocratic "contest" [socket.c for src/port]
Been iterating with Magnus extensively off-list, and he is well on
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> The third option is to redefine all these functions into our own, and
> implement our own emulation layer. This means our own select(), send(),
> recv() (more? I don't think so). And have these call the native winsock
> APIs (WSAEventSelect(), WSASend
>> The third option is to redefine all these functions into our own, and
>> implement our own emulation layer. This means our own
>select(), send(),
>> recv() (more? I don't think so). And have these call the
>native winsock
>> APIs (WSAEventSelect(), WSASend(), WSARecv() etc). These
>functions
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> I *think* we can do a better job with a not-so-large amount of effort,
> ...
> I'm willing to give it a try. If it turns out to be a lot of work, or
> way too much code, I'll drop the idea.
Sure, give it a shot and see what you get.
Hi all,
Magnus Hagander wrote:
> The third option is to redefine all these functions into our own, and
> implement our own emulation layer. This means our own select(), send(),
> recv() (more? I don't think so). And have these call the native winsock
> APIs (WSAEventSelect(), WSASend(), WSARecv()
Claudio Natoli <[EMAIL PROTECTED]> writes:
> ... However, it just occured to me that
> we could wrap select() by augmenting the read_mask with an addition socket,
> that we know will never be touched, and checking this socket on a "valid"
> return. If this socket is still set, we know we got bitten
Tom Lane wrote:
> Claudio Natoli <[EMAIL PROTECTED]> writes:
> > ... However, it just occured to me that
> > we could wrap select() by augmenting the read_mask with an
> addition socket,
> > that we know will never be touched, and checking this
> socket on a "valid"
> > return. If this socket is
> Tom Lane wrote:
> > What happens if the socket() call fails?
>
> Then we return in error. Refer to attachment.
Doh. You *were* referring to the attachment. Ok, so it'll need a check to
make sure the socket actually does get created, but this isn't a fatal flaw,
right? [is a work in progress
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>>> Hopeless, or cute, work-around?
>>
>> It's possibly workable in the limited context of the postmaster, but
>> I've got doubts about doing it in libpq where we can't assume we know
>> what the surrounding application will do.
> No need to touch the
Tom Lane wrote:
> > No need to touch the frontend parts at all. Our APCs are server side
> > only, so it's not a problem there.
>
> Oh really? What if the surrounding app uses APCs?
To my mind, that's actually a vote *for* the work-around, and in /port (in
order to have it propagate to all fron
Claudio Natoli <[EMAIL PROTECTED]> writes:
> Hopeless, or cute, work-around?
It's possibly workable in the limited context of the postmaster, but
I've got doubts about doing it in libpq where we can't assume we know
what the surrounding application will do.
regards, tom la
>> I don't think it's a good idea in general to redefine something as
>> fundamental as select, send, recv etc from libpq-fe.h (or
>files included
>> from there).
>
>Certainly not; the redefinition would have to be in files that are not
>part of the exported API. However this is not difficult.
Hopeless, or cute, work-around?
>>>
>>> It's possibly workable in the limited context of the postmaster, but
>>> I've got doubts about doing it in libpq where we can't
>assume we know
>>> what the surrounding application will do.
>
>> No need to touch the frontend parts at all. Our APCs are
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>>> No need to touch the frontend parts at all. Our APCs are server side
>>> only, so it's not a problem there.
>>
>> Oh really? What if the surrounding app uses APCs?
> Then I'd say it's that apps problem. And it's clearly nothing new - the
> proble
>> Hopeless, or cute, work-around?
>
>It's possibly workable in the limited context of the postmaster, but
>I've got doubts about doing it in libpq where we can't assume we know
>what the surrounding application will do.
No need to touch the frontend parts at all. Our APCs are server side
only, so
>> Ugh. Is there a way we can insert a wrapper layer without
>modifying the
>> call sites? I'm thinking of some kind of macro hack, say
>> [snip]
>
>Sure. Think we've even done this before (also, prevents
>developers needing to remember to use pg_*).
Yup, it's done to redefine kill() to pqkill
> Ugh. Is there a way we can insert a wrapper layer without modifying the
> call sites? I'm thinking of some kind of macro hack, say
> [snip]
Sure. Think we've even done this before (also, prevents developers needing
to remember to use pg_*).
The reason I think it was avoided for select(), in
Claudio Natoli <[EMAIL PROTECTED]> writes:
>> I'm loath to invent pg_select() but it might be cleaner than this.
> We'd also need pg_recv() and pg_send(). Chances are it can happen with every
> blocking socket call :-(
Ugh. Is there a way we can insert a wrapper layer without modifying the
call
> Rather than hoping that we'll remember to decorate every select() call
> with this workaround, would it make sense to use a wrapper function?
> I'm loath to invent pg_select() but it might be cleaner than this.
We'd also need pg_recv() and pg_send(). Chances are it can happen with every
blockin
Claudio Natoli <[EMAIL PROTECTED]> writes:
> It would be more consistent, but unfortunately GetLastError() != errno.
Yeah, I saw Magnus' explanation. So essentially this is a workaround
for a bug in Windows' select() emulation.
Rather than hoping that we'll remember to decorate every select() ca
> Would look more consistent if the code looked like
>
> if (n < 0 && errno == ERROR_IO_PENDING)
> errno = EINTR;
It would be more consistent, but unfortunately GetLastError() != errno.
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the f
>Claudio Natoli <[EMAIL PROTECTED]> writes:
>> + #ifdef WIN32
>> +/* Interrupted by socket/APC interaction? */
>> +if (n < 0 && GetLastError() == ERROR_IO_PENDING)
>> +errno = EINTR;
>> + #endif
>
>This seems a bit schizophrenic; if you can assign to errno,
>why can't you
>read
Claudio Natoli <[EMAIL PROTECTED]> writes:
> + #ifdef WIN32
> + /* Interrupted by socket/APC interaction? */
> + if (n < 0 && GetLastError() == ERROR_IO_PENDING)
> + errno = EINTR;
> + #endif
This seems a bit schizophrenic; if you can assign to errno, why can't you
read from it
'[EMAIL PROTECTED]'
> Subject: [PATCHES] APC/socket fix (final?)
>
>
>
> For application to HEAD.
>
> This should take care of most, if not all, cases where a
> backend can be interrupted in a blocking socket operation by
> a signal which itself performs a s
For application to HEAD.
This should take care of most, if not all, cases where a backend can be
interrupted in a blocking socket operation by a signal which itself performs
a socket operation (which interacts badly with our APC-based signal
implementation).
---
Certain disclaimers and policies
26 matches
Mail list logo
