回复:回复:Fix missing initialization of delayChkptEnd

2023-06-07 Thread ()
) 14:13 收件人:蔡梦娟(玊于) 抄 送:pgsql-hackers ; robertmhaas 主 题:Re: 回复:Fix missing initialization of delayChkptEnd Good catch! At Tue, 06 Jun 2023 00:39:47 +0800, "蔡梦娟(玊于)" wrote in > Hi, all. I updated the patch for this bugfix, the previous one > missed the modification of function

modify error report in mdwrite/mdextend

2021-10-18 Thread ()
Hi, all I noticed that the "else" is missing during the error report after FileWrite() of mdwrite()/mdextend(), short write error is supposed to be reported when written bytes is not less than 0. I modified it in the attached patch: diff --git a/src/backend/storage/smgr/md.c b/src/backend/storag

Some doubts about streaming startpoint in WaitForWALToBecomeAvailable()

2021-10-14 Thread ()
Hi, all I have some doubts about the request xlog streaming startpoint in WaitForWALToBecomeAvailable(). In this function, RecPtr is the endpoint lsn we are waiting for, tliRecPtr is the position of the WAL record we are interested in, I want to know why use RecPtr rather than tliRecPtr as the

回复:回复:Queries that should be canceled will get stuck on secure_write function

2021-09-23 Thread ()
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? -

回复:Queries that should be canceled will get stuck on secure_write function

2021-09-21 Thread ()
Hi all, I want to know your opinion on this patch, or in what way do you think we should solve this problem? -- 发件人:蔡梦娟(玊于) 发送时间:2021年9月9日(星期四) 17:38 收件人:Robert Haas ; Andres Freund ; alvherre ; masao.fujii 抄 送:pgsql-hackers 主 题

回复:Queries that should be canceled will get stuck on secure_write function

2021-09-09 Thread ()
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

回复:Queries that should be canceled will get stuck on secure_write function

2021-09-06 Thread ()
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

Add guc to enable send SIGSTOP to peers when backend exits abnormally

2021-09-03 Thread ()
Hi all I want to share a patch with you, in which I add a guc parameter 'enable_send_stop' to enable set the value of SendStop in postmaster.c more conveniently. SendStop enable postmaster to send SIGSTOP rather than SIGQUIT to its children when some backend dumps core, and this variable is o

回复:Queries that should be canceled will get stuck on secure_write function

2021-08-24 Thread ()
 送:蔡梦娟(玊于) ; 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

Queries that should be canceled will get stuck on secure_write function

2021-08-23 Thread ()
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_

Queries that should be canceled will get stuck on secure_write function

2021-08-22 Thread ()
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

回复:Why don't update minimum recovery point in xact_redo_abort

2021-07-27 Thread ()
收件人:蔡梦娟(玊于) ; pgsql-hackers 主 题:Re: Why don't update minimum recovery point in xact_redo_abort On 2021/07/27 2:38, 蔡梦娟(玊于) wrote: > Hi, all > > Recently, I got a PANIC while restarts standby, which can be reproduced by > the following steps, based on pg 11: > 1. be

Why don't update minimum recovery point in xact_redo_abort

2021-07-26 Thread ()
Hi, all Recently, I got a PANIC while restarts standby, which can be reproduced by the following steps, based on pg 11: 1. begin a transaction in primary node; 2. create a table in the transaction; 3. insert lots of data into the table; 4. do a checkpoint, and restart standby after checkpoint is

回复:Bug on update timing of walrcv->flushedUpto variable

2021-04-12 Thread ()
-- 发件人:Kyotaro Horiguchi 发送时间:2021年3月29日(星期一) 09:54 收件人:蔡梦娟(玊于) 抄 送:bossartn ; x4mmm ; hlinnaka ; pgsql-hackers 主 题:Re: Bug on update timing of walrcv->flushedUpto variable Hi. (Added Nathan, Andrey and Heikki in Cc:) At Fri, 26 Mar 2021 23:44:21 +0800, "蔡梦娟(玊于)" wrote in &

Why reset pgstat during recovery

2021-04-02 Thread ()
Hi, all I want to know why call pgstat_reset_all function during recovery process, under what circumstances the data will be invalid after recovery? Thanks & Best Regard

Bug on update timing of walrcv->flushedUpto variable

2021-03-26 Thread ()
Hi, all Recently, I found a bug on update timing of walrcv->flushedUpto variable, consider the following scenario, there is one Primary node, one Standby node which streaming from Primary: There are a large number of SQL running in the Primary, and the length of the xlog record generated by the