From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reviewing freeze map code |
Date: | 2016-06-10 06:39:24 |
Message-ID: | 20160610063923.anzfsuwfupqw2pap@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016-06-10 11:58:26 +0530, Amit Kapila wrote:
> I have tried in multiple ways by running pgbench with read-write tests, but
> could not see any such behaviour.
It took over an hour of pgbench on a fast laptop till I saw it.
> I have tried by even crashing and
> restarting the server and then again running pgbench. Do you see these
> records on master or slave?
Master, but with an existing standby. So it could be related to
hot_standby_feedback or such.
> While looking at code in this area, I observed that during replay of
> records (heap_xlog_delete), we first clear the vm, then update the page.
> So we don't have Buffer lock while updating the vm where as in the patch
> (collect_corrupt_items()), we are relying on the fact that for clearing vm
> bit one needs to acquire buffer lock. Can that cause a problem?
Unsetting a vm bit is always safe, right? The invariant is that the VM
may never falsely say all_visible/frozen, but it's perfectly ok for a
page to be all_visible/frozen, without the VM bit being present.
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2016-06-10 06:50:52 | Re: Reviewing freeze map code |
Previous Message | Amit Kapila | 2016-06-10 06:28:26 | Re: Reviewing freeze map code |