Chris Browne wrote:
Similarly, does it seem likely that Slony-I users would need to worry
about this?
No.. it should have zero negative effects for Slony-I. In fact, it will
be an advantage in some cases I think. I remember something about
troubles with Slony-I if the in-use xids on a intermediate subscribe
(one that also acts as a origin) drift too bar away from those on the
master. If that still is an issue, than lazy xid assignment might help
a bit - it might reduce xid consumption on that intermediate subscriber.
In general, from a user's point of view, you only see a different if
you look at pg_locks - you will now see NULLs in the transaction
column, and might need to look at virtualtransaction for some use-cases.
[ thinking ] It's been quite a time since I last worked with slony - but
isn't there some code that tried to prevent blocking other queries by
looking at pg_locks? Or was that before you could conditionally acquire
a lock using SQL? Or am I totally mistaken? Anyway, if you *do* scan
pg_locks, than you might want to check those parts of the code.
greetings, Florian Pflug
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
