What you really need to do is read the following
chapter from the PostgreSQL User's guide:
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
> When 2 processes/people are simultaneously working
> on a table
> * does Postgres automatically enforce some sort of
Yes. And it does so at the row level. It's very
> * 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:
I hope this is helpful,
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
In response to
pgsql-novice by date
|Next:||From: Marc Zandvliet||Date: 2001-10-06 00:03:22|
|Subject: pg_dump and timestamps|
|Previous:||From: Josh Berkus||Date: 2001-10-05 20:26:58|
|Subject: Re: The mystery of concurrent access|