postgres-xc-developers Mailing List for Postgres-XC (Page 4)

On Fri, Mar 1, 2013 at 5:48 PM, Amit Khandekar <
ami...@en...> wrote:

> On 19 February 2013 12:37, Abbas Butt <abb...@en...> wrote:
> >
> > Hi,
> > Attached please find a patch that locks the cluster so that dump can be
> > taken to be restored on the new node to be added.
> >
> > To lock the cluster the patch adds a new GUC parameter called
> > xc_lock_for_backup, however its status is maintained by the pooler. The
> > reason is that the default behavior of XC is to release connections as
> soon
> > as a command is done and it uses PersistentConnections GUC to control the
> > behavior. We in this case however need a status that is independent of
> the
> > setting of PersistentConnections.
> >
> > Assume we have two coordinator cluster, the patch provides this behavior:
> >
> > Case 1: set and show
> > ====================
> > psql test -p 5432
> > set xc_lock_for_backup=yes;
> > show xc_lock_for_backup;
> >  xc_lock_for_backup
> > --------------------
> >  yes
> > (1 row)
> >
> > Case 2: set from one client show from other
> > ==================================
> > psql test -p 5432
> > set xc_lock_for_backup=yes;
> > (From another tab)
> > psql test -p 5432
> > show xc_lock_for_backup;
> >  xc_lock_for_backup
> > --------------------
> >  yes
> > (1 row)
> >
> > Case 3: set from one, quit it, run again and show
> > ======================================
> > psql test -p 5432
> > set xc_lock_for_backup=yes;
> > \q
> > psql test -p 5432
> > show xc_lock_for_backup;
> >  xc_lock_for_backup
> > --------------------
> >  yes
> > (1 row)
> >
> > Case 4: set on one coordinator, show from other
> > =====================================
> > psql test -p 5432
> > set xc_lock_for_backup=yes;
> > (From another tab)
> > psql test -p 5433
> > show xc_lock_for_backup;
> >  xc_lock_for_backup
> > --------------------
> >  yes
> > (1 row)
> >
> > pg_dump and pg_dumpall seem to work fine after locking the cluster for
> > backup but I would test these utilities in detail next.
> >
> > Also I have yet to look in detail that standard_ProcessUtility is the
> only
> > place that updates the portion of catalog that is dumped. There may be
> some
> > other places too that need to be blocked for catalog updates.
> >
> > The patch adds no extra warnings and regression shows no extra failure.
> >
> > Comments are welcome.
>
> Abbas wrote on another thread:
>
> >   Amit wrote on another thread:
> >> I haven't given a thought on the earlier patch you sent for cluster lock
> >> implementation; may be we can discuss this on that thread, but just a
> quick
> >> question:
> >>
> >> Does the cluster-lock command wait for the ongoing DDL commands to
> finish
> >> ? If not, we have problems. The subsequent pg_dump would not contain
> objects
> >> created by these particular DDLs.
> >
> >
> > Suppose you have a two coordinator cluster. Assume one client connected
> to
> > each. Suppose one client issues a lock cluster command and the other
> issues
> > a DDL. Is this what you mean by an ongoing DDL? If true then answer to
> your
> > question is Yes.
> >
> > Suppose you have a prepared transaction that has a DDL in it, again if
> this
> > can be considered an on going DDL, then again answer to your question is
> > Yes.
> >
> > Suppose you have a two coordinator cluster. Assume one client connected
> to
> > each. One client starts a transaction and issues a DDL, the second client
> > issues a lock cluster command, the first commits the transaction. If
> this is
> > an ongoing DDL, then the answer to your question is No.
>
> Yes this last scenario is what I meant: A DDL has been executed on nodes,
> but
>  not committed, when the cluster lock command is run and then pg_dump
> immediately
> starts its transaction before the DDL is committed. Here pg_dump does
> not see the new objects that would be created.
>
> I myself am not sure how would we prevent this from happening. There
> are two callback hooks that might be worth considering though:
> 1. Transaction End callback (CallXactCallbacks)
> 2. Object creation/drop hook (InvokeObjectAccessHook)
>
> Suppose we create an object creation/drop hook function that would :
> 1. store the current transaction id in a global objects_created list
> if the cluster is not locked,
> 2. or else if the cluster is locked, this hook would ereport() saying
> "cannot create catalog objects in this mode".
>
> And then during transaction commit , a new transaction callback hook will:
> 1. Check the above objects_created list to see if the current
> transaction has any objects created/dropped.
> 2. If found and if the cluster-lock is on, it will again ereport()
> saying "cannot create catalog objects in this mode"
>
> Thinking more on the object creation hook, we can even consider this
> as a substitute for checking the cluster-lock status in
> standardProcessUtility(). But I am not sure whether this hook does get
> called on each of the catalog objects. At least the code comments say
> it does.
>

Thanks for the ideas, here is how I handled the problem of ongoing DDLs.

1. Online node addition feature requires that each transaction
    should be monitored for any activity that would be prohibited
    if the cluster is locked before the transaction commit.
    This obviously adds some overhead in each transaction.
    If the database administrator is sure that the deployed
    cluster would never require online addition of nodes
    OR the database administrator decides that node addition
    will be done by bringing the cluster down then a
    command line parameter "disable-online-node-addition"
    can be used to disable transaction monitoring for online node addition
    By default on line addition of nodes will be available.
2.  Suppose we have a two coordinator cluster CO1 and CO2
    Assume one client connected to each coordinator.
    Further assume one client starts a transaction
    and issues a DDL. This is an unfinished transaction.
    Now assume the second client issues
    SET xc_lock_for_backup=yes
    The commit on the unfinished transaction should now
    fail. To handle this situation we monitor each
    transaction for any activity that would be prohibited
    if the cluster is locked before transaction commit.
    At the time of commit we check that if the transaction
    had issued a prohibited statement and now the cluster
    has been locked, we abort the commit.
    This is done only if online addition of nodes has not
    been disabled explicitly and the server is not running
    in bootstrap mode.

3. I did not use CallXactCallbacks because the comment in CommitTransaction
reads
     * This is all post-commit cleanup.  Note that if an error is raised
here,
     * it's too late to abort the transaction.  This should be just
     * noncritical resource releasing.

I have attached the revised patch with detailed comments.


>
>
> > But its a matter of
> > deciding which camp are we going to put COMMIT in, the allow camp, or the
> > deny camp. I decided to put it in allow camp, because I have not yet
> written
> > any code to detect whether a transaction being committed has a DDL in it
> or
> > not, and stopping all transactions from committing looks too restrictive
> to
> > me.
>
>
> >
> > Do you have some other meaning of an ongoing DDL?
>
>
>
> >
> > --
> > Abbas
> > Architect
> > EnterpriseDB Corporation
> > The Enterprise PostgreSQL Company
> >
> > Phone: 92-334-5100153
> >
> > Website: www.enterprisedb.com
> > EnterpriseDB Blog: http://blogs.enterprisedb.com/
> > Follow us on Twitter: http://www.twitter.com/enterprisedb
> >
> > This e-mail message (and any attachment) is intended for the use of
> > the individual or entity to whom it is addressed. This message
> > contains information from EnterpriseDB Corporation that may be
> > privileged, confidential, or exempt from disclosure under applicable
> > law. If you are not the intended recipient or authorized to receive
> > this for the intended recipient, any use, dissemination, distribution,
> > retention, archiving, or copying of this communication is strictly
> > prohibited. If you have received this e-mail in error, please notify
> > the sender immediately by reply e-mail and delete this message.
> >
> >
> ------------------------------------------------------------------------------
> > 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_feb
> > _______________________________________________
> > Postgres-xc-developers mailing list
> > Pos...@li...
> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >
>



-- 
--
Abbas
Architect
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: 92-334-5100153

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.

Hi Amit,
The patch looks good and is not the track for parameter handling. I see
that we are relying more on the data produced by PG and standard planner
rather than infering ourselves in XC. So, this looks good improvement.

Here are my comments
Tests
-----
1. It seems testing the parameter handling for queries arising from plpgsql
   functions. The function prm_func() seems to be doing that. Can you
please add
   some comments in this function specifying what is being tested in
various sets
   of statements in function.
2. Also, it seems to be using two tables prm_emp1 and prm_emp2. The first
one is
   being used to populate the other one and a variable inside the function.
   Later only the other is being used. Can we just use a single table
instead of
   two?
3. Can we use an existing volatile function instead of a new one like
prm_volfunc()?

Code
----
1. Please use prefixes rq_ and rqs_ for the newly added members of
RemoteQuery
   and RemoteQueryState structures resp. This allows to locate the usage of
   these members easily through cscope/tag etc. As a general rule, we should
   always add a prefix for members of commonly used structures or members
which
   use very common variable names. rq_, rqs_, en_ are being used for
   RemoteQuery, RemoteQueryState and ExecNodes resp.
2. Is it possible to infer value of has_internal_params from rest of the
members
   of RemoteQuery structure? If so, can we drop this member and use
inference
   logic?
3. Following code needs more commenting in DMLParamListToDataRow()
5027     /* Set the remote param types if they are not already set */
   The code below, this comments seems to execute only the first time the
   RemoteQueryState is used. Please elaborate this in the comment, lest the
   reader is confused as to when this case can happen.
4. In code below
5098         /* copy data to the buffer */
5099         *datarow = palloc(buf.len);
5100         memcpy(*datarow, buf.data, buf.len);
5101         rq_state->paramval_len = buf.len;
5102         pfree(buf.data);
   Can we use datarow = buf.data. The memory context in both the cases will
have
   same life. We will save calls to palloc, pfree and memcpy. You can add
   comments about why this assignment is safe. We do this type of
assignment at
   other places too. See pgxc_rqplan_build_statement. Similar change is
needed
   in ExternParamListToDataRow().
5. More elaboration needed in prologue of DMLParamListToDataRow(). See some
   hints below. We need to elaborate on the purpose of such conversion.
Name of the
   function is misleading, there is not ParamList involved to convert from.
We are
   converting from TupleSlot.
5011 /* --------------------------------
5012  * DMLParamListToDataRow
5013  * Obtain a copy of <given> slot's data row <in what form?>, and copy
it into
5014  * <passed in/given> RemoteQueryState.paramval_data. Also set
remote_param_types <to what?>
5015  * The slot itself is undisturbed.
5016  * --------------------------------
6. Variable declarations in DMLParamListToDataRow() need to aligned. We
align
   the start of declaration and the variable names themselves.
7. In create_remotedml_plan(), we were using SetRemoteStatementName to have
all
   the parameter setting in one place. But you have instead set them
explicitly
   in the function itself. Can you please revert back the change? The
   remote_param_types set here are being over-written in
   DMLParamListToDataRow(). What if the param types/param numbers obtained
in both these
   functions are different? Can we add some asserts to check this?



On Tue, Feb 26, 2013 at 9:51 AM, Amit Khandekar <
ami...@en...> wrote:

> There has been errors like :
> "Cannot find parameter $4" or
> "Bind supplies 4 parameters while Prepare needs 8 parameters" that we
> have been getting for specific scenarios. These scenarios come up in
> plpgsql functions. This is the root cause:
>
> If PLpgSQL_datum.dtype is not a simple type (PLPGSQL_DTYPE_VAR), the
> parameter types (ParamExternData.ptype) for such plpgsql functions are
> not set until when the values are actually populated. Example of such
> variables is record variable without %rowtype specification. The
> ParamListInfo.paramFetch hook function is called when needed to fetch
> the such parameter types. In the XC function
> pgxc_set_remote_parameters(), we do not consider this, and we check
> only the ParamExternData.ptype to see if parameters are present, and
> end up with lesser parameters than the actual parameters, sometimes
> even ending up with 0 parameter types.
>
> During trigger support implementation, it was discovered that due to
> this issue,
> the NEW.field or OLD.field cannot be used directly in SQL statements.
>
> Actually we don't even need parameter types to be set at plan time in
> XC. We only need them at the BIND message. There, we can anyway infer
> the types from the tuple descriptor. So the attached patch removes all
> the places where parameter types are set, and derives them when the
> BIND data row is built.
>
> I have not touched the SetRemoteStatementName function in this patch.
> There can be scenarios where user calls PREPARE using parameter types,
> and in such cases it is better to use these parameters in
> SetRemoteStatementName() being called from BuildCachedPlan with
> non-NULL boundParams. Actually use of parameter types during PREPARE
> and rebuilding cached plans etc will be dealt further after this one.
> So, I haven't removed param types altogether.
>
> We also need to know whether the parameters are supplied through
> source data plan (DMLs) or they are external. So added a field
> has_internal_params in RemoteQuery to make this difference explicit.
> Data row and parameters types are built in a different manner for DMLs
> and non-DMLs.
>
> Moved the datarow generation function from execTuples.c to execRemote.c .
>
> Regressions
> -----------------
>
> There is a parameter related error in plpgsql.sql test, which does not
> occur now, so corrected the expected output. It still does not show
> the exact output because of absence of trigger support.
>
> Added new test xc_params.sql which would be further extended later.
>
>
> ------------------------------------------------------------------------------
> 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_feb
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>


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

On 12 February 2013 14:40, Ashutosh Bapat
<ash...@en...> wrote:
> Hi All,
> PFA patch based on the ideas in this mail thread.
>
> There are two regression failures join and functional_deps. These are old
> bugs 3604199, 3604090 unrelated to the code in this patch.
>
>
> On Tue, Feb 5, 2013 at 1:48 PM, Ashutosh Bapat
> <ash...@en...> wrote:
>>
>> Hi All,
>> There is a small improvement possible in case 2. We don't need to
>> necessarily restrict the case only to equi-joins, justification for the same
>> remains un-altered. The reason we need equi-join in case 1, is because other
>> join conditions can not be evaluated locally when both the relations are
>> distributed.
>>
>> Again anybody sees any loop-hole in the argument?
>>
>>
>> On Tue, Jan 29, 2013 at 4:04 PM, Ashutosh Bapat
>> <ash...@en...> wrote:
>>>
>>> Hi All,
>>> Currently, we do not ship OUTER join to the datanodes when both the sides
>>> of the join are not replicated. But there are cases, where shipping OUTER
>>> join between distributed/replicated tables should be possible. Those cases
>>> are as stated below. For every case, find a justification or proof of
>>> correctness for the said shippability.
>>>
>>>
>>> 1. An equi-outer-join between the distribution columns of two distributed
>>> tables such that the tables are distributed on same set of nodes and
>>> distribution strategy is same and datatype of distribution column is same,
>>> is shippable to the datanodes where the distributed tables are distributed.
>>> justification for the claim
>>> ---------------------------------
>>> Any outer join A OJ B between relations A and B is defined as A IJ B
>>> (term I) + rows from A which are not part of I (term II), with NULL values
>>> for columns of B + rows of B which are not part of I (term III), with NULL
>>> values for columns of A. A IJ B is inner join between A and B. I will prefix
>>> n to OJ, IJ, or terms I, II, III to mean the operations executed on nth
>>> node.
>>>
>>> In such case, rows with same value for distribution column reside on the
>>> same datanode for both the tables. Hence, a given row on a given node from
>>> either table can not join with a row of other table from any node other than
>>> where it resides (referred as (a)). Hence if we collect A IJn B across all
>>> the nodes, it produces A IJ B. Because of (a), a row which is part of IIn
>>> and IIIn, will also be part of II and III resp. Since a row resides only on
>>> a single node, a row r1 which is part of IIn can not be part of IIm (n !=
>>> m). Similarly for any row in IIIn. Thus if we collect IIn and IIIn across
>>> all nodes, it produces II and III respectively. Now In + IIn + IIIn is
>>> nothing but A OJn B. Hence if we collect A OJn B from all the nodes, it
>>> produces A OJ B. Hence the above result.
>>>
>>> 2. An equi-outer-join between a distributed and a replicated relation is
>>> shippable to the datanodes where distributed relation is distributed if the
>>> replicated relation is replicated on those nodes and the outer side of join
>>> is distributed relation.
>>>
>>> justification
>>> ---------------
>>> Any left outer join A LOJ B between relations A and B is defined as A IJ
>>> B (term I) + rows from A which are not part of I (term II). A IJ B is inner
>>> join between A and B. I will prefix n (or m) to LOJ, IJ, or terms I, II to
>>> mean the operations executed on nth (or mth) node. In this case, A is
>>> distributed and B is replicated.
>>>
>>> Since all the rows of B are available on every node where A is
>>> distributed, join of a given row of A on a given node with rows of B can be
>>> evaluated on that node (a). Since a given row of A exists only on a single
>>> node (b), A IJn B intersection A IJm B (n != m) should be NULL. Thus if we
>>> collect A IJn B from all nodes, it will produce A IJ B. Because of (a) and
>>> (b), a row of A on a given node n, which is not part of A IJn B, will be
>>> part of IIn as well as II and can not be part of IIm (m != n). Thus if we
>>> collect all IIn, it would produce II. Since A IJn B + IIn is A LOJn B, we
>>> can collect A LOJn B from all the nodes to produce A LOJ B. Hence the claim
>>> above.
>>>
>>> Does anybody see holes in those arguments?

Hi Ashutosh,

I think the logic of shippability of outer joins is flawless. Didn't
find any holes. Patch comments below :

-------

In case of distributed equi-join case, why is
IsExecNodesColumnDistributed() used instead of
IsExecNodesDistributedByValue() ? We want to always rule out the round
robin case, no ? I can see that pgxc_find_dist_equijoin_qual() will
always fail for round robin tables because they won't have any distrib
columns, but still , just curious ...

-------

		 * PGXC_TODO: What do we do when baselocatortype is
		 * LOCATOR_TYPE_DISTRIBUTED? It could be anything HASH distributed or
		 * MODULO distributed. In that case, having equi-join doesn't work
		 * really, because same value from different relation will go to
		 * different node.

The above comment says that it does not work if one of the tables is
distributed by hash and other table is distributed by modulo. But the
code is actually checking the baselocatortype also, so I guess it
works correctly after all ? I did not get what is the TODO here. Or
does it mean this ? :
For (t1_hash join t2_hash on ...) tj1 join (t1_mod join t2_mod on ...)
tj2 on tj1.col1 = tj2.col4
the merged nodes for tj1 will have  LOCATOR_TYPE_DISTRIBUTED, and the
merged nodes for tj2 will also be LOCATOR_TYPE_DISTRIBUTED, and so tj1
join tj2 would be wrongly marked shippable even though they should not
be shippable because of the mix of hash and modulo ?

-------

Is pgxc_is_expr_shippable(equi_join_expr) necessary ? Won't this qual
be examined in is_query_shippable() walker ?

--------

If both tables reside on a single datanode, every join case should be
shippable, which doesn't seem to be happening :
postgres=# create table tab2 (id2 int, v varchar) distribute by
replication to node (datanode_1);
postgres=# create table tab1 (id1 int, v varchar) to node (datanode_1);
postgres=# explain select * from (tab1 full outer join tab2 on id1 = id2 ) ;
                                           QUERY PLAN
-------------------------------------------------------------------------------------------------
 Hash Full Join  (cost=0.12..0.26 rows=10 width=72)
   Hash Cond: (tab1.id1 = tab2.id2)
   ->  Data Node Scan on tab1 "_REMOTE_TABLE_QUERY_"  (cost=0.00..0.00
rows=1000 width=36)
         Node/s: datanode_1
   ->  Hash  (cost=0.00..0.00 rows=1000 width=36)
         ->  Data Node Scan on tab2 "_REMOTE_TABLE_QUERY_"
(cost=0.00..0.00 rows=1000 width=36)
               Node/s: datanode_1

Probably you need to take out the following statement out of the
distributed case and apply it as a general rule:
		/* If there is only single node, try merging the nodes */
		if (list_length(inner_en->nodeList) == 1 &&
			list_length(outer_en->nodeList) == 1)
			merge_nodes = true;


>>> --
>>> Best Wishes,
>>> Ashutosh Bapat
>>> EntepriseDB Corporation
>>> The Enterprise Postgres Company
>>
>>
>>
>>
>> --
>> Best Wishes,
>> Ashutosh Bapat
>> EntepriseDB Corporation
>> The Enterprise Postgres Company
>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

Hi Amit,
I am looking at this patch.

First I looked at the testcase added. It seems testing the parameter
handling for queries arising from plpgsql functions. The function
prm_func() seems to be doing that. Can you please add some comments in this
function specifying what is being tested in various sets of statements in
function. Also, it seems to be using two tables prm_emp1 and prm_emp2. The
first one is being used to populate the other one and a variable inside the
function. Later only the other is being used. Can we just use a single
table instead of two? Can we use an existing volatile function instead of a
new one like prm_volfunc()?

On Tue, Feb 26, 2013 at 9:51 AM, Amit Khandekar <
ami...@en...> wrote:

> There has been errors like :
> "Cannot find parameter $4" or
> "Bind supplies 4 parameters while Prepare needs 8 parameters" that we
> have been getting for specific scenarios. These scenarios come up in
> plpgsql functions. This is the root cause:
>
> If PLpgSQL_datum.dtype is not a simple type (PLPGSQL_DTYPE_VAR), the
> parameter types (ParamExternData.ptype) for such plpgsql functions are
> not set until when the values are actually populated. Example of such
> variables is record variable without %rowtype specification. The
> ParamListInfo.paramFetch hook function is called when needed to fetch
> the such parameter types. In the XC function
> pgxc_set_remote_parameters(), we do not consider this, and we check
> only the ParamExternData.ptype to see if parameters are present, and
> end up with lesser parameters than the actual parameters, sometimes
> even ending up with 0 parameter types.
>
> During trigger support implementation, it was discovered that due to
> this issue,
> the NEW.field or OLD.field cannot be used directly in SQL statements.
>
> Actually we don't even need parameter types to be set at plan time in
> XC. We only need them at the BIND message. There, we can anyway infer
> the types from the tuple descriptor. So the attached patch removes all
> the places where parameter types are set, and derives them when the
> BIND data row is built.
>
> I have not touched the SetRemoteStatementName function in this patch.
> There can be scenarios where user calls PREPARE using parameter types,
> and in such cases it is better to use these parameters in
> SetRemoteStatementName() being called from BuildCachedPlan with
> non-NULL boundParams. Actually use of parameter types during PREPARE
> and rebuilding cached plans etc will be dealt further after this one.
> So, I haven't removed param types altogether.
>
> We also need to know whether the parameters are supplied through
> source data plan (DMLs) or they are external. So added a field
> has_internal_params in RemoteQuery to make this difference explicit.
> Data row and parameters types are built in a different manner for DMLs
> and non-DMLs.
>
> Moved the datarow generation function from execTuples.c to execRemote.c .
>
> Regressions
> -----------------
>
> There is a parameter related error in plpgsql.sql test, which does not
> occur now, so corrected the expected output. It still does not show
> the exact output because of absence of trigger support.
>
> Added new test xc_params.sql which would be further extended later.
>
>
> ------------------------------------------------------------------------------
> 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_feb
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>


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

The attached patch changes the name of the option to --include-nodes.

On Mon, Mar 4, 2013 at 2:41 PM, Abbas Butt <abb...@en...>wrote:

>
>
> On Mon, Mar 4, 2013 at 2:09 PM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>>
>>
>> On Mon, Mar 4, 2013 at 1:51 PM, Abbas Butt <abb...@en...>wrote:
>>
>>> What I had in mind was to have pg_dump, when run with include-node, emit
>>> CREATE NODE/ CREATE NODE GROUP commands only and nothing else. Those
>>> commands will be used to create existing nodes/groups on the new
>>> coordinator to be added. So it does make sense to use this option
>>> independently, in fact it is supposed to be used independently.
>>>
>>>
>> Ok, got it. But then include-node is really a misnomer. We should use
>> --dump-nodes or something like that.
>>
>
> In that case we can use include-nodes here.
>
>
>>
>>
>>>
>>> On Mon, Mar 4, 2013 at 11:21 AM, Ashutosh Bapat <
>>> ash...@en...> wrote:
>>>
>>>> Dumping TO NODE clause only makes sense if we dump CREATE NODE/ CREATE
>>>> NODE GROUP. Dumping CREATE NODE/CREATE NODE GROUP may make sense
>>>> independently, but might be useless without dumping TO NODE clause.
>>>>
>>>> BTW, OTOH, dumping CREATE NODE/CREATE NODE GROUP clause wouldn't create
>>>> the nodes on all the coordinators,
>>>
>>>
>>> All the coordinators already have the nodes information.
>>>
>>>
>>>> but only the coordinator where dump will be restored. That's another
>>>> thing you will need to consider OR are you going to fix that as well?
>>>
>>>
>>> As a first step I am only listing the manual steps required to add a new
>>> node, that might say run this command on all the existing coordinators by
>>> connecting to them one by one manually. We can decide to automate these
>>> steps later.
>>>
>>>
>> ok
>>
>>
>>
>>>
>>>
>>>>
>>>>
>>>> On Mon, Mar 4, 2013 at 11:41 AM, Abbas Butt <
>>>> abb...@en...> wrote:
>>>>
>>>>> I was thinking of using include-nodes to dump CREATE NODE / CREATE
>>>>> NODE GROUP, that is required as one of the missing links in adding a new
>>>>> node. How do you think about that?
>>>>>
>>>>>
>>>>> On Mon, Mar 4, 2013 at 9:02 AM, Ashutosh Bapat <
>>>>> ash...@en...> wrote:
>>>>>
>>>>>> Hi Abbas,
>>>>>> Please take a look at
>>>>>> http://www.postgresql.org/docs/9.2/static/app-pgdump.html, which
>>>>>> gives all the command line options for pg_dump. instead of
>>>>>> include-to-node-clause, just include-nodes would suffice, I guess.
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 1, 2013 at 8:36 PM, Abbas Butt <
>>>>>> abb...@en...> wrote:
>>>>>>
>>>>>>> PFA a updated patch that provides a command line argument called
>>>>>>> --include-to-node-clause to let pg_dump know that the created dump is
>>>>>>> supposed to emit TO NODE clause in the CREATE TABLE command.
>>>>>>> If the argument is provided while taking the dump from a datanode,
>>>>>>> it does not show TO NODE clause in the dump since the catalog table is
>>>>>>> empty in this case.
>>>>>>> The documentation of pg_dump is updated accordingly.
>>>>>>> The rest of the functionality stays the same as before.
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Feb 25, 2013 at 10:29 AM, Ashutosh Bapat <
>>>>>>> ash...@en...> wrote:
>>>>>>>
>>>>>>>> I think we should always dump DISTRIBUTE BY.
>>>>>>>>
>>>>>>>> PG does not stop dumping (or provide an option to do so) newer
>>>>>>>> syntax so that the dump will work on older versions. On similar lines, an
>>>>>>>> XC dump can not be used against PG without modification (removing
>>>>>>>> DISTRIBUTE BY). There can be more serious problems like exceeding table
>>>>>>>> size limits if an XC dump is tried to be restored in PG.
>>>>>>>>
>>>>>>>> As to TO NODE clause, I agree, that one can restore the dump on a
>>>>>>>> cluster with different configuration, so giving an option to dump TO NODE
>>>>>>>> clause will help.
>>>>>>>>
>>>>>>>> On Mon, Feb 25, 2013 at 6:42 AM, Michael Paquier <
>>>>>>>> mic...@gm...> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Feb 25, 2013 at 4:17 AM, Abbas Butt <
>>>>>>>>> abb...@en...> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 24, 2013 at 5:33 PM, Michael Paquier <
>>>>>>>>>> mic...@gm...> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Feb 24, 2013 at 7:04 PM, Abbas Butt <
>>>>>>>>>>> abb...@en...> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Feb 24, 2013 at 1:44 PM, Michael Paquier <
>>>>>>>>>>>> mic...@gm...> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 3:51 PM, Abbas Butt <
>>>>>>>>>>>>> abb...@en...> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>> PFA a patch to  fix pg_dump to generate TO NODE clause in the
>>>>>>>>>>>>>> dump.
>>>>>>>>>>>>>> This is required because otherwise all tables get created on
>>>>>>>>>>>>>> all nodes after a dump-restore cycle.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Not sure this is good if you take a dump of an XC cluster to
>>>>>>>>>>>>> restore that to a vanilla Postgres cluster.
>>>>>>>>>>>>> Why not adding a new option that would control the generation
>>>>>>>>>>>>> of this clause instead of forcing it?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I think you can use the pg_dump that comes with vanilla PG to
>>>>>>>>>>>> do that, can't you? But I am open to adding a control option if every body
>>>>>>>>>>>> thinks so.
>>>>>>>>>>>>
>>>>>>>>>>> Sure you can, this is just to simplify the life of users a
>>>>>>>>>>> maximum by not having multiple pg_dump binaries in their serves.
>>>>>>>>>>> Saying that, I think that there is no option to choose if
>>>>>>>>>>> DISTRIBUTE BY is printed in the dump or not...
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yah if we choose to have an option we will put both DISTRIBUTE BY
>>>>>>>>>> and TO NODE under it.
>>>>>>>>>>
>>>>>>>>> Why not an option for DISTRIBUTE BY, and another for TO NODE?
>>>>>>>>> This would bring more flexibility to the way dumps are generated.
>>>>>>>>> --
>>>>>>>>> Michael
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> 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_feb
>>>>>>>>> _______________________________________________
>>>>>>>>> Postgres-xc-developers mailing list
>>>>>>>>> Pos...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best Wishes,
>>>>>>>> Ashutosh Bapat
>>>>>>>> EntepriseDB Corporation
>>>>>>>> The Enterprise Postgres Company
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> --
>>>>>>> Abbas
>>>>>>> Architect
>>>>>>> EnterpriseDB Corporation
>>>>>>> The Enterprise PostgreSQL Company
>>>>>>>
>>>>>>> Phone: 92-334-5100153
>>>>>>>
>>>>>>> Website: www.enterprisedb.com
>>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>>>
>>>>>>> This e-mail message (and any attachment) is intended for the use of
>>>>>>> the individual or entity to whom it is addressed. This message
>>>>>>> contains information from EnterpriseDB Corporation that may be
>>>>>>> privileged, confidential, or exempt from disclosure under applicable
>>>>>>> law. If you are not the intended recipient or authorized to receive
>>>>>>> this for the intended recipient, any use, dissemination,
>>>>>>> distribution,
>>>>>>> retention, archiving, or copying of this communication is strictly
>>>>>>> prohibited. If you have received this e-mail in error, please notify
>>>>>>> the sender immediately by reply e-mail and delete this message.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best Wishes,
>>>>>> Ashutosh Bapat
>>>>>> EntepriseDB Corporation
>>>>>> The Enterprise Postgres Company
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> --
>>>>> Abbas
>>>>> Architect
>>>>> EnterpriseDB Corporation
>>>>> The Enterprise PostgreSQL Company
>>>>>
>>>>> Phone: 92-334-5100153
>>>>>
>>>>> Website: www.enterprisedb.com
>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>
>>>>> This e-mail message (and any attachment) is intended for the use of
>>>>> the individual or entity to whom it is addressed. This message
>>>>> contains information from EnterpriseDB Corporation that may be
>>>>> privileged, confidential, or exempt from disclosure under applicable
>>>>> law. If you are not the intended recipient or authorized to receive
>>>>> this for the intended recipient, any use, dissemination, distribution,
>>>>> retention, archiving, or copying of this communication is strictly
>>>>> prohibited. If you have received this e-mail in error, please notify
>>>>> the sender immediately by reply e-mail and delete this message.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best Wishes,
>>>> Ashutosh Bapat
>>>> EntepriseDB Corporation
>>>> The Enterprise Postgres Company
>>>>
>>>
>>>
>>>
>>> --
>>> --
>>> Abbas
>>> Architect
>>> EnterpriseDB Corporation
>>> The Enterprise PostgreSQL Company
>>>
>>> Phone: 92-334-5100153
>>>
>>> Website: www.enterprisedb.com
>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>
>>> This e-mail message (and any attachment) is intended for the use of
>>> the individual or entity to whom it is addressed. This message
>>> contains information from EnterpriseDB Corporation that may be
>>> privileged, confidential, or exempt from disclosure under applicable
>>> law. If you are not the intended recipient or authorized to receive
>>> this for the intended recipient, any use, dissemination, distribution,
>>> retention, archiving, or copying of this communication is strictly
>>> prohibited. If you have received this e-mail in error, please notify
>>> the sender immediately by reply e-mail and delete this message.
>>>
>>
>>
>>
>> --
>> Best Wishes,
>> Ashutosh Bapat
>> EntepriseDB Corporation
>> The Enterprise Postgres Company
>>
>
>
>
> --
> --
> Abbas
> Architect
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company
>
> Phone: 92-334-5100153
>
> Website: www.enterprisedb.com
> EnterpriseDB Blog: http://blogs.enterprisedb.com/
> Follow us on Twitter: http://www.twitter.com/enterprisedb
>
> This e-mail message (and any attachment) is intended for the use of
> the individual or entity to whom it is addressed. This message
> contains information from EnterpriseDB Corporation that may be
> privileged, confidential, or exempt from disclosure under applicable
> law. If you are not the intended recipient or authorized to receive
> this for the intended recipient, any use, dissemination, distribution,
> retention, archiving, or copying of this communication is strictly
> prohibited. If you have received this e-mail in error, please notify
> the sender immediately by reply e-mail and delete this message.
>



-- 
--
Abbas
Architect
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: 92-334-5100153

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.

Thanks Nikhils.   It looks nicd.   Let me take a bit more detailed
look before commit it.

Regards;
----------
Koichi Suzuki


2013/3/4 Nikhil Sontakke <ni...@st...>:
> Hi,
>
> PFA patch which fixes a locking issue in GTM_BeginTransactionMulti
> function. If txn_count is more than 1, then gt_TransArrayLock will be
> attempted to be locked multiple times inside the loop. The behavior is
> really undefined for pthreads and we can see weird hangs here and
> there because of it. I guess we got away with this till date because
> it was mostly being called with value 1 for txn_count.
>
>
> Regards,
> Nikhils
> --
> StormDB - http://www.stormdb.com
> The Database Cloud
> Postgres-XC Support and Service
>
> ------------------------------------------------------------------------------
> 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_feb
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

Thanks Nikhil.   Recent global xmin needs a bit of improvement.   Lock
should be  fixed also.    I can look into it after I have a bit more
progress on pgxc_ctl C version code.    You're welcome to write the
fix.

Regards;
----------
Koichi Suzuki


2013/3/4 Nikhil Sontakke <ni...@st...>:
> Hi,
>
> If I look at GTM_GetTransactionSnapshot() function, it's taking a READ
> lock on GTMTransactions.gt_TransArrayLock. After taking that lock it's
> modifying fields like
>
> GTMTransactions.gt_recent_global_xmin
> GTMTransactions.gt_transactions_array
>
> Hardly READ type of behavior. This behavior particularly seems
> dangerous if multiple threads modify the gt_recent_global_xmin value
> above while holding read locks.
>
> Regards,
> Nikhils
> --
> StormDB - http://www.stormdb.com
> The Database Cloud
> Postgres-XC Support and Service
>
> ------------------------------------------------------------------------------
> 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_feb
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers

Hi,

If I look at GTM_GetTransactionSnapshot() function, it's taking a READ
lock on GTMTransactions.gt_TransArrayLock. After taking that lock it's
modifying fields like

GTMTransactions.gt_recent_global_xmin
GTMTransactions.gt_transactions_array

Hardly READ type of behavior. This behavior particularly seems
dangerous if multiple threads modify the gt_recent_global_xmin value
above while holding read locks.

Regards,
Nikhils
-- 
StormDB - http://www.stormdb.com
The Database Cloud
Postgres-XC Support and Service

On 4 March 2013 14:44, Abbas Butt <abb...@en...> wrote:
>
>
> On Mon, Mar 4, 2013 at 2:00 PM, Amit Khandekar
> <ami...@en...> wrote:
>>
>> On 1 March 2013 18:45, Abbas Butt <abb...@en...> wrote:
>> >
>> >
>> > On Fri, Mar 1, 2013 at 5:48 PM, Amit Khandekar
>> > <ami...@en...> wrote:
>> >>
>> >> On 19 February 2013 12:37, Abbas Butt <abb...@en...>
>> >> wrote:
>> >> >
>> >> > Hi,
>> >> > Attached please find a patch that locks the cluster so that dump can
>> >> > be
>> >> > taken to be restored on the new node to be added.
>> >> >
>> >> > To lock the cluster the patch adds a new GUC parameter called
>> >> > xc_lock_for_backup, however its status is maintained by the pooler.
>> >> > The
>> >> > reason is that the default behavior of XC is to release connections
>> >> > as
>> >> > soon
>> >> > as a command is done and it uses PersistentConnections GUC to control
>> >> > the
>> >> > behavior. We in this case however need a status that is independent
>> >> > of
>> >> > the
>> >> > setting of PersistentConnections.
>> >> >
>> >> > Assume we have two coordinator cluster, the patch provides this
>> >> > behavior:
>> >> >
>> >> > Case 1: set and show
>> >> > ====================
>> >> > psql test -p 5432
>> >> > set xc_lock_for_backup=yes;
>> >> > show xc_lock_for_backup;
>> >> >  xc_lock_for_backup
>> >> > --------------------
>> >> >  yes
>> >> > (1 row)
>> >> >
>> >> > Case 2: set from one client show from other
>> >> > ==================================
>> >> > psql test -p 5432
>> >> > set xc_lock_for_backup=yes;
>> >> > (From another tab)
>> >> > psql test -p 5432
>> >> > show xc_lock_for_backup;
>> >> >  xc_lock_for_backup
>> >> > --------------------
>> >> >  yes
>> >> > (1 row)
>> >> >
>> >> > Case 3: set from one, quit it, run again and show
>> >> > ======================================
>> >> > psql test -p 5432
>> >> > set xc_lock_for_backup=yes;
>> >> > \q
>> >> > psql test -p 5432
>> >> > show xc_lock_for_backup;
>> >> >  xc_lock_for_backup
>> >> > --------------------
>> >> >  yes
>> >> > (1 row)
>> >> >
>> >> > Case 4: set on one coordinator, show from other
>> >> > =====================================
>> >> > psql test -p 5432
>> >> > set xc_lock_for_backup=yes;
>> >> > (From another tab)
>> >> > psql test -p 5433
>> >> > show xc_lock_for_backup;
>> >> >  xc_lock_for_backup
>> >> > --------------------
>> >> >  yes
>> >> > (1 row)
>> >> >
>> >> > pg_dump and pg_dumpall seem to work fine after locking the cluster
>> >> > for
>> >> > backup but I would test these utilities in detail next.
>> >> >
>> >> > Also I have yet to look in detail that standard_ProcessUtility is the
>> >> > only
>> >> > place that updates the portion of catalog that is dumped. There may
>> >> > be
>> >> > some
>> >> > other places too that need to be blocked for catalog updates.
>> >> >
>> >> > The patch adds no extra warnings and regression shows no extra
>> >> > failure.
>> >> >
>> >> > Comments are welcome.
>> >>
>> >> Abbas wrote on another thread:
>> >>
>> >> >   Amit wrote on another thread:
>> >> >> I haven't given a thought on the earlier patch you sent for cluster
>> >> >> lock
>> >> >> implementation; may be we can discuss this on that thread, but just
>> >> >> a
>> >> >> quick
>> >> >> question:
>> >> >>
>> >> >> Does the cluster-lock command wait for the ongoing DDL commands to
>> >> >> finish
>> >> >> ? If not, we have problems. The subsequent pg_dump would not contain
>> >> >> objects
>> >> >> created by these particular DDLs.
>> >> >
>> >> >
>> >> > Suppose you have a two coordinator cluster. Assume one client
>> >> > connected
>> >> > to
>> >> > each. Suppose one client issues a lock cluster command and the other
>> >> > issues
>> >> > a DDL. Is this what you mean by an ongoing DDL? If true then answer
>> >> > to
>> >> > your
>> >> > question is Yes.
>> >> >
>> >> > Suppose you have a prepared transaction that has a DDL in it, again
>> >> > if
>> >> > this
>> >> > can be considered an on going DDL, then again answer to your question
>> >> > is
>> >> > Yes.
>> >> >
>> >> > Suppose you have a two coordinator cluster. Assume one client
>> >> > connected
>> >> > to
>> >> > each. One client starts a transaction and issues a DDL, the second
>> >> > client
>> >> > issues a lock cluster command, the first commits the transaction. If
>> >> > this is
>> >> > an ongoing DDL, then the answer to your question is No.
>> >>
>> >> Yes this last scenario is what I meant: A DDL has been executed on
>> >> nodes,
>> >> but
>> >>  not committed, when the cluster lock command is run and then pg_dump
>> >> immediately
>> >> starts its transaction before the DDL is committed. Here pg_dump does
>> >> not see the new objects that would be created.
>>

--
>> Come to think of it, there would always be a small interval where the
>> concurrency issue would remain.
>
>

> Can you please give an example to clarify.

--

