On Thu, Jan 20, 2011 at 9:53 PM, Bernd Helmle 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() as
> far as the DEB
--On 22. Dezember 2010 15:51:09 +0900 Fujii Masao
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 for the current CF an
On Wed, Dec 22, 2010 at 12:14 PM, Tom Lane wrote:
> Fujii Masao 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 patch.
Regards,
--
Fujii Masao
N
Fujii Masao 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 (pgsql-hackers@postgresql.org)
T
On Sat, Dec 18, 2010 at 1:00 AM, Robert Haas wrote:
> On Fri, Dec 17, 2010 at 10:27 AM, Tom Lane wrote:
>> Robert Haas 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
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 mas
On Tue, Dec 21, 2010 at 2:33 PM, Robert Haas 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
--
Sent via pgsq
On Tue, Dec 21, 2010 at 1:45 PM, Eric Ridge wrote:
> On Mon, Dec 20, 2010 at 3:36 PM, Martijn van Oosterhout
> 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 proce
On Mon, Dec 20, 2010 at 3:36 PM, Martijn van Oosterhout
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 be a BSDis
On Mon, Dec 20, 2010 at 3:14 PM, Robert Haas wrote:
> On Mon, Dec 20, 2010 at 3:11 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Mon, Dec 20, 2010 at 2:23 PM, Tom Lane wrote:
I like that better actually ... one less thing for developers to get wrong.
>>
>>> The attached patch appears t
On Mon, Dec 20, 2010 at 3:36 PM, Martijn van Oosterhout
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
> forever though, so I
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 men
On Mon, Dec 20, 2010 at 3:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Dec 20, 2010 at 2:23 PM, Tom Lane 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()
Robert Haas writes:
> On Mon, Dec 20, 2010 at 2:23 PM, Tom Lane 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 process returns gdb's pid. Poor!
Looks
On Mon, Dec 20, 2010 at 2:23 PM, Tom Lane wrote:
> Robert Haas 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().
>
Robert Haas 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 less thing for devel
On Mon, Dec 20, 2010 at 2:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Dec 20, 2010 at 1:26 PM, Tom Lane wrote:
>>> Robert Haas 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()?
>>>
Robert Haas writes:
> On Mon, Dec 20, 2010 at 1:26 PM, Tom Lane wrote:
>> Robert Haas 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 that you can't know what to issue kill() against.
On Mon, Dec 20, 2010 at 1:26 PM, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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 what's happeni
On Mon, Dec 20, 2010 at 8:20 AM, Alvaro Herrera
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
>> PostmasterIsAlive to return
Alvaro Herrera 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 to zero in long-lived w
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 stu
On Sat, Dec 18, 2010 at 1:24 AM, Alvaro Herrera
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 SignalSomeChild
On 17.12.2010 19:08, Robert Haas wrote:
On Fri, Dec 17, 2010 at 11:43 AM, Tom Lane wrote:
Alvaro Herrera 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 walsende
On Fri, Dec 17, 2010 at 11:43 AM, Tom Lane wrote:
> Alvaro Herrera 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.
>
Alvaro Herrera 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 that walsenders are t
Excerpts from Tom Lane's message of vie dic 17 13:18:35 -0300 2010:
> Alvaro Herrera 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 tha
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, i
On Fri, Dec 17, 2010 at 11:18 AM, Tom Lane 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 distinction are in fac
Alvaro Herrera 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 the child. The
flag i
Robert Haas writes:
> On Fri, Dec 17, 2010 at 10:27 AM, Tom Lane 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 which
>> can be rather expensive
Excerpts from Tom Lane's message of vie dic 17 12:27:30 -0300 2010:
> Robert Haas 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 d
On Fri, Dec 17, 2010 at 10:27 AM, Tom Lane wrote:
> Robert Haas 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 invo
Robert Haas 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 rather expensive (se
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 wrote:
> > I found a bug which always prevents SignalSomeChildren with
> > BACKEND_TYPE_WALSND from sending a signal to walsender.
> >
> > Though currently SignalSomeChildren with
On Tue, Dec 14, 2010 at 10:54 PM, Fujii Masao 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 hard to believe tha
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 fol
38 matches
Mail list logo
