Re: Re: transaction lost when delete clog file after normal shutdown

Yes, i think you're right. The tuple will be set to HEAP_XMIN_COMMITTED when doing the visibility checking, but don't you think it's a little weird? Or may cause some confusion?

Thanks,
Jet

Junwang Zhao<zhjwpku(at)gmail(dot)com&gt;&nbsp;在 2024年12月23日 周一 12:35 写道：

On Mon, Dec 23, 2024 at 12:17 PM 章晨曦(at)易景科技 <zhangchenxi(at)halodbtech(dot)com&gt; wrote:
&gt;
&gt; Hi there,
&gt;
&gt; I notice a little strange things of clog behaviours.
&gt;
&gt; When I create a test table, say, a_test, the table only contains a INT type column.
&gt;
&gt; postgres=# CREATE TABLE a_test (n INT);
&gt; CREATE TABLE
&gt;
&gt; and then insert one tuple:
&gt;
&gt; postgres=# INSERT INTO a_test VALUES (1);
&gt; INSERT 0 1
&gt;
&gt; And then quit, shutdown the database.
&gt; [jet(at)halodev-jet-01 pg_xact]$ pg_ctl stop
&gt; waiting for server to shut down....2024-12-23 12:05:46.568 CST [1340130] LOG:&nbsp; received fast shutdown request
&gt; 2024-12-23 12:05:46.577 CST [1340130] LOG:&nbsp; aborting any active transactions
&gt; 2024-12-23 12:05:46.579 CST [1340130] LOG:&nbsp; background worker "logical replication launcher" (PID 1340136) exited with exit code 1
&gt; 2024-12-23 12:05:46.579 CST [1340131] LOG:&nbsp; shutting down
&gt; 2024-12-23 12:05:46.583 CST [1340131] LOG:&nbsp; checkpoint starting: shutdown immediate
&gt; 2024-12-23 12:05:46.604 CST [1340131] LOG:&nbsp; checkpoint complete: wrote 21 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.002 s, sync=0.011 s, total=0.025 s; sync files=17, longest=0.005 s, average=0.001 s; distance=88 kB, estimate=88 kB; lsn=0/1554658, redo lsn=0/1554658
&gt; 2024-12-23 12:05:46.607 CST [1340130] LOG:&nbsp; database system is shut down
&gt;&nbsp; done
&gt; server stopped
&gt;
&gt; After database stopped, change to the pg_xact directory, and delete the clog file, and then create a dummy clog file.
&gt; [jet(at)halodev-jet-01 pg_xact]$ ls -ltr
&gt; total 8
&gt; -rw-rw-r--. 1 jet jet 8192 Dec 23 12:05 0000
&gt; [jet(at)halodev-jet-01 pg_xact]$ rm -f 0000
&gt; [jet(at)halodev-jet-01 pg_xact]$ dd if=/dev/zero of=./0000 bs=1024 count=8
&gt; 8+0 records in
&gt; 8+0 records out
&gt; 8192 bytes (8.2 kB, 8.0 KiB) copied, 8.5894e-05 s, 95.4 MB/s
&gt;
&gt; And then start the database.
&gt; [jet(at)halodev-jet-01 pg_xact]$ pg_ctl start
&gt; waiting for server to start....2024-12-23 12:06:01.935 CST [1340148] LOG:&nbsp; starting PostgreSQL 16.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4), 64-bit
&gt; 2024-12-23 12:06:01.936 CST [1340148] LOG:&nbsp; listening on IPv6 address "::1", port 5432
&gt; 2024-12-23 12:06:01.936 CST [1340148] LOG:&nbsp; listening on IPv4 address "127.0.0.1", port 5432
&gt; 2024-12-23 12:06:01.943 CST [1340148] LOG:&nbsp; listening on Unix socket "/tmp/.s.PGSQL.5432"
&gt; 2024-12-23 12:06:01.950 CST [1340151] LOG:&nbsp; database system was shut down at 2024-12-23 12:05:46 CST
&gt; 2024-12-23 12:06:01.956 CST [1340148] LOG:&nbsp; database system is ready to accept connections
&gt;&nbsp; done
&gt; server started
&gt;
&gt; The database started normally. But the INSERT transaction was lost:
&gt; [jet(at)halodev-jet-01 pg_xact]$ psql
&gt; psql (16.6)
&gt; Type "help" for help.
&gt;
&gt; postgres=# SELECT * FROM a_test;
&gt;&nbsp; n
&gt; ---
&gt; (0 rows)
&gt;
&gt; postgres=#
&gt;
&gt; BUT! If I do the same steps above, and the only difference is after INSERT,&nbsp; I just do a simple query SELECT * FROM a_test; the INSERT transaction still exists. How could this happen? What's the difference after SELECT?
&gt; [jet(at)halodev-jet-01 pg_xact]$ psql
&gt; psql (16.6)
&gt; Type "help" for help.
&gt;
&gt; postgres=# INSERT INTO a_test VALUES (1);
&gt; INSERT 0 1
&gt; postgres=# SELECT * FROM a_test;
&gt;&nbsp; n
&gt; ---
&gt;&nbsp; 1
&gt; (1 row)
&gt;
&gt; postgres=# \q
&gt; [jet(at)halodev-jet-01 pg_xact]$ pg_ctl stop
&gt; waiting for server to shut down....2024-12-23 12:13:36.577 CST [1340148] LOG:&nbsp; received fast shutdown request
&gt; 2024-12-23 12:13:36.583 CST [1340148] LOG:&nbsp; aborting any active transactions
&gt; 2024-12-23 12:13:36.584 CST [1340148] LOG:&nbsp; background worker "logical replication launcher" (PID 1340154) exited with exit code 1
&gt; 2024-12-23 12:13:36.585 CST [1340149] LOG:&nbsp; shutting down
&gt; 2024-12-23 12:13:36.587 CST [1340149] LOG:&nbsp; checkpoint starting: shutdown immediate
&gt; 2024-12-23 12:13:36.601 CST [1340149] LOG:&nbsp; checkpoint complete: wrote 2 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.006 s, total=0.017 s; sync files=2, longest=0.004 s, average=0.003 s; distance=0 kB, estimate=0 kB; lsn=0/15548E8, redo lsn=0/15548E8
&gt; 2024-12-23 12:13:36.603 CST [1340148] LOG:&nbsp; database system is shut down
&gt;&nbsp; done
&gt; server stopped
&gt; [jet(at)halodev-jet-01 pg_xact]$ rm -f 0000
&gt; [jet(at)halodev-jet-01 pg_xact]$ dd if=/dev/zero of=./0000 bs=1024 count=8
&gt; 8+0 records in
&gt; 8+0 records out
&gt; 8192 bytes (8.2 kB, 8.0 KiB) copied, 8.9862e-05 s, 91.2 MB/s
&gt; [jet(at)halodev-jet-01 pg_xact]$ pg_ctl start
&gt; waiting for server to start....2024-12-23 12:13:48.430 CST [1340205] LOG:&nbsp; starting PostgreSQL 16.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4), 64-bit
&gt; 2024-12-23 12:13:48.430 CST [1340205] LOG:&nbsp; listening on IPv6 address "::1", port 5432
&gt; 2024-12-23 12:13:48.430 CST [1340205] LOG:&nbsp; listening on IPv4 address "127.0.0.1", port 5432
&gt; 2024-12-23 12:13:48.437 CST [1340205] LOG:&nbsp; listening on Unix socket "/tmp/.s.PGSQL.5432"
&gt; 2024-12-23 12:13:48.445 CST [1340208] LOG:&nbsp; database system was shut down at 2024-12-23 12:13:36 CST
&gt; 2024-12-23 12:13:48.451 CST [1340205] LOG:&nbsp; database system is ready to accept connections
&gt;&nbsp; done
&gt; server started
&gt; [jet(at)halodev-jet-01 pg_xact]$ psql
&gt; psql (16.6)
&gt; Type "help" for help.
&gt;
&gt; postgres=# SELECT * FROM a_test;
&gt;&nbsp; n
&gt; ---
&gt;&nbsp; 1
&gt; (1 row)
&gt;
&gt; Jet
&gt;
&gt;
&gt;
&gt;
&gt;

Because after you do a select, the commit info of xmin/xmax has been set
to the tuple header, you don't need to check clog after that.

You can use the *pageinspect* extension to verify that.

--
Regards
Junwang Zhao