Chris Browne <cbbrowne@acm.org> wrote:
> robertmhaas@gmail.com (Robert Haas) writes:
>> I suspect Kevin's patch will solve it if using a sufficiently
>> high transaction isolation level, but something else might be
>> needed otherwise. However, I confess to ignorance as to the
>> underlying issues? Why is MERGE worse in this regard than, say,
>> UPDATE?
>
> It's worse than UPDATE because
> - It could be an INSERT, if the data's new, but
> - If the data's there, it becomes an UPDATE, but
> - If some concurrent update has just DELETEd the data that's
> there, it becomes an INSERT again, but
> - Oops, that DELETE rolled bac, so it's an UPDATE again...
>
> Recurse as needed to make it more undecidable as to whether it's
> really an INSERT or an UPDATE :-).
Not to get too far into the serializable issues, but the server
won't do any such recursion with the serializable patch. Each
serializable transaction would have its own snapshot where the row
was there or it wasn't, and would act accordingly. If they took
conflicting actions on the same row, one of them might be rolled
back with a serialization failure. The client is likely to want to
retry the operation based on the SQLSTATE indicating serialization
failure, which (as the patch stands now) could result in some
head-banging if the client doesn't introduce some delay first. I
have an optimization in mind (described on the Wiki page) which
could help with that, but its impact on overall performance is
uncertain, so I don't want to mess with that until we have more
benchmarks in place for realistic loads which might use serializable
isolation.
So... No, it's not directly a problem on the server itself. Yes, a
client can make it a problem by resubmitting failed queries "too
quickly". But, we might be able to fix that with additional work.
-Kevin