> On 23 Jun 2016, at 11:50, Marko Tiikkaja <ma...@joh.to> 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 half the number of transactions/commits.  It’s 
holding the transaction open for longer, but not necessarily very long.  It’s 
also not holding any contested locks (in the example at least).

It is arguably more complex, but also arguably (imho anyway) simpler.  It gives 
a generic pattern of saying “I want this to happen if things go bad”.  With the 
upper example, you spend time setting up a system or pattern specifically for 
the use-case.  With patterns such as using a column to mark ownership of a row 
to your process, you’d need that extra column.  With a large number of rows, 
and a low probability of actually needing to update the row, that could also 
result in significant update-traffic, that could be avoided.  Similar if you’d 
need to keep a lock on another table as well, you’d loose the lock between the 
first and second transaction.  You could work around that with using 
ownership-type columns on that table as well, but then you have update-traffic 
there too.  Not to mention that for any use of ownership-type columns, you run 
the risk of having to do housekeeping on them, versus the second example, where 
you’re sure that all locks get cleaned up.

I entirely agree though, that this does in no way allow you to solve any new 
problems, that you can’t solve today.

Part of the reason I like the idea, is that it lowers the threshold for and 
work involved in dropping in “If what I’m about to do goes badly, I want X to 
happen”.  Yeah, it’s often comparable to simply do X first, and revert or alter 
it later, but that easily leads to twice the commits, loss of locks, having to 
work around that, possibly introducing even more update-traffic in the process. 
 I just see a potential to both avoid that, and gain some developer-comfort at 
the same time, so I figured I should pitch the idea.

One could easily argue that session-level advisory locks could often be used to 
avoid the issues of loosing locks across the two transactions, and it wouldn’t 
be wrong.  It just moves the question back to complexity though, of which there 
would be more (imho).

Terje Elde

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to