Re: [GENERAL] Using xmin and xmax for optimistic locking
От | Karsten Hilbert |
---|---|
Тема | Re: [GENERAL] Using xmin and xmax for optimistic locking |
Дата | |
Msg-id | 20170220205650.7xv44r6o5uhnqmwd@hermes.hilbert.loc обсуждение исходный текст |
Ответ на | Re: [GENERAL] Using xmin and xmax for optimistic locking (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [GENERAL] Using xmin and xmax for optimistic locking
|
Список | pgsql-general |
On Mon, Feb 20, 2017 at 03:44:49PM -0500, Tom Lane wrote: > > where table.*::text = (saved from select). > > > If the row was changed between the time it was first read and updated, the > > update will do touch any rows as the ::text will be different. > > > Why can't we use xmin and xmax columns to achieve the same. > > Well, that doesn't do quite the same thing: the cookbook query will > proceed if there was a no-op update in between (or maybe even two updates > that canceled each other out). If you look at xmin then you won't proceed > in such cases. I could imagine either behavior being "right" depending on > your application needs. Also a consideration: table.*::text may become quite unwieldy if there's one or more BYTEA columns in the table. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
В списке pgsql-general по дате отправления: