Re: Lazy xid assignment V4

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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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