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