>
>>
>> If we were to totally get rid of this
>> concurrency issue, we need to have some kind of lock. For e.g. the
>> object access hook function will have shared acces lock on this object
>> (may be on pg_depend because it is always used for objcet
>> creation/drop ??) and the lock-cluster command will try to get
>> exclusive lock on the same. This of course should be done after we are
>> sure object access hook is called on all types of objects.

For e.g. Suppose we come up with a solution where just before
transaction commit (i.e. in transaction callback) we check if the
cluster is locked and there are objects created/dropped in the current
transaction, and then commit if the cluster is not locked. But betwen
the instance where we do the lock check and the instance where we
actually commit, during this time gap, there can be cluster lock
issued followed immediately by pg_dump. For  pg_dump the new objects
created in that transaction will not be visible. So by doing the
cluster-lock check at transaction callback, we have reduced the time
gap significantly although it is not completely gone.

But if lock-cluster command and the object creation functions (whether
it is object acces hook or process_standardUtility) have a lock on a
common object, this concurrency issue might be solved. As of now, I
see pg_depend as one common object which is *always* accessed for
object creation/drop.


>>
>>
>> >>
>> >> I myself am not sure how would we prevent this from happening. There
>> >> are two callback hooks that might be worth considering though:
>> >> 1. Transaction End callback (CallXactCallbacks)
>> >> 2. Object creation/drop hook (InvokeObjectAccessHook)
>> >>
>> >> Suppose we create an object creation/drop hook function that would :
>> >> 1. store the current transaction id in a global objects_created list
>> >> if the cluster is not locked,
>> >> 2. or else if the cluster is locked, this hook would ereport() saying
>> >> "cannot create catalog objects in this mode".
>> >>
>> >> And then during transaction commit , a new transaction callback hook
>> >> will:
>> >> 1. Check the above objects_created list to see if the current
>> >> transaction has any objects created/dropped.
>> >> 2. If found and if the cluster-lock is on, it will again ereport()
>> >> saying "cannot create catalog objects in this mode"
>> >>
>> >> Thinking more on the object creation hook, we can even consider this
>> >> as a substitute for checking the cluster-lock status in
>> >> standardProcessUtility(). But I am not sure whether this hook does get
>> >> called on each of the catalog objects. At least the code comments say
>> >> it does.
>> >
>> >
>> > These are very good ideas, Thanks, I will work on those lines and will
>> > report back.
>> >
>> >>
>> >>
>> >>
>> >>
>> >> > But its a matter of
>> >> > deciding which camp are we going to put COMMIT in, the allow camp, or
>> >> > the
>> >> > deny camp. I decided to put it in allow camp, because I have not yet
>> >> > written
>> >> > any code to detect whether a transaction being committed has a DDL in
>> >> > it
>> >> > or
>> >> > not, and stopping all transactions from committing looks too
>> >> > restrictive
>> >> > to
>> >> > me.
>> >>
>> >>
>> >> >
>> >> > Do you have some other meaning of an ongoing DDL?
>> >>
>> >>
>> >>
>> >> >
>> >> > --
>> >> > Abbas
>> >> > Architect
>> >> > EnterpriseDB Corporation
>> >> > The Enterprise PostgreSQL Company
>> >> >
>> >> > Phone: 92-334-5100153
>> >> >
>> >> > Website: www.enterprisedb.com
>> >> > EnterpriseDB Blog: http://blogs.enterprisedb.com/
>> >> > Follow us on Twitter: http://www.twitter.com/enterprisedb
>> >> >
>> >> > This e-mail message (and any attachment) is intended for the use of
>> >> > the individual or entity to whom it is addressed. This message
>> >> > contains information from EnterpriseDB Corporation that may be
>> >> > privileged, confidential, or exempt from disclosure under applicable
>> >> > law. If you are not the intended recipient or authorized to receive
>> >> > this for the intended recipient, any use, dissemination,
>> >> > distribution,
>> >> > retention, archiving, or copying of this communication is strictly
>> >> > prohibited. If you have received this e-mail in error, please notify
>> >> > the sender immediately by reply e-mail and delete this message.
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > 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_feb
>> >> > _______________________________________________
>> >> > Postgres-xc-developers mailing list
>> >> > Pos...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>> >> >
>> >
>> >
>> >
>> >
>> > --
>> > --
>> > Abbas
>> > Architect
>> > EnterpriseDB Corporation
>> > The Enterprise PostgreSQL Company
>> >
>> > Phone: 92-334-5100153
>> >
>> > Website: www.enterprisedb.com
>> > EnterpriseDB Blog: http://blogs.enterprisedb.com/
>> > Follow us on Twitter: http://www.twitter.com/enterprisedb
>> >
>> > This e-mail message (and any attachment) is intended for the use of
>> > the individual or entity to whom it is addressed. This message
>> > contains information from EnterpriseDB Corporation that may be
>> > privileged, confidential, or exempt from disclosure under applicable
>> > law. If you are not the intended recipient or authorized to receive
>> > this for the intended recipient, any use, dissemination, distribution,
>> > retention, archiving, or copying of this communication is strictly
>> > prohibited. If you have received this e-mail in error, please notify
>> > the sender immediately by reply e-mail and delete this message.
>
>
>
>
> --
> --
> Abbas
> Architect
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company
>
> Phone: 92-334-5100153
>
> Website: www.enterprisedb.com
> EnterpriseDB Blog: http://blogs.enterprisedb.com/
> Follow us on Twitter: http://www.twitter.com/enterprisedb
>
> This e-mail message (and any attachment) is intended for the use of
> the individual or entity to whom it is addressed. This message
> contains information from EnterpriseDB Corporation that may be
> privileged, confidential, or exempt from disclosure under applicable
> law. If you are not the intended recipient or authorized to receive
> this for the intended recipient, any use, dissemination, distribution,
> retention, archiving, or copying of this communication is strictly
> prohibited. If you have received this e-mail in error, please notify
> the sender immediately by reply e-mail and delete this message.

On Mon, Mar 4, 2013 at 2:09 PM, Ashutosh Bapat <
ash...@en...> wrote:

>
>
> On Mon, Mar 4, 2013 at 1:51 PM, Abbas Butt <abb...@en...>wrote:
>
>> What I had in mind was to have pg_dump, when run with include-node, emit
>> CREATE NODE/ CREATE NODE GROUP commands only and nothing else. Those
>> commands will be used to create existing nodes/groups on the new
>> coordinator to be added. So it does make sense to use this option
>> independently, in fact it is supposed to be used independently.
>>
>>
> Ok, got it. But then include-node is really a misnomer. We should use
> --dump-nodes or something like that.
>

In that case we can use include-nodes here.


>
>
>>
>> On Mon, Mar 4, 2013 at 11:21 AM, Ashutosh Bapat <
>> ash...@en...> wrote:
>>
>>> Dumping TO NODE clause only makes sense if we dump CREATE NODE/ CREATE
>>> NODE GROUP. Dumping CREATE NODE/CREATE NODE GROUP may make sense
>>> independently, but might be useless without dumping TO NODE clause.
>>>
>>> BTW, OTOH, dumping CREATE NODE/CREATE NODE GROUP clause wouldn't create
>>> the nodes on all the coordinators,
>>
>>
>> All the coordinators already have the nodes information.
>>
>>
>>> but only the coordinator where dump will be restored. That's another
>>> thing you will need to consider OR are you going to fix that as well?
>>
>>
>> As a first step I am only listing the manual steps required to add a new
>> node, that might say run this command on all the existing coordinators by
>> connecting to them one by one manually. We can decide to automate these
>> steps later.
>>
>>
> ok
>
>
>
>>
>>
>>>
>>>
>>> On Mon, Mar 4, 2013 at 11:41 AM, Abbas Butt <abb...@en...
>>> > wrote:
>>>
>>>> I was thinking of using include-nodes to dump CREATE NODE / CREATE NODE
>>>> GROUP, that is required as one of the missing links in adding a new node.
>>>> How do you think about that?
>>>>
>>>>
>>>> On Mon, Mar 4, 2013 at 9:02 AM, Ashutosh Bapat <
>>>> ash...@en...> wrote:
>>>>
>>>>> Hi Abbas,
>>>>> Please take a look at
>>>>> http://www.postgresql.org/docs/9.2/static/app-pgdump.html, which
>>>>> gives all the command line options for pg_dump. instead of
>>>>> include-to-node-clause, just include-nodes would suffice, I guess.
>>>>>
>>>>>
>>>>> On Fri, Mar 1, 2013 at 8:36 PM, Abbas Butt <
>>>>> abb...@en...> wrote:
>>>>>
>>>>>> PFA a updated patch that provides a command line argument called
>>>>>> --include-to-node-clause to let pg_dump know that the created dump is
>>>>>> supposed to emit TO NODE clause in the CREATE TABLE command.
>>>>>> If the argument is provided while taking the dump from a datanode, it
>>>>>> does not show TO NODE clause in the dump since the catalog table is empty
>>>>>> in this case.
>>>>>> The documentation of pg_dump is updated accordingly.
>>>>>> The rest of the functionality stays the same as before.
>>>>>>
>>>>>>
>>>>>> On Mon, Feb 25, 2013 at 10:29 AM, Ashutosh Bapat <
>>>>>> ash...@en...> wrote:
>>>>>>
>>>>>>> I think we should always dump DISTRIBUTE BY.
>>>>>>>
>>>>>>> PG does not stop dumping (or provide an option to do so) newer
>>>>>>> syntax so that the dump will work on older versions. On similar lines, an
>>>>>>> XC dump can not be used against PG without modification (removing
>>>>>>> DISTRIBUTE BY). There can be more serious problems like exceeding table
>>>>>>> size limits if an XC dump is tried to be restored in PG.
>>>>>>>
>>>>>>> As to TO NODE clause, I agree, that one can restore the dump on a
>>>>>>> cluster with different configuration, so giving an option to dump TO NODE
>>>>>>> clause will help.
>>>>>>>
>>>>>>> On Mon, Feb 25, 2013 at 6:42 AM, Michael Paquier <
>>>>>>> mic...@gm...> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Feb 25, 2013 at 4:17 AM, Abbas Butt <
>>>>>>>> abb...@en...> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Feb 24, 2013 at 5:33 PM, Michael Paquier <
>>>>>>>>> mic...@gm...> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 24, 2013 at 7:04 PM, Abbas Butt <
>>>>>>>>>> abb...@en...> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Feb 24, 2013 at 1:44 PM, Michael Paquier <
>>>>>>>>>>> mic...@gm...> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Feb 24, 2013 at 3:51 PM, Abbas Butt <
>>>>>>>>>>>> abb...@en...> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>> PFA a patch to  fix pg_dump to generate TO NODE clause in the
>>>>>>>>>>>>> dump.
>>>>>>>>>>>>> This is required because otherwise all tables get created on
>>>>>>>>>>>>> all nodes after a dump-restore cycle.
>>>>>>>>>>>>>
>>>>>>>>>>>> Not sure this is good if you take a dump of an XC cluster to
>>>>>>>>>>>> restore that to a vanilla Postgres cluster.
>>>>>>>>>>>> Why not adding a new option that would control the generation
>>>>>>>>>>>> of this clause instead of forcing it?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I think you can use the pg_dump that comes with vanilla PG to do
>>>>>>>>>>> that, can't you? But I am open to adding a control option if every body
>>>>>>>>>>> thinks so.
>>>>>>>>>>>
>>>>>>>>>> Sure you can, this is just to simplify the life of users a
>>>>>>>>>> maximum by not having multiple pg_dump binaries in their serves.
>>>>>>>>>> Saying that, I think that there is no option to choose if
>>>>>>>>>> DISTRIBUTE BY is printed in the dump or not...
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yah if we choose to have an option we will put both DISTRIBUTE BY
>>>>>>>>> and TO NODE under it.
>>>>>>>>>
>>>>>>>> Why not an option for DISTRIBUTE BY, and another for TO NODE?
>>>>>>>> This would bring more flexibility to the way dumps are generated.
>>>>>>>> --
>>>>>>>> Michael
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> 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_feb
>>>>>>>> _______________________________________________
>>>>>>>> Postgres-xc-developers mailing list
>>>>>>>> Pos...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best Wishes,
>>>>>>> Ashutosh Bapat
>>>>>>> EntepriseDB Corporation
>>>>>>> The Enterprise Postgres Company
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> Abbas
>>>>>> Architect
>>>>>> EnterpriseDB Corporation
>>>>>> The Enterprise PostgreSQL Company
>>>>>>
>>>>>> Phone: 92-334-5100153
>>>>>>
>>>>>> Website: www.enterprisedb.com
>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>>
>>>>>> This e-mail message (and any attachment) is intended for the use of
>>>>>> the individual or entity to whom it is addressed. This message
>>>>>> contains information from EnterpriseDB Corporation that may be
>>>>>> privileged, confidential, or exempt from disclosure under applicable
>>>>>> law. If you are not the intended recipient or authorized to receive
>>>>>> this for the intended recipient, any use, dissemination, distribution,
>>>>>> retention, archiving, or copying of this communication is strictly
>>>>>> prohibited. If you have received this e-mail in error, please notify
>>>>>> the sender immediately by reply e-mail and delete this message.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best Wishes,
>>>>> Ashutosh Bapat
>>>>> EntepriseDB Corporation
>>>>> The Enterprise Postgres Company
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> Abbas
>>>> Architect
>>>> EnterpriseDB Corporation
>>>> The Enterprise PostgreSQL Company
>>>>
>>>> Phone: 92-334-5100153
>>>>
>>>> Website: www.enterprisedb.com
>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>
>>>> This e-mail message (and any attachment) is intended for the use of
>>>> the individual or entity to whom it is addressed. This message
>>>> contains information from EnterpriseDB Corporation that may be
>>>> privileged, confidential, or exempt from disclosure under applicable
>>>> law. If you are not the intended recipient or authorized to receive
>>>> this for the intended recipient, any use, dissemination, distribution,
>>>> retention, archiving, or copying of this communication is strictly
>>>> prohibited. If you have received this e-mail in error, please notify
>>>> the sender immediately by reply e-mail and delete this message.
>>>>
>>>
>>>
>>>
>>> --
>>> Best Wishes,
>>> Ashutosh Bapat
>>> EntepriseDB Corporation
>>> The Enterprise Postgres Company
>>>
>>
>>
>>
>> --
>> --
>> Abbas
>> Architect
>> EnterpriseDB Corporation
>> The Enterprise PostgreSQL Company
>>
>> Phone: 92-334-5100153
>>
>> Website: www.enterprisedb.com
>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>
>> This e-mail message (and any attachment) is intended for the use of
>> the individual or entity to whom it is addressed. This message
>> contains information from EnterpriseDB Corporation that may be
>> privileged, confidential, or exempt from disclosure under applicable
>> law. If you are not the intended recipient or authorized to receive
>> this for the intended recipient, any use, dissemination, distribution,
>> retention, archiving, or copying of this communication is strictly
>> prohibited. If you have received this e-mail in error, please notify
>> the sender immediately by reply e-mail and delete this message.
>>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company
>



-- 
--
Abbas
Architect
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: 92-334-5100153

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.

Hi,

PFA patch which fixes a locking issue in GTM_BeginTransactionMulti
function. If txn_count is more than 1, then gt_TransArrayLock will be
attempted to be locked multiple times inside the loop. The behavior is
really undefined for pthreads and we can see weird hangs here and
there because of it. I guess we got away with this till date because
it was mostly being called with value 1 for txn_count.


Regards,
Nikhils
-- 
StormDB - http://www.stormdb.com
The Database Cloud
Postgres-XC Support and Service

On Mon, Mar 4, 2013 at 2:00 PM, Amit Khandekar <
ami...@en...> wrote:

> On 1 March 2013 18:45, Abbas Butt <abb...@en...> wrote:
> >
> >
> > On Fri, Mar 1, 2013 at 5:48 PM, Amit Khandekar
> > <ami...@en...> wrote:
> >>
> >> On 19 February 2013 12:37, Abbas Butt <abb...@en...>
> wrote:
> >> >
> >> > Hi,
> >> > Attached please find a patch that locks the cluster so that dump can
> be
> >> > taken to be restored on the new node to be added.
> >> >
> >> > To lock the cluster the patch adds a new GUC parameter called
> >> > xc_lock_for_backup, however its status is maintained by the pooler.
> The
> >> > reason is that the default behavior of XC is to release connections as
> >> > soon
> >> > as a command is done and it uses PersistentConnections GUC to control
> >> > the
> >> > behavior. We in this case however need a status that is independent of
> >> > the
> >> > setting of PersistentConnections.
> >> >
> >> > Assume we have two coordinator cluster, the patch provides this
> >> > behavior:
> >> >
> >> > Case 1: set and show
> >> > ====================
> >> > psql test -p 5432
> >> > set xc_lock_for_backup=yes;
> >> > show xc_lock_for_backup;
> >> >  xc_lock_for_backup
> >> > --------------------
> >> >  yes
> >> > (1 row)
> >> >
> >> > Case 2: set from one client show from other
> >> > ==================================
> >> > psql test -p 5432
> >> > set xc_lock_for_backup=yes;
> >> > (From another tab)
> >> > psql test -p 5432
> >> > show xc_lock_for_backup;
> >> >  xc_lock_for_backup
> >> > --------------------
> >> >  yes
> >> > (1 row)
> >> >
> >> > Case 3: set from one, quit it, run again and show
> >> > ======================================
> >> > psql test -p 5432
> >> > set xc_lock_for_backup=yes;
> >> > \q
> >> > psql test -p 5432
> >> > show xc_lock_for_backup;
> >> >  xc_lock_for_backup
> >> > --------------------
> >> >  yes
> >> > (1 row)
> >> >
> >> > Case 4: set on one coordinator, show from other
> >> > =====================================
> >> > psql test -p 5432
> >> > set xc_lock_for_backup=yes;
> >> > (From another tab)
> >> > psql test -p 5433
> >> > show xc_lock_for_backup;
> >> >  xc_lock_for_backup
> >> > --------------------
> >> >  yes
> >> > (1 row)
> >> >
> >> > pg_dump and pg_dumpall seem to work fine after locking the cluster for
> >> > backup but I would test these utilities in detail next.
> >> >
> >> > Also I have yet to look in detail that standard_ProcessUtility is the
> >> > only
> >> > place that updates the portion of catalog that is dumped. There may be
> >> > some
> >> > other places too that need to be blocked for catalog updates.
> >> >
> >> > The patch adds no extra warnings and regression shows no extra
> failure.
> >> >
> >> > Comments are welcome.
> >>
> >> Abbas wrote on another thread:
> >>
> >> >   Amit wrote on another thread:
> >> >> I haven't given a thought on the earlier patch you sent for cluster
> >> >> lock
> >> >> implementation; may be we can discuss this on that thread, but just a
> >> >> quick
> >> >> question:
> >> >>
> >> >> Does the cluster-lock command wait for the ongoing DDL commands to
> >> >> finish
> >> >> ? If not, we have problems. The subsequent pg_dump would not contain
> >> >> objects
> >> >> created by these particular DDLs.
> >> >
> >> >
> >> > Suppose you have a two coordinator cluster. Assume one client
> connected
> >> > to
> >> > each. Suppose one client issues a lock cluster command and the other
> >> > issues
> >> > a DDL. Is this what you mean by an ongoing DDL? If true then answer to
> >> > your
> >> > question is Yes.
> >> >
> >> > Suppose you have a prepared transaction that has a DDL in it, again if
> >> > this
> >> > can be considered an on going DDL, then again answer to your question
> is
> >> > Yes.
> >> >
> >> > Suppose you have a two coordinator cluster. Assume one client
> connected
> >> > to
> >> > each. One client starts a transaction and issues a DDL, the second
> >> > client
> >> > issues a lock cluster command, the first commits the transaction. If
> >> > this is
> >> > an ongoing DDL, then the answer to your question is No.
> >>
> >> Yes this last scenario is what I meant: A DDL has been executed on
> nodes,
> >> but
> >>  not committed, when the cluster lock command is run and then pg_dump
> >> immediately
> >> starts its transaction before the DDL is committed. Here pg_dump does
> >> not see the new objects that would be created.
>
> Come to think of it, there would always be a small interval where the
> concurrency issue would remain.


Can you please give an example to clarify.


