On Wed, Sep 6, 2017 at 7:40 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> Otherwise, we risk marking the page as all-frozen, and it would be
> skipped by vacuum. If we never come around to HOT-pruning the page, a
> non-permanent xid (or a multixact? not sure that that can happen;
> probably not) would linger unnoticed and cause a DoS condition later
> ("cannot open file pg_clog/1234") when the tuple header is read.
Yes, you are definitely right here.
On Wed, Sep 6, 2017 at 10:27 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> Another thing is that if you're going through heap_copy_data, the tuple
> is only checked for DEAD, not RECENTLY_DEAD. Maybe there is no bug here
> but I'm not sure yet.
Not sure to what you are referring here. Perhaps heap_prune_chain()?
It seems to me that it does the right thing.
> I attach the patch as I have it now -- mostly comment tweaks, but also
> the change to not mark page as all-frozen when we skip freezing a
> recently read tuple. I also renamed the test case, because I think it
> may be possible to reach the problem code without involving a multixact.
> Haven't tried too hard though.
+test: freeze-the-dead
This one has made me smile..
+++ b/src/test/isolation/expected/freeze-the-dead.spec
@@ -0,0 +1,101 @@
+Parsed test spec with 2 sessions
The test fails as expected/ files need to be named with .out, not .spec.
--
Michael
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs