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

Re: Cluster feature: Start/stop archiving at runtime

From: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
To: greg(at)2ndquadrant(dot)com
Cc: ishii(at)sraoss(dot)co(dot)jp, pgsql-cluster-hackers(at)postgresql(dot)org
Subject: Re: Cluster feature: Start/stop archiving at runtime
Date: 2010-02-28 07:54:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-cluster-hackers
> Tatsuo Ishii wrote:
> >> Since I didn't hear anything about "API into the Parser / Parser as an 
> >> independent module", I just wrote my own summary of what I think the 
> >> idea was there is and am moving on.  I'll try to track down more info at 
> >> PG East next month when I run into some of the people I think care about 
> >> this.
> >>     
> >
> > I have took a look at your description. That is totally different from
> > what I thought. Statement replication and/or load balancing middle
> > ware need to know SQL statement is SELECT or others. If it is a (read
> > only) SELECT, it can be routed to standby node of Streaming
> > replication clusters for example. For this purpose, such a middle ware
> > ought to be able to parse SQL. If PostgreSQL provide its raw parser as
> > a C library, it will be very usefull for such middle ware since they
> > do not need to re-implement their own SQL parser (as pgpool-II already
> > did).
> >
> >   
> I never claimed I really understand what entry was alluding to and just 
> made the first wild guess that came to mind.  I'll be happy to replace 
> it with the alternate explanation you suggested for what it was intended 
> to address.  The part I still don't see is how these two comments in 
> that section fit into what you're describing here:
> * statement based replication need to replay certain constructs with 
> CONSTANT values you provide
> * Figure out which you need to replace... quite difficult

I guess these are talking about server internally generated values:
i.e. CURRENT_TIMESTAMP, sequence, oid, random() and so on (Pgpool-II
recently solved problems with CURRENT_TIMESTAMP and large object oid
BTW). To solve the problem we need a SQL parser to find out certain
constructs needed to be replaced with CONSTANT.

> Those are the parts I was basing my guess as to the intended application 
> here on.  If this is just intended to improve relaying SELECT statements 
> over to another node, why would you need to replace anything with 
> constants or other values?
Tatsuo Ishii
SRA OSS, Inc. Japan

In response to


pgsql-cluster-hackers by date

Next:From: Greg SmithDate: 2010-02-28 11:07:17
Subject: Re: Cluster feature: Start/stop archiving at runtime
Previous:From: Greg SmithDate: 2010-02-28 07:18:38
Subject: Re: Cluster feature: Start/stop archiving at runtime

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