Re: [SQL] User Permissions

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

In response to

Browse pgsql-general by date

  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