> If we were to totally get rid of this
> concurrency issue, we need to have some kind of lock. For e.g. the
> object access hook function will have shared acces lock on this object
> (may be on pg_depend because it is always used for objcet
> creation/drop ??) and the lock-cluster command will try to get
> exclusive lock on the same. This of course should be done after we are
> sure object access hook is called on all types of objects.
>
>
> >>
> >> I myself am not sure how would we prevent this from happening. There
> >> are two callback hooks that might be worth considering though:
> >> 1. Transaction End callback (CallXactCallbacks)
> >> 2. Object creation/drop hook (InvokeObjectAccessHook)
> >>
> >> Suppose we create an object creation/drop hook function that would :
> >> 1. store the current transaction id in a global objects_created list
> >> if the cluster is not locked,
> >> 2. or else if the cluster is locked, this hook would ereport() saying
> >> "cannot create catalog objects in this mode".
> >>
> >> And then during transaction commit , a new transaction callback hook
> will:
> >> 1. Check the above objects_created list to see if the current
> >> transaction has any objects created/dropped.
> >> 2. If found and if the cluster-lock is on, it will again ereport()
> >> saying "cannot create catalog objects in this mode"
> >>
> >> Thinking more on the object creation hook, we can even consider this
> >> as a substitute for checking the cluster-lock status in
> >> standardProcessUtility(). But I am not sure whether this hook does get
> >> called on each of the catalog objects. At least the code comments say
> >> it does.
> >
> >
> > These are very good ideas, Thanks, I will work on those lines and will
> > report back.
> >
> >>
> >>
> >>
> >>
> >> > But its a matter of
> >> > deciding which camp are we going to put COMMIT in, the allow camp, or
> >> > the
> >> > deny camp. I decided to put it in allow camp, because I have not yet
> >> > written
> >> > any code to detect whether a transaction being committed has a DDL in
> it
> >> > or
> >> > not, and stopping all transactions from committing looks too
> restrictive
> >> > to
> >> > me.
> >>
> >>
> >> >
> >> > Do you have some other meaning of an ongoing DDL?
> >>
> >>
> >>
> >> >
> >> > --
> >> > Abbas
> >> > Architect
> >> > EnterpriseDB Corporation
> >> > The Enterprise PostgreSQL Company
> >> >
> >> > Phone: 92-334-5100153
> >> >
> >> > Website: www.enterprisedb.com
> >> > EnterpriseDB Blog: http://blogs.enterprisedb.com/
> >> > Follow us on Twitter: http://www.twitter.com/enterprisedb
> >> >
> >> > This e-mail message (and any attachment) is intended for the use of
> >> > the individual or entity to whom it is addressed. This message
> >> > contains information from EnterpriseDB Corporation that may be
> >> > privileged, confidential, or exempt from disclosure under applicable
> >> > law. If you are not the intended recipient or authorized to receive
> >> > this for the intended recipient, any use, dissemination, distribution,
> >> > retention, archiving, or copying of this communication is strictly
> >> > prohibited. If you have received this e-mail in error, please notify
> >> > the sender immediately by reply e-mail and delete this message.
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > 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_feb
> >> > _______________________________________________
> >> > Postgres-xc-developers mailing list
> >> > Pos...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >> >
> >
> >
> >
> >
> > --
> > --
> > Abbas
> > Architect
> > EnterpriseDB Corporation
> > The Enterprise PostgreSQL Company
> >
> > Phone: 92-334-5100153
> >
> > Website: www.enterprisedb.com
> > EnterpriseDB Blog: http://blogs.enterprisedb.com/
> > Follow us on Twitter: http://www.twitter.com/enterprisedb
> >
> > This e-mail message (and any attachment) is intended for the use of
> > the individual or entity to whom it is addressed. This message
> > contains information from EnterpriseDB Corporation that may be
> > privileged, confidential, or exempt from disclosure under applicable
> > law. If you are not the intended recipient or authorized to receive
> > this for the intended recipient, any use, dissemination, distribution,
> > retention, archiving, or copying of this communication is strictly
> > prohibited. If you have received this e-mail in error, please notify
> > the sender immediately by reply e-mail and delete this message.
>



-- 
--
Abbas
Architect
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: 92-334-5100153

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.

On Mon, Mar 4, 2013 at 1:51 PM, Abbas Butt <abb...@en...>wrote:

> What I had in mind was to have pg_dump, when run with include-node, emit
> CREATE NODE/ CREATE NODE GROUP commands only and nothing else. Those
> commands will be used to create existing nodes/groups on the new
> coordinator to be added. So it does make sense to use this option
> independently, in fact it is supposed to be used independently.
>
>
Ok, got it. But then include-node is really a misnomer. We should use
--dump-nodes or something like that.


>
> On Mon, Mar 4, 2013 at 11:21 AM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>> Dumping TO NODE clause only makes sense if we dump CREATE NODE/ CREATE
>> NODE GROUP. Dumping CREATE NODE/CREATE NODE GROUP may make sense
>> independently, but might be useless without dumping TO NODE clause.
>>
>> BTW, OTOH, dumping CREATE NODE/CREATE NODE GROUP clause wouldn't create
>> the nodes on all the coordinators,
>
>
> All the coordinators already have the nodes information.
>
>
>> but only the coordinator where dump will be restored. That's another
>> thing you will need to consider OR are you going to fix that as well?
>
>
> As a first step I am only listing the manual steps required to add a new
> node, that might say run this command on all the existing coordinators by
> connecting to them one by one manually. We can decide to automate these
> steps later.
>
>
ok



>
>
>>
>>
>> On Mon, Mar 4, 2013 at 11:41 AM, Abbas Butt <abb...@en...>wrote:
>>
>>> I was thinking of using include-nodes to dump CREATE NODE / CREATE NODE
>>> GROUP, that is required as one of the missing links in adding a new node.
>>> How do you think about that?
>>>
>>>
>>> On Mon, Mar 4, 2013 at 9:02 AM, Ashutosh Bapat <
>>> ash...@en...> wrote:
>>>
>>>> Hi Abbas,
>>>> Please take a look at
>>>> http://www.postgresql.org/docs/9.2/static/app-pgdump.html, which gives
>>>> all the command line options for pg_dump. instead of
>>>> include-to-node-clause, just include-nodes would suffice, I guess.
>>>>
>>>>
>>>> On Fri, Mar 1, 2013 at 8:36 PM, Abbas Butt <abb...@en...
>>>> > wrote:
>>>>
>>>>> PFA a updated patch that provides a command line argument called
>>>>> --include-to-node-clause to let pg_dump know that the created dump is
>>>>> supposed to emit TO NODE clause in the CREATE TABLE command.
>>>>> If the argument is provided while taking the dump from a datanode, it
>>>>> does not show TO NODE clause in the dump since the catalog table is empty
>>>>> in this case.
>>>>> The documentation of pg_dump is updated accordingly.
>>>>> The rest of the functionality stays the same as before.
>>>>>
>>>>>
>>>>> On Mon, Feb 25, 2013 at 10:29 AM, Ashutosh Bapat <
>>>>> ash...@en...> wrote:
>>>>>
>>>>>> I think we should always dump DISTRIBUTE BY.
>>>>>>
>>>>>> PG does not stop dumping (or provide an option to do so) newer syntax
>>>>>> so that the dump will work on older versions. On similar lines, an XC dump
>>>>>> can not be used against PG without modification (removing DISTRIBUTE BY).
>>>>>> There can be more serious problems like exceeding table size limits if an
>>>>>> XC dump is tried to be restored in PG.
>>>>>>
>>>>>> As to TO NODE clause, I agree, that one can restore the dump on a
>>>>>> cluster with different configuration, so giving an option to dump TO NODE
>>>>>> clause will help.
>>>>>>
>>>>>> On Mon, Feb 25, 2013 at 6:42 AM, Michael Paquier <
>>>>>> mic...@gm...> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Feb 25, 2013 at 4:17 AM, Abbas Butt <
>>>>>>> abb...@en...> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Feb 24, 2013 at 5:33 PM, Michael Paquier <
>>>>>>>> mic...@gm...> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Feb 24, 2013 at 7:04 PM, Abbas Butt <
>>>>>>>>> abb...@en...> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 24, 2013 at 1:44 PM, Michael Paquier <
>>>>>>>>>> mic...@gm...> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Feb 24, 2013 at 3:51 PM, Abbas Butt <
>>>>>>>>>>> abb...@en...> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> PFA a patch to  fix pg_dump to generate TO NODE clause in the
>>>>>>>>>>>> dump.
>>>>>>>>>>>> This is required because otherwise all tables get created on
>>>>>>>>>>>> all nodes after a dump-restore cycle.
>>>>>>>>>>>>
>>>>>>>>>>> Not sure this is good if you take a dump of an XC cluster to
>>>>>>>>>>> restore that to a vanilla Postgres cluster.
>>>>>>>>>>> Why not adding a new option that would control the generation of
>>>>>>>>>>> this clause instead of forcing it?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think you can use the pg_dump that comes with vanilla PG to do
>>>>>>>>>> that, can't you? But I am open to adding a control option if every body
>>>>>>>>>> thinks so.
>>>>>>>>>>
>>>>>>>>> Sure you can, this is just to simplify the life of users a maximum
>>>>>>>>> by not having multiple pg_dump binaries in their serves.
>>>>>>>>> Saying that, I think that there is no option to choose if
>>>>>>>>> DISTRIBUTE BY is printed in the dump or not...
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yah if we choose to have an option we will put both DISTRIBUTE BY
>>>>>>>> and TO NODE under it.
>>>>>>>>
>>>>>>> Why not an option for DISTRIBUTE BY, and another for TO NODE?
>>>>>>> This would bring more flexibility to the way dumps are generated.
>>>>>>> --
>>>>>>> Michael
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> 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_feb
>>>>>>> _______________________________________________
>>>>>>> Postgres-xc-developers mailing list
>>>>>>> Pos...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best Wishes,
>>>>>> Ashutosh Bapat
>>>>>> EntepriseDB Corporation
>>>>>> The Enterprise Postgres Company
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> --
>>>>> Abbas
>>>>> Architect
>>>>> EnterpriseDB Corporation
>>>>> The Enterprise PostgreSQL Company
>>>>>
>>>>> Phone: 92-334-5100153
>>>>>
>>>>> Website: www.enterprisedb.com
>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>
>>>>> This e-mail message (and any attachment) is intended for the use of
>>>>> the individual or entity to whom it is addressed. This message
>>>>> contains information from EnterpriseDB Corporation that may be
>>>>> privileged, confidential, or exempt from disclosure under applicable
>>>>> law. If you are not the intended recipient or authorized to receive
>>>>> this for the intended recipient, any use, dissemination, distribution,
>>>>> retention, archiving, or copying of this communication is strictly
>>>>> prohibited. If you have received this e-mail in error, please notify
>>>>> the sender immediately by reply e-mail and delete this message.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best Wishes,
>>>> Ashutosh Bapat
>>>> EntepriseDB Corporation
>>>> The Enterprise Postgres Company
>>>>
>>>
>>>
>>>
>>> --
>>> --
>>> Abbas
>>> Architect
>>> EnterpriseDB Corporation
>>> The Enterprise PostgreSQL Company
>>>
>>> Phone: 92-334-5100153
>>>
>>> Website: www.enterprisedb.com
>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>
>>> This e-mail message (and any attachment) is intended for the use of
>>> the individual or entity to whom it is addressed. This message
>>> contains information from EnterpriseDB Corporation that may be
>>> privileged, confidential, or exempt from disclosure under applicable
>>> law. If you are not the intended recipient or authorized to receive
>>> this for the intended recipient, any use, dissemination, distribution,
>>> retention, archiving, or copying of this communication is strictly
>>> prohibited. If you have received this e-mail in error, please notify
>>> the sender immediately by reply e-mail and delete this message.
>>>
>>
>>
>>
>> --
>> Best Wishes,
>> Ashutosh Bapat
>> EntepriseDB Corporation
>> The Enterprise Postgres Company
>>
>
>
>
> --
> --
> Abbas
> Architect
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company
>
> Phone: 92-334-5100153
>
> Website: www.enterprisedb.com
> EnterpriseDB Blog: http://blogs.enterprisedb.com/
> Follow us on Twitter: http://www.twitter.com/enterprisedb
>
> This e-mail message (and any attachment) is intended for the use of
> the individual or entity to whom it is addressed. This message
> contains information from EnterpriseDB Corporation that may be
> privileged, confidential, or exempt from disclosure under applicable
> law. If you are not the intended recipient or authorized to receive
> this for the intended recipient, any use, dissemination, distribution,
> retention, archiving, or copying of this communication is strictly
> prohibited. If you have received this e-mail in error, please notify
> the sender immediately by reply e-mail and delete this message.
>



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

On 1 March 2013 18:45, Abbas Butt <abb...@en...> wrote:
>
>
> On Fri, Mar 1, 2013 at 5:48 PM, Amit Khandekar
> <ami...@en...> wrote:
>>
>> On 19 February 2013 12:37, Abbas Butt <abb...@en...> wrote:
>> >
>> > Hi,
>> > Attached please find a patch that locks the cluster so that dump can be
>> > taken to be restored on the new node to be added.
>> >
>> > To lock the cluster the patch adds a new GUC parameter called
>> > xc_lock_for_backup, however its status is maintained by the pooler. The
>> > reason is that the default behavior of XC is to release connections as
>> > soon
>> > as a command is done and it uses PersistentConnections GUC to control
>> > the
>> > behavior. We in this case however need a status that is independent of
>> > the
>> > setting of PersistentConnections.
>> >
>> > Assume we have two coordinator cluster, the patch provides this
>> > behavior:
>> >
>> > Case 1: set and show
>> > ====================
>> > psql test -p 5432
>> > set xc_lock_for_backup=yes;
>> > show xc_lock_for_backup;
>> >  xc_lock_for_backup
>> > --------------------
>> >  yes
>> > (1 row)
>> >
>> > Case 2: set from one client show from other
>> > ==================================
>> > psql test -p 5432
>> > set xc_lock_for_backup=yes;
>> > (From another tab)
>> > psql test -p 5432
>> > show xc_lock_for_backup;
>> >  xc_lock_for_backup
>> > --------------------
>> >  yes
>> > (1 row)
>> >
>> > Case 3: set from one, quit it, run again and show
>> > ======================================
>> > psql test -p 5432
>> > set xc_lock_for_backup=yes;
>> > \q
>> > psql test -p 5432
>> > show xc_lock_for_backup;
>> >  xc_lock_for_backup
>> > --------------------
>> >  yes
>> > (1 row)
>> >
>> > Case 4: set on one coordinator, show from other
>> > =====================================
>> > psql test -p 5432
>> > set xc_lock_for_backup=yes;
>> > (From another tab)
>> > psql test -p 5433
>> > show xc_lock_for_backup;
>> >  xc_lock_for_backup
>> > --------------------
>> >  yes
>> > (1 row)
>> >
>> > pg_dump and pg_dumpall seem to work fine after locking the cluster for
>> > backup but I would test these utilities in detail next.
>> >
>> > Also I have yet to look in detail that standard_ProcessUtility is the
>> > only
>> > place that updates the portion of catalog that is dumped. There may be
>> > some
>> > other places too that need to be blocked for catalog updates.
>> >
>> > The patch adds no extra warnings and regression shows no extra failure.
>> >
>> > Comments are welcome.
>>
>> Abbas wrote on another thread:
>>
>> >   Amit wrote on another thread:
>> >> I haven't given a thought on the earlier patch you sent for cluster
>> >> lock
>> >> implementation; may be we can discuss this on that thread, but just a
>> >> quick
>> >> question:
>> >>
>> >> Does the cluster-lock command wait for the ongoing DDL commands to
>> >> finish
>> >> ? If not, we have problems. The subsequent pg_dump would not contain
>> >> objects
>> >> created by these particular DDLs.
>> >
>> >
>> > Suppose you have a two coordinator cluster. Assume one client connected
>> > to
>> > each. Suppose one client issues a lock cluster command and the other
>> > issues
>> > a DDL. Is this what you mean by an ongoing DDL? If true then answer to
>> > your
>> > question is Yes.
>> >
>> > Suppose you have a prepared transaction that has a DDL in it, again if
>> > this
>> > can be considered an on going DDL, then again answer to your question is
>> > Yes.
>> >
>> > Suppose you have a two coordinator cluster. Assume one client connected
>> > to
>> > each. One client starts a transaction and issues a DDL, the second
>> > client
>> > issues a lock cluster command, the first commits the transaction. If
>> > this is
>> > an ongoing DDL, then the answer to your question is No.
>>
>> Yes this last scenario is what I meant: A DDL has been executed on nodes,
>> but
>>  not committed, when the cluster lock command is run and then pg_dump
>> immediately
>> starts its transaction before the DDL is committed. Here pg_dump does
>> not see the new objects that would be created.

Come to think of it, there would always be a small interval where the
concurrency issue would remain. If we were to totally get rid of this
concurrency issue, we need to have some kind of lock. For e.g. the
object access hook function will have shared acces lock on this object
(may be on pg_depend because it is always used for objcet
creation/drop ??) and the lock-cluster command will try to get
exclusive lock on the same. This of course should be done after we are
sure object access hook is called on all types of objects.


>>
>> I myself am not sure how would we prevent this from happening. There
>> are two callback hooks that might be worth considering though:
>> 1. Transaction End callback (CallXactCallbacks)
>> 2. Object creation/drop hook (InvokeObjectAccessHook)
>>
>> Suppose we create an object creation/drop hook function that would :
>> 1. store the current transaction id in a global objects_created list
>> if the cluster is not locked,
>> 2. or else if the cluster is locked, this hook would ereport() saying
>> "cannot create catalog objects in this mode".
>>
>> And then during transaction commit , a new transaction callback hook will:
>> 1. Check the above objects_created list to see if the current
>> transaction has any objects created/dropped.
>> 2. If found and if the cluster-lock is on, it will again ereport()
>> saying "cannot create catalog objects in this mode"
>>
>> Thinking more on the object creation hook, we can even consider this
>> as a substitute for checking the cluster-lock status in
>> standardProcessUtility(). But I am not sure whether this hook does get
>> called on each of the catalog objects. At least the code comments say
>> it does.
>
>
> These are very good ideas, Thanks, I will work on those lines and will
> report back.
>
>>
>>
>>
>>
>> > But its a matter of
>> > deciding which camp are we going to put COMMIT in, the allow camp, or
>> > the
>> > deny camp. I decided to put it in allow camp, because I have not yet
>> > written
>> > any code to detect whether a transaction being committed has a DDL in it
>> > or
>> > not, and stopping all transactions from committing looks too restrictive
>> > to
>> > me.
>>
>>
>> >
>> > Do you have some other meaning of an ongoing DDL?
>>
>>
>>
>> >
>> > --
>> > Abbas
>> > Architect
>> > EnterpriseDB Corporation
>> > The Enterprise PostgreSQL Company
>> >
>> > Phone: 92-334-5100153
>> >
>> > Website: www.enterprisedb.com
>> > EnterpriseDB Blog: http://blogs.enterprisedb.com/
>> > Follow us on Twitter: http://www.twitter.com/enterprisedb
>> >
>> > This e-mail message (and any attachment) is intended for the use of
>> > the individual or entity to whom it is addressed. This message
>> > contains information from EnterpriseDB Corporation that may be
>> > privileged, confidential, or exempt from disclosure under applicable
>> > law. If you are not the intended recipient or authorized to receive
>> > this for the intended recipient, any use, dissemination, distribution,
>> > retention, archiving, or copying of this communication is strictly
>> > prohibited. If you have received this e-mail in error, please notify
>> > the sender immediately by reply e-mail and delete this message.
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > 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_feb
>> > _______________________________________________
>> > Postgres-xc-developers mailing list
>> > Pos...@li...
>> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>> >
>
>
>
>
> --
> --
> Abbas
> Architect
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company
>
> Phone: 92-334-5100153
>
> Website: www.enterprisedb.com
> EnterpriseDB Blog: http://blogs.enterprisedb.com/
> Follow us on Twitter: http://www.twitter.com/enterprisedb
>
> This e-mail message (and any attachment) is intended for the use of
> the individual or entity to whom it is addressed. This message
> contains information from EnterpriseDB Corporation that may be
> privileged, confidential, or exempt from disclosure under applicable
> law. If you are not the intended recipient or authorized to receive
> this for the intended recipient, any use, dissemination, distribution,
> retention, archiving, or copying of this communication is strictly
> prohibited. If you have received this e-mail in error, please notify
> the sender immediately by reply e-mail and delete this message.

Thank you Benny;

Ashutosh, could you commit it when we're sure that the patch is okay to developers.

Regards;
---
Koichi

On Mon, 4 Mar 2013 15:50:36 +0800
Xiong Wang <wan...@gm...> wrote:

