Confussion with Table_lock levels and isolation levels.

From: Gabriel Fernandez <gabi(at)unica(dot)edu>
To: pgsql-general(at)postgresql(dot)org
Subject: Confussion with Table_lock levels and isolation levels.
Date: 2000-01-07 10:31:38
Message-ID: 3875C089.A0076E0F@unica.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi fellows !

I would only want to ask some questions concerning table-locking levels
and isolation levels:

First of all: should I assume that Access___ modes imply locking
the complete table and Row___ imply locking only the
rows which have been accessed, and beyond that the conflicts will
be solved according the hierarchy between modes, or
is this distinction inaccurate ?

Second:
What does exactly mean that a mode 'CONFLICTS' with another ?

Does it mean that another concurrent transactions having these
modes will have to wait until the first transaction
have finished (commit or roll back) ?
Can we determine (when accessing a row in a table) wether we
will have a conflict or not according to the criteria
explained in the previous question (Access-> complete table,
Row -> rows accessed) ?

Third:
If all the previous assumptions are true:
When there is a conflict, will the only consequence be
that all concurrent transactions will be processed in a
FIFO serie and not in parallel ?
What about all the concurrent transactions which haven't
conflicted ? How can you avoid falling into
contradiction with the isolation level (and assure the
protection against non-repeteable reads or phantom
reads ?
I feel those two levels (transactions and isolation
levels) are two layers so the transactions will be
processed according to a FIFO serie when exist any
problem concerning the isolation level or the
table-locking. Is this a good way to describe the way
PostgreSQL manages the things ?

Thank you very much for your help.

Best regards and good Y2K,

Gabi :-)

Browse pgsql-general by date

  From Date Subject
Next Message Vince Vielhaber 2000-01-07 11:22:00 Re: [HACKERS] New Search Engine ... UdmSearch
Previous Message Adriaan Joubert 2000-01-07 09:22:56 Re: [HACKERS] New Search Engine ... UdmSearch