> 2025年9月23日 15:38，David Rowley 写道：
>
> If you check the release notes and the commit message for f5050f795
> you'll see that it does mention that wrong results could be returned.
>
> What wasn't mentioned was that this wasn't fixed in prior versions.
> The reason being is that the fix required
I've noticed that two GROUP BY ROLLUP queries behave differently in v17
compared to master and REL_18_STABLE. The issue can be reproduced by
following SQL:
``` SQL
CREATE TABLE t(id int);
INSERT INTO t SELECT generate_series(1, 3);
-- Query 1
SELECT DISTINCT 'XXX'
FROM t
GROUP BY ROLLUP (id, 1);
> 2025年8月26日 11:59，Jingtang Zhang 写道：
>
> Hi~
>
>> I purpose a patch which calls smgrdestroyall() when redo each
>> XLOG_CHECKPOINT_ONLINE, so that it can keep the same frequency of calling
>> smgrdestroyall() as background processes on primary. I don't call it for
>> XLOG_CHECKPOINT_SHUTDOWN be
> 2025年8月21日 23:07，Jingtang Zhang 写道：
>
> Also, in this situation, should startup process be treated as a background
> worker similar to bgwriter/checkpointer and call smgrdestroyall in some
> period?
Agree with that. Maybe we can call smgrdestroyall in startup process when
replaying CHECKPOINT
While reading code, I notice off in mdfd is an uint32, which might be
problematic. Considering enlarge segsize to 8GB and even larger, the off
might be overflowed. So I change it to off_t.
Best regards,
Yuhang Qiu
0001-Change-off-in-mdfd-from-uint32-to-off_t.patch
Description: Binary data
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 affec
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 the
> @@ -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) ||
> + !XLogRecG
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 8090
> 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 p
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 arm
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 redo
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
15 matches
Mail list logo
