| От | Harald Fuchs |
|---|---|
| Тема | Re: Tracking row updates - race condition |
| Дата | |
| Msg-id | puwts03801.fsf@srv.protecting.net обсуждение исходный текст |
| Ответ на | Tracking row updates - race condition (Alex Adriaanse <alex@alexandcarmen.com>) |
| Ответы |
Re: Tracking row updates - race condition
|
| Список | pgsql-general |
In article <423F09CF.2030008@alexandcarmen.com>, Alex Adriaanse <alex@alexandcarmen.com> writes: > I think that would greatly decrease the chances of a race condition > occurring, but I don't think it'd solve it. What if 150 other > revisions occur between a row update and its corresponding commit? How about the following: * Use a TIMESTAMP rather than a SERIAL * Set this timestamp to NULL in your INSERT/UPDATE trigger * Use a cron job to set the timestamp to current_timestamp when it's NULL This way the client would lag behind somewhat, depending on the cron job frequency, but it should not miss a change.
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера