| From: | Dan Ports <drkp(at)csail(dot)mit(dot)edu> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | Kevin Grittner <kgrittn(at)ymail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com> |
| Subject: | Re: SSI freezing bug |
| Date: | 2013-10-07 20:20:19 |
| Message-ID: | 20131007202019.GN9940@cs.washington.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Oct 07, 2013 at 12:26:37PM +0300, Heikki Linnakangas wrote:
> When updating a tuple, CheckTargetForConflictsIn() only marks a
> conflict if the transaction holding the predicate lock overlapped
> with the updating transaction.
Ah, this is the bit I was forgetting. (I really ought to have
remembered that, but it's been a while...)
I think it's possible, then, to construct a scenario where a slot is
reused before predicate locks on the old tuple are eligible for
cleanup -- but those locks will never cause a conflict.
So I agree: it's correct to just remove the xmin from the key
unconditionally.
And this is also true:
> And if there's a hole in that thinking I can't see right now,
> the worst that will happen is some unnecessary conflicts, ie. it's
> still correct. It surely can't be worse than upgrading the lock to a
> page-level lock, which would also create unnecessary conflicts.
Dan
--
Dan R. K. Ports UW CSE http://drkp.net/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2013-10-07 20:45:44 | Re: SSI freezing bug |
| Previous Message | Robert Haas | 2013-10-07 20:06:59 | Re: pgbench progress report improvements - split 3 v2 - A |