From: | Doug McNaught <doug(at)wireboard(dot)com> |
---|---|
To: | "SHELTON,MICHAEL (Non-HP-Boise,ex1)" <michael_shelton(at)non(dot)hp(dot)com> |
Cc: | "'Braum Meakes'" <braum(at)telus(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: [SQL] User Permissions |
Date: | 2002-01-18 01:30:38 |
Message-ID: | m3elkomon5.fsf@varsoon.denali.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"SHELTON,MICHAEL (Non-HP-Boise,ex1)" <michael_shelton(at)non(dot)hp(dot)com> writes:
> Now, in the case of a select, then update/insert it will try an "optimistic"
> (hope I'm getting my terminology correct here) lock on the table (which
> will allow others to "read" the data or also apply "optimistic" locks --
> again for SELECT purposes -- but won't allow them to "change" or "write" the
> data locked -- less obtrusive this way, helps speed up concurrent access to
> tables). Then when you go to update whatever row, it would get an
> "exclusive" lock meaning no one is allowed to even "read" the data let alone
> "write" it. Again, the granularity (row vs page vs table) of the lock
> depends on the PG implementation itself.
>
> Hopefully one of the authors of PG will respond and correct/clarify anything
> I've said here.
Actually you're completely and utterly wrong. ;) PG doesn't work that
way, though other databases do.
See:
http://www.us.postgresql.org/users-lounge/docs/7.1/postgres/mvcc.html
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2002-01-18 01:44:22 | Re: Books on PostgreSQL |
Previous Message | Vince Vielhaber | 2002-01-18 01:12:12 | Re: Books on PostgreSQL |