Hi,
On 2023-08-02 12:35:19 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2020-09-11 11:52:55 -0400, Tom Lane wrote:
> >> It's simple enough that maybe we could back-patch it, once it's
> >> aged awhile in HEAD. OTOH, given the lack of field reports of
> >> trouble here, I'm not sure back
Andres Freund writes:
> On 2020-09-11 11:52:55 -0400, Tom Lane wrote:
>> It's simple enough that maybe we could back-patch it, once it's
>> aged awhile in HEAD. OTOH, given the lack of field reports of
>> trouble here, I'm not sure back-patching is worth the risk.
> FWIW, looking at collected st
Hi,
On 2020-09-11 11:52:55 -0400, Tom Lane wrote:
> It's simple enough that maybe we could back-patch it, once it's
> aged awhile in HEAD. OTOH, given the lack of field reports of
> trouble here, I'm not sure back-patching is worth the risk.
FWIW, looking at collected stack traces in azure, ther
I wrote:
> I looked briefly at the idea of postponing ProcessStartupPacket
> until InitPostgres has set up a fairly normal environment. It
> seems like it'd take a fair amount of refactoring. I really
> doubt it's worth the effort, even though the result would be
> arguably cleaner logic than wha
I wrote:
> I'll take a closer look at the idea of using _exit(1) tomorrow,
> but I'd be pretty hesitant to back-patch that.
Here's a patch for that; it passes light testing, including forcing
the backend through the SIGTERM and timeout code paths. There's
not much to it except for changing the si
Robert Haas writes:
> On Thu, Sep 10, 2020 at 12:56 PM Tom Lane wrote:
>> Also, man that CHECK_FOR_INTERRUPTS() looks like trouble.
>> Could we take that out?
> Maybe I'm missing something, but why wouldn't that be a horrible idea?
> We do not want to have long waits where we refuse to respond t
On Thu, Sep 10, 2020 at 12:56 PM Tom Lane wrote:
> Also, man that CHECK_FOR_INTERRUPTS() looks like trouble.
> Could we take that out?
Maybe I'm missing something, but why wouldn't that be a horrible idea?
We do not want to have long waits where we refuse to respond to
interrupts.
--
Robert Haa
Robert Haas writes:
> On Wed, Sep 9, 2020 at 10:07 PM Tom Lane wrote:
>> bgworker_die (SIGTERM)
>> Calls ereport(FATAL). This is surely not any safer than, say,
>> quickdie(). No, it's worse, because at least that won't try
>> to go out via proc_exit().
> I think bgworker_die() is pretty much
On Wed, Sep 9, 2020 at 10:07 PM Tom Lane wrote:
> bgworker_die (SIGTERM)
>
> Calls ereport(FATAL). This is surely not any safer than, say,
> quickdie(). No, it's worse, because at least that won't try
> to go out via proc_exit().
I think bgworker_die() is pretty much a terrible idea. Every
back
At Wed, 09 Sep 2020 10:46:28 -0400, Tom Lane wrote in
> > I also think we should
> > back-patch these changes, as the commit mentioned in Horiguchi-san's
> > patch for pgarch_exit() was.
>
> Agreed; I'll go make it happen.
Thank you for committing this!
regards.
--
Kyotaro Horiguchi
NTT Open
From: Tom Lane
> This is straying a bit from the stated topic of this thread, but ...
> I did some further looking around to see whether there were any
> unsafe signal handlers besides SIGQUIT ones. The situation is not
> too awful, but I did find several issues not already mentioned
> in this th
I wrote:
> Of course, this is only safe if the SIGQUIT handler is safe to be invoked
> anywhere, so I did a quick survey of backend signal handlers to see if
> that is true.
This is straying a bit from the stated topic of this thread, but ...
I did some further looking around to see whether there
Here's a draft patch that I think would be reasonable to back-patch.
(Before v13, we'd need a bespoke SIGQUIT handler to substitute for
SignalHandlerForCrashExit, but that's easy enough.)
Aside from comment updates, this
* uses SignalHandlerForCrashExit for SIGQUIT
* renames startup_die per your
I wrote:
>> Not only DNS, but all the various auth libraries would have to be
>> contended with. Lots of work there compared to the likely rewards.
> Wait a minute. The entire authentication cycle happens inside
> InitPostgres, using the backend's normal signal handlers. So
> maybe we are overt
Hi,
On 2020-09-09 16:30:37 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2020-09-09 16:09:00 -0400, Tom Lane wrote:
> >> We could call it startup_packet_die or something?
>
> > Yea, I think that'd be good.
>
> I'll make it so.
Thanks!
> >> We see backends going through this code on a
I wrote:
> Not only DNS, but all the various auth libraries would have to be
> contended with. Lots of work there compared to the likely rewards.
Wait a minute. The entire authentication cycle happens inside
InitPostgres, using the backend's normal signal handlers. So
maybe we are overthinking
Andres Freund writes:
> On 2020-09-09 16:09:00 -0400, Tom Lane wrote:
>> We could call it startup_packet_die or something?
> Yea, I think that'd be good.
I'll make it so.
>> We see backends going through this code on a very regular basis in the
>> buildfarm, but complete hangs are rare as can b
Hi,
On 2020-09-09 16:09:00 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I wish startup_die() weren't named startup_ - every single time I see
> > the name I think it's about the startup process...
>
> We could call it startup_packet_die or something?
Yea, I think that'd be good.
> > I t
Andres Freund writes:
> I wish startup_die() weren't named startup_ - every single time I see
> the name I think it's about the startup process...
We could call it startup_packet_die or something?
> I think StartupPacketTimeoutHandler is another case?
Yeah. Although it's a lot less risky, sinc
Hi,
On 2020-09-08 17:39:24 -0400, Tom Lane wrote:
> Of course, this is only safe if the SIGQUIT handler is safe to be invoked
> anywhere, so I did a quick survey of backend signal handlers to see if
> that is true. I immediately found pgarch_exit() which surely is not. It
> turns out that Horigu
I wrote:
> Stephen Frost writes:
>> As I mentioned over there, I agree that we should do this and we should
>> further have the statistics collector also do so, which currently sets
>> up SIGQUIT with ShutdownRequestPending() and in its loop decides it's
>> fine to write out the stats file (which
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Of course, this is only safe if the SIGQUIT handler is safe to be invoked
>> anywhere, so I did a quick survey of backend signal handlers to see if
>> that is true. I immediately found pgarch_exit() which surely is not. It
>> turn
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> This is to pull together a couple of recent threads that are seemingly
> unrelated to $SUBJECT.
>
> Over in the long thread at [1] we've agreed to try to make the backend
> code actually do what assorted comments claim it does, namely allow
> SI
This is to pull together a couple of recent threads that are seemingly
unrelated to $SUBJECT.
Over in the long thread at [1] we've agreed to try to make the backend
code actually do what assorted comments claim it does, namely allow
SIGQUIT to be accepted at any point after a given process has est
24 matches
Mail list logo
