Why is lock not released?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Why is lock not released?

Álvaro Herrera
I just noticed that AlterSchemaOwner (and others like AlterFunctionOwner
-- I haven't checked anything else yet) does not release the lock on
pg_namespace (resp. AlterFunctionOwner) after it's done changing it.  Is
there a reason for this?

I notice ATExecChangeOwner uses a different mechanism, but it still
locks the relation until transaction end.

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"Ni aun el genio muy grande llegaría muy lejos
si tuviera que sacarlo todo de su propio interior" (Goethe)


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

schemacmds.patch (515 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why is lock not released?

Tom Lane-2
Alvaro Herrera <[hidden email]> writes:
> I just noticed that AlterSchemaOwner (and others like AlterFunctionOwner
> -- I haven't checked anything else yet) does not release the lock on
> pg_namespace (resp. AlterFunctionOwner) after it's done changing it.  Is
> there a reason for this?

The code's a bit inconsistent about whether it releases non-exclusive
locks on system catalogs or leaves them till transaction end.  I suppose
sometime we should try to make it consistent --- but as long as you're
talking about non-exclusive locks, it doesn't really matter too much.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
Reply | Threaded
Open this post in threaded view
|

Re: Why is lock not released?

Álvaro Herrera
On Fri, Aug 19, 2005 at 01:11:54PM -0400, Tom Lane wrote:

> Alvaro Herrera <[hidden email]> writes:
> > I just noticed that AlterSchemaOwner (and others like AlterFunctionOwner
> > -- I haven't checked anything else yet) does not release the lock on
> > pg_namespace (resp. AlterFunctionOwner) after it's done changing it.  Is
> > there a reason for this?
>
> The code's a bit inconsistent about whether it releases non-exclusive
> locks on system catalogs or leaves them till transaction end.  I suppose
> sometime we should try to make it consistent --- but as long as you're
> talking about non-exclusive locks, it doesn't really matter too much.

Ok, I'll change it where I find reasonable in my "drop owned by" patch.
(The locks are RowExclusive).

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"Cuando mañana llegue pelearemos segun lo que mañana exija" (Mowgli)

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
Reply | Threaded
Open this post in threaded view
|

Re: Why is lock not released?

Tom Lane-2
Alvaro Herrera <[hidden email]> writes:
> On Fri, Aug 19, 2005 at 01:11:54PM -0400, Tom Lane wrote:
>> The code's a bit inconsistent about whether it releases non-exclusive
>> locks on system catalogs or leaves them till transaction end.  I suppose
>> sometime we should try to make it consistent --- but as long as you're
>> talking about non-exclusive locks, it doesn't really matter too much.

> Ok, I'll change it where I find reasonable in my "drop owned by" patch.
> (The locks are RowExclusive).

Well, before you start changing stuff, we probably oughta decide on
which way we want to make it consistent --- keep the locks always,
or drop always?

The "drop" way probably allows slightly more concurrency, but given that
people should seldom be taking exclusionary locks on system catalogs,
I'm not sure this is really an issue.  The "keep" way might be a little
quicker, at least for catalogs that are touched more than once per xact
(since retaking a lock we already hold does not touch shared memory
anymore).  I'm not sure I see an argument either way as concerns
code clarity.  Comments?

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
Reply | Threaded
Open this post in threaded view
|

Re: Why is lock not released?

Álvaro Herrera
On Fri, Aug 19, 2005 at 05:47:11PM -0400, Tom Lane wrote:

> Alvaro Herrera <[hidden email]> writes:
> > On Fri, Aug 19, 2005 at 01:11:54PM -0400, Tom Lane wrote:
> >> The code's a bit inconsistent about whether it releases non-exclusive
> >> locks on system catalogs or leaves them till transaction end.  I suppose
> >> sometime we should try to make it consistent --- but as long as you're
> >> talking about non-exclusive locks, it doesn't really matter too much.
>
> > Ok, I'll change it where I find reasonable in my "drop owned by" patch.
> > (The locks are RowExclusive).
>
> Well, before you start changing stuff, we probably oughta decide on
> which way we want to make it consistent --- keep the locks always,
> or drop always?
>
> The "drop" way probably allows slightly more concurrency, but given that
> people should seldom be taking exclusionary locks on system catalogs,
> I'm not sure this is really an issue.

Hmm.  The problem at hand (REASSIGN OWNED BY) may involve changing
ownership of several objects in a single transaction.  The order is
unspecified, because it's following a scan of the pg_shdepend entries --
so it'd be easy for one REASSIGN OWNED BY transaction to deadlock with
another one, if they happen to follow different orderings.

I'm not sure if this argument is strong enough to favor the balance to
the side of "drop always."  It seems that way to me.

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"Si un desconocido se acerca y te regala un CD de Ubuntu ...
                                     Eso es ...  Eau de Tux"

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
Reply | Threaded
Open this post in threaded view
|

Re: Why is lock not released?

Tom Lane-2
Alvaro Herrera <[hidden email]> writes:
>> The "drop" way probably allows slightly more concurrency, but given that
>> people should seldom be taking exclusionary locks on system catalogs,
>> I'm not sure this is really an issue.

> Hmm.  The problem at hand (REASSIGN OWNED BY) may involve changing
> ownership of several objects in a single transaction.  The order is
> unspecified, because it's following a scan of the pg_shdepend entries --
> so it'd be easy for one REASSIGN OWNED BY transaction to deadlock with
> another one, if they happen to follow different orderings.

Uh, how is it going to deadlock on a lock that is not exclusive?

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
Reply | Threaded
Open this post in threaded view
|

Re: Why is lock not released?

Álvaro Herrera
On Sat, Aug 20, 2005 at 12:23:38AM -0400, Tom Lane wrote:

> Alvaro Herrera <[hidden email]> writes:
> >> The "drop" way probably allows slightly more concurrency, but given that
> >> people should seldom be taking exclusionary locks on system catalogs,
> >> I'm not sure this is really an issue.
>
> > Hmm.  The problem at hand (REASSIGN OWNED BY) may involve changing
> > ownership of several objects in a single transaction.  The order is
> > unspecified, because it's following a scan of the pg_shdepend entries --
> > so it'd be easy for one REASSIGN OWNED BY transaction to deadlock with
> > another one, if they happen to follow different orderings.
>
> Uh, how is it going to deadlock on a lock that is not exclusive?

Oh, so is RowExclusiveLock not exclusive?  (pokes)  yeah, I guess it
isn't ...

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"La grandeza es una experiencia transitoria.  Nunca es consistente.
Depende en gran parte de la imaginación humana creadora de mitos"
(Irulan)

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

               http://archives.postgresql.org
Reply | Threaded
Open this post in threaded view
|

Re: Why is lock not released?

Tom Lane-2
Alvaro Herrera <[hidden email]> writes:
> Oh, so is RowExclusiveLock not exclusive?  (pokes)  yeah, I guess it
> isn't ...

I'm not sure where we got our lock mode names from, but there are a
number of things that aren't great about the choices.  In particular
"Exclusive" doesn't always mean "exclusive at the table level".

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [hidden email] so that your
       message can get through to the mailing list cleanly