Re: [HACKERS] proposals for LLL, part 1

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: vadim(at)krs(dot)ru (Vadim Mikheev)
Cc: hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] proposals for LLL, part 1
Date: 1998-07-17 18:36:24
Message-ID: 199807171836.OAA11233@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)candle(dot)pha(dot)pa(dot)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)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1998-07-18 14:37:39 Re: [HACKERS] s_lock.h problem on S/Linux
Previous Message The Hermit Hacker 1998-07-17 14:38:36 Re: [HACKERS] How about re-moderating pgsql-announce?