
I'm seeing a weird problem, that I don't think I should be expecting in
v6.5.3 of PostgreSQL ... an inability to SELECT form a database while the
UdmSearch/indexer is running...

ps shows:

30040  ??  R     20:54.37 /home/database/v6.5.3/bin/postgres pgsql 216.126.84.1 udmsearch UPDATE
43846  ??  I      0:00.03 /home/database/v6.5.3/bin/postgres pgsql 216.126.84.1 udmsearch SELECT waiting

And, if I do successive ps's in a row, the 'SELECT waiting' stays, but the
UPDATING keeps flashing between 'UPDATING' and 'idle'...

*Eventually*, the SELECT gets perform and the call returns...

But, with MVCC, I didn't think that I should see any 'hangs' on SELECT
calls...the process on 43846 is 'indexer -S', which just generates stats
on the database.

The problem, in the case of this particular application, is that if
multiple searches were to happen, while the database is being updated, it
seems that this could be a point of contention?

>From what I can tell reading through the reading through the code, there
is never a TABLE LOCK issued when using PostgreSQL, but it does use
BEGIN/END...

Am I misunderstanding how MVCC is supposed to work?  Could we have a bug
in v6.5.3?

I'm still looking through the code, to see if I've overlooked something,
but I figure I'd check to see if maybe I'm misunderstanding MVCC
altogether first...

I'm CCng in the author of the code, just in case this is something that
I'm overlooking in theh code...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Sat, 8 Jan 2000 23:17:26 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Table locking ...

Okay, I did find a LOCK being issued, just not sure if its required or
not, with MVCC...

On Sat, 8 Jan 2000, The Hermit Hacker wrote:

> 
> I'm seeing a weird problem, that I don't think I should be expecting in
> v6.5.3 of PostgreSQL ... an inability to SELECT form a database while the
> UdmSearch/indexer is running...
> 
> ps shows:
> 
> 30040  ??  R     20:54.37 /home/database/v6.5.3/bin/postgres pgsql 216.126.84.1 udmsearch UPDATE
> 43846  ??  I      0:00.03 /home/database/v6.5.3/bin/postgres pgsql 216.126.84.1 udmsearch SELECT waiting
> 
> And, if I do successive ps's in a row, the 'SELECT waiting' stays, but the
> UPDATING keeps flashing between 'UPDATING' and 'idle'...
> 
> *Eventually*, the SELECT gets perform and the call returns...
> 
> But, with MVCC, I didn't think that I should see any 'hangs' on SELECT
> calls...the process on 43846 is 'indexer -S', which just generates stats
> on the database.
> 
> The problem, in the case of this particular application, is that if
> multiple searches were to happen, while the database is being updated, it
> seems that this could be a point of contention?
> 
> >From what I can tell reading through the reading through the code, there
> is never a TABLE LOCK issued when using PostgreSQL, but it does use
> BEGIN/END...
> 
> Am I misunderstanding how MVCC is supposed to work?  Could we have a bug
> in v6.5.3?
> 
> I'm still looking through the code, to see if I've overlooked something,
> but I figure I'd check to see if maybe I'm misunderstanding MVCC
> altogether first...
> 
> I'm CCng in the author of the code, just in case this is something that
> I'm overlooking in theh code...
> 
> Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
> Systems Administrator @ hub.org 
> primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 
> 
> 
> ************
> 

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Sat, 8 Jan 2000 23:27:03 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Table locking ...