> Hi Ashutosh ,
> 
> Sorry, I made a mistake that I revised the wrong file which is relative
> with \d+ reference.  The attached patch made it right.
> 
> Thanks & Regards,
> 
> Benny Wang
> 
> 2013/3/1 Ashutosh Bapat <ash...@en...>
> 
> > Hi Benny,
> > Sorry for coming back again on this one. I have two requests
> >
> > 1. We are using two different queries to get distribution information, can
> > we do this in a single query? I am extremely sorry for not spotting this
> > earlier. Also, can we compress following code
> >  73 +           if (tuples > 0)
> >  74 +           {
> >  75 +               const char *dist_by = _("Distribute By");
> >  76 +               const char *loc_nodes = _("Location Nodes");
> >  77 +
> >  78 +               /* Only one tuple should be returned */
> >  79 +               if (tuples > 1)
> >  80 +                   goto error_return;
> >
> > to read
> > if (tuples == 1)
> > {
> > }
> > else
> >  goto error_return;
> >
> > 2. Can you please provide the documentation changes as well, in the same
> > patch? You will need to change the sgml file under doc-xc folder
> > corresponding to app-psql.html. You will find somewhere on Postgres-XC
> > wiki, how to compile the documentation. Suzuki-san, can you please help
> > here?
> >
> >
> > On Thu, Feb 28, 2013 at 2:11 PM, Ashutosh Bapat <
> > ash...@en...> wrote:
> >
> >> I have reviewed the code and it looks fine. The regression is not showing
> >> any extra diffs.
> >>
> >> I will commit this patch tomorrow morning (IST time), if I do not see any
> >> objections.
> >>
> >>
> >> On Thu, Feb 28, 2013 at 12:32 PM, Xiong Wang <wan...@gm...>wrote:
> >>
> >>> Hi,
> >>>
> >>> 2013/2/28 Ashutosh Bapat <ash...@en...>
> >>>
> >>>> Hi Benny,
> >>>>
> >>>> It seems you commented out some tests in serial schedule in this patch.
> >>>> Can you please uncomment those?
> >>>>
> >>>> Yes.  I forgot to clean the comments.  Thanks.
> >>>
> >>>
> >>
> >>
> >>
> >>> Regards
> >>>
> >>> BennyWang
> >>>
> >>>>
> >>>> On Thu, Feb 28, 2013 at 11:56 AM, Xiong Wang <wan...@gm...>wrote:
> >>>>
> >>>>> Hi Ashutosh,
> >>>>>
> >>>>> I revised the patch according to your advice. I deleted one duplicated
> >>>>> colon when print "Location Nodes" by your revised patch.
> >>>>>
> >>>>> Thanks & Regards,
> >>>>> Benny Wang
> >>>>>
> >>>>>
> >>>>> 2013/2/28 Ashutosh Bapat <ash...@en...>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Feb 28, 2013 at 7:56 AM, Xiong Wang <wan...@gm...>wrote:
> >>>>>>
> >>>>>>> Hi Ashutosh,
> >>>>>>>
> >>>>>>> Thanks for your review at first.
> >>>>>>>
> >>>>>>> I compared inherit.out and inherit_1.out under directory
> >>>>>>> regress/expected. There's a lot of differences between these two files.
> >>>>>>> Expected inherit.out keeps the original PG
> >>>>>>> results. Do you think it's necessary to revise the inherit.out
> >>>>>>> impacted by this patch?
> >>>>>>>
> >>>>>>>
> >>>>>> Yes. As a default we change all the .out files when there is
> >>>>>> corresponding change in functionality for XC. E.g. now onwards, \d+ output
> >>>>>> on XC will always have distribution information, so there is no point in
> >>>>>> keeping the PG output. It's only when the outputs differ because of lack of
> >>>>>> functionality (restricted features) in XC or because of bugs in XC, we keep
> >>>>>> the PG output for references and create an alternate expected output file.
> >>>>>>
> >>>>>>
> >>>>>>> Thanks & Regards,
> >>>>>>>
> >>>>>>> Benny Wang
> >>>>>>>
> >>>>>>>
> >>>>>>> 2013/2/27 Ashutosh Bapat <ash...@en...>
> >>>>>>>
> >>>>>>>> Hi Benny,
> >>>>>>>> I took a good look at this patch now. Attached please find a
> >>>>>>>> revised patch, with some minor modifications done. Rest of the comments are
> >>>>>>>> below
> >>>>>>>>
> >>>>>>>> 1. As a general guideline for adding #ifdef SOMETHING, it's good to
> >>>>>>>> end it with not just #endif but #endif /* SOMETHING */, so that it's easier
> >>>>>>>> to find the mutually corresponding pairs of #ifdef and #endif. Right now I
> >>>>>>>> have added it myself in the attached patch.
> >>>>>>>>
> >>>>>>>> 2. It's better to print the the distribution information at the end
> >>>>>>>> of everything else, so that it's easy to spot in case, someone needs to
> >>>>>>>> differentiate between PG and PGXC output of \d+. This has been taken care
> >>>>>>>> in the revised patch.
> >>>>>>>>
> >>>>>>>> 3. Distribution type and nodes better be on the same line as their
> >>>>>>>> heading e.g. Distributed by: REPLICATION. The patch contains the change.
> >>>>>>>>
> >>>>>>>> 4. As suggested by Nikhil in one of the mails, the ouptut of
> >>>>>>>> location nodes needs to be changed from format {node1,node2,..} to node1,
> >>>>>>>> node2, node3, ... (notice the space after "," and removal of braces.). Done
> >>>>>>>> in my patch.
> >>>>>>>>
> >>>>>>>> Please provide me a patch, with the regression outputs adjusted
> >>>>>>>> accordingly. You will need to change inherit.out along-with inherit_1.out.
> >>>>>>>>
> >>>>>>>> In attached files, print_distribution_info.patch.2 is patch with
> >>>>>>>> the changes described above applied on your patch.
> >>>>>>>> print_distribution_info.patch.diff is the patch containing only the changes
> >>>>>>>> described above. Please review these changes and provide me an updated
> >>>>>>>> patch.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Fri, Feb 22, 2013 at 9:21 AM, Xiong Wang <wan...@gm...
> >>>>>>>> > wrote:
> >>>>>>>>
> >>>>>>>>> Hi all,
> >>>>>>>>>
> >>>>>>>>> I finished the patch. If you have any comments, give me a reply.
> >>>>>>>>>
> >>>>>>>>> Thanks & Regards,
> >>>>>>>>>
> >>>>>>>>> Benny Wang
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 2013/2/21 Koichi Suzuki <koi...@gm...>
> >>>>>>>>>
> >>>>>>>>>> Okay.   I hope this satisfies everybody.
> >>>>>>>>>> ----------
> >>>>>>>>>> Koichi Suzuki
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 2013/2/20 Ashutosh Bapat <ash...@en...>:
> >>>>>>>>>> >
> >>>>>>>>>> >
> >>>>>>>>>> > On Wed, Feb 20, 2013 at 10:49 AM, Xiong Wang <
> >>>>>>>>>> wan...@gm...> wrote:
> >>>>>>>>>> >>
> >>>>>>>>>> >> Hi Ashutosh,
> >>>>>>>>>> >>
> >>>>>>>>>> >> 2013/2/6 Ashutosh Bapat <ash...@en...>
> >>>>>>>>>> >>>
> >>>>>>>>>> >>> Hi Xiong,
> >>>>>>>>>> >>>
> >>>>>>>>>> >>> On Tue, Feb 5, 2013 at 8:06 PM, Xiong Wang <
> >>>>>>>>>> wan...@gm...>
> >>>>>>>>>> >>> wrote:
> >>>>>>>>>> >>>>
> >>>>>>>>>> >>>> Hi Ashutosh,
> >>>>>>>>>> >>>> 2013/2/5 Ashutosh Bapat <ash...@en...>
> >>>>>>>>>> >>>>>
> >>>>>>>>>> >>>>> Hi Xiong,
> >>>>>>>>>> >>>>> Thanks for the patch. It's very much awaited feature.
> >>>>>>>>>> >>>>>
> >>>>>>>>>> >>>>> Here are some comments on your patch.
> >>>>>>>>>> >>>>>
> >>>>>>>>>> >>>>> The patch applies well, but has some unwanted white spaces
> >>>>>>>>>> >>>>> [ashutosh@ubuntu coderoot]git apply
> >>>>>>>>>> >>>>> /mnt/hgfs/tmp/print_distribution_info.patch
> >>>>>>>>>> >>>>> /mnt/hgfs/tmp/print_distribution_info.patch:28: space
> >>>>>>>>>> before tab in
> >>>>>>>>>> >>>>> indent.
> >>>>>>>>>> >>>>>                      "SELECT CASE pclocatortype \n"
> >>>>>>>>>> >>>>> /mnt/hgfs/tmp/print_distribution_info.patch:35: trailing
> >>>>>>>>>> whitespace.
> >>>>>>>>>> >>>>>                     "WHEN '%c' THEN 'MODULO' END || ' ('||
> >>>>>>>>>> a.attname
> >>>>>>>>>> >>>>> ||')' as distype\n"
> >>>>>>>>>> >>>>> /mnt/hgfs/tmp/print_distribution_info.patch:59: trailing
> >>>>>>>>>> whitespace.
> >>>>>>>>>> >>>>>
> >>>>>>>>>> >>>>> warning: 3 lines add whitespace errors.
> >>>>>>>>>> >>>>> Please take care of those.
> >>>>>>>>>> >>>>
> >>>>>>>>>> >>>>
> >>>>>>>>>> >>>> Thanks for your patient review. I will fix these problems.
> >>>>>>>>>> >>>>
> >>>>>>>>>> >>>>>
> >>>>>>>>>> >>>>>
> >>>>>>>>>> >>>>> I see that there are comments like /* NOTICE: The number of
> >>>>>>>>>> beginning
> >>>>>>>>>> >>>>> whitespace is the same as index print */ followed by
> >>>>>>>>>> printing of a message
> >>>>>>>>>> >>>>> with some spaces hard-coded in it. I do not see this style
> >>>>>>>>>> being used
> >>>>>>>>>> >>>>> anywhere in the file and it looks problematic. If it
> >>>>>>>>>> happens that this new
> >>>>>>>>>> >>>>> information is indented, the hard-coded spaces will not
> >>>>>>>>>> align properly. Can
> >>>>>>>>>> >>>>> you please check what's the proper way of aligning the
> >>>>>>>>>> lines and use that
> >>>>>>>>>> >>>>> method?
> >>>>>>>>>> >>>>
> >>>>>>>>>> >>>> I add this notice deliberately because the length of white
> >>>>>>>>>> spaces before
> >>>>>>>>>> >>>> printing index information is 4. There is no warn similar
> >>>>>>>>>> with my comment in
> >>>>>>>>>> >>>> describe.c. So, I will delete this comment within later
> >>>>>>>>>> patch. Thanks again.
> >>>>>>>>>> >>>>
> >>>>>>>>>> >>>
> >>>>>>>>>> >>>
> >>>>>>>>>> >>> Don't just delete the comment, we need to get rid of
> >>>>>>>>>> hardcoded white
> >>>>>>>>>> >>> spaces. Do you see any other instance in the file which uses
> >>>>>>>>>> white spaces?
> >>>>>>>>>> >>
> >>>>>>>>>> >>
> >>>>>>>>>> >> Yes.  There are several other places use hardcoded white
> >>>>>>>>>> spaces such as
> >>>>>>>>>> >> printing constraints including check, fk and printing trigger
> >>>>>>>>>> informations.
> >>>>>>>>>> >> In order to follow postgresql style, I will just delete my
> >>>>>>>>>> comments.
> >>>>>>>>>> >>>
> >>>>>>>>>> >>>
> >>>>>>>>>> >>>>>
> >>>>>>>>>> >>>>> Instead of following query,
> >>>>>>>>>> >>>>> 1742                         "SELECT node_name FROM
> >>>>>>>>>> >>>>> pg_catalog.pgxc_node \n"
> >>>>>>>>>> >>>>> 1743                         "WHERE oid::text in \n"
> >>>>>>>>>> >>>>> 1744                         "(SELECT
> >>>>>>>>>> >>>>> pg_catalog.regexp_split_to_table(nodeoids::text, E'\\\\s+')
> >>>>>>>>>> FROM
> >>>>>>>>>> >>>>> pg_catalog.pgxc_class WHERE pcrelid =      '%s');"
> >>>>>>>>>> >>>>>
> >>>>>>>>>> >>>>> I would use (with proper indentation)
> >>>>>>>>>> >>>>> SELECT ARRAY(SELECT node_name FROM pg_catalog.pgxc_node
> >>>>>>>>>> WHERE oid IN
> >>>>>>>>>> >>>>> (SELECT unnest(nodeoids) FROM pgxc_class WHERE pcrelid =
> >>>>>>>>>> %s));
> >>>>>>>>>> >>>>> This query will give you only one row containing all the
> >>>>>>>>>> nodes. Using
> >>>>>>>>>> >>>>> unnest to convert an array to table and then using IN
> >>>>>>>>>> operator is better
> >>>>>>>>>> >>>>> than converting array to string and using split on string,
> >>>>>>>>>> and then
> >>>>>>>>>> >>>>> combining the result back. That way, we don't rely on the
> >>>>>>>>>> syntax of array to
> >>>>>>>>>> >>>>> string conversion or any particular regular expression.
> >>>>>>>>>> >>>>
> >>>>>>>>>> >>>> Great. I didn't find the unnest function. I will change my
> >>>>>>>>>> query later.
> >>>>>>>>>> >>>>
> >>>>>>>>>> >>>>>
> >>>>>>>>>> >>>>> Please provide the fix for the failing regressions as well.
> >>>>>>>>>> You will
> >>>>>>>>>> >>>>> need to change the expected output.
> >>>>>>>>>> >>>>
> >>>>>>>>>> >>>> As for regression failure, I wanted to submit the fixing
> >>>>>>>>>> patch but my
> >>>>>>>>>> >>>> test environment is different from yours. I doubt that my
> >>>>>>>>>> patch for fixing
> >>>>>>>>>> >>>> the failure may be not useful.
> >>>>>>>>>> >>>>
> >>>>>>>>>> >>>
> >>>>>>>>>> >>>
> >>>>>>>>>> >>> Send the expected output changes anyway, we will have to find
> >>>>>>>>>> out a way
> >>>>>>>>>> >>> to fix the regression.
> >>>>>>>>>> >>
> >>>>>>>>>> >> Ok.
> >>>>>>>>>> >>
> >>>>>>>>>> >
> >>>>>>>>>> > Now you have a way to fix the regression as well. Use ALL
> >>>>>>>>>> DATANODES if the
> >>>>>>>>>> > list of nodes contains all the datanodes. We have just seen one
> >>>>>>>>>> objection.
> >>>>>>>>>> > Printing ALL DATANODES looks to have uses other than silencing
> >>>>>>>>>> regressions.
> >>>>>>>>>> > So, it's worth putting it.
> >>>>>>>>>> >
> >>>>>>>>>> >>
> >>>>>>>>>> >> Thanks & Regards
> >>>>>>>>>> >> Benny Wang
> >>>>>>>>>> >>>>
> >>>>>>>>>> >>>>
> >>>>>>>>>> >>>>>
> >>>>>>>>>> >>>>> Rest of the patch looks good.
> >>>>>>>>>> >>>>>
> >>>>>>>>>> >>>>> On Tue, Feb 5, 2013 at 11:41 AM, Xiong Wang <
> >>>>>>>>>> wan...@gm...>
> >>>>>>>>>> >>>>> wrote:
> >>>>>>>>>> >>>>>>
> >>>>>>>>>> >>>>>> Hi all,
> >>>>>>>>>> >>>>>>
> >>>>>>>>>> >>>>>> The enclosure is the patch for showing distribution
> >>>>>>>>>> information.
> >>>>>>>>>> >>>>>>
> >>>>>>>>>> >>>>>> Two sql files, inherit.sql and create_table_like.sql in
> >>>>>>>>>> the regression
> >>>>>>>>>> >>>>>> test will fail.
> >>>>>>>>>> >>>>>>
> >>>>>>>>>> >>>>>> Thanks & Regards,
> >>>>>>>>>> >>>>>>
> >>>>>>>>>> >>>>>> Benny Wang
> >>>>>>>>>> >>>>>>
> >>>>>>>>>> >>>>>>
> >>>>>>>>>> >>>>>>
> >>>>>>>>>> >>>>>>
> >>>>>>>>>> >>>>>> 2013/2/1 Koichi Suzuki <koi...@gm...>
> >>>>>>>>>> >>>>>>>
> >>>>>>>>>> >>>>>>> Yes, it's nice to have.
> >>>>>>>>>> >>>>>>>
> >>>>>>>>>> >>>>>>> I understand there were many discuttions to have it,
> >>>>>>>>>> separate command
> >>>>>>>>>> >>>>>>> or \d and \d+.   \d, \d+ extension will not be affected
> >>>>>>>>>> by command
> >>>>>>>>>> >>>>>>> name conflict.   I hope we can handle further change both
> >>>>>>>>>> in XC and
> >>>>>>>>>> >>>>>>> PG.    I don't see very big difference in comparison of
> >>>>>>>>>> >>>>>>> separate/existing command.   Their pros and cons seems to
> >>>>>>>>>> be
> >>>>>>>>>> >>>>>>> comparable.   So I think we can decide what is more
> >>>>>>>>>> convenient to
> >>>>>>>>>> >>>>>>> use.
> >>>>>>>>>> >>>>>>>   So far, I understand more people prefer \d.   It's
> >>>>>>>>>> quite okay with
> >>>>>>>>>> >>>>>>> me.
> >>>>>>>>>> >>>>>>>
> >>>>>>>>>> >>>>>>> In addition, we may want to see each node information
> >>>>>>>>>> (resource,
> >>>>>>>>>> >>>>>>> primary, preferred) and configuration of each nodegroup.
> >>>>>>>>>>  Because
> >>>>>>>>>> >>>>>>> this
> >>>>>>>>>> >>>>>>> is quite new to XC, I think it's better to have
> >>>>>>>>>> xc-specific command
> >>>>>>>>>> >>>>>>> such as \xc something.
> >>>>>>>>>> >>>>>>>
> >>>>>>>>>> >>>>>>> Regards;
> >>>>>>>>>> >>>>>>> ----------
> >>>>>>>>>> >>>>>>> Koichi Suzuki
> >>>>>>>>>> >>>>>>>
> >>>>>>>>>> >>>>>>>
> >>>>>>>>>> >>>>>>> 2013/2/1 Xiong Wang <wan...@gm...>:
> >>>>>>>>>> >>>>>>> > Hi Suzuki,
> >>>>>>>>>> >>>>>>> > According to Ashutosh and ANikhil, It seems that they
> >>>>>>>>>> want to print
> >>>>>>>>>> >>>>>>> > distributed method as well as the location node list
> >>>>>>>>>> using \d+ .
> >>>>>>>>>> >>>>>>> > Are you in favor?
> >>>>>>>>>> >>>>>>> >
> >>>>>>>>>> >>>>>>> > Regards,
> >>>>>>>>>> >>>>>>> > Benny
> >>>>>>>>>> >>>>>>> >
> >>>>>>>>>> >>>>>>> >
> >>>>>>>>>> >>>>>>> > 2013/2/1 Koichi Suzuki <koi...@gm...>
> >>>>>>>>>> >>>>>>> >>
> >>>>>>>>>> >>>>>>> >> One more issue,
> >>>>>>>>>> >>>>>>> >>
> >>>>>>>>>> >>>>>>> >> Does anybody need a command to print node list from
> >>>>>>>>>> pgxc_node and
> >>>>>>>>>> >>>>>>> >> pgxc_group?
> >>>>>>>>>> >>>>>>> >> ----------
> >>>>>>>>>> >>>>>>> >> Koichi Suzuki
> >>>>>>>>>> >>>>>>> >>
> >>>>>>>>>> >>>>>>> >>
> >>>>>>>>>> >>>>>>> >> 2013/2/1 Koichi Suzuki <koi...@gm...>:
> >>>>>>>>>> >>>>>>> >> > Great!
> >>>>>>>>>> >>>>>>> >> >
> >>>>>>>>>> >>>>>>> >> > Benny, please post your patch when ready.
> >>>>>>>>>> >>>>>>> >> > ----------
> >>>>>>>>>> >>>>>>> >> > Koichi Suzuki
> >>>>>>>>>> >>>>>>> >> >
> >>>>>>>>>> >>>>>>> >> >
> >>>>>>>>>> >>>>>>> >> > 2013/2/1 Mason Sharp <ma...@st...>:
> >>>>>>>>>> >>>>>>> >> >>
> >>>>>>>>>> >>>>>>> >> >>
> >>>>>>>>>> >>>>>>> >> >> On Thu, Jan 31, 2013 at 5:38 AM, Ashutosh Bapat
> >>>>>>>>>> >>>>>>> >> >> <ash...@en...> wrote:
> >>>>>>>>>> >>>>>>> >> >>>
> >>>>>>>>>> >>>>>>> >> >>> +1. We should add this functionality as \d+.
> >>>>>>>>>> >>>>>>> >> >>
> >>>>>>>>>> >>>>>>> >> >>
> >>>>>>>>>> >>>>>>> >> >> +1
> >>>>>>>>>> >>>>>>> >> >>
> >>>>>>>>>> >>>>>>> >> >>>
> >>>>>>>>>> >>>>>>> >> >>>
> >>>>>>>>>> >>>>>>> >> >>> Xion,
> >>>>>>>>>> >>>>>>> >> >>> You will need to output the nodes where the table
> >>>>>>>>>> is
> >>>>>>>>>> >>>>>>> >> >>> distributed or
> >>>>>>>>>> >>>>>>> >> >>> replicated.
> >>>>>>>>>> >>>>>>> >> >>>
> >>>>>>>>>> >>>>>>> >> >>>
> >>>>>>>>>> >>>>>>> >> >>> On Thu, Jan 31, 2013 at 3:11 PM, Nikhil Sontakke
> >>>>>>>>>> >>>>>>> >> >>> <ni...@st...>
> >>>>>>>>>> >>>>>>> >> >>> wrote:
> >>>>>>>>>> >>>>>>> >> >>>>
> >>>>>>>>>> >>>>>>> >> >>>> Btw, I vote for showing PGXC output with \d+ and
> >>>>>>>>>> other
> >>>>>>>>>> >>>>>>> >> >>>> extended
> >>>>>>>>>> >>>>>>> >> >>>> commands
> >>>>>>>>>> >>>>>>> >> >>>> only.
> >>>>>>>>>> >>>>>>> >> >>>>
> >>>>>>>>>> >>>>>>> >> >>>> Nikhils
> >>>>>>>>>> >>>>>>> >> >>>>
> >>>>>>>>>> >>>>>>> >> >>>> On Thu, Jan 31, 2013 at 3:08 PM, Nikhil Sontakke
> >>>>>>>>>> >>>>>>> >> >>>> <ni...@st...>
> >>>>>>>>>> >>>>>>> >> >>>> wrote:
> >>>>>>>>>> >>>>>>> >> >>>> > I still do not understand how showing
> >>>>>>>>>> additional stuff in
> >>>>>>>>>> >>>>>>> >> >>>> > the PGXC
> >>>>>>>>>> >>>>>>> >> >>>> > version makes it incompatible with vanilla
> >>>>>>>>>> Postgres?
> >>>>>>>>>> >>>>>>> >> >>>> >
> >>>>>>>>>> >>>>>>> >> >>>> > As you can see, the OP made changes to the
> >>>>>>>>>> *existing* \d
> >>>>>>>>>> >>>>>>> >> >>>> > logic
> >>>>>>>>>> >>>>>>> >> >>>> > which
> >>>>>>>>>> >>>>>>> >> >>>> > is a logical way of doing things. As long as we
> >>>>>>>>>> use #ifdef
> >>>>>>>>>> >>>>>>> >> >>>> > PGXC, I
> >>>>>>>>>> >>>>>>> >> >>>> > do
> >>>>>>>>>> >>>>>>> >> >>>> > not see how printing additional info breaks
> >>>>>>>>>> anything.
> >>>>>>>>>> >>>>>>> >> >>>> > Infact it
> >>>>>>>>>> >>>>>>> >> >>>> > avoids
> >>>>>>>>>> >>>>>>> >> >>>> > users having to learn more stuff.
> >>>>>>>>>> >>>>>>> >> >>>> >
> >>>>>>>>>> >>>>>>> >> >>>> > Regards,
> >>>>>>>>>> >>>>>>> >> >>>> > Nikhils
> >>>>>>>>>> >>>>>>> >> >>>> >
> >>>>>>>>>> >>>>>>> >> >>>> > On Thu, Jan 31, 2013 at 2:59 PM, Michael Paquier
> >>>>>>>>>> >>>>>>> >> >>>> > <mic...@gm...> wrote:
> >>>>>>>>>> >>>>>>> >> >>>> >> On Thu, Jan 31, 2013 at 6:04 PM, Xiong Wang
> >>>>>>>>>> >>>>>>> >> >>>> >> <wan...@gm...>
> >>>>>>>>>> >>>>>>> >> >>>> >> wrote:
> >>>>>>>>>> >>>>>>> >> >>>> >>>
> >>>>>>>>>> >>>>>>> >> >>>> >>> I wrote a simple patch which will show
> >>>>>>>>>> distribution
> >>>>>>>>>> >>>>>>> >> >>>> >>> information
> >>>>>>>>>> >>>>>>> >> >>>> >>> when
> >>>>>>>>>> >>>>>>> >> >>>> >>> you
> >>>>>>>>>> >>>>>>> >> >>>> >>> use \d tablename command.
> >>>>>>>>>> >>>>>>> >> >>>> >>
> >>>>>>>>>> >>>>>>> >> >>>> >> I vote no for that with \d. I agree it is
> >>>>>>>>>> useful, but it
> >>>>>>>>>> >>>>>>> >> >>>> >> makes the
> >>>>>>>>>> >>>>>>> >> >>>> >> output
> >>>>>>>>>> >>>>>>> >> >>>> >> inconsistent with vanilla Postgres. And I am
> >>>>>>>>>> sure it
> >>>>>>>>>> >>>>>>> >> >>>> >> creates many
> >>>>>>>>>> >>>>>>> >> >>>> >> failures
> >>>>>>>>>> >>>>>>> >> >>>> >> in regression tests. It has been discussed
> >>>>>>>>>> before to use
> >>>>>>>>>> >>>>>>> >> >>>> >> either a
> >>>>>>>>>> >>>>>>> >> >>>> >> new
> >>>>>>>>>> >>>>>>> >> >>>> >> command with a word or a letter we'll be sure
> >>>>>>>>>> won't be in
> >>>>>>>>>> >>>>>>> >> >>>> >> conflict
> >>>>>>>>>> >>>>>>> >> >>>> >> with
> >>>>>>>>>> >>>>>>> >> >>>> >> vanilla now and at some point in the future.
> >>>>>>>>>> Something
> >>>>>>>>>> >>>>>>> >> >>>> >> like
> >>>>>>>>>> >>>>>>> >> >>>> >> "\distrib"
> >>>>>>>>>> >>>>>>> >> >>>> >> perhaps?
> >>>>>>>>>> >>>>>>> >> >>>> >> --
> >>>>>>>>>> >>>>>>> >> >>>> >> Michael Paquier
> >>>>>>>>>> >>>>>>> >> >>>> >> http://michael.otacoo.com
> >>>>>>>>>> >>>>>>> >> >>>> >>
> >>>>>>>>>> >>>>>>> >> >>>> >>
> >>>>>>>>>> >>>>>>> >> >>>> >>
> >>>>>>>>>> >>>>>>> >> >>>> >>
> >>>>>>>>>> ------------------------------------------------------------------------------
> >>>>>>>>>> >>>>>>> >> >>>> >> 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_jan
> >>>>>>>>>> >>>>>>> >> >>>> >> _______________________________________________
> >>>>>>>>>> >>>>>>> >> >>>> >> Postgres-xc-developers mailing list
> >>>>>>>>>> >>>>>>> >> >>>> >> Pos...@li...
> >>>>>>>>>> >>>>>>> >> >>>> >>
> >>>>>>>>>> >>>>>>> >> >>>> >>
> >>>>>>>>>> >>>>>>> >> >>>> >>
> >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >>>>>>>>>> >>>>>>> >> >>>> >>
> >>>>>>>>>> >>>>>>> >> >>>> >
> >>>>>>>>>> >>>>>>> >> >>>> >
> >>>>>>>>>> >>>>>>> >> >>>> >
> >>>>>>>>>> >>>>>>> >> >>>> > --
> >>>>>>>>>> >>>>>>> >> >>>> > StormDB - http://www.stormdb.com
> >>>>>>>>>> >>>>>>> >> >>>> > The Database Cloud
> >>>>>>>>>> >>>>>>> >> >>>> > Postgres-XC Support and Service
> >>>>>>>>>> >>>>>>> >> >>>>
> >>>>>>>>>> >>>>>>> >> >>>>
> >>>>>>>>>> >>>>>>> >> >>>>
> >>>>>>>>>> >>>>>>> >> >>>> --
> >>>>>>>>>> >>>>>>> >> >>>> StormDB - http://www.stormdb.com
> >>>>>>>>>> >>>>>>> >> >>>> The Database Cloud
> >>>>>>>>>> >>>>>>> >> >>>> Postgres-XC Support and Service
> >>>>>>>>>> >>>>>>> >> >>>>
> >>>>>>>>>> >>>>>>> >> >>>>
> >>>>>>>>>> >>>>>>> >> >>>>
> >>>>>>>>>> >>>>>>> >> >>>>
> >>>>>>>>>> >>>>>>> >> >>>>
> >>>>>>>>>> ------------------------------------------------------------------------------
> >>>>>>>>>> >>>>>>> >> >>>> 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_jan
> >>>>>>>>>> >>>>>>> >> >>>> _______________________________________________
> >>>>>>>>>> >>>>>>> >> >>>> Postgres-xc-developers mailing list
> >>>>>>>>>> >>>>>>> >> >>>> Pos...@li...
> >>>>>>>>>> >>>>>>> >> >>>>
> >>>>>>>>>> >>>>>>> >> >>>>
> >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >>>>>>>>>> >>>>>>> >> >>>
> >>>>>>>>>> >>>>>>> >> >>>
> >>>>>>>>>> >>>>>>> >> >>>
> >>>>>>>>>> >>>>>>> >> >>>
> >>>>>>>>>> >>>>>>> >> >>> --
> >>>>>>>>>> >>>>>>> >> >>> Best Wishes,
> >>>>>>>>>> >>>>>>> >> >>> Ashutosh Bapat
> >>>>>>>>>> >>>>>>> >> >>> EntepriseDB Corporation
> >>>>>>>>>> >>>>>>> >> >>> The Enterprise Postgres Company
> >>>>>>>>>> >>>>>>> >> >>>
> >>>>>>>>>> >>>>>>> >> >>>
> >>>>>>>>>> >>>>>>> >> >>>
> >>>>>>>>>> >>>>>>> >> >>>
> >>>>>>>>>> >>>>>>> >> >>>
> >>>>>>>>>> ------------------------------------------------------------------------------
> >>>>>>>>>> >>>>>>> >> >>> 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_jan
> >>>>>>>>>> >>>>>>> >> >>> _______________________________________________
> >>>>>>>>>> >>>>>>> >> >>> Postgres-xc-developers mailing list
> >>>>>>>>>> >>>>>>> >> >>> Pos...@li...
> >>>>>>>>>> >>>>>>> >> >>>
> >>>>>>>>>> >>>>>>> >> >>>
> >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >>>>>>>>>> >>>>>>> >> >>>
> >>>>>>>>>> >>>>>>> >> >>
> >>>>>>>>>> >>>>>>> >> >>
> >>>>>>>>>> >>>>>>> >> >>
> >>>>>>>>>> >>>>>>> >> >> --
> >>>>>>>>>> >>>>>>> >> >> Mason Sharp
> >>>>>>>>>> >>>>>>> >> >>
> >>>>>>>>>> >>>>>>> >> >>
> >>>>>>>>>> >>>>>>> >> >> StormDB - http://www.stormdb.com
> >>>>>>>>>> >>>>>>> >> >> The Database Cloud
> >>>>>>>>>> >>>>>>> >> >> Postgres-XC Support and Services
> >>>>>>>>>> >>>>>>> >> >>
> >>>>>>>>>> >>>>>>> >> >>
> >>>>>>>>>> >>>>>>> >> >>
> >>>>>>>>>> ------------------------------------------------------------------------------
> >>>>>>>>>> >>>>>>> >> >> 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_jan
> >>>>>>>>>> >>>>>>> >> >> _______________________________________________
> >>>>>>>>>> >>>>>>> >> >> Postgres-xc-developers mailing list
> >>>>>>>>>> >>>>>>> >> >> Pos...@li...
> >>>>>>>>>> >>>>>>> >> >>
> >>>>>>>>>> >>>>>>> >> >>
> >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >>>>>>>>>> >>>>>>> >> >>
> >>>>>>>>>> >>>>>>> >>
> >>>>>>>>>> >>>>>>> >>
> >>>>>>>>>> >>>>>>> >>
> >>>>>>>>>> >>>>>>> >>
> >>>>>>>>>> ------------------------------------------------------------------------------
> >>>>>>>>>> >>>>>>> >> 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_jan
> >>>>>>>>>> >>>>>>> >> _______________________________________________
> >>>>>>>>>> >>>>>>> >> Postgres-xc-developers mailing list
> >>>>>>>>>> >>>>>>> >> Pos...@li...
> >>>>>>>>>> >>>>>>> >>
> >>>>>>>>>> >>>>>>> >>
> >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >>>>>>>>>> >>>>>>> >
> >>>>>>>>>> >>>>>>> >
> >>>>>>>>>> >>>>>>
> >>>>>>>>>> >>>>>>
> >>>>>>>>>> >>>>>>
> >>>>>>>>>> >>>>>>
> >>>>>>>>>> >>>>>>
> >>>>>>>>>> ------------------------------------------------------------------------------
> >>>>>>>>>> >>>>>> Free Next-Gen Firewall Hardware Offer
> >>>>>>>>>> >>>>>> Buy your Sophos next-gen firewall before the end March 2013
> >>>>>>>>>> >>>>>> and get the hardware for free! Learn more.
> >>>>>>>>>> >>>>>> http://p.sf.net/sfu/sophos-d2d-feb
> >>>>>>>>>> >>>>>> _______________________________________________
> >>>>>>>>>> >>>>>> Postgres-xc-developers mailing list
> >>>>>>>>>> >>>>>> Pos...@li...
> >>>>>>>>>> >>>>>>
> >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >>>>>>>>>> >>>>>>
> >>>>>>>>>> >>>>>
> >>>>>>>>>> >>>>>
> >>>>>>>>>> >>>>>
> >>>>>>>>>> >>>>> --
> >>>>>>>>>> >>>>> Best Wishes,
> >>>>>>>>>> >>>>> Ashutosh Bapat
> >>>>>>>>>> >>>>> EntepriseDB Corporation
> >>>>>>>>>> >>>>> The Enterprise Postgres Company
> >>>>>>>>>> >>>>
> >>>>>>>>>> >>>>
> >>>>>>>>>> >>>
> >>>>>>>>>> >>>
> >>>>>>>>>> >>>
> >>>>>>>>>> >>> --
> >>>>>>>>>> >>> Best Wishes,
> >>>>>>>>>> >>> Ashutosh Bapat
> >>>>>>>>>> >>> EntepriseDB Corporation
> >>>>>>>>>> >>> The Enterprise Postgres Company
> >>>>>>>>>> >>
> >>>>>>>>>> >>
> >>>>>>>>>> >
> >>>>>>>>>> >
> >>>>>>>>>> >
> >>>>>>>>>> > --
> >>>>>>>>>> > Best Wishes,
> >>>>>>>>>> > Ashutosh Bapat
> >>>>>>>>>> > EntepriseDB Corporation
> >>>>>>>>>> > The Enterprise Postgres Company
> >>>>>>>>>> >
> >>>>>>>>>> >
> >>>>>>>>>> ------------------------------------------------------------------------------
> >>>>>>>>>> > 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_feb
> >>>>>>>>>> > _______________________________________________
> >>>>>>>>>> > Postgres-xc-developers mailing list
> >>>>>>>>>> > Pos...@li...
> >>>>>>>>>> >
> >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >>>>>>>>>> >
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ------------------------------------------------------------------------------
> >>>>>>>>> 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_feb
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Postgres-xc-developers mailing list
> >>>>>>>>> Pos...@li...
> >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Best Wishes,
> >>>>>>>> Ashutosh Bapat
> >>>>>>>> EntepriseDB Corporation
> >>>>>>>> The Enterprise Postgres Company
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Best Wishes,
> >>>>>> Ashutosh Bapat
> >>>>>> EntepriseDB Corporation
> >>>>>> The Enterprise Postgres Company
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best Wishes,
> >>>> Ashutosh Bapat
> >>>> EntepriseDB Corporation
> >>>> The Enterprise Postgres Company
> >>>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Best Wishes,
> >> Ashutosh Bapat
> >> EntepriseDB Corporation
> >> The Enterprise Postgres Company
> >>
> >
> >
> >
> > --
> > Best Wishes,
> > Ashutosh Bapat
> > EntepriseDB Corporation
> > The Enterprise Postgres Company
> >

