Hi Heikki,
On 2014-09-02 21:22:29 +0300, Heikki Linnakangas wrote:
> On 08/28/2014 03:47 PM, Kyotaro HORIGUCHI wrote:
> > To make the code mentioned above (Patch 0002) tidy, rewrite the
> > socket emulation code for win32 backends so that each socket
> > can have its own non-blocking state.
On 2015-01-12 00:40:50 +0100, Andres Freund wrote:
> Fixed in what I've since pushed (as Heikki basically was ok with the
> patch sent a couple months back, modulo some fixes)...
I'd not actually pushed that patch... I had pushed some patches
(barriers, atomics), but had decided to hold off on thi
On Mon, Jan 12, 2015 at 01:45:41AM +0100, Andres Freund wrote:
> On 2015-01-11 19:37:53 -0500, Noah Misch wrote:
> > I recommend either (a) taking no action or (b) adding a regression test
> > verifying WaitLatchOrSocket() conformance in this scenario.
>
> Do you have a good idea how to test b) sa
On 2015-01-11 19:37:53 -0500, Noah Misch wrote:
> I recommend either (a) taking no action or (b) adding a regression test
> verifying WaitLatchOrSocket() conformance in this scenario.
Do you have a good idea how to test b) save a C function in regress.c
that does what your test does using latches?
On Mon, Jan 12, 2015 at 12:40:50AM +0100, Andres Freund wrote:
> On 2015-01-11 16:36:07 -0500, Noah Misch wrote:
> > On Sat, Jan 10, 2015 at 03:25:42AM +0100, Andres Freund wrote:
> > > 0001-Allow-latches-to-wait-for-socket-writability-without.patch
> > > Imo pretty close to commit and can be
On 2015-01-11 16:47:53 -0500, Robert Haas wrote:
> > My guess that's not so much the overhead of the latch itself, but the
> > lack of the directed wakeup stuff the OS provides for semaphores.
>
> That's possible.
> On Sat, Jan 10, 2015 at 11:35 AM, Andres Freund
> wrote:
> > Interesting. I dim
On 2015-01-11 16:36:07 -0500, Noah Misch wrote:
> On Sat, Jan 10, 2015 at 03:25:42AM +0100, Andres Freund wrote:
> > 0001-Allow-latches-to-wait-for-socket-writability-without.patch
> > Imo pretty close to commit and can be committed independently.
>
> The key open question is whether all plat
On Sat, Jan 10, 2015 at 11:35 AM, Andres Freund wrote:
> Interesting. I dimly remembered you mentioning this, that's how I
> rediscovered this message.
>
> Do you remember any details?
No, not really.
> My guess that's not so much the overhead of the latch itself, but the
> lack of the directed
On Sat, Jan 10, 2015 at 03:25:42AM +0100, Andres Freund wrote:
> 0001-Allow-latches-to-wait-for-socket-writability-without.patch
> Imo pretty close to commit and can be committed independently.
The key open question is whether all platforms of interest can reliably detect
end-of-file when pol
On 2014-09-04 08:49:22 -0400, Robert Haas wrote:
> On Tue, Sep 2, 2014 at 3:01 PM, Andres Freund wrote:
> > I'm slightly worried about the added overhead due to the latch code. In
> > my implementation I only use latches after a nonblocking read, but
> > still. Every WaitLatchOrSocket() does a dra
On 2014-11-17 18:22:54 +0300, Alex Shulgin wrote:
>
> Andres Freund writes:
> >
> > I've invested some more time in this:
> > 0002 now makes sense on its own and doesn't change anything around the
> > interrupt handling. Oh, and it compiles without 0003.
>
> In this patch, the endif appears
On 2014-10-03 16:26:35 +0200, Andres Freund wrote:
> On 2014-10-03 17:12:18 +0300, Heikki Linnakangas wrote:
> > >0002 now makes sense on its own and doesn't change anything around the
> > > interrupt handling. Oh, and it compiles without 0003.
> >
> > WaitLatchOrSocket() can throw an error,
Hello,
> On 2014-12-15 18:19:26 +0900, Kyotaro HORIGUCHI wrote:
> > Since I don't have clear idea how to promote this, I will remake
> > and be back with new patch based on Andres' for patches.
>
> Do my patches miss any functionality you want?
The patch satisfies what I want, as I said upthread
On 2014-12-15 18:19:26 +0900, Kyotaro HORIGUCHI wrote:
> Since I don't have clear idea how to promote this, I will remake
> and be back with new patch based on Andres' for patches.
Do my patches miss any functionality you want?
Greetings,
Andres Freund
--
Andres Freund htt
Since I don't have clear idea how to promote this, I will remake
and be back with new patch based on Andres' for patches.
> Hmm.. Sorry for my stupidity.
>
> > Why is that necessary? It seems really rather wrong to make
> > BIO_set_retry_write() dependant on ProcDiePending? Especially as, at
> >
On Thu, Oct 30, 2014 at 10:27 PM, Heikki Linnakangas
wrote:
> On 10/03/2014 06:29 PM, Heikki Linnakangas wrote:
>> [blah]
> About patch 3:
> Looking closer, this design still looks OK to me. As you said yourself, the
> comments need some work (e.g. the step 5. in the top comment in async.c
> needs
Andres Freund writes:
>
> I've invested some more time in this:
> 0002 now makes sense on its own and doesn't change anything around the
> interrupt handling. Oh, and it compiles without 0003.
In this patch, the endif appears to be misplaced in PostgresMain:
+ if (MyProcPort != NULL)
On 2014-10-30 15:27:13 +0200, Heikki Linnakangas wrote:
> The comment on PGPROC.procLatch in storage/proc.h says just this:
>
> > Latch procLatch; /* generic latch for process */
>
> This needs a lot more explaining. It's now used by signal handlers to
> interrupt a rea
On 10/03/2014 06:29 PM, Heikki Linnakangas wrote:
On 10/03/2014 05:26 PM, Andres Freund wrote:
On 2014-10-03 17:12:18 +0300, Heikki Linnakangas wrote:
On 09/28/2014 01:54 AM, Andres Freund wrote:
0003 Sinval/notify processing got simplified further. There really isn't
any need for Disab
Hmm.. Sorry for my stupidity.
> Why is that necessary? It seems really rather wrong to make
> BIO_set_retry_write() dependant on ProcDiePending? Especially as, at
> least in my testing, it's not even required because the be_tls_write()
> can just check the error properly?
I mistook the previous c
On 2014-10-09 14:06:35 +0900, Kyotaro HORIGUCHI wrote:
> Hello, simplly inhibit set retry flag when ProcDiePending in
> my_sock_write seems enough.
>
> But it returns with SSL_ERROR_SYSCALL not SSL_ERROR_WANT_WRITE so
> I modified the patch 4 as the attached patch.
Why is that necessary? It seems
Hello, simplly inhibit set retry flag when ProcDiePending in
my_sock_write seems enough.
But it returns with SSL_ERROR_SYSCALL not SSL_ERROR_WANT_WRITE so
I modified the patch 4 as the attached patch.
Finally, the attached patch works as expected with Andres's patch
1-3.
regards,
--
Kyotaro Ho
On 2014-10-03 18:29:23 +0300, Heikki Linnakangas wrote:
> On 10/03/2014 05:26 PM, Andres Freund wrote:
> >On 2014-10-03 17:12:18 +0300, Heikki Linnakangas wrote:
> >>On 09/28/2014 01:54 AM, Andres Freund wrote:
> >>>0003 Sinval/notify processing got simplified further. There really isn't
> >>>
On 10/03/2014 05:26 PM, Andres Freund wrote:
On 2014-10-03 17:12:18 +0300, Heikki Linnakangas wrote:
On 09/28/2014 01:54 AM, Andres Freund wrote:
0003 Sinval/notify processing got simplified further. There really isn't
any need for DisableNotifyInterrupt/DisableCatchupInterrupt
anym
Hi,
On 2014-10-03 17:12:18 +0300, Heikki Linnakangas wrote:
> On 09/28/2014 01:54 AM, Andres Freund wrote:
> >I've invested some more time in this:
>
> Thanks!
>
> In 0001, the select() codepath will not return (WL_SOCKET_READABLE |
> WL_SOCKET_WRITEABLE) on EOF or error, like the comment says a
On 09/28/2014 01:54 AM, Andres Freund wrote:
I've invested some more time in this:
Thanks!
In 0001, the select() codepath will not return (WL_SOCKET_READABLE |
WL_SOCKET_WRITEABLE) on EOF or error, like the comment says and like the
poll() path does. It only sets WL_SOCKET_READABLE if WL_SOC
Hi,
> > > But this is imo prohibitive. Yes, we're doing it for a long while. But
> > > no, that's not ok. It actually prompoted me into prototyping the latch
> > > thing (in some other thread). I don't think existing practice justifies
> > > expanding it further.
> >
> > I see, in that case, this
On 2014-10-02 17:47:39 +0900, Kyotaro HORIGUCHI wrote:
> Hello,
>
> > > I propose the attached patch. It adds a new flag ImmediateDieOK, which is
> > > a
> > > weaker form of ImmediateInterruptOK that only allows handling a pending
> > > die-signal in the signal handler.
> > >
> > > Robert, othe
Hello,
> > I propose the attached patch. It adds a new flag ImmediateDieOK, which is a
> > weaker form of ImmediateInterruptOK that only allows handling a pending
> > die-signal in the signal handler.
> >
> > Robert, others, do you see a problem with this?
>
> Per se I don't have a problem with
> >> Sorry, I missed this message and only cought up when reading your CF
> >> status mail. I've attached three patches:
> >
> > Could let me know how to get the CF status mail?
>
> I think he meant this email I sent last weekend:
>
> http://www.postgresql.org/message-id/542672d2.3060...@vmware.c
On 2014-09-26 21:02:16 +0300, Heikki Linnakangas wrote:
> I propose the attached patch. It adds a new flag ImmediateDieOK, which is a
> weaker form of ImmediateInterruptOK that only allows handling a pending
> die-signal in the signal handler.
>
> Robert, others, do you see a problem with this?
P
On 09/30/2014 10:05 AM, Kyotaro HORIGUCHI wrote:
By the way,
Sorry, I missed this message and only cought up when reading your CF
status mail. I've attached three patches:
Could let me know how to get the CF status mail?
I think he meant this email I sent last weekend:
http://www.postgresq
By the way,
> Sorry, I missed this message and only cought up when reading your CF
> status mail. I've attached three patches:
Could let me know how to get the CF status mail?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Wow, thank you for the patch.
> > > 0001: Allows WaitLatchOrSocket(WL_WRITABLE) without WL_READABLE. I've
> > > tested the poll() and select() implementations on linux and
> > > blindly patched up windows.
> > > 0002: Put the socket the backend uses to communicate with the client
> > >
Thank you for reviewing. I'll look close to the patch tomorrow.
> I must say this scares the heck out of me. The current code goes
> through some trouble to not throw an error while in a recv()
> send(). For example, you removed the DoingCommandRead check from
> prepare_for_client_read(). There's
On 2014-09-28 00:54:21 +0200, Andres Freund wrote:
> On 2014-09-27 21:12:43 +0200, Andres Freund wrote:
> > On 2014-09-03 15:09:54 +0300, Heikki Linnakangas wrote:
> > Sorry, I missed this message and only cought up when reading your CF
> > status mail. I've attached three patches:
> >
> > 0001: A
On 2014-09-03 15:09:54 +0300, Heikki Linnakangas wrote:
> On 09/03/2014 12:23 AM, Andres Freund wrote:
> >On 2014-09-02 17:21:03 -0400, Tom Lane wrote:
> >>Heikki Linnakangas writes:
> >>>I was going to suggest using WaitLatchOrSocket instead of sleeping in 1
> >>>second increment, but I see that
On 09/09/2014 01:31 PM, Kyotaro HORIGUCHI wrote:
Hi, I added and edited some comments.
Sorry, It tha patch contains a silly bug. Please find the
attatched one.
I must say this scares the heck out of me. The current code goes through
some trouble to not throw an error while in a recv() send()
Sorry for the mistake...
At Wed, 10 Sep 2014 18:53:03 +0300, Heikki Linnakangas
wrote in <541073df.70...@vmware.com>
> Wrong thread...
>
> On 09/10/2014 03:04 AM, Kyotaro HORIGUCHI wrote:
> > Hmm. Sorry, I misunderstood the specification.
> >
> >> You approach that coloring tokens seems right,
Wrong thread...
On 09/10/2014 03:04 AM, Kyotaro HORIGUCHI wrote:
Hmm. Sorry, I misunderstood the specification.
You approach that coloring tokens seems right, but you have
broken the parse logic by adding your code.
Other than the mistakes others pointed, I found that
- non-SQL-ident like to
Hmm. Sorry, I misunderstood the specification.
> You approach that coloring tokens seems right, but you have
> broken the parse logic by adding your code.
>
> Other than the mistakes others pointed, I found that
>
> - non-SQL-ident like tokens are ignored by their token style,
> quoted or not,
Hi, I added and edited some comments.
> Sorry, It tha patch contains a silly bug. Please find the
> attatched one.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From eb91a7c91e1fd3b24bf5bff0eb885f1c3d274637 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: Fri, 5 Sep 2014
Sorry, It tha patch contains a silly bug. Please find the
attatched one.
> Hello, attached is the new-and-far-simple version of this
> patch. It no longer depends on win32 nonblocking patch since the
> socket is in blocking mode again.
>
> > On 08/28/2014 03:47 PM, Kyotaro HORIGUCHI wrote:
> > >
Hello, attached is the new-and-far-simple version of this
patch. It no longer depends on win32 nonblocking patch since the
socket is in blocking mode again.
> On 08/28/2014 03:47 PM, Kyotaro HORIGUCHI wrote:
> > - Preventing protocol violation.
> >
> >To prevent protocol violation, secure_writ
Hello,
> > - This patch introduced redundant socket emulation for win32
> >backend but win32 bare socket for Port is already nonblocking
> >as described so it donsn't seem to be a serious problem on
> >performance. Addition to it, since I don't know the reason why
> >win32/socket.c
On Thu, Sep 4, 2014 at 9:53 AM, Heikki Linnakangas
wrote:
> On 09/04/2014 04:37 PM, Robert Haas wrote:
>> Hrm. So we'd have to block SIGUSR1, check the flag, then use
>> pselect() to temporarily unblock SIGUSR1 and wait, then on return
>> again unblock SIGUSR1? Doesn't seem very appealing. I th
On 09/04/2014 04:37 PM, Robert Haas wrote:
Hrm. So we'd have to block SIGUSR1, check the flag, then use
pselect() to temporarily unblock SIGUSR1 and wait, then on return
again unblock SIGUSR1? Doesn't seem very appealing. I think changing
the signal mask is fast on Linux, but quite slow on at
On Thu, Sep 4, 2014 at 9:05 AM, Heikki Linnakangas
wrote:
> Hmm. Perhaps we should call drainSelfPipe() only after poll/select returns
> saying that there is something in the self-pipe. That would be a win
> assuming it's more common for the self-pipe to be empty.
Couldn't hurt.
>> But my
>> imp
On 09/04/2014 03:49 PM, Robert Haas wrote:
On Tue, Sep 2, 2014 at 3:01 PM, Andres Freund wrote:
I'm slightly worried about the added overhead due to the latch code. In
my implementation I only use latches after a nonblocking read, but
still. Every WaitLatchOrSocket() does a drainSelfPipe(). I w
On Tue, Sep 2, 2014 at 3:01 PM, Andres Freund wrote:
> I'm slightly worried about the added overhead due to the latch code. In
> my implementation I only use latches after a nonblocking read, but
> still. Every WaitLatchOrSocket() does a drainSelfPipe(). I wonder if
> that can be made problematic.
On 09/03/2014 12:23 AM, Andres Freund wrote:
On 2014-09-02 17:21:03 -0400, Tom Lane wrote:
Heikki Linnakangas writes:
I was going to suggest using WaitLatchOrSocket instead of sleeping in 1
second increment, but I see that WaitLatchOrSocket() doesn't currently
support waiting for a socket to b
On 2014-09-02 17:21:03 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > I was going to suggest using WaitLatchOrSocket instead of sleeping in 1
> > second increment, but I see that WaitLatchOrSocket() doesn't currently
> > support waiting for a socket to become writeable, without also wai
Heikki Linnakangas writes:
> I was going to suggest using WaitLatchOrSocket instead of sleeping in 1
> second increment, but I see that WaitLatchOrSocket() doesn't currently
> support waiting for a socket to become writeable, without also waiting
> for it to become readable. I wonder how diffic
On 2014-09-02 21:01:44 +0200, Andres Freund wrote:
> I've actually been working on a patch to make the whole interaction with
> the client using sockets. The reason I started so is that we lots of far
> to complex stuff in signal handlers, and using a latch would allow us to
> instead interrupt sen
On 2014-09-02 21:46:29 +0300, Heikki Linnakangas wrote:
> I was going to suggest using WaitLatchOrSocket instead of sleeping in 1
> second increment, but I see that WaitLatchOrSocket() doesn't currently
> support waiting for a socket to become writeable, without also waiting for
> it to become read
On 08/28/2014 03:47 PM, Kyotaro HORIGUCHI wrote:
- Preventing protocol violation.
To prevent protocol violation, secure_write sets
ClientConnectionLost when SIGTERM detected, then
internal_flush() and ProcessInterrupts() follow the
instruction.
Oh, hang on. Now that I look at pqcom
On 08/28/2014 03:47 PM, Kyotaro HORIGUCHI wrote:
To make the code mentioned above (Patch 0002) tidy, rewrite the
socket emulation code for win32 backends so that each socket
can have its own non-blocking state. (patch 0001)
The first patch that makes non-blocking sockets behave more sa
Hello, sorry for the dazed reply in the previous mail.
I made revised patch for this issue.
Attached patches are following,
- 0001_Revise_socket_emulation_for_win32_backend.patch
Revises socket emulation on win32 backend so that each socket
can have its own blocking mode state.
- 0002_Allo
Hello,
> > I condiered it but select() frequently (rather in most cases when
> > send() blocks by send buffer exhaustion) fails to predict that
> > following send() will be blocked. (If my memory is correct.) So
> > the final problem would be blocked send()...
>
> My point was to put the socket
On 08/26/2014 09:17 AM, Kyotaro HORIGUCHI wrote:
but I don't think we want to define the behavior as "usually,
pq_terminate_backend() will kill a backend that's blocked on sending
to the client, but sometimes you have to call it twice (or more!) to
really kill it".
I agree that it is desirable
Sorry, I was absorbed by other tasks..
Thank you for reviewing thiis.
> On 07/01/2014 06:26 AM, Kyotaro HORIGUCHI wrote:
> > At Mon, 30 Jun 2014 11:27:47 -0400, Robert Haas
> > wrote in
> >
> >> 1. I think it's the case that there are platforms around where a
> >> signal won't cause send() to r
On 07/01/2014 06:26 AM, Kyotaro HORIGUCHI wrote:
At Mon, 30 Jun 2014 11:27:47 -0400, Robert Haas wrote in
1. I think it's the case that there are platforms around where a
signal won't cause send() to return EINTR and I'd be entirely
unsurprised if SSL_write() doesn't necessarily return EI
Hello, thank you for keeping this discussion moving.
> > I think there's no such a reasonable time. The behavior might
> > should be determined from another point.. On alternative would be
> > let pg_terminate_backend() have a parameter instructing force
> > shutodwn (how to propagate it?), or mak
Hello,
At Tue, 1 Jul 2014 21:21:38 +0200, Martijn van Oosterhout
wrote in <20140701192138.gb20...@svana.org>
> On Tue, Jul 01, 2014 at 12:26:43PM +0900, Kyotaro HORIGUCHI wrote:
> > > 1. I think it's the case that there are platforms around where a
> > > signal won't cause send() to return EINTR
On Tue, Jul 01, 2014 at 12:26:43PM +0900, Kyotaro HORIGUCHI wrote:
> > 1. I think it's the case that there are platforms around where a
> > signal won't cause send() to return EINTR and I'd be entirely
> > unsurprised if SSL_write() doesn't necessarily return EINTR in that
> > case. I'm not su
On Mon, Jun 30, 2014 at 11:26 PM, Kyotaro HORIGUCHI
wrote:
>> 2. I think it would be reasonable to try to kill off the connection
>> without notifying the client if we're unable to send the data to the
>> client in a reasonable period of time. But I'm unsure what "a
>> reasonable period of time"
Hello, The replies follow are mainly as a memo for myself so
please don't be bothered to answer until the time comes.
At Mon, 30 Jun 2014 11:27:47 -0400, Robert Haas wrote
in
> You should probably add your patch here, so it doesn't get forgotten about:
>
> https://commitfest.postgresql.org/act
On Mon, Jun 30, 2014 at 4:13 AM, Kyotaro HORIGUCHI
wrote:
> Hello, I have received inquiries related to blocked communication
> several times for these weeks with different symptoms. Then I
> found this message from archive,
>
> http://postgresql.1045698.n5.nabble.com/Escaping-a-blocked-sendto-sys
Hello, I have received inquiries related to blocked communication
several times for these weeks with different symptoms. Then I
found this message from archive,
http://postgresql.1045698.n5.nabble.com/Escaping-a-blocked-sendto-syscall-without-causing-a-restart-td5740855.html
> Subject: Escaping a
69 matches
Mail list logo
