Re: Tracking row updates - race condition
От | Alex Adriaanse |
---|---|
Тема | Re: Tracking row updates - race condition |
Дата | |
Msg-id | 423F09CF.2030008@alexandcarmen.com обсуждение исходный текст |
Ответ на | Re: Tracking row updates - race condition ("Vincent Hikida" <vhikida@inreach.com>) |
Список | pgsql-general |
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? Alex Vincent Hikida wrote: >> >> To fetch all updates since the last synchronization, the client would >> calculated a value for $lastrevision by running this query on its >> local database: >> SELECT max(revision) AS lastrevision FROM codes; >> >> It would then fetch all updated rows by running this query against >> the server: >> SELECT * FROM codes WHERE revision > $lastrevision; >> > > How about > > SELECT * FROM codes WHERE revision > $lastrevision - 100 > > You could use another number other than 100. As you said, the client > can handle duplicates. > > Vincent > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if > your > joining column's datatypes do not match
В списке pgsql-general по дате отправления: