postgres-xc-developers Mailing List for Postgres-XC

+Alex and Sasi

On 3/21/13 7:58 AM, "Bei Xu" <be...@ad...> wrote:

>Hi, Koichi:
>Base on your reply,
>
>Since slave is a copy of master, the slave has the same GTM_proxy listed
>in postgresql.conf as the master, it will connect to server3's proxy AFTER
>SLAVE IS STARTED,
>And we will only change the slave's proxy to server 4 AFTER promotion,
>correct?
>
>Thus, looks like SLAVE needs to connect to A PROXY at ALL TIME: before
>promotion is server3's proxy, after promotion is server 4's proxy.
>
>Please take a look at following 2 senarios:
>Senario1: If slave was configured with server4's proxy AFTER SLAVE IS
>STARTED, upon server 3 failure, we will do :
>1) promote on slave
>Since slave is already connect server 4's proxy, we don't have to do
>anything here.
>
>senario2: If slave was configured with server3's proxy AFTER SLAVE IS
>STARTED, upon server 3 failure, we will do:
>1) restart slave to change proxy from server3's proxy value to server4's
>proxy value
>2) promote on slave
>
>Obviously, senario1 has less steps and simpler, senario2 is suggested by
>you. Is there any reason you suggested senario2?
>
>My concern is, If a slave is connect to any active proxy (the proxy is
>started and pointing to the GTM), will the transaction be applied TWICE?
>One from proxy, one from the master?
>
>
>
>
> 
>
>On 3/21/13 12:40 AM, "Koichi Suzuki" <koi...@gm...> wrote:
>
>>Only after promotion.   Before promotion, they will not be connected
>>to gtm_proxy.
>>
>>Regards;
>>----------
>>Koichi Suzuki
>>
>>
>>2013/3/21 Bei Xu <be...@ad...>:
>>> Hi Koichi:
>>>      Thanks for the reply. I still have doubts for item 1.  If we setup
>>> proxy on server 4, do we reconfigure server 4's coordinator/datanodes
>>>to
>>> point to server 4's proxy at ALL TIME(after replication is setup, I can
>>> change gtm_host to point to server4's proxy before I bring up slaves)
>>>or
>>> only AFTER promotion?
>>>
>>>
>>> On 3/20/13 11:08 PM, "Koichi Suzuki" <koi...@gm...> wrote:
>>>
>>>>1. It's better to have gtm proxy at server 4 when you failover to this
>>>>server.   We need gtm proxy now to failover GTM while
>>>>coordinators/datanodes are running.   When you simply make a copy of
>>>>coordinator/datanode with pg_basebackup and promote them, they will
>>>>try to connect to gtm_proxy at server3.   You need to reconfigure them
>>>>to connect to gtm_proxy at server4.
>>>>
>>>>2. Only one risk is the recovery point could be different from
>>>>component to component, I mean, some transaction may be committed at
>>>>some node but aborted at another because there could be some
>>>>difference in available WAL records.   It may possible to improve the
>>>>core to handle this to some extent but please understand there will be
>>>>some corner case, especially if DDL is involved in such a case.  This
>>>>chance could be small and you may be able to correct this manually or
>>>>this can be allowed in some applications.
>>>>
>>>>Regards;
>>>>----------
>>>>Koichi Suzuki
>>>>
>>>>
>>>>2013/3/21 Bei Xu <be...@ad...>:
>>>>> Hi, I want to set up HA for pgxc, please see below for my current
>>>>>setup.
>>>>>
>>>>> server1: 1 GTM
>>>>> server2: 1 GTM_Standby
>>>>> server3 (master):  1 proxy
>>>>>                                   1 coordinator
>>>>>                                   2 datanode
>>>>>
>>>>> Server4: (stream replication slave) :  1 standalone proxy ??
>>>>>                                   1 replicated coordinator (slave of
>>>>> server3's coordinator)
>>>>>                                    2 replicated datanode  (slave of
>>>>> server3's datanodes)
>>>>>
>>>>>
>>>>> server3's coordinator and datanodes are the master of the server4's
>>>>> coordinator/datanodes by stream replication.
>>>>>
>>>>> Question.
>>>>> 1. Should there be a proxy on server 4?   If not, which proxy  should
>>>>>the
>>>>> server4's coordinator and datanodes pointing to? (I have to specify
>>>>>the
>>>>> gtm_host in postgresql.conf)/
>>>>> 2. Do I have to use synchronous replication vs Asynchrous
>>>>>replication?
>>>>>I am
>>>>> currently using Asynchrnous replication because I think if I use
>>>>> synchronous, slave failour will affect master.
>>>>>
>>>>>
>>>>>----------------------------------------------------------------------
>>>>>-
>>>>>--
>>>>>-----
>>>>> Everyone hates slow websites. So do we.
>>>>> Make your web apps faster with AppDynamics
>>>>> Download AppDynamics Lite for free today:
>>>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>>>> _______________________________________________
>>>>> Postgres-xc-developers mailing list
>>>>> Pos...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>
>>>>
>>>
>>>
>>
>

I had forgotten to send it on hackers list.

---------- Forwarded message ----------
From: Ashutosh Bapat <ash...@en...>
Date: Fri, Feb 15, 2013 at 1:45 PM
Subject: Subqueries and permission checks
To: Postgres-XC core <Pos...@li...>


Hi All,
It seems subqueries FQS or faster planning has many unknown problems. This
one is second in the series,

Permissions on object involved in queries are checked at the time of
executing the query (not planning or parsing). This is done by traversing
the final range table collected in PlannerGlobal during the planning phase.
This final range table contains the RTEs from the subqueries and sublinks
in the query, collected during pull_up_subqueries() and pull_up_sublinks().

While FQSing a query, we need to do the same. We need to collect the RTEs
from the subqueries and sublinks. We need to do it after we have deemed a
query to be FQSable. We can do it while walking the tree for shippability,
but read on.

In very near future, we should be able to use the infrastructure for FQS
for shipping sub-queries without planning at the coordinator, the whole
query is not shippable. If we get there, (which I am hoping to do in this
quarter), we can't rely on the shippability walker to gather the RTEs as
said above, since this collection will be lost once we come out of FQS
planner. Instead we need to do it, after we have decided to FQS a certain
subquery or sublink. To do so, the only way I see is to add yet another
walker just to collect the RTEs.

Does anybody see any other way?

-- 
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company



-- 
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company