From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: SSI freezing bug |
Date: | 2013-10-01 14:41:46 |
Message-ID: | 1380638506.34122.YahooMailNeo@web162905.mail.bf1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> A better solution probably is to promote tuple-level locks if
> they exist to a relation level one upon freezing I guess?
It would be sufficient to promote the tuple lock to a page lock.
It would be pretty easy to add a function to predicate.c which
would accept a Relation and HeapTuple, check for a predicate lock
for the tuple, and add a page lock if found (which will
automatically clear the tuple lock). This new function would be
called when a tuple was chosen for freezing. Since freezing always
causes WAL-logging and disk I/O, the cost of a couple hash table
operations should not be noticeable.
This seems like a bug fix which should be back-patched to 9.1, yes?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-10-01 14:43:45 | Re: SSI freezing bug |
Previous Message | Andres Freund | 2013-10-01 14:31:54 | Re: logical changeset generation v6.1 |