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.g.johns...@gmail.com>
wrote:

> On Mon, Aug 2, 2021 at 4:30 PM Anthony Berglas <anth...@berglas.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.
>
>

Reply via email to