Re: Common case not at all clear

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.