From: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
---|---|
To: | 'Thomas Munro' <thomas(dot)munro(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: A test for replay of regression tests |
Date: | 2021-04-23 06:27:25 |
Message-ID: | OSAPR01MB2977FC83B77A4B7977742EE0FE459@OSAPR01MB2977.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
> We have automated tests for many specific replication and recovery scenarios,
> but nothing that tests replay of a wide range of records.
> People working on recovery code often use installcheck (presumably along
> with other custom tests) to exercise it, sometimes with
> wal_consistency_check enabled. So, why don't we automate that? Aside
> from exercising the WAL decoding machinery (which brought me here), that'd
> hopefully provide some decent improvements in coverage of the various redo
> routines, many of which are not currently exercised at all.
>
> I'm not quite sure where it belongs, though. The attached initial sketch patch
I think that's a good attempt. It'd be better to confirm that the database contents are identical on the primary and standby. But... I remember when I ran make installcheck with a standby connected, then ran pg_dumpall on both the primary and standby and compare the two output files, about 40 lines of difference were observed. Those differences were all about the sequence values. I didn't think about whether I should/can remove the differences.
+# XXX The tablespace tests don't currently work when the standby shares a
+# filesystem with the primary due to colliding absolute paths. We'll skip
+# that for now.
Maybe we had better have a hidden feature that creates tablespace contents in
/tablespace_location/PG_..._<some_name>/
<some_name> is the value of cluster_name or application_name.
Or, we may provide a visible feature that allows users to store tablespace contents in a specified directory regardless of the LOCATION value in CREATE TABLESPACE. For instance, add a GUC like
table_space_directory = '/some_dir'
Then, the tablespace contents are stored in /some_dir/<tablespace_name>/. This may be useful if a DBaaS provider wants to offer some tablespace-based feature, say tablespace transparent data encryption, but doesn't want users to specify filesystem directories.
Regards
Takayuki Tsunakawa
From | Date | Subject | |
---|---|---|---|
Next Message | osumi.takamichi@fujitsu.com | 2021-04-23 06:34:12 | RE: Truncate in synchronous logical replication failed |
Previous Message | Ajin Cherian | 2021-04-23 05:57:34 | Re: logical replication empty transactions |