Quick Links

Re: determine snapshot after obtaining locks for first statement

From:	"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To:	"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc:	"Markus Wanner" <markus(at)bluegap(dot)ch>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject:	Re: determine snapshot after obtaining locks for first statement
Date:	2009-12-17 17:51:07
Message-ID:	4B2A1B2B020000250002D703@gw.wicourts.gov
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Thread:
Lists:	pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> I'm not very sure what a clearer explanation would look like

As a stab at it, how about?:

This behavior makes Read Committed mode unsuitable for many UPDATE
or DELETE commands with joins or subqueries

-Kevin

In response to

Re: determine snapshot after obtaining locks for first statement at 2009-12-17 17:39:58 from Tom Lane

Responses

Re: determine snapshot after obtaining locks for first statement at 2009-12-17 17:58:30 from Robert Haas
Re: determine snapshot after obtaining locks for first statement at 2009-12-17 18:05:51 from Tom Lane

Browse pgsql-hackers by date

	From	Date	Subject
Next Message	Tom Lane	2009-12-17 17:58:25	Re: determine snapshot after obtaining locks for first statement
Previous Message	Greg Stark	2009-12-17 17:49:11	Re: determine snapshot after obtaining locks for first statement