On Tue, Nov 23, 2010 at 4:00 AM, Christopher Browne
<cbbrowne at ca.afilias.info> wrote:
> I have taken the features discussed thus far, along with outstanding bug
> reports that are of a "featureful nature," and put them in as a wiki
> page on the PostgreSQL developers wiki, here:
>  <http://wiki.postgresql.org/wiki/SlonyToDo>
>
> None of them represent promises; they're just some more-or-less
> promising ideas of things that might improve the usability of Slony-I.
> In early December, the set of us at Afilias are planning to try to
> figure out which are more than just promising, with a view to have that
> guide our development efforts in 2011.
>
> I thought Jan had some ideas to present to allow community discussion
> about some deeper features to take place before the December meetings,
> but it looks as though I may have been mistaken.

I'm still interested in making my applications cooperate better with
Slony locking.

The idea discussed on the mailing list is to have Slony take out an
advisory lock before attempting to lock tables and releasing that lock
afterwards. At the start of a transaction, my application would block
until that advisory lock is available. This way, Slony can actually be
granted locks on a busy system. Currently, in some situations Slony
will never be granted the locks because there is always at least one
transaction in progress reading the resources it is attempting to
lock.

I imagine this behavior would only occur if the site has configured
which number to use as the lock.

-- 
Stuart Bishop <stuart at stuartbishop.net>
http://www.stuartbishop.net/