postgres-xc-developers Mailing List for Postgres-XC

A) GTM standby writes its backup (both usual backup and Barrier
backup) at the same timing as GTM master so you don't have to restore
these data from the master to the slave at the failover.   Please note
that usual backup timing may be different from the master and the
slave.   In both cases, backup advances GTM and sequence value from
the current value so they can be used as a restart point.

B) You just restart GTM standby at the same or a different server.
GTM standby will backup master status, writes restart point and then
it continues restart point as A).    Please note that it does not
backup existing Barrier restart points so you may have to backup them
manually.

Regards;
---
Koichi Suzuki


2013/12/27 Tomonari Katsumata <kat...@po...>:
> Hi,
>
> I'm investigating about the behavior of GTM/GTM_standby.
> Because I'm thinking about how making GTM more High Availability.
> To clarify the behavior, I want to understand some things below.
>
> A)When do GTM/GTM_standby write data to their disk?
> Currently I know that GTM writes data in below case.
>
> 1)Stopping GTM
> 2)GXID/Sequence are over the limit
> 3)Executing CREATE BARRIER
>
> Are there another case?
> And then, what timing does GTM_standby write data at?
>
> B)When occurring something wrong against GTM/GTM_standby, how do they work?
>
> a)How does GTM work without write permission on the disk?
> According to the situation 1),2),3), the behavior is changed?
> 1)GTM continues to work(gtm_ctl returns ERROR)
> 2)GTM Stopped abnormally
> 3)GTM continues to work, but backup file is never created
>
> Are there another behavior?
>
> b)How does GTM_standby work without write permission on the disk?
> - GTM_standby will stop abnormally?
> - How GTM_standby work when executing promote in this situation?
>
> regards,
> ---------------
> NTT Software Corporation
> Tomonari Katsumata
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers

Hi,

I'm investigating about the behavior of GTM/GTM_standby.
Because I'm thinking about how making GTM more High Availability.
To clarify the behavior, I want to understand some things below.

A)When do GTM/GTM_standby write data to their disk?
Currently I know that GTM writes data in below case.

1)Stopping GTM
2)GXID/Sequence are over the limit
3)Executing CREATE BARRIER

Are there another case?
And then, what timing does GTM_standby write data at?

B)When occurring something wrong against GTM/GTM_standby, how do they work?

a)How does GTM work without write permission on the disk?
According to the situation 1),2),3), the behavior is changed?
1)GTM continues to work(gtm_ctl returns ERROR)
2)GTM Stopped abnormally
3)GTM continues to work, but backup file is never created

Are there another behavior?

b)How does GTM_standby work without write permission on the disk?
- GTM_standby will stop abnormally?
- How GTM_standby work when executing promote in this situation?

regards,
---------------
NTT Software Corporation
Tomonari Katsumata

Koichi-san,

> As you know, XC does not add any changes to configure, except for XC version number and related settings.
> 
> If the error is from XC-specific code, they could be improved as well.
> 
> Could you let me know how the build failed?   I don’t have S390 build environment.

It took a while to get answers from some claiming to be in the know but I
finally got to talk to one of these guys and he said that there is apparently
nothing you can do but using -fPIC instead of -fpic for s390 and maybe even
others. He thinks the problem simply comes from the library exceeding the size
limit for -fpic. If this holds true PostgreSQL proper may run into the same
problem eventually. 

I don't have any s390 development experience myself, so I cannot verify this
information easily, though.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Hi, all.

I got an error report that EXECUTE DIRECT queries with particular GROUP BY
clause return strange binary results and I made brief analysis.

The next query returns strang result.

EXECUTE DIRECT ON (datanode1) $$SELECT relkind FROM pg_class GROUP BY
relname, relkind$$;

It should return a result like Table A, but it returns a result like Table
B.

*Table A*

 relkind
---------
 i
 r
 v
 t
(4 rows)

*Table B*

 relkind
---------
 h

 \x18
 `

 8

 \x10
 X

 0
 x

 \x08
 P

 (
 p

 H

A query to a regular table work well.

cx=# create table tbl as select generate_series(1,10) as a,
generate_series(1,10) as b;
INSERT 0 10
cx=# execute direct on (datanode2) $$select b from tbl group by a,b$$;
 b
----
  7
 10
  4
  3
(4 rows)

On master_pg93_merge, this issue may cause psql disconnection. This query
doesn't make coordinator to be aborted.

cx=# execute direct on (datanode1) $$select tablename from
pg_catalog.pg_tables group by schemaname,tablename$$;
The connection to the server was lost. Attempting reset: Failed.
!>

And next queries return the right results.

# execute direct on (datanode1) $$select relkind from pg_class group
by relkind$$;
# execute direct on (datanode1) $$select relname, relkind from
pg_class group by relname, relkind$$;

It seems that this problem is produced when SELECT statement to pg_catalog
is issued and the selection target does not contain all of the columns
listed in the GROUP BY clause.

A datanode is returning the right result but a coordinator is returning
wrong result.
I think this issue is a bug of coordinator.

Regards.

On Thu, Dec 5, 2013 at 11:22 AM, normandi <nor...@al...> wrote:
> Hi all,
>
> When reading the Postgres-XC document, I got the following two questions
> (the same in nature  maybe :) )
>
> Q1: Why XC need the GTM component?
GTM needs what is called in the XC language global snapshot, that
gives to every session anywhere in the cluster an image of the
transactions running. This is essential to keep data consistent across
the nodes and is well adapted for the definition of MVCC that sticks
to PostgreSQL.

>    In my opinion,if a transaction is submitted at the coord node , the coord
> should break it
> up into a collection of subtransactions which will be submit to the
> corresponding data nodes,
> and the subtransaction will be resolved by datanode's local transaction
> manager.
And could you explain how do you manage consistency of data for
replicated tables?

>   Coordinator can decide whether commit the transaction or not ,by means of
> 2PC/3PC protocol.
2PC is already costly, and I am not going to imagine how your
performance will drop particularly for replicated tables.

> Q2: "same Timestamp view",  how it will affect the App clients?  What is
> means ?
When a transaction begins, the timestamp indicating when the
transaction has begun is recorded on GTM as well, and is registered
centrally by GTM. The same behavior applies for current_timestamp for
example. clock_timestamp, on the contrary, fetch the timestamp of the
local node clock.
-- 
Michael

Hi all,
 When reading the Postgres-XC document, I got the following two questions (the same in nature  maybe :) )

 Q1: Why XC need the GTM component? 
   In my opinion,if a transaction is submitted at the coord node , the coord should break it
 up into a collection of subtransactions which will be submit to the corresponding data nodes,and the subtransaction will be resolved by datanode's local transaction manager.  Coordinator can decide whether commit the transaction or not ,by means of 2PC/3PC protocol.
 
 Q2: "same Timestamp view",  how it will affect the App clients?  What is means ? 
 
 

 Thanks a lot!

 Best Regards!