Hi,
I read the V6 patch and found something needs to be improved.
Prepared transactions should also be documented.
A value of zero (the default) disables the timeout.
+This timeout is not applied to prepared transactions. Only transactions
+with user connections are
I test the V4 patch and found the backend does't process SIGINT while it's in
secure_read.
And it seems not a good choice to report ERROR during secure_read, which will
turns into
FATAL "terminating connection because protocol synchronization was lost".
It might be much easier to terminate
> @@ -2036,8 +2035,8 @@ RestoreBlockImage(XLogReaderState *record, uint8
> block_id, char *page)
> char*ptr;
> PGAlignedBlock tmp;
>
> - if (block_id > record->record->max_block_id ||
> - !record->record->blocks[block_id].in_use)
> + if (block_id > XLogRecMaxBlockId(record) ||
> +
Hello hackers,
Commit 3f1ce97 refactored XLog record access macros, but missed in a few
places. I fixed this, and patch is attached.
--
Yuhang Qiu
0001-Simplify-xlogreader.c-with-XLogRec-macros.patch
Description: Binary data
I wrote a script and test on branch REL_[10-16]_STABLE, and do see performance
drop in REL_13_STABLE, which is about 1~2%.
scale round 10 11 12 13 14 15 16
1 1 7922.2 8018.3 8102.8 7838.3 7829.2 7870.0 7846.1
2 7922.4 7923.5
> Windows has CreateProcess, which isn't available elsewhere.
Yes, we still need fork() on *nix. So the solution is to reduce the
overhead of fork(). Attach to shared memory after fork() might be a
"Better shared memory management".
> This is one of the reasons for using a connection pooler like
Fork is an expensive operation[1]. The major cost is the mm(VMA PTE...) copy.
ARM is especially weak on fork, which will invalid TLB entries one by one, and
this is an expensive operation[2]. We could easily got 100% CPU on ARM machine.
We also meet fork problem in x86, but not as serious as
And one more question, what LogAccessExclusiveLocks in LogStandbySnapshot is
used for? Can We remove this.
> 2020年5月6日 上午10:36，邱宇航 写道：
>
> I mean that all resources protected by XLOG_STANDBY_LOCK should redo later.
> The semantics of XLOG_STANDBY_LOCK is still kept.
>
I mean that all resources protected by XLOG_STANDBY_LOCK should redo later.
The semantics of XLOG_STANDBY_LOCK is still kept.
> 2020年4月30日 下午7:12，Amit Kapila 写道：
>
> On Thu, Apr 30, 2020 at 4:07 PM 邱宇航 wrote:
>>
>> I noticed that in hot standby, XLOG_STANDBY_LOCK re
I noticed that in hot standby, XLOG_STANDBY_LOCK redo is sometimes block by
another query, and all the rest redo is blocked by this lock getting operation,
which is not good and often happed in my database, so the hot standby will be
left behind and master will store a lot of WAL which can’t be
10 matches
Mail list logo
