Skip site navigation (1) Skip section navigation (2)

Re: [PATCH 08/16] Introduce the ApplyCache module which can reassemble transactions from a stream of interspersed changes

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Steve Singer <steve(at)ssinger(dot)info>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH 08/16] Introduce the ApplyCache module which can reassemble transactions from a stream of interspersed changes
Date: 2012-06-28 16:04:25
Message-ID: 201206281804.26084.andres@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thursday, June 28, 2012 06:01:10 PM Robert Haas wrote:
> On Tue, Jun 26, 2012 at 8:13 PM, Andres Freund <andres(at)2ndquadrant(dot)com> 
wrote:
> > It even can be significantly higher than max_connections because
> > subtransactions are only recognizable as part of their parent transaction
> > uppon commit.
> 
> I've been wondering whether sub-XID assignment was going to end up on
> the list of things that need to be WAL-logged to enable logical
> replication.  It would be nicer to avoid that if we can, but I have a
> feeling that we may not be able to.
I don't think it needs to. We only need that information during commit and we 
have it there. If a subtxn aborts a separate abort is logged, so thats no 
problem. The 'merging' of the transactions would be slightly easier if we had 
the knowledge from the get go but that would add complications again in the 
case of rollbacks.

What do you think we need it?

Greetings,

Andres
-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-06-28 16:07:58
Subject: Re: Covering Indexes
Previous:From: Robert HaasDate: 2012-06-28 16:01:10
Subject: Re: [PATCH 08/16] Introduce the ApplyCache module which can reassemble transactions from a stream of interspersed changes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group