Merlin Moncure <mmonc...@gmail.com> writes:
> As long as lock as held between ctid examination and row modification
> you are ok. didn't read the patch, just pointing that out (history is
> full of client side drivers that did not do this properly).
> I also might have missed some of the finer contextual points of the
> discussion here: I was thinking that you are identifying rows on the
> client over fetch transaction A to write back in transaction B. If
> that is the case, ctid based identification to me is full of issues
Absolutely --- you can't rely on ctid across transactions. postgres_fdw
isn't doing that though, just using it to update or delete rows that it
locked earlier in the same remote transaction.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
