Re: Common case not at all clear

From: Anthony Berglas <anthony(at)berglas(dot)org>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Pg Docs <pgsql-docs(at)lists(dot)postgresql(dot)org>
Subject: Re: Common case not at all clear
Date: 2021-09-20 05:54:34
Message-ID: CA+_PZMeom2fi0SeX6X2Rr7QAU47cy8yN1O5bMphr5ZDx6dqF7Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

Hello David,

I note that nothing has happened.

In future I would suggest that you simply tell people that document updates
are not really welcome. Otherwise you waste people's time.

The locking issue is actually quite serious.

Cheers,

Anthony

On Tue, Aug 3, 2021 at 10:01 AM Anthony Berglas <anthony(at)berglas(dot)org> wrote:

> Hello David,
>
> Thanks for that, I had thought that you were a committer. Sounds like it
> might all be a bit too difficult.
>
> Anthony
>
> On Tue, Aug 3, 2021 at 9:39 AM David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
>> On Mon, Aug 2, 2021 at 4:30 PM Anthony Berglas <anthony(at)berglas(dot)org>
>> wrote:
>>
>>> You are talking about optimistic locking, commonly used for web
>>> applications where there is no transaction kept open during user think time.
>>>
>>
>> Yes, I said as much a couple of emails ago.
>>
>>
>>> And more importantly it is very important that people do not use a
>>> SELECT without a FOR UPDATE and introduce subtle, unreproducible threading
>>> errors.
>>>
>>
>> Ok. This does get covered, though I agreed earlier that there seems to
>> be room for improvement.
>>
>> So please do have the update (or similar) inserted. If you wanted to
>>> also talk about optimistic locking that would be fine, but probably not
>>> necessary.
>>>
>>
>> Just to be clear - this isn't going to be up to me (at least, not anytime
>> soon). First a correctly written patch needs to be produced. If/when
>> someone decides to do that we can move onto getting it applied to the
>> source code (which is done by a committer, which also is not me).
>>
>>> P.S. Do you know if Postgresql Guarantees that all timestamps are
>>> distinct, even if they occur within the same clock tick? (i.e. does it run
>>> the clock forward). I have another reason to know that. Using clocks is
>>> iffy for synchronization.
>>>
>>
>> I've never seen such a guarantee documented...but the details involved
>> are beyond my experience with the code.
>>
>> David J.
>>
>>

--
Anthony(at)Berglas(dot)org
+61 4 4838 8874
Just because it is possible to push twigs along the ground with ones nose
does not necessarily mean that that is the best way to collect firewood.

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Peter Geoghegan 2021-09-20 06:08:42 Re: Common case not at all clear
Previous Message Alexander Lakhin 2021-09-19 20:20:01 Re: Some inconsistencies in release-14