public inbox for [email protected]  

help / color / mirror / Atom feed

From: Greg Sabino Mullane <[email protected]>
To: Jacob Biesinger <[email protected]>
Cc: [email protected]
Subject: Re: Ghost data from failed FDW transactions?
Date: Wed, 11 Sep 2024 08:57:17 -0400
Message-ID: <CAKAnmmKmgOgo2yXfpgseFQXJy1__D__+Oo-1Dizcz9zUh-MLJQ@mail.gmail.com> (raw)
In-Reply-To: <CAHYXj6etiV1pTBvBiQFZ=jqxvNHczZio9cSSb7gMy+RrWwZTTQ@mail.gmail.com>
References: <CAHYXj6eJiX0jQpq4u7xYc1qy3=zBN+sPhGMTJETAF0fdoSyNUA@mail.gmail.com>
	<CAKAnmmJfKZejX0yE8dMHRZiQApq-PO_+aetGCHkkjK3VdOjD3w@mail.gmail.com>
	<CAHYXj6etiV1pTBvBiQFZ=jqxvNHczZio9cSSb7gMy+RrWwZTTQ@mail.gmail.com>

Any updates on this?

A few replies from me inline:

On Wed, Aug 28, 2024 at 12:18 PM Jacob Biesinger <[email protected]>
wrote:

> There aren't many details in the docs around failure modes... is there
> anything there that could cause this issue?
>

Nothing that I know of, but it's possible there is some sort of weird race
condition/bug. But frankly, it's far more likely to be some sort of
application bug  / missed behavior. If you could trigger it at will by
developing a self-contained test, that would be ideal.


> The ordering shouldn't matter, but this also means that error handling
> (e.g., when there is a conflict with the `EXCLUDE "serialNumber"`
> constraint) may not stop the second `INSERT` statement from being attempted
> (and rejected by postgres). But I think that's all client-side details that
> shouldn't affect the FDW txn semantics, right?
>

Correct, but it's hard to say for sure without seeing the code or knowing
exactly how the serialization errors are being handled. I'm not clear on
how the inserts are run "in parallel" if your flow is:

BEGIN;
> INSERT INTO "devices" ("orgId", "patientId", "deviceId", "data") ...
> INSERT INTO "devices" ("orgId", "patientId", "deviceId", "data") ...

SELECT * FROM "rootDb"."assets";

-- execute some logic client-side, nothing touching the DB

UPDATE "rootDb"."assets" WHERE ...;

COMMIT;


Perhaps expand on that, because it almost sounds like you have two
processes trying to talk to the same backend at once?

Cheers,
Greg

view thread (6+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Ghost data from failed FDW transactions?
  In-Reply-To: <CAKAnmmKmgOgo2yXfpgseFQXJy1__D__+Oo-1Dizcz9zUh-MLJQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox