Re: [HACKERS] Feature suggestions: "dead letter"-savepoint.

2016-06-23 Thread Tsunakawa, Takayuki
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

Re: [HACKERS] Feature suggestions: "dead letter"-savepoint.

2016-06-23 Thread Craig Ringer
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 >

Re: [HACKERS] Feature suggestions: "dead letter"-savepoint.

2016-06-23 Thread Terje Elde
> 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

Re: [HACKERS] Feature suggestions: "dead letter"-savepoint.

2016-06-23 Thread Marko Tiikkaja
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’

[HACKERS] Feature suggestions: "dead letter"-savepoint.

2016-06-23 Thread Terje Elde
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