Re: [HACKERS] proposals for LLL, part 1 - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] proposals for LLL, part 1
Date
Msg-id 199807171836.OAA11233@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] proposals for LLL, part 1  (Vadim Mikheev <vadim@krs.ru>)
List pgsql-hackers
> Bruce Momjian wrote:
> >
> > You are correct.  We need to lock Proc stuctures during our scan, but we
> > don't need to keep the list in shared memory.  No reason to do it.  Do
> > we have to keep the Proc's locked while we get our table data locks.  I
>                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> No! Only while we are scanning Procs...
>
> > sure hope not.  Not sure how we are going prevent someone from
> > committing their transaction between our Proc scan and when we start our
> > transaction.  Not even sure if I should be worried about that.
>
> We shouldn't... It doesn't matter.

One more item.  If we don't lock Proc between the scan and our
aquisition of a transaction id, it is possible some other backend will
get a transaction id between the time we scan the Proc structure and
when we get our transaction id, causing us to look at rows that are part
of a non-committed transaction.  I think we have to get our transaction
id first, before scanning Proc.

There is definately an area of vulnerabilty there.  I am now wondering
how much we need to lock Proc during the scan.

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] How about re-moderating pgsql-announce?
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] s_lock.h problem on S/Linux