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
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) save a C
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 Sat, Jan 10, 2015 at 11:35 AM, Andres Freund and...@2ndquadrant.com 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
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 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
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 and...@2ndquadrant.com
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 committed independently.
The key open question is whether all platforms
On 2014-09-04 08:49:22 -0400, Robert Haas wrote:
On Tue, Sep 2, 2014 at 3:01 PM, Andres Freund and...@2ndquadrant.com 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
On 2014-11-17 18:22:54 +0300, Alex Shulgin wrote:
Andres Freund and...@2ndquadrant.com 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
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, so it's
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. What
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
least
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
On Thu, Oct 30, 2014 at 10:27 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
Andres Freund and...@2ndquadrant.com 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
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
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 read or
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
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
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
any need for
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
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 and like
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
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.com
I see,
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 it. There
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, others, do you see a
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 approach seems
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 an
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
into
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
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?
Per
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: Allows
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 hlinnakan...@vmware.com writes:
I was going to suggest using WaitLatchOrSocket instead of sleeping in 1
second increment, but I
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()
Sorry for the mistake...
At Wed, 10 Sep 2014 18:53:03 +0300, Heikki Linnakangas
hlinnakan...@vmware.com 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
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
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
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, so
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 provides
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_write sets
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:
-
On Tue, Sep 2, 2014 at 3:01 PM, Andres Freund and...@2ndquadrant.com 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
On 09/04/2014 03:49 PM, Robert Haas wrote:
On Tue, Sep 2, 2014 at 3:01 PM, Andres Freund and...@2ndquadrant.com 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
On Thu, Sep 4, 2014 at 9:05 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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
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:53 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On 09/03/2014 12:23 AM, Andres Freund wrote:
On 2014-09-02 17:21:03 -0400, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
I was going to suggest using WaitLatchOrSocket instead of sleeping in 1
second increment, but I see that WaitLatchOrSocket() doesn't currently
support
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
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
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
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
Heikki Linnakangas hlinnakan...@vmware.com 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.
On 2014-09-02 17:21:03 -0400, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com 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,
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.
-
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
robertmh...@gmail.com wrote in
CA+TgmoZfcGzAEmtbyoCe6VdHnq085x+ox752zuJ2AKN=wc8...@mail.gmail.com
1. I think it's the
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
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 in
On 07/01/2014 06:26 AM, Kyotaro HORIGUCHI wrote:
At Mon, 30 Jun 2014 11:27:47 -0400, Robert Haas robertmh...@gmail.com wrote in
CA+TgmoZfcGzAEmtbyoCe6VdHnq085x+ox752zuJ2AKN=wc8...@mail.gmail.com
1. I think it's the case that there are platforms around where a
signal won't cause send() to
Hello,
At Tue, 1 Jul 2014 21:21:38 +0200, Martijn van Oosterhout klep...@svana.org
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
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 make a
On Mon, Jun 30, 2014 at 11:26 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp 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
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 sure
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
On Mon, Jun 30, 2014 at 4:13 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp 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,
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 robertmh...@gmail.com wrote
in CA+TgmoZfcGzAEmtbyoCe6VdHnq085x+ox752zuJ2AKN=wc8...@mail.gmail.com
You should probably add your
67 matches
Mail list logo
