Re: The mystery of concurrent access

What you really need to do is read the following
chapter from the PostgreSQL User's guide:

http://www.postgresql.org/idocs/index.php?mvcc.html

It explains all you need to know about how PostgreSQL
handles concurrent access. Pay special attention to
section 9.3 as Read Committed Isolation Level is the
default for PostgreSQL.

--- "P.V. Subramanian" <pvsmian(at)hotmail(dot)com> wrote:
> Hi all
>
> I thought enough experimentation would reveal this
> mystery, but its very
> confusing, so I'll ask.

Yes, I imagine that experimenting would be very
confusing. Fortunately the documentation is very
good.

> When 2 processes/people are simultaneously working
> on a table
>
> * does Postgres automatically enforce some sort of
> locking?

Yes. And it does so at the row level. It's very
cool.

> * do the changes made by process A become visible to
> process B immediately
> (of course, the result of a SELECT wouldn't change
> dynamically, but suppose
> process B did another SELECT, would it access
> process A's records?)

It depends on the isolation level, and on what you
mean by "immediately." In the default isolation level
if transaction A starts and then transaction B starts
transaction A cannot see any of the changes from
transaction B until transaction B is committed.

Bruce Momjian explains it much better than I ever
could, you should also take a look at the relevant
chapter of his book:

http://www.ca.postgresql.org/docs/aw_pgsql_book/node98.html

> Thanks
>
> PVS

I hope this is helpful,
Jason

__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1