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.
