--On 22. Dezember 2010 15:51:09 +0900 Fujii Masao masao.fu...@gmail.com
wrote:
How about doing target != ALL test at the head for the most common case
(target == ALL)?
That's an idea, but the test you propose implements it incorrectly.
Thanks! I revised the patch.
I had a look at this
On Thu, Jan 20, 2011 at 9:53 PM, Bernd Helmle maili...@oopsware.de wrote:
I had a look at this for the current CF and the patch looks reasonable to
me. Some testing shows that the changes are working as intended (at least,
the wal sender actually receives now signals from SignalSomeChildren()
On Mon, Dec 20, 2010 at 3:14 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 20, 2010 at 3:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 20, 2010 at 2:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I like that better actually ... one less
On Mon, Dec 20, 2010 at 3:36 PM, Martijn van Oosterhout
klep...@svana.org wrote:
On Mon, Dec 20, 2010 at 03:08:02PM -0500, Robert Haas wrote:
The attached patch appears to work correctly on MacOS X. I did check,
BTW: getppid() in the attached process returns gdb's pid. Poor!
This appears to
On Tue, Dec 21, 2010 at 1:45 PM, Eric Ridge eeb...@gmail.com wrote:
On Mon, Dec 20, 2010 at 3:36 PM, Martijn van Oosterhout
klep...@svana.org wrote:
On Mon, Dec 20, 2010 at 03:08:02PM -0500, Robert Haas wrote:
The attached patch appears to work correctly on MacOS X. I did check,
BTW:
On Tue, Dec 21, 2010 at 2:33 PM, Robert Haas robertmh...@gmail.com wrote:
The point of the patch was to improve cases where attaching gdb
*didn't* work well. Any cases where it was already working for you
aren't going to be made worse by this.
Okay, great. Thanks for the clarification.
eric
Excerpts from Robert Haas's message of mar dic 21 08:40:49 -0300 2010:
Well, non-developers don't tend to attach gdb very often. Alvaro
mentioned a problem installation upthread, thus the question.
Hearing no cries of please-oh-please-backpatch-this, I've committed
it just to master.
On Sat, Dec 18, 2010 at 1:00 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 17, 2010 at 10:27 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I think the attached might be a little tidier. Thoughts?
I'm not really thrilled at the idea of calling
Fujii Masao masao.fu...@gmail.com writes:
How about doing target != ALL test at the head for the most common case
(target == ALL)?
That's an idea, but the test you propose implements it incorrectly.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Wed, Dec 22, 2010 at 12:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
How about doing target != ALL test at the head for the most common case
(target == ALL)?
That's an idea, but the test you propose implements it incorrectly.
Thanks! I revised the
Excerpts from Robert Haas's message of vie dic 17 14:08:04 -0300 2010:
I'm having a bit of trouble confirming this on MacOS X, though.
Attaching gdb to either the startup process or a WAL sender causes
PostmasterIsAlive to return false, resulting in a near-immediate exit.
Seems pretty stupid
Alvaro Herrera alvhe...@commandprompt.com writes:
... We have an open problem report on autovacuum failing to run after
some time, and we haven't been able to get a backtrace or strace because
of this issue ...
I wonder whether that's the already-fixed problem with autovacuum cost
limit going
On Mon, Dec 20, 2010 at 8:20 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of vie dic 17 14:08:04 -0300 2010:
I'm having a bit of trouble confirming this on MacOS X, though.
Attaching gdb to either the startup process or a WAL sender causes
Robert Haas robertmh...@gmail.com writes:
Attaching gdb to either the startup process or a WAL sender causes
PostmasterIsAlive to return false, resulting in a near-immediate exit.
Seems pretty stupid for attaching gdb to change the return value of
getppid() but it seems like that must be
On Mon, Dec 20, 2010 at 1:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Attaching gdb to either the startup process or a WAL sender causes
PostmasterIsAlive to return false, resulting in a near-immediate exit.
Seems pretty stupid for attaching gdb to
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 20, 2010 at 1:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Can we add a develop option to force use of the kill(0) method?
How will that avoid needing to have an honest answer from getppid()?
Without
On Mon, Dec 20, 2010 at 2:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 20, 2010 at 1:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Can we add a develop option to force use of the kill(0) method?
How will
Robert Haas robertmh...@gmail.com writes:
Another option that might be workable (but I have reservations, and
haven't tested it either) is to check whether the return value of
getppid() is equal to 1. If it's neither 1 nor PostmasterPid then try
kill().
I like that better actually ... one
On Mon, Dec 20, 2010 at 2:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Another option that might be workable (but I have reservations, and
haven't tested it either) is to check whether the return value of
getppid() is equal to 1. If it's neither 1 nor
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 20, 2010 at 2:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I like that better actually ... one less thing for developers to get wrong.
The attached patch appears to work correctly on MacOS X. I did check,
BTW: getppid() in the attached
On Mon, Dec 20, 2010 at 3:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 20, 2010 at 2:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I like that better actually ... one less thing for developers to get wrong.
The attached patch appears to work
On Mon, Dec 20, 2010 at 03:08:02PM -0500, Robert Haas wrote:
The attached patch appears to work correctly on MacOS X. I did check,
BTW: getppid() in the attached process returns gdb's pid. Poor!
This appears to be a BSDism at least. On Linux and BSD derivatives the
man pages specifically
On Mon, Dec 20, 2010 at 3:36 PM, Martijn van Oosterhout
klep...@svana.org wrote:
Frankly it's a wart, for example strace/truss/whatever could (since
it's tracing anyway) just fudge the correct value in the getppid() call
so the userspace process doesn't notice. This has been a bug since
On Sat, Dec 18, 2010 at 1:24 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Fujii Masao's message of mié dic 15 00:54:39 -0300 2010:
Hi,
I found a bug which always prevents SignalSomeChildren with
BACKEND_TYPE_WALSND from sending a signal to walsender.
Though currently
On Tue, Dec 14, 2010 at 10:54 PM, Fujii Masao masao.fu...@gmail.com wrote:
I found a bug which always prevents SignalSomeChildren with
BACKEND_TYPE_WALSND from sending a signal to walsender.
Though currently SignalSomeChildren with BACKEND_TYPE_WALSND
has not been called anywhere, it's not
Excerpts from Robert Haas's message of vie dic 17 10:08:04 -0300 2010:
On Tue, Dec 14, 2010 at 10:54 PM, Fujii Masao masao.fu...@gmail.com wrote:
I found a bug which always prevents SignalSomeChildren with
BACKEND_TYPE_WALSND from sending a signal to walsender.
Though currently
Robert Haas robertmh...@gmail.com writes:
I think the attached might be a little tidier. Thoughts?
I'm not really thrilled at the idea of calling
IsPostmasterChildWalSender for every child whether or not it will have
any impact on the decision. That involves touching shared memory which
can be
On Fri, Dec 17, 2010 at 10:27 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I think the attached might be a little tidier. Thoughts?
I'm not really thrilled at the idea of calling
IsPostmasterChildWalSender for every child whether or not it will have
any
Excerpts from Tom Lane's message of vie dic 17 12:27:30 -0300 2010:
Robert Haas robertmh...@gmail.com writes:
I think the attached might be a little tidier. Thoughts?
I'm not really thrilled at the idea of calling
IsPostmasterChildWalSender for every child whether or not it will have
any
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 17, 2010 at 10:27 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not really thrilled at the idea of calling
IsPostmasterChildWalSender for every child whether or not it will have
any impact on the decision. That involves touching shared memory
Alvaro Herrera alvhe...@commandprompt.com writes:
Is it possible to save the is walsender flag in the Backend struct?
That would make it possible to solve the problem very easily.
Yeah, I was wondering about that too, but the problem is that the
postmaster doesn't know that at the time it forks
On Fri, Dec 17, 2010 at 11:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think what we ought to be looking to do is get rid of the distinction,
so that the postmaster treats walsenders the same as other children.
It's not apparent to me that the existing places where postmaster.c
makes that
Excerpts from Fujii Masao's message of mié dic 15 00:54:39 -0300 2010:
Hi,
I found a bug which always prevents SignalSomeChildren with
BACKEND_TYPE_WALSND from sending a signal to walsender.
Though currently SignalSomeChildren with BACKEND_TYPE_WALSND
has not been called anywhere, it's
Excerpts from Tom Lane's message of vie dic 17 13:18:35 -0300 2010:
Alvaro Herrera alvhe...@commandprompt.com writes:
Is it possible to save the is walsender flag in the Backend struct?
That would make it possible to solve the problem very easily.
Yeah, I was wondering about that too, but
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of vie dic 17 13:18:35 -0300 2010:
I think what we ought to be looking to do is get rid of the distinction,
so that the postmaster treats walsenders the same as other children.
I think the problem with this is
On Fri, Dec 17, 2010 at 11:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of vie dic 17 13:18:35 -0300 2010:
I think what we ought to be looking to do is get rid of the distinction,
so that the postmaster treats
On 17.12.2010 19:08, Robert Haas wrote:
On Fri, Dec 17, 2010 at 11:43 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Alvaro Herreraalvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of vie dic 17 13:18:35 -0300 2010:
I think what we ought to be looking to do is get rid of the
Hi,
I found a bug which always prevents SignalSomeChildren with
BACKEND_TYPE_WALSND from sending a signal to walsender.
Though currently SignalSomeChildren with BACKEND_TYPE_WALSND
has not been called anywhere, it's not hard to believe that will
be called in the future. So we should apply the
38 matches
Mail list logo
