From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | "Thomas F(dot) O'Connell" <tfo(at)sitening(dot)com> |
Cc: | PgSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Lock Modes (Documentation) |
Date: | 2005-11-02 22:59:15 |
Message-ID: | 200511022259.jA2MxFK26988@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thomas F. O'Connell wrote:
> I thought about posting to pgsql-docs, but since this might require
> comment from developers, I thought -general might be a better
> starting point.
>
> Anyway, I've occasionally run into monitoring situations where it
> would be immediately helpful to know the built-in SQL statements that
> generate given table-lock modes.
>
> For instance, doesn't UPDATE implicitly mean that an ACCESS SHARE
> lock will be taken if there are foreign keys involved (at least in
> versions prior to 8.1)? Are there any other scenarios where a given
> SQL command might take a lock of one of these forms as a result of
> what it does under the hood? Maybe UPDATE is the only one since it's
> implicitly a SELECT, DELETE, and INSERT all rolled into one.
>
> I'd love to see 12.3 <http://www.postgresql.org/docs/8.0/static/
> explicit-locking.html> document this more thoroughly, but I don't
> know enough about the underlying locking requirements of each step of
> each SQL command to know when locks might implicitly be acquired.
> Even if UPDATE is the only special case, it seems like it'd be worth
> mentioning.
Actually, pre-8.1 used ROW EXCLUSIVE for foreign keys because we didn't
have ROW SHARE until 8.1. I actually can't find out how we are doing
that in the code, however. Analyzing the code is probably the only way
to get this detailed lock information.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Glaesemann | 2005-11-02 23:08:30 | Re: SQL injection |
Previous Message | Andrew Sullivan | 2005-11-02 22:45:40 | Re: Replicating databases |