Re: Lazy xid assignment V4

fgp(at)phlo(dot)org ("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..."