What I had in mind was to have pg_dump, when run with include-node, emit
CREATE NODE/ CREATE NODE GROUP commands only and nothing else. Those
commands will be used to create existing nodes/groups on the new
coordinator to be added. So it does make sense to use this option
independently, in fact it is supposed to be used independently.


On Mon, Mar 4, 2013 at 11:21 AM, Ashutosh Bapat <
ash...@en...> wrote:

> Dumping TO NODE clause only makes sense if we dump CREATE NODE/ CREATE
> NODE GROUP. Dumping CREATE NODE/CREATE NODE GROUP may make sense
> independently, but might be useless without dumping TO NODE clause.
>
> BTW, OTOH, dumping CREATE NODE/CREATE NODE GROUP clause wouldn't create
> the nodes on all the coordinators,


All the coordinators already have the nodes information.


> but only the coordinator where dump will be restored. That's another thing
> you will need to consider OR are you going to fix that as well?


As a first step I am only listing the manual steps required to add a new
node, that might say run this command on all the existing coordinators by
connecting to them one by one manually. We can decide to automate these
steps later.



>
>
> On Mon, Mar 4, 2013 at 11:41 AM, Abbas Butt <abb...@en...>wrote:
>
>> I was thinking of using include-nodes to dump CREATE NODE / CREATE NODE
>> GROUP, that is required as one of the missing links in adding a new node.
>> How do you think about that?
>>
>>
>> On Mon, Mar 4, 2013 at 9:02 AM, Ashutosh Bapat <
>> ash...@en...> wrote:
>>
>>> Hi Abbas,
>>> Please take a look at
>>> http://www.postgresql.org/docs/9.2/static/app-pgdump.html, which gives
>>> all the command line options for pg_dump. instead of
>>> include-to-node-clause, just include-nodes would suffice, I guess.
>>>
>>>
>>> On Fri, Mar 1, 2013 at 8:36 PM, Abbas Butt <abb...@en...>wrote:
>>>
>>>> PFA a updated patch that provides a command line argument called
>>>> --include-to-node-clause to let pg_dump know that the created dump is
>>>> supposed to emit TO NODE clause in the CREATE TABLE command.
>>>> If the argument is provided while taking the dump from a datanode, it
>>>> does not show TO NODE clause in the dump since the catalog table is empty
>>>> in this case.
>>>> The documentation of pg_dump is updated accordingly.
>>>> The rest of the functionality stays the same as before.
>>>>
>>>>
>>>> On Mon, Feb 25, 2013 at 10:29 AM, Ashutosh Bapat <
>>>> ash...@en...> wrote:
>>>>
>>>>> I think we should always dump DISTRIBUTE BY.
>>>>>
>>>>> PG does not stop dumping (or provide an option to do so) newer syntax
>>>>> so that the dump will work on older versions. On similar lines, an XC dump
>>>>> can not be used against PG without modification (removing DISTRIBUTE BY).
>>>>> There can be more serious problems like exceeding table size limits if an
>>>>> XC dump is tried to be restored in PG.
>>>>>
>>>>> As to TO NODE clause, I agree, that one can restore the dump on a
>>>>> cluster with different configuration, so giving an option to dump TO NODE
>>>>> clause will help.
>>>>>
>>>>> On Mon, Feb 25, 2013 at 6:42 AM, Michael Paquier <
>>>>> mic...@gm...> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Feb 25, 2013 at 4:17 AM, Abbas Butt <
>>>>>> abb...@en...> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Feb 24, 2013 at 5:33 PM, Michael Paquier <
>>>>>>> mic...@gm...> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Feb 24, 2013 at 7:04 PM, Abbas Butt <
>>>>>>>> abb...@en...> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Feb 24, 2013 at 1:44 PM, Michael Paquier <
>>>>>>>>> mic...@gm...> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 24, 2013 at 3:51 PM, Abbas Butt <
>>>>>>>>>> abb...@en...> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>> PFA a patch to  fix pg_dump to generate TO NODE clause in the
>>>>>>>>>>> dump.
>>>>>>>>>>> This is required because otherwise all tables get created on all
>>>>>>>>>>> nodes after a dump-restore cycle.
>>>>>>>>>>>
>>>>>>>>>> Not sure this is good if you take a dump of an XC cluster to
>>>>>>>>>> restore that to a vanilla Postgres cluster.
>>>>>>>>>> Why not adding a new option that would control the generation of
>>>>>>>>>> this clause instead of forcing it?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think you can use the pg_dump that comes with vanilla PG to do
>>>>>>>>> that, can't you? But I am open to adding a control option if every body
>>>>>>>>> thinks so.
>>>>>>>>>
>>>>>>>> Sure you can, this is just to simplify the life of users a maximum
>>>>>>>> by not having multiple pg_dump binaries in their serves.
>>>>>>>> Saying that, I think that there is no option to choose if
>>>>>>>> DISTRIBUTE BY is printed in the dump or not...
>>>>>>>>
>>>>>>>
>>>>>>> Yah if we choose to have an option we will put both DISTRIBUTE BY
>>>>>>> and TO NODE under it.
>>>>>>>
>>>>>> Why not an option for DISTRIBUTE BY, and another for TO NODE?
>>>>>> This would bring more flexibility to the way dumps are generated.
>>>>>> --
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> 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_feb
>>>>>> _______________________________________________
>>>>>> Postgres-xc-developers mailing list
>>>>>> Pos...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best Wishes,
>>>>> Ashutosh Bapat
>>>>> EntepriseDB Corporation
>>>>> The Enterprise Postgres Company
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> Abbas
>>>> Architect
>>>> EnterpriseDB Corporation
>>>> The Enterprise PostgreSQL Company
>>>>
>>>> Phone: 92-334-5100153
>>>>
>>>> Website: www.enterprisedb.com
>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>
>>>> This e-mail message (and any attachment) is intended for the use of
>>>> the individual or entity to whom it is addressed. This message
>>>> contains information from EnterpriseDB Corporation that may be
>>>> privileged, confidential, or exempt from disclosure under applicable
>>>> law. If you are not the intended recipient or authorized to receive
>>>> this for the intended recipient, any use, dissemination, distribution,
>>>> retention, archiving, or copying of this communication is strictly
>>>> prohibited. If you have received this e-mail in error, please notify
>>>> the sender immediately by reply e-mail and delete this message.
>>>>
>>>
>>>
>>>
>>> --
>>> Best Wishes,
>>> Ashutosh Bapat
>>> EntepriseDB Corporation
>>> The Enterprise Postgres Company
>>>
>>
>>
>>
>> --
>> --
>> Abbas
>> Architect
>> EnterpriseDB Corporation
>> The Enterprise PostgreSQL Company
>>
>> Phone: 92-334-5100153
>>
>> Website: www.enterprisedb.com
>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>
>> This e-mail message (and any attachment) is intended for the use of
>> the individual or entity to whom it is addressed. This message
>> contains information from EnterpriseDB Corporation that may be
>> privileged, confidential, or exempt from disclosure under applicable
>> law. If you are not the intended recipient or authorized to receive
>> this for the intended recipient, any use, dissemination, distribution,
>> retention, archiving, or copying of this communication is strictly
>> prohibited. If you have received this e-mail in error, please notify
>> the sender immediately by reply e-mail and delete this message.
>>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company
>



