> Thanks to Ashutosh Sharma for doing the testing of the patch and > helping me in analyzing some of the above issues.
Hi All, I would like to summarize the test-cases that i have executed for validating WAL logging in hash index feature. 1) I have mainly ran the pgbench test with read-write workload at the scale factor of 1000 and various client counts like 16, 64 and 128 for time duration of 30 mins, 1 hr and 24 hrs. I have executed this test on highly configured power2 machine with 128 cores and 512GB of RAM. I ran the test-case both with and without the replication setup. Please note that i have changed the schema of pgbench tables created during initialisation phase. The new schema of pgbench tables looks as shown below on both master and standby: postgres=# \d pgbench_accounts Table "public.pgbench_accounts" Column | Type | Modifiers ----------+---------------+----------- aid | integer | not null bid | integer | abalance | integer | filler | character(84) | Indexes: "pgbench_accounts_pkey" PRIMARY KEY, btree (aid) "pgbench_accounts_bid" hash (bid) postgres=# \d pgbench_history Table "public.pgbench_history" Column | Type | Modifiers --------+-----------------------------+----------- tid | integer | bid | integer | aid | integer | delta | integer | mtime | timestamp without time zone | filler | character(22) | Indexes: "pgbench_history_bid" hash (bid) 2) I have also made use of the following tools for analyzing the hash index tables created on master and standby. a) pgstattuple : Using this tool, i could verfiy the tuple level statistics which includes index table physical length, dead tuple percentageand other infos on both master and standby. However, i could see below error message when using this tool for one of the hash index table on both master and standby server. postgres=# SELECT * FROM pgstattuple('pgbench_history_bid'); ERROR: index "pgbench_history_bid" contains unexpected zero page at block 2482297 To investigate on this, i made use of pageinspect contrib module and came to know that above block contains an uninitialised page. But, this is quite possible in hash index as here the bucket split happens in the power-of-2 and we may find some of the uninitialised bucket pages. b) pg_filedump : Using this tool, i could take a dump of all the hash index tables on master and standy and compare the dump file to verify if there is any difference between hash index pages on both master and standby. In short, this is all i did to verify the patch for wal logging in hash index. I would like thank Amit and Robert for their valuable inputs during the hash index testing phase. I am also planning to verify wal logging in hash index using Kuntal's patch for WAL consistency check once it is stablized. With Regards, Ashutosh Sharma EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers