Re: Why is lock not released?

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)

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> 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

On Fri, Aug 19, 2005 at 01:11:54PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> 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)

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> 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

On Fri, Aug 19, 2005 at 05:47:11PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> 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"

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> 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

On Sat, Aug 20, 2005 at 12:23:38AM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> 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)

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> 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