Question about HEAP_XMIN_COMMITTED
Hi
I did the following steps on PG.
1. Building a synchronous streaming replication environment.
2. Executing the following SQL statements on primary
(1) postgres=# CREATE EXTENSION pageinspect;
(2) postgres=# begin;
(3) postgres=# select txid_current();
(4) postgres=# create table mytest6(i int);
(6) postgres=# insert into mytest6 values(1);
(7) postgres=# commit;
3. Executing the following SQL statements on standby
(8) postgres=# select * from mytest6;
i
---
1
(1 row)
(9) postgres=# SELECT t_infomask FROM
heap_page_items(get_raw_page('pg_class', 0)) where t_xmin=502※;
t_infomask
2049
(1 row)
※502 is the transaction ID returned by step (3) above.
In the result of step (9),the value of the t_infomask field is 2049(0x801)
which means that HEAP_XMAX_INVALID
and HEAP_HASNULL flags were setted, but HEAP_XMIN_COMMITTED flag was not setted.
According to source , when step (8) was executed,SetHintBits function were
called to set HEAP_XMIN_COMMITTED.
however, the minRecoveryPoint value was not updated. So HEAP_XMIN_COMMITTED
flag was not setted successfully.
After CheckPoint, select from mytest6 again in another session, we can see
HEAP_XMIN_COMMITTED flag was setted.
So my question is that before checkpoint, HEAP_XMIN_COMMITTED flag was not
setted correctly, right?
Or we need to move minRecoveryPoint forword to make HEAP_XMIN_COMMITTED flag
setted correctly when first select
from mytest6.
Best Regards, LiuHuailing
--
以上
Liu Huailing
--
Liu Huailing
Development Department III
Software Division II
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
ADDR.: No.6 Wenzhu Road, Software Avenue,
Nanjing, 210012, China
TEL : +86+25-86630566-8439
COINS: 7998-8439
FAX : +86+25-83317685
MAIL : liuhuail...@cn.fujitsu.com
--
RE: SI messages sent when excuting ROLLBACK PREPARED command
> On Wed, Aug 11, 2021 at 03:14:11PM +0900, Michael Paquier wrote: > > I would just tweak the comment block at the top of what's being > > changed, as per the attached. Please let me know if there are any > > objections. > > And applied as of 710796f. Thanks for your comment and commit. I've changed the patch's commit fest status to 'committed'. https://commitfest.postgresql.org/34/3257/ Regards, Liu
RE: SI messages sent when excuting ROLLBACK PREPARED command
Hi, tom > >Hmmm, yeah, I think you're right. It probably doesn't make a big difference > >in > the real world --- anyone who's dependent on the performance of 2PC rollbaxks > is Doing It Wrong. > > But we'd have already done LocalExecuteInvalidationMessage when getting > out of the prepared transaction, so no other SI invals should be needed. > Yes, it does not make any error. > > But for the beginner, when understanding the code, it may make confused. > And for the developer, when developing based on this code, it may make > unnecessary handling added. > > So, I think it is better to optimize the code. > > Here is the patch. There was a problem with the before patch when testing. So resubmit it. Regards, Liu Huailing 0001-Disallow-sending-SI-messages-when-excuting-ROLLBACK.patch Description: 0001-Disallow-sending-SI-messages-when-excuting-ROLLBACK.patch
Segment fault when excuting SPI function On PG with commit 41c6a5be
Hi, all When I used SPI_execute_plan function on PG12 which commit 41c6a5be is used, Segment fault occurred. PS: If commit 41c6a5be is not used, this phenomenon will not happen. Reproduce: In a background process, the following steps are executed. -- StartTransactionCommand(); SPI_connect(); plan = SPI_prepare(query,0,NULL); ★the query is a SELECT SQL. SPI_keepplan(plan); SPI_finish(); CommitTransactionCommand(); StartTransactionCommand(); SPI_connect(); SPI_execute_plan(plan, NULL, NULL, true, 0); ★Segment fault -- Core stack: Stack trace of thread 43926: #0 0x00772f19 EnsurePortalSnapshotExists (postgres) #1 0x0064f85c _SPI_execute_plan (postgres) #2 0x0064fbd1 SPI_execute_plan (postgres) #3 0x7fbee784402e xxx (xxx.so) #4 0x7fbee78424ae (.so) #5 0x006e91f5 StartBackgroundWorker (postgres) #6 0x006f5e25 maybe_start_bgworkers (postgres) #7 0x006f6121 reaper (postgres) #8 0x7fbeedf48dc0 __restore_rt (libpthread.so.0) #9 0x7fbeebadf75b __select (libc.so.6) #10 0x006f6ea6 ServerLoop (postgres) #11 0x006f8c30 PostmasterMain (postgres) #12 0x00485d99 main (postgres) #13 0x7fbeeba0f873 __libc_start_main (libc.so.6) #14 0x00485e3e _start (postgres) Is there a bug in the commit 41c6a5be? Please confirm it. Regards, Liu Huailing
RE: SI messages sent when excuting ROLLBACK PREPARED command
Hi, tom Thanks for your reply. >Hmmm, yeah, I think you're right. It probably doesn't make a big difference >in the real world --- anyone who's dependent on the performance of 2PC >rollbaxks is Doing It Wrong. > But we'd have already done LocalExecuteInvalidationMessage when getting out > of the prepared transaction, so no other SI invals should be needed. Yes, it does not make any error. But for the beginner, when understanding the code, it may make confused. And for the developer, when developing based on this code, it may make unnecessary handling added. So, I think it is better to optimize the code. Here is the patch. Regards, liuhl -Original Message- From: Tom Lane Sent: Thursday, July 15, 2021 1:36 AM To: Liu, Huailing/刘 怀玲 Cc: pgsql-hack...@postgresql.org Subject: Re: SI messages sent when excuting ROLLBACK PREPARED command "liuhuail...@fujitsu.com" writes: > So, I think we needn't send SI messags when rollbacking the two-phase > transaction. > Or Does it has something special because of two-phase transaction? Hmmm, yeah, I think you're right. It probably doesn't make a big difference in the real world --- anyone who's dependent on the performance of 2PC rollbaxks is Doing It Wrong. But we'd have already done LocalExecuteInvalidationMessage when getting out of the prepared transaction, so no other SI invals should be needed. regards, tom lane twophase.patch Description: twophase.patch
SI messages sent when excuting ROLLBACK PREPARED command
Hi When reading the code FinishPreparedTransaction, I found that SI messages are sent when executing ROLLBACK PREPARED command. But according to AtEOXact_Inval function, we send the SI messages only when committing the transaction . So, I think we needn't send SI messags when rollbacking the two-phase transaction. Or Does it has something special because of two-phase transaction? Regards
