On Mon, Nov 14, 2005 at 07:38:00PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Do we really need to prevent inserts from happening under a SELECT FOR
> > UPDATE? ISTM that's trying to apply serializable concurrency to SELECT
> > FOR UPDATE even if it's running in a read
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Do we really need to prevent inserts from happening under a SELECT FOR
> UPDATE? ISTM that's trying to apply serializable concurrency to SELECT
> FOR UPDATE even if it's running in a read committed transaction. In the
> single table case we don't prevent
On Tue, Nov 15, 2005 at 02:22:15AM +1100, Gavin Sherry wrote:
> On Mon, 14 Nov 2005, Tom Lane wrote:
> > is that you have exclusive hold on the selected rows and they won't
> > change underneath you before the end of your transaction. In the case
> > of an outer join where the left-side row joined
Gavin Sherry <[EMAIL PROTECTED]> writes:
> On Mon, 14 Nov 2005, Tom Lane wrote:
>> The point of the comment really is that this is a predicate locking
>> problem.
> I thought you might say that. I'm yet to do much reading on predicate
> locking -- do you think it is an area we will even pursue?
D
On Mon, 14 Nov 2005, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > I think we could, in fact, lock rows on the nullable side of the join if
> > we say that locking the NULL rows is not necessary. The rows do not
> > physical exist and I could see an argument which says that those
Gavin Sherry <[EMAIL PROTECTED]> writes:
> I think we could, in fact, lock rows on the nullable side of the join if
> we say that locking the NULL rows is not necessary. The rows do not
> physical exist and I could see an argument which says that those rows do
> not match any other rows which a con
