| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Kevin Grittner <kgrittn(at)ymail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: SSI freezing bug |
| Date: | 2013-10-04 10:23:37 |
| Message-ID: | 20131004102337.GL19661@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2013-10-03 21:14:17 -0700, Dan Ports wrote:
> On Thu, Oct 03, 2013 at 06:19:49AM -0700, Kevin Grittner wrote:
> > Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> wrote:
> > > IMHO it would be better to remove xmin from the lock key, and vacuum
> > > away the old predicate locks when the corresponding tuple is vacuumed.
> > > The xmin field is only required to handle the case that a tuple is
> > > vacuumed, and a new unrelated tuple is inserted to the same slot.
> > > Removing the lock when the tuple is removed fixes that.
>
> This seems definitely safe: we need the predicate locks to determine if
> someone is modifying a tuple we read, and certainly if it's eligible
> for vacuum nobody's going to be modifying that tuple anymore.
But we're talking about freezing a tuple, not removing a dead tuple. I
don't see anything preventing modification of a frozen tuple. Right?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2013-10-04 10:51:00 | Re: SSI freezing bug |
| Previous Message | Haribabu kommi | 2013-10-04 10:19:38 | Re: insert throw error when year field len > 4 for timestamptz datatype |