Alvaro Herrera writes:
> Tom Lane wrote:
>> The attached patch passes "make check-world" for me. Can you check it
>> against BDR?
> Just checked. It works fine.
Thanks! I'll push it shortly.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> It looks to me like the reason for it is simply not having bothered to
> >> copy the rw->rw_worker data to somewhere that would survive deletion
> >> of the PostmasterContext. I wonder though if anyone remembers a more
> >> fundame
Alvaro Herrera writes:
> Tom Lane wrote:
>> It looks to me like the reason for it is simply not having bothered to
>> copy the rw->rw_worker data to somewhere that would survive deletion
>> of the PostmasterContext. I wonder though if anyone remembers a more
>> fundamental reason? Surely the bgw
Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Aug 1, 2016 at 4:18 PM, Tom Lane wrote:
> >> Now, I'm undecided whether to flush that context only in parallel workers,
> >> or to try to make it go away for all bgworkers of any stripe. The latter
> >> seems a little better from a security stand
Robert Haas writes:
> On Mon, Aug 1, 2016 at 4:18 PM, Tom Lane wrote:
>> Now, I'm undecided whether to flush that context only in parallel workers,
>> or to try to make it go away for all bgworkers of any stripe. The latter
>> seems a little better from a security standpoint, but I wonder if any
Robert Haas writes:
> On Mon, Aug 1, 2016 at 7:42 PM, Tom Lane wrote:
>> ... This is what makes me dubious that getting rid
>> of doing work in the postmaster's signal handlers is really going
>> to add any noticeable increment of safety. It might make the
>> code look cleaner, but I'm afraid i
On Mon, Aug 1, 2016 at 7:42 PM, Tom Lane wrote:
> Thomas Munro writes:
>> I found this apparently unresolved bug report about glibc fork()
>> inside a signal handler deadlocking:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=4737
>
>> I wonder if that could bite postmaster.
>
> I seriously d
Thomas Munro writes:
> I found this apparently unresolved bug report about glibc fork()
> inside a signal handler deadlocking:
> https://sourceware.org/bugzilla/show_bug.cgi?id=4737
> I wonder if that could bite postmaster.
I seriously doubt it. The key thing about the postmaster is that
it run
On 2016-08-02 11:27:25 +1200, Thomas Munro wrote:
> On Tue, Aug 2, 2016 at 10:28 AM, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2016-08-01 18:09:03 -0400, Robert Haas wrote:
> >>> (Also vaguely on the list of things to clean up: can't we make it so
> >>> that bgworkers aren't launched from
On Tue, Aug 2, 2016 at 10:28 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2016-08-01 18:09:03 -0400, Robert Haas wrote:
>>> (Also vaguely on the list of things to clean up: can't we make it so
>>> that bgworkers aren't launched from inside a signal handler? Blech.)
>
>> Isn't pretty much ev
Andres Freund writes:
> Personally I think the whole logic should be reworked so we do most of
> that that only from one place.
Alvaro already mentioned a couple of reasons why that might not be so
easy.
> Especially the signal handler stuff
> should imo just be replaced by setting latch, which
On 2016-08-01 18:28:44 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-08-01 18:09:03 -0400, Robert Haas wrote:
> >> (Also vaguely on the list of things to clean up: can't we make it so
> >> that bgworkers aren't launched from inside a signal handler? Blech.)
>
> > Isn't pretty much e
Tom Lane wrote:
> Andres Freund writes:
> > On 2016-08-01 18:09:03 -0400, Robert Haas wrote:
> >> (Also vaguely on the list of things to clean up: can't we make it so
> >> that bgworkers aren't launched from inside a signal handler? Blech.)
>
> > Isn't pretty much everything on-demand below post
Andres Freund writes:
> On 2016-08-01 18:09:03 -0400, Robert Haas wrote:
>> (Also vaguely on the list of things to clean up: can't we make it so
>> that bgworkers aren't launched from inside a signal handler? Blech.)
> Isn't pretty much everything on-demand below postmaster started from a
> sign
Robert Haas writes:
> (Also vaguely on the list of things to clean up: can't we make it so
> that bgworkers aren't launched from inside a signal handler? Blech.)
So are other postmaster children, I believe. We could probably try
to rewrite the postmaster to not do useful work in signal handlers
On 2016-08-01 18:09:03 -0400, Robert Haas wrote:
> (Also vaguely on the list of things to clean up: can't we make it so
> that bgworkers aren't launched from inside a signal handler? Blech.)
Isn't pretty much everything on-demand below postmaster started from a
signal handler?
--
Sent via pgsq
On Mon, Aug 1, 2016 at 4:18 PM, Tom Lane wrote:
> I noticed $subject while fooling around with the tqueue.c memory leak
> issues. This does not seem like a good idea to me. At the very least,
> it's a waste of space that could be used for something else, and at the
> worst, it might be a securit
17 matches
Mail list logo
