From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Chris Browne <cbbrowne(at)acm(dot)org> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Lazy xid assignment V4 |
Date: | 2007-09-04 23:09:29 |
Message-ID: | 46DDE5A9.20303@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
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
From | Date | Subject | |
---|---|---|---|
Next Message | John DeSoi | 2007-09-05 00:18:14 | Re: Has anyone tried out the PL/pgSQL debugger? |
Previous Message | Chris Browne | 2007-09-04 21:41:20 | Re: Lazy xid assignment V4 |
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-09-04 23:20:25 | Re: HOT documentation README |
Previous Message | Chris Browne | 2007-09-04 21:41:20 | Re: Lazy xid assignment V4 |