Re: Revised Patch to allow multiple table locks in "Unison"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Neil Padgett <npadgett(at)redhat(dot)com>, Fernando Nasser <fnasser(at)cygnus(dot)com>, "pgsql-patches(at)postgresql(dot)org" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Revised Patch to allow multiple table locks in "Unison"
Date: 2001-08-04 19:51:36
Message-ID: 345.996954696@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Patch applied.

Idly looking this over again, I noticed a big OOPS:

>> ! freeList(lockstmt->rellist);

>> ! pfree(relname);

>> ! pfree(relname);

It is most definitely NOT the executor's business to release pieces of
the querytree; this will certainly break plpgsql functions, for example,
where the same querytree is executed repeatedly.
Bruce, please remove those lines.

Another thing I am concerned about now that I look more closely is that
the multi-rel case code opens the relations without any lock, and then
assumes they'll stick around while it opens and access-checks the rest.
This will fail if someone else drops one of the rels meanwhile. I think
the entire routine should be reduced to a simple loop that opens, locks,
and closes the rels one at a time. The extra code bulk to do it this
way isn't buying us anything at all.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-08-04 22:03:31 Re: Revised Patch to allow multiple table locks in "Unison"
Previous Message Bruce Momjian 2001-08-04 19:42:42 Re: Small patch for Hurd

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2001-08-04 22:03:31 Re: Revised Patch to allow multiple table locks in "Unison"
Previous Message Bruce Momjian 2001-08-04 19:42:53 Re: [HACKERS] Small patch for Hurd