-- 
--
Abbas
Architect
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: 92-334-5100153

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.

Dumping TO NODE clause only makes sense if we dump CREATE NODE/ CREATE NODE
GROUP. Dumping CREATE NODE/CREATE NODE GROUP may make sense independently,
but might be useless without dumping TO NODE clause.

BTW, OTOH, dumping CREATE NODE/CREATE NODE GROUP clause wouldn't create the
nodes on all the coordinators, but only the coordinator where dump will be
restored. That's another thing you will need to consider OR are you going
to fix that as well?

On Mon, Mar 4, 2013 at 11:41 AM, Abbas Butt <abb...@en...>wrote:

> I was thinking of using include-nodes to dump CREATE NODE / CREATE NODE
> GROUP, that is required as one of the missing links in adding a new node.
> How do you think about that?
>
>
> On Mon, Mar 4, 2013 at 9:02 AM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>> Hi Abbas,
>> Please take a look at
>> http://www.postgresql.org/docs/9.2/static/app-pgdump.html, which gives
>> all the command line options for pg_dump. instead of
>> include-to-node-clause, just include-nodes would suffice, I guess.
>>
>>
>> On Fri, Mar 1, 2013 at 8:36 PM, Abbas Butt <abb...@en...>wrote:
>>
>>> PFA a updated patch that provides a command line argument called
>>> --include-to-node-clause to let pg_dump know that the created dump is
>>> supposed to emit TO NODE clause in the CREATE TABLE command.
>>> If the argument is provided while taking the dump from a datanode, it
>>> does not show TO NODE clause in the dump since the catalog table is empty
>>> in this case.
>>> The documentation of pg_dump is updated accordingly.
>>> The rest of the functionality stays the same as before.
>>>
>>>
>>> On Mon, Feb 25, 2013 at 10:29 AM, Ashutosh Bapat <
>>> ash...@en...> wrote:
>>>
>>>> I think we should always dump DISTRIBUTE BY.
>>>>
>>>> PG does not stop dumping (or provide an option to do so) newer syntax
>>>> so that the dump will work on older versions. On similar lines, an XC dump
>>>> can not be used against PG without modification (removing DISTRIBUTE BY).
>>>> There can be more serious problems like exceeding table size limits if an
>>>> XC dump is tried to be restored in PG.
>>>>
>>>> As to TO NODE clause, I agree, that one can restore the dump on a
>>>> cluster with different configuration, so giving an option to dump TO NODE
>>>> clause will help.
>>>>
>>>> On Mon, Feb 25, 2013 at 6:42 AM, Michael Paquier <
>>>> mic...@gm...> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Feb 25, 2013 at 4:17 AM, Abbas Butt <
>>>>> abb...@en...> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Feb 24, 2013 at 5:33 PM, Michael Paquier <
>>>>>> mic...@gm...> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Feb 24, 2013 at 7:04 PM, Abbas Butt <
>>>>>>> abb...@en...> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Feb 24, 2013 at 1:44 PM, Michael Paquier <
>>>>>>>> mic...@gm...> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Feb 24, 2013 at 3:51 PM, Abbas Butt <
>>>>>>>>> abb...@en...> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>> PFA a patch to  fix pg_dump to generate TO NODE clause in the
>>>>>>>>>> dump.
>>>>>>>>>> This is required because otherwise all tables get created on all
>>>>>>>>>> nodes after a dump-restore cycle.
>>>>>>>>>>
>>>>>>>>> Not sure this is good if you take a dump of an XC cluster to
>>>>>>>>> restore that to a vanilla Postgres cluster.
>>>>>>>>> Why not adding a new option that would control the generation of
>>>>>>>>> this clause instead of forcing it?
>>>>>>>>>
>>>>>>>>
>>>>>>>> I think you can use the pg_dump that comes with vanilla PG to do
>>>>>>>> that, can't you? But I am open to adding a control option if every body
>>>>>>>> thinks so.
>>>>>>>>
>>>>>>> Sure you can, this is just to simplify the life of users a maximum
>>>>>>> by not having multiple pg_dump binaries in their serves.
>>>>>>> Saying that, I think that there is no option to choose if DISTRIBUTE
>>>>>>> BY is printed in the dump or not...
>>>>>>>
>>>>>>
>>>>>> Yah if we choose to have an option we will put both DISTRIBUTE BY and
>>>>>> TO NODE under it.
>>>>>>
>>>>> Why not an option for DISTRIBUTE BY, and another for TO NODE?
>>>>> This would bring more flexibility to the way dumps are generated.
>>>>> --
>>>>> Michael
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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_feb
>>>>> _______________________________________________
>>>>> Postgres-xc-developers mailing list
>>>>> Pos...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best Wishes,
>>>> Ashutosh Bapat
>>>> EntepriseDB Corporation
>>>> The Enterprise Postgres Company
>>>>
>>>
>>>
>>>
>>> --
>>> --
>>> Abbas
>>> Architect
>>> EnterpriseDB Corporation
>>> The Enterprise PostgreSQL Company
>>>
>>> Phone: 92-334-5100153
>>>
>>> Website: www.enterprisedb.com
>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>
>>> This e-mail message (and any attachment) is intended for the use of
>>> the individual or entity to whom it is addressed. This message
>>> contains information from EnterpriseDB Corporation that may be
>>> privileged, confidential, or exempt from disclosure under applicable
>>> law. If you are not the intended recipient or authorized to receive
>>> this for the intended recipient, any use, dissemination, distribution,
>>> retention, archiving, or copying of this communication is strictly
>>> prohibited. If you have received this e-mail in error, please notify
>>> the sender immediately by reply e-mail and delete this message.
>>>
>>
>>
>>
>> --
>> Best Wishes,
>> Ashutosh Bapat
>> EntepriseDB Corporation
>> The Enterprise Postgres Company
>>
>
>
>
> --
> --
> Abbas
> Architect
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company
>
> Phone: 92-334-5100153
>
> Website: www.enterprisedb.com
> EnterpriseDB Blog: http://blogs.enterprisedb.com/
> Follow us on Twitter: http://www.twitter.com/enterprisedb
>
> This e-mail message (and any attachment) is intended for the use of
> the individual or entity to whom it is addressed. This message
> contains information from EnterpriseDB Corporation that may be
> privileged, confidential, or exempt from disclosure under applicable
> law. If you are not the intended recipient or authorized to receive
> this for the intended recipient, any use, dissemination, distribution,
> retention, archiving, or copying of this communication is strictly
> prohibited. If you have received this e-mail in error, please notify
> the sender immediately by reply e-mail and delete this message.
>



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

I was thinking of using include-nodes to dump CREATE NODE / CREATE NODE
GROUP, that is required as one of the missing links in adding a new node.
How do you think about that?

On Mon, Mar 4, 2013 at 9:02 AM, Ashutosh Bapat <
ash...@en...> wrote:

> Hi Abbas,
> Please take a look at
> http://www.postgresql.org/docs/9.2/static/app-pgdump.html, which gives
> all the command line options for pg_dump. instead of
> include-to-node-clause, just include-nodes would suffice, I guess.
>
>
> On Fri, Mar 1, 2013 at 8:36 PM, Abbas Butt <abb...@en...>wrote:
>
>> PFA a updated patch that provides a command line argument called
>> --include-to-node-clause to let pg_dump know that the created dump is
>> supposed to emit TO NODE clause in the CREATE TABLE command.
>> If the argument is provided while taking the dump from a datanode, it
>> does not show TO NODE clause in the dump since the catalog table is empty
>> in this case.
>> The documentation of pg_dump is updated accordingly.
>> The rest of the functionality stays the same as before.
>>
>>
>> On Mon, Feb 25, 2013 at 10:29 AM, Ashutosh Bapat <
>> ash...@en...> wrote:
>>
>>> I think we should always dump DISTRIBUTE BY.
>>>
>>> PG does not stop dumping (or provide an option to do so) newer syntax so
>>> that the dump will work on older versions. On similar lines, an XC dump can
>>> not be used against PG without modification (removing DISTRIBUTE BY). There
>>> can be more serious problems like exceeding table size limits if an XC dump
>>> is tried to be restored in PG.
>>>
>>> As to TO NODE clause, I agree, that one can restore the dump on a
>>> cluster with different configuration, so giving an option to dump TO NODE
>>> clause will help.
>>>
>>> On Mon, Feb 25, 2013 at 6:42 AM, Michael Paquier <
>>> mic...@gm...> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Feb 25, 2013 at 4:17 AM, Abbas Butt <
>>>> abb...@en...> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, Feb 24, 2013 at 5:33 PM, Michael Paquier <
>>>>> mic...@gm...> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Feb 24, 2013 at 7:04 PM, Abbas Butt <
>>>>>> abb...@en...> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Feb 24, 2013 at 1:44 PM, Michael Paquier <
>>>>>>> mic...@gm...> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Feb 24, 2013 at 3:51 PM, Abbas Butt <
>>>>>>>> abb...@en...> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> PFA a patch to  fix pg_dump to generate TO NODE clause in the dump.
>>>>>>>>> This is required because otherwise all tables get created on all
>>>>>>>>> nodes after a dump-restore cycle.
>>>>>>>>>
>>>>>>>> Not sure this is good if you take a dump of an XC cluster to
>>>>>>>> restore that to a vanilla Postgres cluster.
>>>>>>>> Why not adding a new option that would control the generation of
>>>>>>>> this clause instead of forcing it?
>>>>>>>>
>>>>>>>
>>>>>>> I think you can use the pg_dump that comes with vanilla PG to do
>>>>>>> that, can't you? But I am open to adding a control option if every body
>>>>>>> thinks so.
>>>>>>>
>>>>>> Sure you can, this is just to simplify the life of users a maximum by
>>>>>> not having multiple pg_dump binaries in their serves.
>>>>>> Saying that, I think that there is no option to choose if DISTRIBUTE
>>>>>> BY is printed in the dump or not...
>>>>>>
>>>>>
>>>>> Yah if we choose to have an option we will put both DISTRIBUTE BY and
>>>>> TO NODE under it.
>>>>>
>>>> Why not an option for DISTRIBUTE BY, and another for TO NODE?
>>>> This would bring more flexibility to the way dumps are generated.
>>>> --
>>>> Michael
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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_feb
>>>> _______________________________________________
>>>> Postgres-xc-developers mailing list
>>>> Pos...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>
>>>>
>>>
>>>
>>> --
>>> Best Wishes,
>>> Ashutosh Bapat
>>> EntepriseDB Corporation
>>> The Enterprise Postgres Company
>>>
>>
>>
>>
>> --
>> --
>> Abbas
>> Architect
>> EnterpriseDB Corporation
>> The Enterprise PostgreSQL Company
>>
>> Phone: 92-334-5100153
>>
>> Website: www.enterprisedb.com
>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>
>> This e-mail message (and any attachment) is intended for the use of
>> the individual or entity to whom it is addressed. This message
>> contains information from EnterpriseDB Corporation that may be
>> privileged, confidential, or exempt from disclosure under applicable
>> law. If you are not the intended recipient or authorized to receive
>> this for the intended recipient, any use, dissemination, distribution,
>> retention, archiving, or copying of this communication is strictly
>> prohibited. If you have received this e-mail in error, please notify
>> the sender immediately by reply e-mail and delete this message.
>>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company
>



-- 
--
Abbas
Architect
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: 92-334-5100153

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.

On 1 March 2013 13:53, Nikhil Sontakke <ni...@st...> wrote:
>>
>> Issue: Whether we should fetch the whole from the datanode (OLD row) and not
>> just ctid and node_id and required columns and store it at the coordinator
>> for the processing  OR whether we should fetch each row (OLD and NEW
>> variants) while processing each row.
>>
>> Both of them have performance impacts - the first one has disk impact for
>> large number of rows whereas the second has network impact for querying
>> rows. Is it possible to do some analytical assessment as to which of them
>> would be better? If you can come up with something concrete (may be numbers
>> or formulae) we will be able to judge better as to which one to pick up.

Will check if we can come up with some sensible analysis or figures.

>>
>
> Or we can consider a hybrid approach of getting the rows in batches of
> 1000 or so if possible as well. That ways they get into coordinator
> memory in one shot and can be processed in batches. Obviously this
> should be considered if it's not going to be a complicated
> implementation.

It just occurred to me that it would not be that hard to optimize the
row-fetching-by-ctid as shown below:
1. When it is time to fire the queued triggers at the
statement/transaction end, initialize cursors - one cursor per
datanode - which would do: SELECT remote_heap_fetch(table_name,
'<ctidlist>'); We can form this ctidlist out of the trigger even list.
2. For each trigger event entry in the trigger queue, FETCH NEXT using
the appropriate cursor name according to the datanode id to which the
trigger entry belongs.

>
>>> Currently we fetch all attributes in the SELECT subplans. I have
>>> created another patch to fetch only the required attribtues, but have
>>> not merged that into this patch.
>
> Do we have other places where we unnecessary fetch all attributes?
> ISTM, this should be fixed as a performance improvement first ahead of
> everything else.

I believe DML subplan is the only remaining place where we fetch all
attributes. And yes, this is a must-have for triggers, otherwise, the
other optimizations would be of no use.

>
>>> 2.  One important TODO for BEFORE trigger is this: Just before
>>> invoking the trigger functions, in PG, the tuple is row-locked
>>> (exclusive) by GetTupleTrigger() and the locked version is fetched
>>> from the table. So it is made sure that while all the triggers for
>>> that table are executed, no one can update that particular row.
>>> In the patch, we haven't locked the row. We need to lock it either by
>>> executing :
>>>    1. SELECT * from tab1 where ctid = <ctid_val> FOR UPDATE, and then
>>> use the returned ROW as the OLD row.
>>> OR
>>>    2. The UPDATE subplan itself should have SELECT for UPDATE so that
>>> the row is already locked, and we don't have to lock it again.
>>> #2 is simple though it might cause some amount of longer waits in general.
>>> Using #1, though the locks would be acquired only when the particular
>>> row is updated, the locks would be released only after transaction
>>> end, so #1 might not be worth implementing.
>>> Also #1 requires another explicit remote fetch for the
>>> lock-and-get-latest-version operation.
>>> I am more inclined towards #2.
>>>
>> The option #2 however, has problem of locking too many rows if there are
>> coordinator quals in the subplans IOW the number of rows finally updated are
>> lesser than the number of rows fetched from the datanode. It can cause
>> unwanted deadlocks. Unless there is a way to release these extra locks, I am
>> afraid this option will be a problem.

True. Regardless of anything else - whether it is deadlocks or longer
waits, we should not lock rows that are not to be updated.

There is a more general row-locking issue that we need to solve first
: 3606317. I anticipate that solving this will solve the trigger
specific lock issue. So for triggers, this is a must-have, and I am
going to solve this issue as part of this bug 3606317.

>>
> Deadlocks? ISTM, we can get more lock waits because of this but I do
> not see deadlock scenarios..
>
> With the FQS shipping work being done by Ashutosh, will we also ship
> major chunks of subplans to the datanodes? If yes, then row locking
> will only involve required tuples (hopefully) from the coordinator's
> point of view.
>
> Also, something radical is can be invent a new type of FOR [NODE]
> UPDATE type lock to minimize the impact of such locking of rows on
> datanodes?
>
> Regards,
> Nikhils
>
>>>
>>> 3.  The BEFORE trigger function can change the distribution column
>>> itself. We need to add a check at the end of the trigger executions.
>>>
>>
>> Good, you thought about that. Yes we should check it.
>>
>>>
>>> 4. Fetching OLD row for WHEN clause handling.
>>>
>>> 5. Testing with mix of Shippable and non-shippable ROW triggers
>>>
>>> 6. Other types of triggers. INSTEAD triggers are anticipated to work
>>> without significant changes, but they are yet to be tested.
>>> INSERT/DELETE triggers: Most of the infrastructure has been done while
>>> implementing UPDATE triggers. But some changes specific to INSERT and
>>> DELETE are yet to be done.
>>> Deferred triggers to be tested.
>>>
>>> 7. Regression analysis. There are some new failures. Will post another
>>> fair version of the patch after regression analysis and fixing various
>>> TODOs.
>>>
>>> Comments welcome.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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_feb
>>> _______________________________________________
>>> Postgres-xc-developers mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>
>>
>>
>>
>> --
>> Best Wishes,
>> Ashutosh Bapat
>> EntepriseDB Corporation
>> The Enterprise Postgres Company
>>
>> ------------------------------------------------------------------------------
>> 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_feb
>> _______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>
>
>
>
> --
> StormDB - http://www.stormdb.com
> The Database Cloud
> Postgres-XC Support and Service

Hi Abbas,
Please take a look at
http://www.postgresql.org/docs/9.2/static/app-pgdump.html, which gives all
the command line options for pg_dump. instead of include-to-node-clause,
just include-nodes would suffice, I guess.

On Fri, Mar 1, 2013 at 8:36 PM, Abbas Butt <abb...@en...>wrote:

