Re: Cluster feature: Start/stop archiving at runtime
От | Tatsuo Ishii |
---|---|
Тема | Re: Cluster feature: Start/stop archiving at runtime |
Дата | |
Msg-id | 20100228.165435.58456301.t-ishii@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: Cluster feature: Start/stop archiving at runtime (Greg Smith <greg@2ndquadrant.com>) |
Ответы |
Re: Cluster feature: Start/stop archiving
at runtime
|
Список | 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 English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp
В списке pgsql-cluster-hackers по дате отправления: