From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCHES] NO WAIT ... |
Date: | 2004-02-18 22:09:39 |
Message-ID: | 4033E2A3.80201@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> The question is whether we should have a GUC variable to control no
>> waiting on locks or add NO WAIT to specific SQL commands.
>
> That's only a minor part of the issue. The major problem I have with
> the patch is that it affects *all* locks, including system-internal
> lock attempts that the user is probably not even aware of much less
> able to control. It's like giving someone a poorly-aligned shotgun
> when what they need is a rifle --- they'll end up putting holes in
> a lot of other things besides what they intended.
I absolutely agree to that.
>
> I think that what we actually want is something that is narrowly
> tailored to affect only row-level locks taken by SELECT FOR UPDATE,
> and maybe one or two other places that (a) people can make specific
> use-cases for, and (b) we can be certain are only invoked by user
> commands and never indirectly from behind-the-scenes system operations.
I would gereralize this to user table row level and explicit lock table.
There is no need to force a separate SELECT FOR UPDATE in front of every
UPDATE or DELETE attempt in order to achieve the desired nolock behaviour.
>
> The reason for proposing syntax rather than a GUC variable is the same
> one of control. If you set a GUC variable then it will be hard to
> prevent it from breaking operations other than the one you thought you
> intended. (Example: you think you are only causing your SELECT FOR
> UPDATE to error out, but what about ones done behind the scenes for
> foreign key checks?) GUC variables are good for stuff that tends to
> apply application-wide, which is why I thought regex_flavor wasn't too
> dangerous, but they're terrible for functions that you want to apply to
> only certain specific operations. And I can't imagine an app where that
> wouldn't be true for NO WAIT.
This all needs a lot more detail than it has so far. If one tries to
UPDATE a row with NOLOCK, and a trigger fired during this would block on
the attempt to create a temp table, I think the resulting transaction
abort would rather be reported as a bug to us, then accepted as a nice
feature.
If there is a call for vote, I vote against.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2004-02-19 00:05:15 | Summary of Changes since last release (7.4.1) |
Previous Message | scott.marlowe | 2004-02-18 21:50:12 | Re: Inserting NULL into Integer column |
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2004-02-19 01:00:45 | Re: [PATCHES] NO WAIT ... |
Previous Message | Bruce Momjian | 2004-02-18 21:42:14 | Re: [PATCHES] NO WAIT ... |