[EMAIL PROTECTED] ("Florian G. Pflug") writes: > 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.
The problem isn't usually the growth of XID numbers, but more the general notion that the open transactions tend to prevent successful vacuums from taking place on tables like pg_listener. The pointed issues with pg_listener has, we think, been mostly resolved, as Slony-I has been getting less aggressive about generating dead tuples there. During initial subscription time, there is a pretty big issue, for very large replicas as there is a single big, long-running transaction running on the origin (the transaction pulling initial table data); that is one "big" XID, and it has history of adversely affecting application of replication data during the catch-up period. If flurries of read-only transactions are no longer generating XIDs that are being included in snapshot information, that *may* be something of a help; for our version 2, there is already a change that excludes XIDs for rolled-back transactions, which gets it mostly around the issues with the Big Initial-Subscription-Related Transaction. > 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. There are no references to pg_locks, unless there's some other view that references it, so that's good news :-). -- "cbbrowne","@","linuxdatabases.info" http://www3.sympatico.ca/cbbrowne/rdbms.html "Windows 98 Roast Specialty Blend coffee beans - just like ordinary gourmet coffee except that processing is rushed to leave in the insect larvae. Also sold under the ``Chock Full o' Bugs'' brand name..." ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org