Re: Common case not at all clear

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.
>
>