Yes, it is more appropriate to set a duration time to determine whether
secure_write() is stuck, but it is difficult to define how long the duration
time is.
in my first patch, I add a GUC to allow the user to set the time, or it can be
hardcoded if a time deemed reasonable is provided?
-
On 2021/09/22 1:14, 蔡梦娟(玊于) wrote:
Hi all, I want to know your opinion on this patch, or in what way do you think
we should solve this problem?
I agree that something like the patch (i.e., introduction of promotion
from cancel request to terminate one) is necessary for the fix. One concern
：回复：Queries that should be canceled will get stuck on secure_write function
I changed the implementation about this problem:
a) if the cancel query interrupt is from db for some reason, such as recovery
conflict, then handle it immediately, and cancel request is treated as
terminate request;
b
On Fri, Aug 27, 2021 at 4:10 PM Andres Freund wrote:
> On Fri, Aug 27, 2021, at 13:07, Robert Haas wrote:
> > On Fri, Aug 27, 2021 at 3:24 PM Andres Freund wrote:
> > > I wonder if we could improve the situation somewhat by using the
> > > non-blocking
> > > pqcomm functions in a few select plac
I changed the implementation about this problem:
a) if the cancel query interrupt is from db for some reason, such as recovery
conflict, then handle it immediately, and cancel request is treated as
terminate request;
b) if the cancel query interrupt is from client, then ignore as original way
I add a test to reproduce the problem, you can see the attachment for specific
content
during the last sleep time of the test, use pstack to get the stack of the
backend process, which is as follows:
#0 0x7f6ebdd744d3 in __epoll_wait_nocancel () from /lib64/libc.so.6
#1 0x007738d
Hi,
On Fri, Aug 27, 2021, at 13:07, Robert Haas wrote:
> On Fri, Aug 27, 2021 at 3:24 PM Andres Freund wrote:
> > I wonder if we could improve the situation somewhat by using the
> > non-blocking
> > pqcomm functions in a few select places. E.g. if elog.c's
> > send_message_to_frontend() sent it
On Fri, Aug 27, 2021 at 3:24 PM Andres Freund wrote:
> I wonder if we could improve the situation somewhat by using the non-blocking
> pqcomm functions in a few select places. E.g. if elog.c's
> send_message_to_frontend() sent its message via a new pq_endmessage_noblock()
> (which'd use the existi
Hi,
On 2021-08-27 08:27:38 -0400, Robert Haas wrote:
> On Tue, Aug 24, 2021 at 9:58 PM Fujii Masao
> wrote:
> > to report an error to a client, and then calls AbortCurrentTransaction()
> > to abort the transaction. If secure_write() called by EmitErrorReport()
> > gets stuck, a backend gets stuc
Hi,
On 2021-08-23 10:13:03 -0400, Robert Haas wrote:
> On Mon, Aug 23, 2021 at 4:15 AM 蔡梦娟(玊于) wrote:
> > I want to know why the interrupt is only handled when ProcDiePending is
> > true, I think query which is supposed to be canceled also should respond to
> > the signal.
>
> Well, if we're h
On Tue, Aug 24, 2021 at 9:58 PM Fujii Masao wrote:
> I was thinking that it's valid even if secure_write() doesn't react to
> pg_cancel_backend() because it's basically called outside transaction block,
> i.e., there is no longer transaction to cancel in that case. But there can be
> some cases wh
On 2021/08/25 2:30, Robert Haas wrote:
Hmm, maybe you're right. What about pg_cancel_backend()?
I was thinking that it's valid even if secure_write() doesn't react to
pg_cancel_backend() because it's basically called outside transaction block,
i.e., there is no longer transaction to cancel i
On Tue, Aug 24, 2021 at 1:15 AM Fujii Masao wrote:
> > Oh, you're right. But I guess a similar problem could also occur in
> > response to pg_terminate_backend(), no?
>
> There seems no problem in that case because pg_terminate_backend() causes
> a backend to set ProcDiePending to true in die() si
送：蔡梦娟(玊于) ; pgsql-hackers
; Andres Freund
主 题：Re: Queries that should be canceled will get stuck on secure_write function
On 2021/08/24 0:26, Alvaro Herrera wrote:
> Aren't we talking about query cancellations that occur in response to a
> standby delay limit? Those aren't in
On 2021/08/24 0:26, Alvaro Herrera wrote:
Aren't we talking about query cancellations that occur in response to a
standby delay limit? Those aren't in response to user action. What I
mean is that if the standby delay limit is exceeded, then we send a
query cancel; we expect the standby to can
On Mon, Aug 23, 2021 at 11:26 AM Alvaro Herrera wrote:
> Aren't we talking about query cancellations that occur in response to a
> standby delay limit? Those aren't in response to user action.
Oh, you're right. But I guess a similar problem could also occur in
response to pg_terminate_backend(),
On 2021-Aug-23, Robert Haas wrote:
> On Mon, Aug 23, 2021 at 10:45 AM Alvaro Herrera
> wrote:
> > Do we actually need new GUCs, though? I think we should never let an
> > unresponsive client dictate what the server does, because that opens the
> > door for uncooperative or malicious clients to
On Mon, Aug 23, 2021 at 10:45 AM Alvaro Herrera wrote:
> Do we actually need new GUCs, though? I think we should never let an
> unresponsive client dictate what the server does, because that opens the
> door for uncooperative or malicious clients to wreak serious havoc. I
> think the implementat
On 2021-Aug-23, Robert Haas wrote:
> On Mon, Aug 23, 2021 at 4:15 AM 蔡梦娟(玊于) wrote:
> > I want to know why the interrupt is only handled when ProcDiePending
> > is true, I think query which is supposed to be canceled also should
> > respond to the signal.
Yeah, I agree.
> Well, if we're halfway
On Mon, Aug 23, 2021 at 4:15 AM 蔡梦娟(玊于) wrote:
> I want to know why the interrupt is only handled when ProcDiePending is true,
> I think query which is supposed to be canceled also should respond to the
> signal.
Well, if we're halfway through sending a message to the client and we
abort the wr
Hi, all
Recently, I got a problem that the startup process of standby is stuck and
keeps in a waiting state. The backtrace of startup process shows that it is
waiting for a backend process which conflicts with recovery processing to exit,
the guc parameters max_standby_streaming_delay and max_
Hi, all
Recently, I got a problem that the startup process of standby is stuck and
keeps in a waiting state. The backtrace of startup process shows that it is
waiting for a backend process which conflicts with recovery processing to exit,
the guc parameters max_standby_streaming_delay and max
22 matches
Mail list logo
