>>> Sure, but we are not clearing in conditionally. I am not sure, how >>> after recovery it will be cleared it gets set during normal operation. >>> Moreover, btree already clears similar flag during replay (refer >>> btree_xlog_delete). >> >> You were right. In case datachecksum is enabled or wal_log_hint is set >> to true, 'LH_PAGE_HAS_DEAD_TUPLES' will get wal logged and therefore >> needs to be cleared on the standby as well. >> > > I was thinking what bad can happen if we don't clear this flag during > replay, the main thing that comes to mind is that after crash > recovery, if the flag is set the inserts on that page might need to > traverse all the tuples on that page once the page is full even if > there are no dead tuples in that page. It can be later cleared when > there are dead tuples in that page and we actually delete them, but I > don't think it is worth the price to pay for not clearing the flag > during replay.
Yes, you are absolutely correct. If we do not clear this flag during replay then there is a possibility of _hash_doinsert() unnecessarily scanning the page with no space assuming that the page has got some dead tuples in it which is not true. > >> Attached is the patch that >> clears this flag on standby during replay. >> > > Don't you think, we should also clear it during the replay of > XLOG_HASH_DELETE? We might want to log the clear of flag along with > WAL record for XLOG_HASH_DELETE. > Yes, it should be cleared. I completely missed this part in a hurry. Thanks for informing. I have taken care of it in the attached v2 patch. -- With Regards, Ashutosh Sharma EnterpriseDB:http://www.enterprisedb.com
0001-Reset-LH_PAGE_HAS_DEAD_TUPLES-flag-on-standby-during.patch
Description: binary/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