> PFA a updated patch that provides a command line argument called
> --include-to-node-clause to let pg_dump know that the created dump is
> supposed to emit TO NODE clause in the CREATE TABLE command.
> If the argument is provided while taking the dump from a datanode, it does
> not show TO NODE clause in the dump since the catalog table is empty in
> this case.
> The documentation of pg_dump is updated accordingly.
> The rest of the functionality stays the same as before.
>
>
> On Mon, Feb 25, 2013 at 10:29 AM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>> I think we should always dump DISTRIBUTE BY.
>>
>> PG does not stop dumping (or provide an option to do so) newer syntax so
>> that the dump will work on older versions. On similar lines, an XC dump can
>> not be used against PG without modification (removing DISTRIBUTE BY). There
>> can be more serious problems like exceeding table size limits if an XC dump
>> is tried to be restored in PG.
>>
>> As to TO NODE clause, I agree, that one can restore the dump on a cluster
>> with different configuration, so giving an option to dump TO NODE clause
>> will help.
>>
>> On Mon, Feb 25, 2013 at 6:42 AM, Michael Paquier <
>> mic...@gm...> wrote:
>>
>>>
>>>
>>> On Mon, Feb 25, 2013 at 4:17 AM, Abbas Butt <abb...@en...
>>> > wrote:
>>>
>>>>
>>>>
>>>> On Sun, Feb 24, 2013 at 5:33 PM, Michael Paquier <
>>>> mic...@gm...> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, Feb 24, 2013 at 7:04 PM, Abbas Butt <
>>>>> abb...@en...> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Feb 24, 2013 at 1:44 PM, Michael Paquier <
>>>>>> mic...@gm...> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Feb 24, 2013 at 3:51 PM, Abbas Butt <
>>>>>>> abb...@en...> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> PFA a patch to  fix pg_dump to generate TO NODE clause in the dump.
>>>>>>>> This is required because otherwise all tables get created on all
>>>>>>>> nodes after a dump-restore cycle.
>>>>>>>>
>>>>>>> Not sure this is good if you take a dump of an XC cluster to restore
>>>>>>> that to a vanilla Postgres cluster.
>>>>>>> Why not adding a new option that would control the generation of
>>>>>>> this clause instead of forcing it?
>>>>>>>
>>>>>>
>>>>>> I think you can use the pg_dump that comes with vanilla PG to do
>>>>>> that, can't you? But I am open to adding a control option if every body
>>>>>> thinks so.
>>>>>>
>>>>> Sure you can, this is just to simplify the life of users a maximum by
>>>>> not having multiple pg_dump binaries in their serves.
>>>>> Saying that, I think that there is no option to choose if DISTRIBUTE
>>>>> BY is printed in the dump or not...
>>>>>
>>>>
>>>> Yah if we choose to have an option we will put both DISTRIBUTE BY and
>>>> TO NODE under it.
>>>>
>>> Why not an option for DISTRIBUTE BY, and another for TO NODE?
>>> This would bring more flexibility to the way dumps are generated.
>>> --
>>> Michael
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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_feb
>>> _______________________________________________
>>> Postgres-xc-developers mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>
>>>
>>
>>
>> --
>> Best Wishes,
>> Ashutosh Bapat
>> EntepriseDB Corporation
>> The Enterprise Postgres Company
>>
>
>
>
> --
> --
> Abbas
> Architect
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company
>
> Phone: 92-334-5100153
>
> Website: www.enterprisedb.com
> EnterpriseDB Blog: http://blogs.enterprisedb.com/
> Follow us on Twitter: http://www.twitter.com/enterprisedb
>
> This e-mail message (and any attachment) is intended for the use of
> the individual or entity to whom it is addressed. This message
> contains information from EnterpriseDB Corporation that may be
> privileged, confidential, or exempt from disclosure under applicable
> law. If you are not the intended recipient or authorized to receive
> this for the intended recipient, any use, dissemination, distribution,
> retention, archiving, or copying of this communication is strictly
> prohibited. If you have received this e-mail in error, please notify
> the sender immediately by reply e-mail and delete this message.
>



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

>
> We are running metrics on the system now, we loaded some data recently, and
> continuing to do so now. If Hint bits are the case, what steps can I take to
> relieve some of this IO?
>

This is internal IO which will settle down if you are not loading into
the same table again immediately. A lumpsum count(1) call (after a
recent data load) will touch all pages immediately, so try to avoid
that and amortize the IO over multiple specific select calls.

HTH,
Nikhils


>
>
> From: Mason Sharp [mailto:ma...@st...]
> Sent: Friday, March 01, 2013 2:29 PM
> To: Arni Sumarlidason
> Cc: pos...@li...; Postgres-XC Developers
> (pos...@li...)
> Subject: Re: [Postgres-xc-general] IO PGXC
>
>
>
>
> Sent from my IPhone
>
>
> On Mar 1, 2013, at 4:13 PM, Arni Sumarlidason <Arn...@md...>
> wrote:
>
> Users,
>
>
>
> I have 20 nodes sitting on a disk arrays, with multiple LUNs. when I issue
> queries – `select count(1) from table` for example, I am experiencing heavy
> writes and heavy reads. I expected the reads but not the writes and it has
> really thrown a wrench in the caching. My first assumption would be the log
> files, do you have any other ideas what could be causing all these writes
> with a select?
>
>
>
> It could be vacuum. Also, did you just load data? Hint bits get updated,
> dirtying pages and causing them to be written.
>
>
>
>
>
> Arni Sumarlidason | Software Engineer, Information Technology
>
> MDA | 820 West Diamond Ave | Gaithersburg, MD | USA
>
> O: 240-833-8200 D: 240-833-8318 M: 256-393-2803
>
> arn...@md...| http://www.mdaus.com
>
>
>
> ------------------------------------------------------------------------------
> 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_feb
>
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general



-- 
StormDB - http://www.stormdb.com
The Database Cloud
Postgres-XC Support and Service

Thanks, pushed with some other changes I noticed at the same time.

On Fri, Mar 1, 2013 at 5:41 PM, Nikhil Sontakke <ni...@st...> wrote:

> PFA,
>
> Patch which adds proper formatting at a couple of places. This was
> causing the doc build (and hence me ;)) some grief.
>
> Regards,
> Nikhils
> --
> StormDB - http://www.stormdb.com
> The Database Cloud
> Postgres-XC Support and Service
>
>
> ------------------------------------------------------------------------------
> 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_feb
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>


-- 
Michael

Hmmm, this is going to be a pretty common scenario then.

So no option other than #1 I guess.

Regards,
Nikhils

>> Deadlocks? ISTM, we can get more lock waits because of this but I do
>> not see deadlock scenarios..
>
>
> :) Simple rule is: if DBMS is locking transaction-long resources which
> application doesn't expect, there are bound to be deadlocks.
>
> The application induced deadlocks. An application would think that statement
> A would not lock row rA because it's not being updated, but actually it gets
> locked for UPDATE because of option #2 it locks it. The same application
> would assume that statement B would not lock row rB the same way. WIth this
> context consider following sequence of events
>
> Statement A updates row rB
>
> Statement B updates row rA
>
> Statement A tries to update row rM, but XC tries to lock rA (because of
> option #2) and waits
>
> Statement B tries to update row rN, but XC tries to lock rB (because of
> option #2) and waits
>
> None of A and B can proceed and thus deadlock, even if the application
> doesn't expect those to deadlock.
>
>>
>>
>> With the FQS shipping work being done by Ashutosh, will we also ship
>> major chunks of subplans to the datanodes? If yes, then row locking
>> will only involve required tuples (hopefully) from the coordinator's
>> point of view.
>>
>
> The push-down will work only when there shippable subplans, but if they are
> not ...
>
>>
>> Also, something radical is can be invent a new type of FOR [NODE]
>> UPDATE type lock to minimize the impact of such locking of rows on
>> datanodes?
>>
>> Regards,
>> Nikhils
>>
>> >>
>> >> 3.  The BEFORE trigger function can change the distribution column
>> >> itself. We need to add a check at the end of the trigger executions.
>> >>
>> >
>> > Good, you thought about that. Yes we should check it.
>> >
>> >>
>> >> 4. Fetching OLD row for WHEN clause handling.
>> >>
>> >> 5. Testing with mix of Shippable and non-shippable ROW triggers
>> >>
>> >> 6. Other types of triggers. INSTEAD triggers are anticipated to work
>> >> without significant changes, but they are yet to be tested.
>> >> INSERT/DELETE triggers: Most of the infrastructure has been done while
>> >> implementing UPDATE triggers. But some changes specific to INSERT and
>> >> DELETE are yet to be done.
>> >> Deferred triggers to be tested.
>> >>
>> >> 7. Regression analysis. There are some new failures. Will post another
>> >> fair version of the patch after regression analysis and fixing various
>> >> TODOs.
>> >>
>> >> Comments welcome.
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> 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_feb
>> >> _______________________________________________
>> >> Postgres-xc-developers mailing list
>> >> Pos...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>> >>
>> >
>> >
>> >
>> > --
>> > Best Wishes,
>> > Ashutosh Bapat
>> > EntepriseDB Corporation
>> > The Enterprise Postgres Company
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > 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_feb
>> > _______________________________________________
>> > Postgres-xc-developers mailing list
>> > Pos...@li...
>> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>> >
>>
>>
>>
>> --
>> StormDB - http://www.stormdb.com
>> The Database Cloud
>> Postgres-XC Support and Service
>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company



-- 
StormDB - http://www.stormdb.com
The Database Cloud
Postgres-XC Support and Service

On Fri, Mar 1, 2013 at 5:48 PM, Amit Khandekar <
ami...@en...> wrote:

> On 19 February 2013 12:37, Abbas Butt <abb...@en...> wrote:
> >
> > Hi,
> > Attached please find a patch that locks the cluster so that dump can be
> > taken to be restored on the new node to be added.
> >
> > To lock the cluster the patch adds a new GUC parameter called
> > xc_lock_for_backup, however its status is maintained by the pooler. The
> > reason is that the default behavior of XC is to release connections as
> soon
> > as a command is done and it uses PersistentConnections GUC to control the
> > behavior. We in this case however need a status that is independent of
> the
> > setting of PersistentConnections.
> >
> > Assume we have two coordinator cluster, the patch provides this behavior:
> >
> > Case 1: set and show
> > ====================
> > psql test -p 5432
> > set xc_lock_for_backup=yes;
> > show xc_lock_for_backup;
> >  xc_lock_for_backup
> > --------------------
> >  yes
> > (1 row)
> >
> > Case 2: set from one client show from other
> > ==================================
> > psql test -p 5432
> > set xc_lock_for_backup=yes;
> > (From another tab)
> > psql test -p 5432
> > show xc_lock_for_backup;
> >  xc_lock_for_backup
> > --------------------
> >  yes
> > (1 row)
> >
> > Case 3: set from one, quit it, run again and show
> > ======================================
> > psql test -p 5432
> > set xc_lock_for_backup=yes;
> > \q
> > psql test -p 5432
> > show xc_lock_for_backup;
> >  xc_lock_for_backup
> > --------------------
> >  yes
> > (1 row)
> >
> > Case 4: set on one coordinator, show from other
> > =====================================
> > psql test -p 5432
> > set xc_lock_for_backup=yes;
> > (From another tab)
> > psql test -p 5433
> > show xc_lock_for_backup;
> >  xc_lock_for_backup
> > --------------------
> >  yes
> > (1 row)
> >
> > pg_dump and pg_dumpall seem to work fine after locking the cluster for
> > backup but I would test these utilities in detail next.
> >
> > Also I have yet to look in detail that standard_ProcessUtility is the
> only
> > place that updates the portion of catalog that is dumped. There may be
> some
> > other places too that need to be blocked for catalog updates.
> >
> > The patch adds no extra warnings and regression shows no extra failure.
> >
> > Comments are welcome.
>
> Abbas wrote on another thread:
>
> >   Amit wrote on another thread:
> >> I haven't given a thought on the earlier patch you sent for cluster lock
> >> implementation; may be we can discuss this on that thread, but just a
> quick
> >> question:
> >>
> >> Does the cluster-lock command wait for the ongoing DDL commands to
> finish
> >> ? If not, we have problems. The subsequent pg_dump would not contain
> objects
> >> created by these particular DDLs.
> >
> >
> > Suppose you have a two coordinator cluster. Assume one client connected
> to
> > each. Suppose one client issues a lock cluster command and the other
> issues
> > a DDL. Is this what you mean by an ongoing DDL? If true then answer to
> your
> > question is Yes.
> >
> > Suppose you have a prepared transaction that has a DDL in it, again if
> this
> > can be considered an on going DDL, then again answer to your question is
> > Yes.
> >
> > Suppose you have a two coordinator cluster. Assume one client connected
> to
> > each. One client starts a transaction and issues a DDL, the second client
> > issues a lock cluster command, the first commits the transaction. If
> this is
> > an ongoing DDL, then the answer to your question is No.
>
> Yes this last scenario is what I meant: A DDL has been executed on nodes,
> but
>  not committed, when the cluster lock command is run and then pg_dump
> immediately
> starts its transaction before the DDL is committed. Here pg_dump does
> not see the new objects that would be created.
>
> I myself am not sure how would we prevent this from happening. There
> are two callback hooks that might be worth considering though:
> 1. Transaction End callback (CallXactCallbacks)
> 2. Object creation/drop hook (InvokeObjectAccessHook)
>
> Suppose we create an object creation/drop hook function that would :
> 1. store the current transaction id in a global objects_created list
> if the cluster is not locked,
> 2. or else if the cluster is locked, this hook would ereport() saying
> "cannot create catalog objects in this mode".
>
> And then during transaction commit , a new transaction callback hook will:
> 1. Check the above objects_created list to see if the current
> transaction has any objects created/dropped.
> 2. If found and if the cluster-lock is on, it will again ereport()
> saying "cannot create catalog objects in this mode"
>
> Thinking more on the object creation hook, we can even consider this
> as a substitute for checking the cluster-lock status in
> standardProcessUtility(). But I am not sure whether this hook does get
> called on each of the catalog objects. At least the code comments say
> it does.
>

These are very good ideas, Thanks, I will work on those lines and will
report back.


>
>
>
> > But its a matter of
> > deciding which camp are we going to put COMMIT in, the allow camp, or the
> > deny camp. I decided to put it in allow camp, because I have not yet
> written
> > any code to detect whether a transaction being committed has a DDL in it
> or
> > not, and stopping all transactions from committing looks too restrictive
> to
> > me.
>
>
> >
> > Do you have some other meaning of an ongoing DDL?
>
>
>
> >
> > --
> > Abbas
> > Architect
> > EnterpriseDB Corporation
> > The Enterprise PostgreSQL Company
> >
> > Phone: 92-334-5100153
> >
> > Website: www.enterprisedb.com
> > EnterpriseDB Blog: http://blogs.enterprisedb.com/
> > Follow us on Twitter: http://www.twitter.com/enterprisedb
> >
> > This e-mail message (and any attachment) is intended for the use of
> > the individual or entity to whom it is addressed. This message
> > contains information from EnterpriseDB Corporation that may be
> > privileged, confidential, or exempt from disclosure under applicable
> > law. If you are not the intended recipient or authorized to receive
> > this for the intended recipient, any use, dissemination, distribution,
> > retention, archiving, or copying of this communication is strictly
> > prohibited. If you have received this e-mail in error, please notify
> > the sender immediately by reply e-mail and delete this message.
> >
> >
> ------------------------------------------------------------------------------
> > 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_feb
> > _______________________________________________
> > Postgres-xc-developers mailing list
> > Pos...@li...
> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >
>



-- 
--
Abbas
Architect
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: 92-334-5100153

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.

On 19 February 2013 12:37, Abbas Butt <abb...@en...> wrote:
>
> Hi,
> Attached please find a patch that locks the cluster so that dump can be
> taken to be restored on the new node to be added.
>
> To lock the cluster the patch adds a new GUC parameter called
> xc_lock_for_backup, however its status is maintained by the pooler. The
> reason is that the default behavior of XC is to release connections as soon
> as a command is done and it uses PersistentConnections GUC to control the
> behavior. We in this case however need a status that is independent of the
> setting of PersistentConnections.
>
> Assume we have two coordinator cluster, the patch provides this behavior:
>
> Case 1: set and show
> ====================
> psql test -p 5432
> set xc_lock_for_backup=yes;
> show xc_lock_for_backup;
>  xc_lock_for_backup
> --------------------
>  yes
> (1 row)
>
> Case 2: set from one client show from other
> ==================================
> psql test -p 5432
> set xc_lock_for_backup=yes;
> (From another tab)
> psql test -p 5432
> show xc_lock_for_backup;
>  xc_lock_for_backup
> --------------------
>  yes
> (1 row)
>
> Case 3: set from one, quit it, run again and show
> ======================================
> psql test -p 5432
> set xc_lock_for_backup=yes;
> \q
> psql test -p 5432
> show xc_lock_for_backup;
>  xc_lock_for_backup
> --------------------
>  yes
> (1 row)
>
> Case 4: set on one coordinator, show from other
> =====================================
> psql test -p 5432
> set xc_lock_for_backup=yes;
> (From another tab)
> psql test -p 5433
> show xc_lock_for_backup;
>  xc_lock_for_backup
> --------------------
>  yes
> (1 row)
>
> pg_dump and pg_dumpall seem to work fine after locking the cluster for
> backup but I would test these utilities in detail next.
>
> Also I have yet to look in detail that standard_ProcessUtility is the only
> place that updates the portion of catalog that is dumped. There may be some
> other places too that need to be blocked for catalog updates.
>
> The patch adds no extra warnings and regression shows no extra failure.
>
> Comments are welcome.

Abbas wrote on another thread:

>   Amit wrote on another thread:
>> I haven't given a thought on the earlier patch you sent for cluster lock
>> implementation; may be we can discuss this on that thread, but just a quick
>> question:
>>
>> Does the cluster-lock command wait for the ongoing DDL commands to finish
>> ? If not, we have problems. The subsequent pg_dump would not contain objects
>> created by these particular DDLs.
>
>
> Suppose you have a two coordinator cluster. Assume one client connected to
> each. Suppose one client issues a lock cluster command and the other issues
> a DDL. Is this what you mean by an ongoing DDL? If true then answer to your
> question is Yes.
>
> Suppose you have a prepared transaction that has a DDL in it, again if this
> can be considered an on going DDL, then again answer to your question is
> Yes.
>
> Suppose you have a two coordinator cluster. Assume one client connected to
> each. One client starts a transaction and issues a DDL, the second client
> issues a lock cluster command, the first commits the transaction. If this is
> an ongoing DDL, then the answer to your question is No.

Yes this last scenario is what I meant: A DDL has been executed on nodes, but
 not committed, when the cluster lock command is run and then pg_dump
immediately
starts its transaction before the DDL is committed. Here pg_dump does
not see the new objects that would be created.

I myself am not sure how would we prevent this from happening. There
are two callback hooks that might be worth considering though:
1. Transaction End callback (CallXactCallbacks)
2. Object creation/drop hook (InvokeObjectAccessHook)

Suppose we create an object creation/drop hook function that would :
1. store the current transaction id in a global objects_created list
if the cluster is not locked,
2. or else if the cluster is locked, this hook would ereport() saying
"cannot create catalog objects in this mode".

And then during transaction commit , a new transaction callback hook will:
1. Check the above objects_created list to see if the current
transaction has any objects created/dropped.
2. If found and if the cluster-lock is on, it will again ereport()
saying "cannot create catalog objects in this mode"

Thinking more on the object creation hook, we can even consider this
as a substitute for checking the cluster-lock status in
standardProcessUtility(). But I am not sure whether this hook does get
called on each of the catalog objects. At least the code comments say
it does.



> But its a matter of
> deciding which camp are we going to put COMMIT in, the allow camp, or the
> deny camp. I decided to put it in allow camp, because I have not yet written
> any code to detect whether a transaction being committed has a DDL in it or
> not, and stopping all transactions from committing looks too restrictive to
> me.


>
> Do you have some other meaning of an ongoing DDL?



>
> --
> Abbas
> Architect
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company
>
> Phone: 92-334-5100153
>
> Website: www.enterprisedb.com
> EnterpriseDB Blog: http://blogs.enterprisedb.com/
> Follow us on Twitter: http://www.twitter.com/enterprisedb
>
> This e-mail message (and any attachment) is intended for the use of
> the individual or entity to whom it is addressed. This message
> contains information from EnterpriseDB Corporation that may be
> privileged, confidential, or exempt from disclosure under applicable
> law. If you are not the intended recipient or authorized to receive
> this for the intended recipient, any use, dissemination, distribution,
> retention, archiving, or copying of this communication is strictly
> prohibited. If you have received this e-mail in error, please notify
> the sender immediately by reply e-mail and delete this message.
>
> ------------------------------------------------------------------------------
> 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_feb
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>