| From: | Jürgen Purtz <juergen(at)purtz(dot)de> | 
|---|---|
| To: | Erik Rijkers <er(at)xs4all(dot)nl> | 
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> | 
| Subject: | Re: Additional Chapter for Tutorial | 
| Date: | 2020-11-02 08:26:27 | 
| Message-ID: | da4037ea-cf9f-0461-17c0-aeac257cedf4@purtz.de | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-docs pgsql-hackers | 
On 02.11.20 07:15, Erik Rijkers wrote:
> On 2020-11-01 16:38, Jürgen Purtz wrote:
>> On 30.10.20 17:45, Erik Rijkers wrote:
>>>
>>> And I wrote down some separate items:
>>>
>>> 1.
>>> 'Two Phase Locking' and 'TPL' should be, I think,
>>> 'Two-Phase Commit'. Please someone confirm.
>>> (no changes made)
>>>
>>> Erik Rijkers
>>
>> All suggestions so far are summarized in the attached patch with the
>> following exceptions:
>>
>> - 'Two Phase Locking' is the intended term.
>
> OK, so what is 'Two Phase Locking'?  The term is not explained, and 
> not used anywhere else in the manual.  You propose to introduce it 
> here, in the tutorial.  I don't know what it means, and I am not 
> really a beginner.
>
> 'Two Phase Locking' should be explained somewhere, and how it relates 
> (or not) to Two-Phase Commit (2PC), don't you agree?
>
>
> Erik Rijkers
>
>
It may be possible to explain OCC and 2PL in two or three sentences 
within the glossary. But I think, we shall not try to explain such 
general strategies. They are not specific to PG and even not 
implemented. Instead, if the paragraph is too detailed, we can use a 
more general formulation without explicitly naming locking strategies.
OLD:
     A first approach to implement protections against concurrent
     access to the same data may be the locking of critical
     rows. Two such techniques are:
     <emphasis>Optimistic Concurrency Control</emphasis> (OCC)
     and <emphasis>Two Phase Locking</emphasis> (2PL).
     <productname>PostgreSQL</productname> implements a third, more
     sophisticated technique: <firstterm>Multiversion Concurrency
     Control</firstterm> (MVCC). The crucial advantage of MVCC ...
Proposal:
     A first approach to implement protections against concurrent
     access to the same data may be the locking of critical
     rows.
     <productname>PostgreSQL</productname> implements a more
     sophisticated technique which avoids any locking: 
<firstterm>Multiversion Concurrency
     Control</firstterm> (MVCC). The crucial advantage of MVCC ...
Any thoughts or other suggestions?
--
J. Purtz
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Erik Rijkers | 2020-11-02 08:44:54 | Re: Additional Chapter for Tutorial | 
| Previous Message | Erik Rijkers | 2020-11-02 06:15:28 | Re: Additional Chapter for Tutorial | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Erik Rijkers | 2020-11-02 08:44:54 | Re: Additional Chapter for Tutorial | 
| Previous Message | Kyotaro Horiguchi | 2020-11-02 08:25:04 | Re: Dereference before NULL check (src/backend/storage/ipc/latch.c) |