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 :-)
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 |