From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer
Now, what I do think we need is to give the client the ability to determine
whether one of its xacts actually committed or not when it lost the session
after dispatching COMMIT but befo
On 23 June 2016 at 17:34, Terje Elde wrote:
>
> But what if there’s a bug making a call to the external service? Most of
> the time, you’ll trap the error and set status to something sane, but what
> if there’s a crash-bug in the SDK implementing it, or some other situation
> where things go ve
> On 23 Jun 2016, at 11:50, Marko Tiikkaja wrote:
>
> Comparing these two; how is the latter any better? It's the same number of
> commands, except it's holding a transaction open for longer, it's using a
> non-standard concept and it's arguably more complex.
Same number of commands, but hal
On 2016-06-23 12:34, Terje Elde wrote:
Typically the flow would be something like:
BEGIN;
SELECT id FROM targets WHERE status=‘scheduled’ FOR UPDATE SKIP LOCKED LIMIT 1;
UPDATE targets SET status=‘in-flight’ WHERE id =%(id);
COMMIT;
— Do the work.
BEGIN;
UPDATE targets SET status=‘completed’ WHE
Hi all,
I’d like to pitch the idea of supporting “dead letter”-savepoints, similar to
the way you have “dead letter”-exchanges in message-queue systems, etc. The
idea is basically that a client can publish a message, but in such a away that
it only ever actually gets published if the client di