Menu
▾
▴
postgres-xc-general — General info and messages
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
(19) |
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(12) |
Feb
(1) |
Mar
(4) |
Apr
(4) |
May
(32) |
Jun
(12) |
Jul
(11) |
Aug
(1) |
Sep
(6) |
Oct
(3) |
Nov
|
Dec
(10) |
| 2012 |
Jan
(11) |
Feb
(1) |
Mar
(3) |
Apr
(25) |
May
(53) |
Jun
(38) |
Jul
(103) |
Aug
(54) |
Sep
(31) |
Oct
(66) |
Nov
(77) |
Dec
(20) |
| 2013 |
Jan
(91) |
Feb
(86) |
Mar
(103) |
Apr
(107) |
May
(25) |
Jun
(37) |
Jul
(17) |
Aug
(59) |
Sep
(38) |
Oct
(78) |
Nov
(29) |
Dec
(15) |
| 2014 |
Jan
(23) |
Feb
(82) |
Mar
(118) |
Apr
(101) |
May
(103) |
Jun
(45) |
Jul
(6) |
Aug
(10) |
Sep
|
Oct
(32) |
Nov
|
Dec
(9) |
| 2015 |
Jan
(3) |
Feb
(5) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(9) |
Aug
(4) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
|
2
(3) |
3
(3) |
4
(4) |
5
(1) |
|
6
|
7
(7) |
8
(6) |
9
(5) |
10
(7) |
11
(7) |
12
(1) |
|
13
|
14
(3) |
15
(4) |
16
(6) |
17
(13) |
18
(6) |
19
|
|
20
|
21
|
22
|
23
(1) |
24
(4) |
25
(5) |
26
(1) |
|
27
|
28
(2) |
29
(10) |
30
(2) |
|
|
|
|
From: Aaron J. <aja...@re...> - 2014-04-15 19:36:33
|
Is there any capability to create unique indices where one part of the constraint is the distribution key. In theory, if I created distributed on column name, but then created a unique index on name + level, the constraint could be applied at the data node level. Aaron |
|
From: Juned K. <jkh...@gm...> - 2014-04-15 11:30:19
|
Hi Masataka, You answer helped but again i am having this problem. do i need to remove register.node file again ? GTM logs 1:140587359135488:2014-04-15 12:22:56.711 WAT -LOG: Saving transaction restoration info, backed-up gxid: 259975 LOCATION: GTM_WriteRestorePointXid, gtm_txn.c:2649 1:140587359135488:2014-04-15 12:22:56.712 WAT -LOG: Started to run as GTM-Active. LOCATION: main, main.c:641 1:140587359135488:2014-04-15 12:22:57.712 WAT -LOG: Any GTM standby node not found in registered node(s). LOCATION: gtm_standby_connect_to_standby_int, gtm_standby.c:381 1:140587350980352:2014-04-15 12:22:57.717 WAT -LOG: Failed to establish a connection with GTM standby. - 0x13ac390 LOCATION: gtm_standby_connect_to_standby_int, gtm_standby.c:396 1:140587321448192:2014-04-15 12:27:02.055 WAT -LOG: unexpected EOF on client connection LOCATION: ReadCommand, main.c:1374 1:140587359135488:2014-04-15 12:27:03.928 WAT -LOG: GTM shutting down. LOCATION: ServerLoop, main.c:802 1:140587359135488:2014-04-15 12:27:03.928 WAT -LOG: Saving transaction info - next_gxid: 257975 LOCATION: GTM_SaveTxnInfo, gtm_txn.c:2632 Received signal 15 GTM Proxy logs LOCATION: pgxcnode_add_info, register_common.c:249 1:140179440826112:2014-04-15 12:27:22.893 WAT -LOG: Node with the given ID number already exists LOCATION: pgxcnode_add_info, register_common.c:249 1:140179440826112:2014-04-15 12:27:22.893 WAT -LOG: Node with the given ID number already exists LOCATION: pgxcnode_add_info, register_common.c:249 1:140179440826112:2014-04-15 12:27:22.893 WAT -LOG: Node with the given ID number already exists LOCATION: pgxcnode_add_info, register_common.c:249 1:140179440826112:2014-04-15 12:27:22.893 WAT -LOG: Node with the given ID number already exists LOCATION: pgxcnode_add_info, register_common.c:249 1:140179440826112:2014-04-15 12:27:22.893 WAT -LOG: Node with the given ID number already exists LOCATION: pgxcnode_add_info, register_common.c:249 On Tue, Apr 15, 2014 at 10:49 AM, Juned Khan <jkh...@gm...> wrote: > Hi Masataka, > > Thanks for help > > > On Tue, Apr 15, 2014 at 7:07 AM, Masataka Saito <pg...@gm...> wrote: > >> I'm not sure but GTM or GTM proxy seems to be wrong. >> >> Please check their log. >> If you find an issue, search postgres-xc-general ml for keyword >> "register.node". >> >> Regards. >> >> On 14 April 2014 20:11, Juned Khan <jkh...@gm...> wrote: >> > Here few more logs of the component which doesn't start >> > >> > root@db02:~# tail -f >> > >> /home/postgres/pgxc/nodes/dn_master/pg_log/postgresql-2014-04-14_114619.log >> > LOG: database system was interrupted; last known up at 2014-04-14 >> 11:00:55 >> > WAT >> > LOG: database system was not properly shut down; automatic recovery in >> > progress >> > LOG: record with zero length at 4/9A01A588 >> > LOG: redo is not required >> > FATAL: the database system is starting up >> > LOG: autovacuum launcher started >> > LOG: database system is ready to accept connections >> > WARNING: worker took too long to start; canceled >> > FATAL: Can not register Datanode on GTM >> > >> > >> > root@db02:~# tail -f >> > /home/postgres/pgxc/nodes/coord/pg_log/postgresql-2014-04-14_114612.log >> > DEBUG: 00000: name: unnamed; blockState: DEFAULT; state: INPROGR, >> > xid/subid/cid: 0/1/0, nestlvl: 1, children: >> > LOCATION: ShowTransactionStateRec, xact.c:5238 >> > DEBUG: 00000: Autovacuum launcher: connection to GTM closed >> > LOCATION: CloseGTM, gtm.c:116 >> > DEBUG: 00000: Autovacuum launcher: connection established to GTM with >> > string host=db02 port=20002 node_name=coord1 >> > LOCATION: InitGTM, gtm.c:84 >> > WARNING: 01000: Xid is invalid. >> > LOCATION: GetNewTransactionId, varsup.c:160 >> > DEBUG: 00000: Getting snapshot. Current XID = 0 >> > LOCATION: GetSnapshotDataCoordinator, procarray.c:3054 >> > DEBUG: 00000: Autovacuum launcher: connection to GTM closed >> > LOCATION: CloseGTM, gtm.c:116 >> > DEBUG: 00000: Autovacuum launcher: connection established to GTM with >> > string host=db02 port=20002 node_name=coord1 >> > LOCATION: InitGTM, gtm.c:84 >> > >> > >> > >> > >> > >> > On Mon, Apr 14, 2014 at 3:56 PM, Juned Khan <jkh...@gm...> >> wrote: >> >> >> >> Hi all, >> >> >> >> Yesterday due some problem datanode slave stopped working on one of my >> DB >> >> server. After figuring out the issue i freed out the space on that >> server. >> >> now almost 50% disk is free on server. >> >> >> >> the problem is after that incident i am not able start all my pgxc >> >> components, now its uncertain some of components starts and sometimes >> it >> >> does not each time when i execute "stop all" and "start all" scenario >> is >> >> different.I am not able to figure out the problem which causing this >> issue. >> >> >> >> I have enabled the debug log though and tried to identify the issue and >> >> after reviewing the logs it seems memory related issue, i am not sure >> about >> >> this. >> >> >> >> PGXC start all >> >> Start GTM master >> >> gtm_ctl: PID file "/home/postgres/pgxc/nodes/gtm/gtm.pid" does not >> exist >> >> Is server running? >> >> server starting >> >> Start GTM slavegtm_ctl: PID file >> "/home/postgres/pgxc/nodes/gtm/gtm.pid" >> >> does not exist >> >> Is server running? >> >> server starting >> >> Done. >> >> Starting all the gtm proxies. >> >> Starting gtm proxy gtm_pxy1. >> >> Starting gtm proxy gtm_pxy2. >> >> gtm_proxy: no process found >> >> server starting >> >> gtm_proxy: no process found >> >> server starting >> >> Done. >> >> Starting coordinator master. >> >> Starting coordinator master coord1 >> >> Starting coordinator master coord2 >> >> DEBUG: 00000: postgres: PostmasterMain: initial environment dump: >> >> LOCATION: PostmasterMain, postmaster.c:962 >> >> DEBUG: 00000: ----------------------------------------- >> >> LOCATION: PostmasterMain, postmaster.c:964 >> >> DEBUG: 00000: MAIL=/var/mail/postgres >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: SSH_CLIENT=41.218.72.115 48992 59696 >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: USER=postgres >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LANGUAGE=en_ZA:en >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: SHLVL=1 >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: HOME=/home/postgres >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: PG_GRANDPARENT_PID=19891 >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LOGNAME=postgres >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: _=/usr/local/bin/pg_ctl >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: PGSYSCONFDIR=/usr/local/pgsql/etc >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: >> PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LANG=en_ZA.UTF-8 >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: SHELL=/bin/bash >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: PWD=/home/postgres >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: SSH_CONNECTION=41.218.72.115 48992 41.218.72.115 59696 >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: PGDATA=/home/postgres/pgxc/nodes/coord >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LC_COLLATE=en_ZA.UTF-8 >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LC_CTYPE=en_ZA.UTF-8 >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LC_MESSAGES=en_ZA.UTF-8 >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LC_MONETARY=C >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LC_NUMERIC=C >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LC_TIME=C >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: ----------------------------------------- >> >> LOCATION: PostmasterMain, postmaster.c:969 >> >> DEBUG: 00000: invoking IpcMemoryCreate(size=148193280) >> >> LOCATION: CreateSharedMemoryAndSemaphores, ipci.c:149 >> >> DEBUG: 00000: SlruScanDirectory invoking callback on pg_notify/0000 >> >> LOCATION: SlruScanDirectory, slru.c:1312 >> >> DEBUG: 00000: removing file "pg_notify/0000" >> >> LOCATION: SlruScanDirCbDeleteAll, slru.c:1277 >> >> DEBUG: 00000: max_safe_fds = 984, usable_fds = 1000, already_open = 6 >> >> LOCATION: set_max_safe_fds, fd.c:548 >> >> LOG: 00000: redirecting log output to logging collector process >> >> HINT: Future log output will appear in directory "pg_log". >> >> LOCATION: SysLogger_Start, syslogger.c:649 >> >> DEBUG: 00000: postgres: PostmasterMain: initial environment dump: >> >> LOCATION: PostmasterMain, postmaster.c:962 >> >> DEBUG: 00000: ----------------------------------------- >> >> LOCATION: PostmasterMain, postmaster.c:964 >> >> DEBUG: 00000: MAIL=/var/mail/postgres >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: SSH_CLIENT=41.218.72.115 33169 59696 >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: USER=postgres >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LANGUAGE=en_ZA:en >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: SHLVL=1 >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: HOME=/home/postgres >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: PG_GRANDPARENT_PID=19507 >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LOGNAME=postgres >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: _=/usr/local/bin/pg_ctl >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: PGSYSCONFDIR=/usr/local/pgsql/etc >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: >> PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LANG=en_ZA.UTF-8 >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: SHELL=/bin/bash >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: PWD=/home/postgres >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: SSH_CONNECTION=41.218.72.115 33169 41.218.72.114 59696 >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: PGDATA=/home/postgres/pgxc/nodes/coord >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LC_COLLATE=en_ZA.UTF-8 >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LC_CTYPE=en_ZA.UTF-8 >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LC_MESSAGES=en_ZA.UTF-8 >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LC_MONETARY=C >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LC_NUMERIC=C >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: LC_TIME=C >> >> LOCATION: PostmasterMain, postmaster.c:967 >> >> DEBUG: 00000: ----------------------------------------- >> >> LOCATION: PostmasterMain, postmaster.c:969 >> >> DEBUG: 00000: invoking IpcMemoryCreate(size=148193280) >> >> LOCATION: CreateSharedMemoryAndSemaphores, ipci.c:149 >> >> DEBUG: 00000: SlruScanDirectory invoking callback on pg_notify/0000 >> >> LOCATION: SlruScanDirectory, slru.c:1312 >> >> DEBUG: 00000: removing file "pg_notify/0000" >> >> LOCATION: SlruScanDirCbDeleteAll, slru.c:1277 >> >> DEBUG: 00000: max_safe_fds = 984, usable_fds = 1000, already_open = 6 >> >> LOCATION: set_max_safe_fds, fd.c:548 >> >> LOG: 00000: redirecting log output to logging collector process >> >> HINT: Future log output will appear in directory "pg_log". >> >> LOCATION: SysLogger_Start, syslogger.c:649 >> >> DEBUG: 00000: logger shutting down >> >> LOCATION: SysLoggerMain, syslogger.c:517 >> >> DEBUG: 00000: shmem_exit(0): 0 callbacks to make >> >> LOCATION: shmem_exit, ipc.c:212 >> >> DEBUG: 00000: proc_exit(0): 0 callbacks to make >> >> LOCATION: proc_exit_prepare, ipc.c:184 >> >> DEBUG: 00000: exit(0) >> >> LOCATION: proc_exit, ipc.c:135 >> >> DEBUG: 00000: shmem_exit(-1): 0 callbacks to make >> >> LOCATION: shmem_exit, ipc.c:212 >> >> DEBUG: 00000: proc_exit(-1): 0 callbacks to make >> >> LOCATION: proc_exit_prepare, ipc.c:184 >> >> pg_ctl: could not start server >> >> Examine the log output. >> >> Done. >> >> Starting all the datanode masters. >> >> Starting datanode master datanode1. >> >> LOG: redirecting log output to logging collector process >> >> HINT: Future log output will appear in directory "pg_log". >> >> Done. >> >> Starting all the datanode slaves. >> >> Starting datanode slave datanode1. >> >> LOG: redirecting log output to logging collector process >> >> HINT: Future log output will appear in directory "pg_log". >> >> Done. >> >> PGXC monitor all >> >> Running: gtm master >> >> Running: gtm slave >> >> Running: gtm proxy gtm_pxy1 >> >> Running: gtm proxy gtm_pxy2 >> >> Running: coordinator master coord1 >> >> Not running: coordinator master coord2 >> >> Not running: datanode master datanode1 >> >> Running: datanode slave datanode1 >> >> >> >> >> >> My DB server has 32 GB RAM and 260 GB of Hard disk and i am using >> >> pgxc-1.2.1. what would be the optimal memory related postgresql.conf >> >> configuration for this server. >> >> >> >> Anyone has an idea about this issue ? >> >> >> >> -- >> >> Thanks, >> >> Juned Khan >> >> iNextrix Technologies Pvt Ltd. >> >> www.inextrix.com >> > >> > >> > >> > >> > -- >> > Thanks, >> > Juned Khan >> > iNextrix Technologies Pvt Ltd. >> > www.inextrix.com >> > >> > >> ------------------------------------------------------------------------------ >> > Learn Graph Databases - Download FREE O'Reilly Book >> > "Graph Databases" is the definitive new guide to graph databases and >> their >> > applications. Written by three acclaimed leaders in the field, >> > this first edition is now available. Download your free book today! >> > http://p.sf.net/sfu/NeoTech >> > _______________________________________________ >> > Postgres-xc-general mailing list >> > Pos...@li... >> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >> > >> > > > > -- > Thanks, > Juned Khan > iNextrix Technologies Pvt Ltd. > www.inextrix.com > -- Thanks, Juned Khan iNextrix Technologies Pvt Ltd. www.inextrix.com |
|
From: Juned K. <jkh...@gm...> - 2014-04-15 05:19:35
|
Hi Masataka, Thanks for help On Tue, Apr 15, 2014 at 7:07 AM, Masataka Saito <pg...@gm...> wrote: > I'm not sure but GTM or GTM proxy seems to be wrong. > > Please check their log. > If you find an issue, search postgres-xc-general ml for keyword > "register.node". > > Regards. > > On 14 April 2014 20:11, Juned Khan <jkh...@gm...> wrote: > > Here few more logs of the component which doesn't start > > > > root@db02:~# tail -f > > > /home/postgres/pgxc/nodes/dn_master/pg_log/postgresql-2014-04-14_114619.log > > LOG: database system was interrupted; last known up at 2014-04-14 > 11:00:55 > > WAT > > LOG: database system was not properly shut down; automatic recovery in > > progress > > LOG: record with zero length at 4/9A01A588 > > LOG: redo is not required > > FATAL: the database system is starting up > > LOG: autovacuum launcher started > > LOG: database system is ready to accept connections > > WARNING: worker took too long to start; canceled > > FATAL: Can not register Datanode on GTM > > > > > > root@db02:~# tail -f > > /home/postgres/pgxc/nodes/coord/pg_log/postgresql-2014-04-14_114612.log > > DEBUG: 00000: name: unnamed; blockState: DEFAULT; state: INPROGR, > > xid/subid/cid: 0/1/0, nestlvl: 1, children: > > LOCATION: ShowTransactionStateRec, xact.c:5238 > > DEBUG: 00000: Autovacuum launcher: connection to GTM closed > > LOCATION: CloseGTM, gtm.c:116 > > DEBUG: 00000: Autovacuum launcher: connection established to GTM with > > string host=db02 port=20002 node_name=coord1 > > LOCATION: InitGTM, gtm.c:84 > > WARNING: 01000: Xid is invalid. > > LOCATION: GetNewTransactionId, varsup.c:160 > > DEBUG: 00000: Getting snapshot. Current XID = 0 > > LOCATION: GetSnapshotDataCoordinator, procarray.c:3054 > > DEBUG: 00000: Autovacuum launcher: connection to GTM closed > > LOCATION: CloseGTM, gtm.c:116 > > DEBUG: 00000: Autovacuum launcher: connection established to GTM with > > string host=db02 port=20002 node_name=coord1 > > LOCATION: InitGTM, gtm.c:84 > > > > > > > > > > > > On Mon, Apr 14, 2014 at 3:56 PM, Juned Khan <jkh...@gm...> wrote: > >> > >> Hi all, > >> > >> Yesterday due some problem datanode slave stopped working on one of my > DB > >> server. After figuring out the issue i freed out the space on that > server. > >> now almost 50% disk is free on server. > >> > >> the problem is after that incident i am not able start all my pgxc > >> components, now its uncertain some of components starts and sometimes it > >> does not each time when i execute "stop all" and "start all" scenario is > >> different.I am not able to figure out the problem which causing this > issue. > >> > >> I have enabled the debug log though and tried to identify the issue and > >> after reviewing the logs it seems memory related issue, i am not sure > about > >> this. > >> > >> PGXC start all > >> Start GTM master > >> gtm_ctl: PID file "/home/postgres/pgxc/nodes/gtm/gtm.pid" does not exist > >> Is server running? > >> server starting > >> Start GTM slavegtm_ctl: PID file "/home/postgres/pgxc/nodes/gtm/gtm.pid" > >> does not exist > >> Is server running? > >> server starting > >> Done. > >> Starting all the gtm proxies. > >> Starting gtm proxy gtm_pxy1. > >> Starting gtm proxy gtm_pxy2. > >> gtm_proxy: no process found > >> server starting > >> gtm_proxy: no process found > >> server starting > >> Done. > >> Starting coordinator master. > >> Starting coordinator master coord1 > >> Starting coordinator master coord2 > >> DEBUG: 00000: postgres: PostmasterMain: initial environment dump: > >> LOCATION: PostmasterMain, postmaster.c:962 > >> DEBUG: 00000: ----------------------------------------- > >> LOCATION: PostmasterMain, postmaster.c:964 > >> DEBUG: 00000: MAIL=/var/mail/postgres > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: SSH_CLIENT=41.218.72.115 48992 59696 > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: USER=postgres > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LANGUAGE=en_ZA:en > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: SHLVL=1 > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: HOME=/home/postgres > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: PG_GRANDPARENT_PID=19891 > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LOGNAME=postgres > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: _=/usr/local/bin/pg_ctl > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: PGSYSCONFDIR=/usr/local/pgsql/etc > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: > PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LANG=en_ZA.UTF-8 > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: SHELL=/bin/bash > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: PWD=/home/postgres > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: SSH_CONNECTION=41.218.72.115 48992 41.218.72.115 59696 > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: PGDATA=/home/postgres/pgxc/nodes/coord > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LC_COLLATE=en_ZA.UTF-8 > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LC_CTYPE=en_ZA.UTF-8 > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LC_MESSAGES=en_ZA.UTF-8 > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LC_MONETARY=C > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LC_NUMERIC=C > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LC_TIME=C > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: ----------------------------------------- > >> LOCATION: PostmasterMain, postmaster.c:969 > >> DEBUG: 00000: invoking IpcMemoryCreate(size=148193280) > >> LOCATION: CreateSharedMemoryAndSemaphores, ipci.c:149 > >> DEBUG: 00000: SlruScanDirectory invoking callback on pg_notify/0000 > >> LOCATION: SlruScanDirectory, slru.c:1312 > >> DEBUG: 00000: removing file "pg_notify/0000" > >> LOCATION: SlruScanDirCbDeleteAll, slru.c:1277 > >> DEBUG: 00000: max_safe_fds = 984, usable_fds = 1000, already_open = 6 > >> LOCATION: set_max_safe_fds, fd.c:548 > >> LOG: 00000: redirecting log output to logging collector process > >> HINT: Future log output will appear in directory "pg_log". > >> LOCATION: SysLogger_Start, syslogger.c:649 > >> DEBUG: 00000: postgres: PostmasterMain: initial environment dump: > >> LOCATION: PostmasterMain, postmaster.c:962 > >> DEBUG: 00000: ----------------------------------------- > >> LOCATION: PostmasterMain, postmaster.c:964 > >> DEBUG: 00000: MAIL=/var/mail/postgres > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: SSH_CLIENT=41.218.72.115 33169 59696 > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: USER=postgres > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LANGUAGE=en_ZA:en > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: SHLVL=1 > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: HOME=/home/postgres > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: PG_GRANDPARENT_PID=19507 > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LOGNAME=postgres > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: _=/usr/local/bin/pg_ctl > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: PGSYSCONFDIR=/usr/local/pgsql/etc > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: > PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LANG=en_ZA.UTF-8 > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: SHELL=/bin/bash > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: PWD=/home/postgres > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: SSH_CONNECTION=41.218.72.115 33169 41.218.72.114 59696 > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: PGDATA=/home/postgres/pgxc/nodes/coord > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LC_COLLATE=en_ZA.UTF-8 > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LC_CTYPE=en_ZA.UTF-8 > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LC_MESSAGES=en_ZA.UTF-8 > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LC_MONETARY=C > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LC_NUMERIC=C > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: LC_TIME=C > >> LOCATION: PostmasterMain, postmaster.c:967 > >> DEBUG: 00000: ----------------------------------------- > >> LOCATION: PostmasterMain, postmaster.c:969 > >> DEBUG: 00000: invoking IpcMemoryCreate(size=148193280) > >> LOCATION: CreateSharedMemoryAndSemaphores, ipci.c:149 > >> DEBUG: 00000: SlruScanDirectory invoking callback on pg_notify/0000 > >> LOCATION: SlruScanDirectory, slru.c:1312 > >> DEBUG: 00000: removing file "pg_notify/0000" > >> LOCATION: SlruScanDirCbDeleteAll, slru.c:1277 > >> DEBUG: 00000: max_safe_fds = 984, usable_fds = 1000, already_open = 6 > >> LOCATION: set_max_safe_fds, fd.c:548 > >> LOG: 00000: redirecting log output to logging collector process > >> HINT: Future log output will appear in directory "pg_log". > >> LOCATION: SysLogger_Start, syslogger.c:649 > >> DEBUG: 00000: logger shutting down > >> LOCATION: SysLoggerMain, syslogger.c:517 > >> DEBUG: 00000: shmem_exit(0): 0 callbacks to make > >> LOCATION: shmem_exit, ipc.c:212 > >> DEBUG: 00000: proc_exit(0): 0 callbacks to make > >> LOCATION: proc_exit_prepare, ipc.c:184 > >> DEBUG: 00000: exit(0) > >> LOCATION: proc_exit, ipc.c:135 > >> DEBUG: 00000: shmem_exit(-1): 0 callbacks to make > >> LOCATION: shmem_exit, ipc.c:212 > >> DEBUG: 00000: proc_exit(-1): 0 callbacks to make > >> LOCATION: proc_exit_prepare, ipc.c:184 > >> pg_ctl: could not start server > >> Examine the log output. > >> Done. > >> Starting all the datanode masters. > >> Starting datanode master datanode1. > >> LOG: redirecting log output to logging collector process > >> HINT: Future log output will appear in directory "pg_log". > >> Done. > >> Starting all the datanode slaves. > >> Starting datanode slave datanode1. > >> LOG: redirecting log output to logging collector process > >> HINT: Future log output will appear in directory "pg_log". > >> Done. > >> PGXC monitor all > >> Running: gtm master > >> Running: gtm slave > >> Running: gtm proxy gtm_pxy1 > >> Running: gtm proxy gtm_pxy2 > >> Running: coordinator master coord1 > >> Not running: coordinator master coord2 > >> Not running: datanode master datanode1 > >> Running: datanode slave datanode1 > >> > >> > >> My DB server has 32 GB RAM and 260 GB of Hard disk and i am using > >> pgxc-1.2.1. what would be the optimal memory related postgresql.conf > >> configuration for this server. > >> > >> Anyone has an idea about this issue ? > >> > >> -- > >> Thanks, > >> Juned Khan > >> iNextrix Technologies Pvt Ltd. > >> www.inextrix.com > > > > > > > > > > -- > > Thanks, > > Juned Khan > > iNextrix Technologies Pvt Ltd. > > www.inextrix.com > > > > > ------------------------------------------------------------------------------ > > Learn Graph Databases - Download FREE O'Reilly Book > > "Graph Databases" is the definitive new guide to graph databases and > their > > applications. Written by three acclaimed leaders in the field, > > this first edition is now available. Download your free book today! > > http://p.sf.net/sfu/NeoTech > > _______________________________________________ > > Postgres-xc-general mailing list > > Pos...@li... > > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general > > > -- Thanks, Juned Khan iNextrix Technologies Pvt Ltd. www.inextrix.com |
|
From: Masataka S. <pg...@gm...> - 2014-04-15 01:38:02
|
I'm not sure but GTM or GTM proxy seems to be wrong. Please check their log. If you find an issue, search postgres-xc-general ml for keyword "register.node". Regards. On 14 April 2014 20:11, Juned Khan <jkh...@gm...> wrote: > Here few more logs of the component which doesn't start > > root@db02:~# tail -f > /home/postgres/pgxc/nodes/dn_master/pg_log/postgresql-2014-04-14_114619.log > LOG: database system was interrupted; last known up at 2014-04-14 11:00:55 > WAT > LOG: database system was not properly shut down; automatic recovery in > progress > LOG: record with zero length at 4/9A01A588 > LOG: redo is not required > FATAL: the database system is starting up > LOG: autovacuum launcher started > LOG: database system is ready to accept connections > WARNING: worker took too long to start; canceled > FATAL: Can not register Datanode on GTM > > > root@db02:~# tail -f > /home/postgres/pgxc/nodes/coord/pg_log/postgresql-2014-04-14_114612.log > DEBUG: 00000: name: unnamed; blockState: DEFAULT; state: INPROGR, > xid/subid/cid: 0/1/0, nestlvl: 1, children: > LOCATION: ShowTransactionStateRec, xact.c:5238 > DEBUG: 00000: Autovacuum launcher: connection to GTM closed > LOCATION: CloseGTM, gtm.c:116 > DEBUG: 00000: Autovacuum launcher: connection established to GTM with > string host=db02 port=20002 node_name=coord1 > LOCATION: InitGTM, gtm.c:84 > WARNING: 01000: Xid is invalid. > LOCATION: GetNewTransactionId, varsup.c:160 > DEBUG: 00000: Getting snapshot. Current XID = 0 > LOCATION: GetSnapshotDataCoordinator, procarray.c:3054 > DEBUG: 00000: Autovacuum launcher: connection to GTM closed > LOCATION: CloseGTM, gtm.c:116 > DEBUG: 00000: Autovacuum launcher: connection established to GTM with > string host=db02 port=20002 node_name=coord1 > LOCATION: InitGTM, gtm.c:84 > > > > > > On Mon, Apr 14, 2014 at 3:56 PM, Juned Khan <jkh...@gm...> wrote: >> >> Hi all, >> >> Yesterday due some problem datanode slave stopped working on one of my DB >> server. After figuring out the issue i freed out the space on that server. >> now almost 50% disk is free on server. >> >> the problem is after that incident i am not able start all my pgxc >> components, now its uncertain some of components starts and sometimes it >> does not each time when i execute "stop all" and "start all" scenario is >> different.I am not able to figure out the problem which causing this issue. >> >> I have enabled the debug log though and tried to identify the issue and >> after reviewing the logs it seems memory related issue, i am not sure about >> this. >> >> PGXC start all >> Start GTM master >> gtm_ctl: PID file "/home/postgres/pgxc/nodes/gtm/gtm.pid" does not exist >> Is server running? >> server starting >> Start GTM slavegtm_ctl: PID file "/home/postgres/pgxc/nodes/gtm/gtm.pid" >> does not exist >> Is server running? >> server starting >> Done. >> Starting all the gtm proxies. >> Starting gtm proxy gtm_pxy1. >> Starting gtm proxy gtm_pxy2. >> gtm_proxy: no process found >> server starting >> gtm_proxy: no process found >> server starting >> Done. >> Starting coordinator master. >> Starting coordinator master coord1 >> Starting coordinator master coord2 >> DEBUG: 00000: postgres: PostmasterMain: initial environment dump: >> LOCATION: PostmasterMain, postmaster.c:962 >> DEBUG: 00000: ----------------------------------------- >> LOCATION: PostmasterMain, postmaster.c:964 >> DEBUG: 00000: MAIL=/var/mail/postgres >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: SSH_CLIENT=41.218.72.115 48992 59696 >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: USER=postgres >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LANGUAGE=en_ZA:en >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: SHLVL=1 >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: HOME=/home/postgres >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: PG_GRANDPARENT_PID=19891 >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LOGNAME=postgres >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: _=/usr/local/bin/pg_ctl >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: PGSYSCONFDIR=/usr/local/pgsql/etc >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LANG=en_ZA.UTF-8 >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: SHELL=/bin/bash >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: PWD=/home/postgres >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: SSH_CONNECTION=41.218.72.115 48992 41.218.72.115 59696 >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: PGDATA=/home/postgres/pgxc/nodes/coord >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LC_COLLATE=en_ZA.UTF-8 >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LC_CTYPE=en_ZA.UTF-8 >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LC_MESSAGES=en_ZA.UTF-8 >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LC_MONETARY=C >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LC_NUMERIC=C >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LC_TIME=C >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: ----------------------------------------- >> LOCATION: PostmasterMain, postmaster.c:969 >> DEBUG: 00000: invoking IpcMemoryCreate(size=148193280) >> LOCATION: CreateSharedMemoryAndSemaphores, ipci.c:149 >> DEBUG: 00000: SlruScanDirectory invoking callback on pg_notify/0000 >> LOCATION: SlruScanDirectory, slru.c:1312 >> DEBUG: 00000: removing file "pg_notify/0000" >> LOCATION: SlruScanDirCbDeleteAll, slru.c:1277 >> DEBUG: 00000: max_safe_fds = 984, usable_fds = 1000, already_open = 6 >> LOCATION: set_max_safe_fds, fd.c:548 >> LOG: 00000: redirecting log output to logging collector process >> HINT: Future log output will appear in directory "pg_log". >> LOCATION: SysLogger_Start, syslogger.c:649 >> DEBUG: 00000: postgres: PostmasterMain: initial environment dump: >> LOCATION: PostmasterMain, postmaster.c:962 >> DEBUG: 00000: ----------------------------------------- >> LOCATION: PostmasterMain, postmaster.c:964 >> DEBUG: 00000: MAIL=/var/mail/postgres >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: SSH_CLIENT=41.218.72.115 33169 59696 >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: USER=postgres >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LANGUAGE=en_ZA:en >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: SHLVL=1 >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: HOME=/home/postgres >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: PG_GRANDPARENT_PID=19507 >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LOGNAME=postgres >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: _=/usr/local/bin/pg_ctl >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: PGSYSCONFDIR=/usr/local/pgsql/etc >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LANG=en_ZA.UTF-8 >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: SHELL=/bin/bash >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: PWD=/home/postgres >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: SSH_CONNECTION=41.218.72.115 33169 41.218.72.114 59696 >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: PGDATA=/home/postgres/pgxc/nodes/coord >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LC_COLLATE=en_ZA.UTF-8 >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LC_CTYPE=en_ZA.UTF-8 >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LC_MESSAGES=en_ZA.UTF-8 >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LC_MONETARY=C >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LC_NUMERIC=C >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: LC_TIME=C >> LOCATION: PostmasterMain, postmaster.c:967 >> DEBUG: 00000: ----------------------------------------- >> LOCATION: PostmasterMain, postmaster.c:969 >> DEBUG: 00000: invoking IpcMemoryCreate(size=148193280) >> LOCATION: CreateSharedMemoryAndSemaphores, ipci.c:149 >> DEBUG: 00000: SlruScanDirectory invoking callback on pg_notify/0000 >> LOCATION: SlruScanDirectory, slru.c:1312 >> DEBUG: 00000: removing file "pg_notify/0000" >> LOCATION: SlruScanDirCbDeleteAll, slru.c:1277 >> DEBUG: 00000: max_safe_fds = 984, usable_fds = 1000, already_open = 6 >> LOCATION: set_max_safe_fds, fd.c:548 >> LOG: 00000: redirecting log output to logging collector process >> HINT: Future log output will appear in directory "pg_log". >> LOCATION: SysLogger_Start, syslogger.c:649 >> DEBUG: 00000: logger shutting down >> LOCATION: SysLoggerMain, syslogger.c:517 >> DEBUG: 00000: shmem_exit(0): 0 callbacks to make >> LOCATION: shmem_exit, ipc.c:212 >> DEBUG: 00000: proc_exit(0): 0 callbacks to make >> LOCATION: proc_exit_prepare, ipc.c:184 >> DEBUG: 00000: exit(0) >> LOCATION: proc_exit, ipc.c:135 >> DEBUG: 00000: shmem_exit(-1): 0 callbacks to make >> LOCATION: shmem_exit, ipc.c:212 >> DEBUG: 00000: proc_exit(-1): 0 callbacks to make >> LOCATION: proc_exit_prepare, ipc.c:184 >> pg_ctl: could not start server >> Examine the log output. >> Done. >> Starting all the datanode masters. >> Starting datanode master datanode1. >> LOG: redirecting log output to logging collector process >> HINT: Future log output will appear in directory "pg_log". >> Done. >> Starting all the datanode slaves. >> Starting datanode slave datanode1. >> LOG: redirecting log output to logging collector process >> HINT: Future log output will appear in directory "pg_log". >> Done. >> PGXC monitor all >> Running: gtm master >> Running: gtm slave >> Running: gtm proxy gtm_pxy1 >> Running: gtm proxy gtm_pxy2 >> Running: coordinator master coord1 >> Not running: coordinator master coord2 >> Not running: datanode master datanode1 >> Running: datanode slave datanode1 >> >> >> My DB server has 32 GB RAM and 260 GB of Hard disk and i am using >> pgxc-1.2.1. what would be the optimal memory related postgresql.conf >> configuration for this server. >> >> Anyone has an idea about this issue ? >> >> -- >> Thanks, >> Juned Khan >> iNextrix Technologies Pvt Ltd. >> www.inextrix.com > > > > > -- > Thanks, > Juned Khan > iNextrix Technologies Pvt Ltd. > www.inextrix.com > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general > |
|
From: Juned K. <jkh...@gm...> - 2014-04-14 11:12:02
|
Here few more logs of the component which doesn't start root@db02:~# tail -f /home/postgres/pgxc/nodes/dn_master/pg_log/postgresql-2014-04-14_114619.log LOG: database system was interrupted; last known up at 2014-04-14 11:00:55 WAT LOG: database system was not properly shut down; automatic recovery in progress LOG: record with zero length at 4/9A01A588 LOG: redo is not required FATAL: the database system is starting up LOG: autovacuum launcher started LOG: database system is ready to accept connections WARNING: worker took too long to start; canceled FATAL: Can not register Datanode on GTM root@db02:~# tail -f /home/postgres/pgxc/nodes/coord/pg_log/postgresql-2014-04-14_114612.log DEBUG: 00000: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: LOCATION: ShowTransactionStateRec, xact.c:5238 DEBUG: 00000: Autovacuum launcher: connection to GTM closed LOCATION: CloseGTM, gtm.c:116 DEBUG: 00000: Autovacuum launcher: connection established to GTM with string host=db02 port=20002 node_name=coord1 LOCATION: InitGTM, gtm.c:84 WARNING: 01000: Xid is invalid. LOCATION: GetNewTransactionId, varsup.c:160 DEBUG: 00000: Getting snapshot. Current XID = 0 LOCATION: GetSnapshotDataCoordinator, procarray.c:3054 DEBUG: 00000: Autovacuum launcher: connection to GTM closed LOCATION: CloseGTM, gtm.c:116 DEBUG: 00000: Autovacuum launcher: connection established to GTM with string host=db02 port=20002 node_name=coord1 LOCATION: InitGTM, gtm.c:84 On Mon, Apr 14, 2014 at 3:56 PM, Juned Khan <jkh...@gm...> wrote: > Hi all, > > Yesterday due some problem datanode slave stopped working on one of my DB > server. After figuring out the issue i freed out the space on that server. > now almost 50% disk is free on server. > > the problem is after that incident i am not able start all my pgxc > components, now its uncertain some of components starts and sometimes it > does not each time when i execute "stop all" and "start all" scenario is > different.I am not able to figure out the problem which causing this issue. > > I have enabled the debug log though and tried to identify the issue and > after reviewing the logs it seems memory related issue, i am not sure about > this. > > PGXC start all > Start GTM master > gtm_ctl: PID file "/home/postgres/pgxc/nodes/gtm/gtm.pid" does not exist > Is server running? > server starting > Start GTM slavegtm_ctl: PID file "/home/postgres/pgxc/nodes/gtm/gtm.pid" > does not exist > Is server running? > server starting > Done. > Starting all the gtm proxies. > Starting gtm proxy gtm_pxy1. > Starting gtm proxy gtm_pxy2. > gtm_proxy: no process found > server starting > gtm_proxy: no process found > server starting > Done. > Starting coordinator master. > Starting coordinator master coord1 > Starting coordinator master coord2 > DEBUG: 00000: postgres: PostmasterMain: initial environment dump: > LOCATION: PostmasterMain, postmaster.c:962 > DEBUG: 00000: ----------------------------------------- > LOCATION: PostmasterMain, postmaster.c:964 > DEBUG: 00000: MAIL=/var/mail/postgres > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: SSH_CLIENT=41.218.72.115 48992 59696 > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: USER=postgres > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LANGUAGE=en_ZA:en > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: SHLVL=1 > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: HOME=/home/postgres > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: PG_GRANDPARENT_PID=19891 > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LOGNAME=postgres > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: _=/usr/local/bin/pg_ctl > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: PGSYSCONFDIR=/usr/local/pgsql/etc > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LANG=en_ZA.UTF-8 > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: SHELL=/bin/bash > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: PWD=/home/postgres > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: SSH_CONNECTION=41.218.72.115 48992 41.218.72.115 59696 > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: PGDATA=/home/postgres/pgxc/nodes/coord > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LC_COLLATE=en_ZA.UTF-8 > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LC_CTYPE=en_ZA.UTF-8 > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LC_MESSAGES=en_ZA.UTF-8 > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LC_MONETARY=C > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LC_NUMERIC=C > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LC_TIME=C > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: ----------------------------------------- > LOCATION: PostmasterMain, postmaster.c:969 > DEBUG: 00000: invoking IpcMemoryCreate(size=148193280) > LOCATION: CreateSharedMemoryAndSemaphores, ipci.c:149 > DEBUG: 00000: SlruScanDirectory invoking callback on pg_notify/0000 > LOCATION: SlruScanDirectory, slru.c:1312 > DEBUG: 00000: removing file "pg_notify/0000" > LOCATION: SlruScanDirCbDeleteAll, slru.c:1277 > DEBUG: 00000: max_safe_fds = 984, usable_fds = 1000, already_open = 6 > LOCATION: set_max_safe_fds, fd.c:548 > LOG: 00000: redirecting log output to logging collector process > HINT: Future log output will appear in directory "pg_log". > LOCATION: SysLogger_Start, syslogger.c:649 > DEBUG: 00000: postgres: PostmasterMain: initial environment dump: > LOCATION: PostmasterMain, postmaster.c:962 > DEBUG: 00000: ----------------------------------------- > LOCATION: PostmasterMain, postmaster.c:964 > DEBUG: 00000: MAIL=/var/mail/postgres > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: SSH_CLIENT=41.218.72.115 33169 59696 > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: USER=postgres > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LANGUAGE=en_ZA:en > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: SHLVL=1 > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: HOME=/home/postgres > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: PG_GRANDPARENT_PID=19507 > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LOGNAME=postgres > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: _=/usr/local/bin/pg_ctl > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: PGSYSCONFDIR=/usr/local/pgsql/etc > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LANG=en_ZA.UTF-8 > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: SHELL=/bin/bash > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: PWD=/home/postgres > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: SSH_CONNECTION=41.218.72.115 33169 41.218.72.114 59696 > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: PGDATA=/home/postgres/pgxc/nodes/coord > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LC_COLLATE=en_ZA.UTF-8 > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LC_CTYPE=en_ZA.UTF-8 > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LC_MESSAGES=en_ZA.UTF-8 > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LC_MONETARY=C > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LC_NUMERIC=C > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: LC_TIME=C > LOCATION: PostmasterMain, postmaster.c:967 > DEBUG: 00000: ----------------------------------------- > LOCATION: PostmasterMain, postmaster.c:969 > DEBUG: 00000: invoking IpcMemoryCreate(size=148193280) > LOCATION: CreateSharedMemoryAndSemaphores, ipci.c:149 > DEBUG: 00000: SlruScanDirectory invoking callback on pg_notify/0000 > LOCATION: SlruScanDirectory, slru.c:1312 > DEBUG: 00000: removing file "pg_notify/0000" > LOCATION: SlruScanDirCbDeleteAll, slru.c:1277 > DEBUG: 00000: max_safe_fds = 984, usable_fds = 1000, already_open = 6 > LOCATION: set_max_safe_fds, fd.c:548 > LOG: 00000: redirecting log output to logging collector process > HINT: Future log output will appear in directory "pg_log". > LOCATION: SysLogger_Start, syslogger.c:649 > DEBUG: 00000: logger shutting down > LOCATION: SysLoggerMain, syslogger.c:517 > DEBUG: 00000: shmem_exit(0): 0 callbacks to make > LOCATION: shmem_exit, ipc.c:212 > DEBUG: 00000: proc_exit(0): 0 callbacks to make > LOCATION: proc_exit_prepare, ipc.c:184 > DEBUG: 00000: exit(0) > LOCATION: proc_exit, ipc.c:135 > DEBUG: 00000: shmem_exit(-1): 0 callbacks to make > LOCATION: shmem_exit, ipc.c:212 > DEBUG: 00000: proc_exit(-1): 0 callbacks to make > LOCATION: proc_exit_prepare, ipc.c:184 > pg_ctl: could not start server > Examine the log output. > Done. > Starting all the datanode masters. > Starting datanode master datanode1. > LOG: redirecting log output to logging collector process > HINT: Future log output will appear in directory "pg_log". > Done. > Starting all the datanode slaves. > Starting datanode slave datanode1. > LOG: redirecting log output to logging collector process > HINT: Future log output will appear in directory "pg_log". > Done. > PGXC monitor all > Running: gtm master > Running: gtm slave > Running: gtm proxy gtm_pxy1 > Running: gtm proxy gtm_pxy2 > Running: coordinator master coord1 > Not running: coordinator master coord2 > Not running: datanode master datanode1 > Running: datanode slave datanode1 > > > My DB server has 32 GB RAM and 260 GB of Hard disk and i am using > pgxc-1.2.1. what would be the optimal memory related postgresql.conf > configuration for this server. > > Anyone has an idea about this issue ? > > -- > Thanks, > Juned Khan > iNextrix Technologies Pvt Ltd. > www.inextrix.com > -- Thanks, Juned Khan iNextrix Technologies Pvt Ltd. www.inextrix.com |
|
From: Juned K. <jkh...@gm...> - 2014-04-14 10:26:16
|
Hi all, Yesterday due some problem datanode slave stopped working on one of my DB server. After figuring out the issue i freed out the space on that server. now almost 50% disk is free on server. the problem is after that incident i am not able start all my pgxc components, now its uncertain some of components starts and sometimes it does not each time when i execute "stop all" and "start all" scenario is different.I am not able to figure out the problem which causing this issue. I have enabled the debug log though and tried to identify the issue and after reviewing the logs it seems memory related issue, i am not sure about this. PGXC start all Start GTM master gtm_ctl: PID file "/home/postgres/pgxc/nodes/gtm/gtm.pid" does not exist Is server running? server starting Start GTM slavegtm_ctl: PID file "/home/postgres/pgxc/nodes/gtm/gtm.pid" does not exist Is server running? server starting Done. Starting all the gtm proxies. Starting gtm proxy gtm_pxy1. Starting gtm proxy gtm_pxy2. gtm_proxy: no process found server starting gtm_proxy: no process found server starting Done. Starting coordinator master. Starting coordinator master coord1 Starting coordinator master coord2 DEBUG: 00000: postgres: PostmasterMain: initial environment dump: LOCATION: PostmasterMain, postmaster.c:962 DEBUG: 00000: ----------------------------------------- LOCATION: PostmasterMain, postmaster.c:964 DEBUG: 00000: MAIL=/var/mail/postgres LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: SSH_CLIENT=41.218.72.115 48992 59696 LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: USER=postgres LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LANGUAGE=en_ZA:en LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: SHLVL=1 LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: HOME=/home/postgres LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: PG_GRANDPARENT_PID=19891 LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LOGNAME=postgres LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: _=/usr/local/bin/pg_ctl LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: PGSYSCONFDIR=/usr/local/pgsql/etc LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LANG=en_ZA.UTF-8 LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: SHELL=/bin/bash LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: PWD=/home/postgres LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: SSH_CONNECTION=41.218.72.115 48992 41.218.72.115 59696 LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: PGDATA=/home/postgres/pgxc/nodes/coord LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LC_COLLATE=en_ZA.UTF-8 LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LC_CTYPE=en_ZA.UTF-8 LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LC_MESSAGES=en_ZA.UTF-8 LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LC_MONETARY=C LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LC_NUMERIC=C LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LC_TIME=C LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: ----------------------------------------- LOCATION: PostmasterMain, postmaster.c:969 DEBUG: 00000: invoking IpcMemoryCreate(size=148193280) LOCATION: CreateSharedMemoryAndSemaphores, ipci.c:149 DEBUG: 00000: SlruScanDirectory invoking callback on pg_notify/0000 LOCATION: SlruScanDirectory, slru.c:1312 DEBUG: 00000: removing file "pg_notify/0000" LOCATION: SlruScanDirCbDeleteAll, slru.c:1277 DEBUG: 00000: max_safe_fds = 984, usable_fds = 1000, already_open = 6 LOCATION: set_max_safe_fds, fd.c:548 LOG: 00000: redirecting log output to logging collector process HINT: Future log output will appear in directory "pg_log". LOCATION: SysLogger_Start, syslogger.c:649 DEBUG: 00000: postgres: PostmasterMain: initial environment dump: LOCATION: PostmasterMain, postmaster.c:962 DEBUG: 00000: ----------------------------------------- LOCATION: PostmasterMain, postmaster.c:964 DEBUG: 00000: MAIL=/var/mail/postgres LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: SSH_CLIENT=41.218.72.115 33169 59696 LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: USER=postgres LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LANGUAGE=en_ZA:en LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: SHLVL=1 LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: HOME=/home/postgres LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: PG_GRANDPARENT_PID=19507 LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LOGNAME=postgres LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: _=/usr/local/bin/pg_ctl LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: PGSYSCONFDIR=/usr/local/pgsql/etc LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LANG=en_ZA.UTF-8 LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: SHELL=/bin/bash LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: PWD=/home/postgres LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: SSH_CONNECTION=41.218.72.115 33169 41.218.72.114 59696 LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: PGDATA=/home/postgres/pgxc/nodes/coord LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LC_COLLATE=en_ZA.UTF-8 LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LC_CTYPE=en_ZA.UTF-8 LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LC_MESSAGES=en_ZA.UTF-8 LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LC_MONETARY=C LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LC_NUMERIC=C LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: LC_TIME=C LOCATION: PostmasterMain, postmaster.c:967 DEBUG: 00000: ----------------------------------------- LOCATION: PostmasterMain, postmaster.c:969 DEBUG: 00000: invoking IpcMemoryCreate(size=148193280) LOCATION: CreateSharedMemoryAndSemaphores, ipci.c:149 DEBUG: 00000: SlruScanDirectory invoking callback on pg_notify/0000 LOCATION: SlruScanDirectory, slru.c:1312 DEBUG: 00000: removing file "pg_notify/0000" LOCATION: SlruScanDirCbDeleteAll, slru.c:1277 DEBUG: 00000: max_safe_fds = 984, usable_fds = 1000, already_open = 6 LOCATION: set_max_safe_fds, fd.c:548 LOG: 00000: redirecting log output to logging collector process HINT: Future log output will appear in directory "pg_log". LOCATION: SysLogger_Start, syslogger.c:649 DEBUG: 00000: logger shutting down LOCATION: SysLoggerMain, syslogger.c:517 DEBUG: 00000: shmem_exit(0): 0 callbacks to make LOCATION: shmem_exit, ipc.c:212 DEBUG: 00000: proc_exit(0): 0 callbacks to make LOCATION: proc_exit_prepare, ipc.c:184 DEBUG: 00000: exit(0) LOCATION: proc_exit, ipc.c:135 DEBUG: 00000: shmem_exit(-1): 0 callbacks to make LOCATION: shmem_exit, ipc.c:212 DEBUG: 00000: proc_exit(-1): 0 callbacks to make LOCATION: proc_exit_prepare, ipc.c:184 pg_ctl: could not start server Examine the log output. Done. Starting all the datanode masters. Starting datanode master datanode1. LOG: redirecting log output to logging collector process HINT: Future log output will appear in directory "pg_log". Done. Starting all the datanode slaves. Starting datanode slave datanode1. LOG: redirecting log output to logging collector process HINT: Future log output will appear in directory "pg_log". Done. PGXC monitor all Running: gtm master Running: gtm slave Running: gtm proxy gtm_pxy1 Running: gtm proxy gtm_pxy2 Running: coordinator master coord1 Not running: coordinator master coord2 Not running: datanode master datanode1 Running: datanode slave datanode1 My DB server has 32 GB RAM and 260 GB of Hard disk and i am using pgxc-1.2.1. what would be the optimal memory related postgresql.conf configuration for this server. Anyone has an idea about this issue ? -- Thanks, Juned Khan iNextrix Technologies Pvt Ltd. www.inextrix.com |
|
From: 鈴木 幸市 <ko...@in...> - 2014-04-14 00:55:44
|
Thank you Aaron for the detailed analysis. As long as the issue is just for XC, we need a fix for it to work correctly regardless the compiler optimization. Did to locate where such wrong estimation takes place? And what compilation option did you use? They are very helpful. Best; --- Koichi Suzuki 2014/04/12 11:40、Aaron Jackson <aja...@re...<mailto:aja...@re...>> のメール： It appears that problem is a compiler optimization issue. I narrowed the issue down to the loop at the end of the ProcArrayRemove method. I'm not entirely sure why, but the compiler generated code that evaluates the test block of the loop improperly. Since changing the compiler options, the problem has been resolved. Aaron ________________________________ From: Aaron Jackson [aja...@re...<mailto:aja...@re...>] Sent: Friday, April 11, 2014 1:07 AM To: pos...@li...<mailto:pos...@li...> Subject: Re: [Postgres-xc-general] failed to find proc - increasing numProcs I forgot to mention that if I injected a context switch (sleep(0) did the trick as did an elog statement) during the test in the ProcArrayRemove, that it no longer failed. Hopefully that will help in understanding the reasons why that may have triggered the ProcArrayRemove to succeed. ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_______________________________________________ Postgres-xc-general mailing list Pos...@li... https://lists.sourceforge.net/lists/listinfo/postgres-xc-general |
|
From: Aaron J. <aja...@re...> - 2014-04-12 02:40:41
|
It appears that problem is a compiler optimization issue. I narrowed the issue down to the loop at the end of the ProcArrayRemove method. I'm not entirely sure why, but the compiler generated code that evaluates the test block of the loop improperly. Since changing the compiler options, the problem has been resolved. Aaron ________________________________ From: Aaron Jackson [aja...@re...] Sent: Friday, April 11, 2014 1:07 AM To: pos...@li... Subject: Re: [Postgres-xc-general] failed to find proc - increasing numProcs I forgot to mention that if I injected a context switch (sleep(0) did the trick as did an elog statement) during the test in the ProcArrayRemove, that it no longer failed. Hopefully that will help in understanding the reasons why that may have triggered the ProcArrayRemove to succeed. |
|
From: Juned K. <jkh...@gm...> - 2014-04-11 07:05:15
|
Thanks to Pavan and Koichi for your inputs. So i think as of now i do not need to worry about this On Fri, Apr 11, 2014 at 12:31 PM, Pavan Deolasee <pav...@gm...>wrote: > On Fri, Apr 11, 2014 at 12:07 PM, Juned Khan <jkh...@gm...> wrote: > >> As of now this fix worked fine for me. is there any side effect of this >> patch ? >> > > IMV there won't be any significant side effect of the patch. pg_dump used > to run in RW mode till we fixed it in 9.3. If it has worked for so many > years, it may work for some more time too :-) Marking pg_dump READ ONLY was > exactly to catch bugs like these. But other than that, I think its OK. > > Thanks, > Pavan > > -- > Pavan Deolasee > http://www.linkedin.com/in/pavandeolasee > -- Thanks, Juned Khan iNextrix Technologies Pvt Ltd. www.inextrix.com |
|
From: Pavan D. <pav...@gm...> - 2014-04-11 07:02:25
|
On Fri, Apr 11, 2014 at 12:07 PM, Juned Khan <jkh...@gm...> wrote: > As of now this fix worked fine for me. is there any side effect of this > patch ? > IMV there won't be any significant side effect of the patch. pg_dump used to run in RW mode till we fixed it in 9.3. If it has worked for so many years, it may work for some more time too :-) Marking pg_dump READ ONLY was exactly to catch bugs like these. But other than that, I think its OK. Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee |
|
From: Koichi S. <koi...@gm...> - 2014-04-11 07:00:56
|
The patch restores the working environment back to those of 1.1 (PG
9.2) so I believe there must not be any side effect. As I wrote,
because XC pg_dump uses nextval() to get sequence value, we have a
side effect that sequence values will be advanced. This is the sam
as in 1.1.
Regards;
---
Koichi Suzuki
2014-04-11 15:37 GMT+09:00 Juned Khan <jkh...@gm...>:
> As of now this fix worked fine for me. is there any side effect of this
> patch ?
>
> And yeah please let me know when this issue gets fixed in main release
> so i can apply patch accordingly.
>
> Regards
>
>
>
> On Fri, Apr 11, 2014 at 11:49 AM, Koichi Suzuki <koi...@gm...>
> wrote:
>>
>> The fix will be okay for the short term basis. At present, sequence
>> is handled by GTM and we need to invoke nextval() to get its value,
>> which advances current sequence value, which may not be comfortable
>> for one usecase. This is the main reason why XC's pg_dump and
>> pg_dumpall do not work in read-only transaction.
>>
>> We need this fix after this.
>>
>> Regards;
>> ---
>> Koichi Suzuki
>>
>>
>> 2014-04-10 15:59 GMT+09:00 Juned Khan <jkh...@gm...>:
>> > Hi Masataka,
>> >
>> > Yeah you are correct, even pg_dumpall is not working.
>> > do you have any idea about how to solve this issue or any
>> > alternative way to take dump ?
>> >
>> >
>> > Regards,
>> >
>> >
>> > On Thu, Apr 10, 2014 at 12:26 PM, Masataka Saito <pg...@gm...>
>> > wrote:
>> >>
>> >> I can't believe pg_dumpall is working.
>> >>
>> >> pg_dumpall uses pg_dump internally to dump each database. pg_dump uses
>> >> nextval() to obtain sequce values in a read only transaction. It's
>> >> invalid operation because nextval() changes a sequce value regardless
>> >> of being read-only transaction.
>> >>
>> >> Regards.
>> >>
>> >> On 9 April 2014 17:43, 鈴木 幸市 <ko...@in...> wrote:
>> >> > Please try pg_dumpall if it works.
>> >> >
>> >> > Regards;
>> >> > ---
>> >> > Koichi Suzuki
>> >> >
>> >> > 2014/04/09 17:31、Juned Khan <jkh...@gm...> のメール：
>> >> >
>> >> > Hi All,
>> >> >
>> >> > recently i have just installed the pgxc-1.2.1 on one of my production
>> >> > server
>> >> > but when i tried to take backup of all data it gave me below errors.
>> >> >
>> >> > PGXC pg_dump mydatabase > mydatabase.sql
>> >> > pg_dump: [archiver (db)] query failed: ERROR: cannot execute
>> >> > nextval()
>> >> > in a
>> >> > read-only transaction
>> >> > pg_dump: [archiver (db)] query was: SELECT
>> >> > pg_catalog.nextval('account_package_id_seq');
>> >> >
>> >> > With some googling i found this
>> >> >
>> >> >
>> >> > http://www.postgresql.org/message-id/4DC...@po...
>> >> >
>> >> > How to solve this issue? even pg_dumpall is working
>> >> >
>> >> > Please suggest.
>> >> >
>> >> > --
>> >> >
>> >> > Thanks,
>> >> > Juned Khan
>> >> > iNextrix Technologies Pvt Ltd.
>> >> > www.inextrix.com
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > Put Bad Developers to Shame
>> >> > Dominate Development with Jenkins Continuous Integration
>> >> > Continuously Automate Build, Test & Deployment
>> >> > Start a new project now. Try Jenkins in the cloud.
>> >> >
>> >> >
>> >> > http://p.sf.net/sfu/13600_Cloudbees_______________________________________________
>> >> > Postgres-xc-general mailing list
>> >> > Pos...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > Put Bad Developers to Shame
>> >> > Dominate Development with Jenkins Continuous Integration
>> >> > Continuously Automate Build, Test & Deployment
>> >> > Start a new project now. Try Jenkins in the cloud.
>> >> > http://p.sf.net/sfu/13600_Cloudbees
>> >> > _______________________________________________
>> >> > Postgres-xc-general mailing list
>> >> > Pos...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>> >> >
>> >
>> >
>> >
>> >
>> > --
>> > Thanks,
>> > Juned Khan
>> > iNextrix Technologies Pvt Ltd.
>> > www.inextrix.com
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Put Bad Developers to Shame
>> > Dominate Development with Jenkins Continuous Integration
>> > Continuously Automate Build, Test & Deployment
>> > Start a new project now. Try Jenkins in the cloud.
>> > http://p.sf.net/sfu/13600_Cloudbees
>> > _______________________________________________
>> > Postgres-xc-general mailing list
>> > Pos...@li...
>> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>> >
>
>
>
>
> --
> Thanks,
> Juned Khan
> iNextrix Technologies Pvt Ltd.
> www.inextrix.com
|
|
From: Juned K. <jkh...@gm...> - 2014-04-11 06:37:40
|
As of now this fix worked fine for me. is there any side effect of this
patch ?
And yeah please let me know when this issue gets fixed in main release
so i can apply patch accordingly.
Regards
On Fri, Apr 11, 2014 at 11:49 AM, Koichi Suzuki <koi...@gm...>wrote:
> The fix will be okay for the short term basis. At present, sequence
> is handled by GTM and we need to invoke nextval() to get its value,
> which advances current sequence value, which may not be comfortable
> for one usecase. This is the main reason why XC's pg_dump and
> pg_dumpall do not work in read-only transaction.
>
> We need this fix after this.
>
> Regards;
> ---
> Koichi Suzuki
>
>
> 2014-04-10 15:59 GMT+09:00 Juned Khan <jkh...@gm...>:
> > Hi Masataka,
> >
> > Yeah you are correct, even pg_dumpall is not working.
> > do you have any idea about how to solve this issue or any
> > alternative way to take dump ?
> >
> >
> > Regards,
> >
> >
> > On Thu, Apr 10, 2014 at 12:26 PM, Masataka Saito <pg...@gm...>
> wrote:
> >>
> >> I can't believe pg_dumpall is working.
> >>
> >> pg_dumpall uses pg_dump internally to dump each database. pg_dump uses
> >> nextval() to obtain sequce values in a read only transaction. It's
> >> invalid operation because nextval() changes a sequce value regardless
> >> of being read-only transaction.
> >>
> >> Regards.
> >>
> >> On 9 April 2014 17:43, 鈴木 幸市 <ko...@in...> wrote:
> >> > Please try pg_dumpall if it works.
> >> >
> >> > Regards;
> >> > ---
> >> > Koichi Suzuki
> >> >
> >> > 2014/04/09 17:31、Juned Khan <jkh...@gm...> のメール：
> >> >
> >> > Hi All,
> >> >
> >> > recently i have just installed the pgxc-1.2.1 on one of my production
> >> > server
> >> > but when i tried to take backup of all data it gave me below errors.
> >> >
> >> > PGXC pg_dump mydatabase > mydatabase.sql
> >> > pg_dump: [archiver (db)] query failed: ERROR: cannot execute
> nextval()
> >> > in a
> >> > read-only transaction
> >> > pg_dump: [archiver (db)] query was: SELECT
> >> > pg_catalog.nextval('account_package_id_seq');
> >> >
> >> > With some googling i found this
> >> >
> >> >
> http://www.postgresql.org/message-id/4DC...@po...
> >> >
> >> > How to solve this issue? even pg_dumpall is working
> >> >
> >> > Please suggest.
> >> >
> >> > --
> >> >
> >> > Thanks,
> >> > Juned Khan
> >> > iNextrix Technologies Pvt Ltd.
> >> > www.inextrix.com
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > Put Bad Developers to Shame
> >> > Dominate Development with Jenkins Continuous Integration
> >> > Continuously Automate Build, Test & Deployment
> >> > Start a new project now. Try Jenkins in the cloud.
> >> >
> >> >
> http://p.sf.net/sfu/13600_Cloudbees_______________________________________________
> >> > Postgres-xc-general mailing list
> >> > Pos...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
> >> >
> >> >
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > Put Bad Developers to Shame
> >> > Dominate Development with Jenkins Continuous Integration
> >> > Continuously Automate Build, Test & Deployment
> >> > Start a new project now. Try Jenkins in the cloud.
> >> > http://p.sf.net/sfu/13600_Cloudbees
> >> > _______________________________________________
> >> > Postgres-xc-general mailing list
> >> > Pos...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
> >> >
> >
> >
> >
> >
> > --
> > Thanks,
> > Juned Khan
> > iNextrix Technologies Pvt Ltd.
> > www.inextrix.com
> >
> >
> ------------------------------------------------------------------------------
> > Put Bad Developers to Shame
> > Dominate Development with Jenkins Continuous Integration
> > Continuously Automate Build, Test & Deployment
> > Start a new project now. Try Jenkins in the cloud.
> > http://p.sf.net/sfu/13600_Cloudbees
> > _______________________________________________
> > Postgres-xc-general mailing list
> > Pos...@li...
> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
> >
>
--
Thanks,
Juned Khan
iNextrix Technologies Pvt Ltd.
www.inextrix.com
|
|
From: Koichi S. <koi...@gm...> - 2014-04-11 06:19:33
|
The fix will be okay for the short term basis. At present, sequence
is handled by GTM and we need to invoke nextval() to get its value,
which advances current sequence value, which may not be comfortable
for one usecase. This is the main reason why XC's pg_dump and
pg_dumpall do not work in read-only transaction.
We need this fix after this.
Regards;
---
Koichi Suzuki
2014-04-10 15:59 GMT+09:00 Juned Khan <jkh...@gm...>:
> Hi Masataka,
>
> Yeah you are correct, even pg_dumpall is not working.
> do you have any idea about how to solve this issue or any
> alternative way to take dump ?
>
>
> Regards,
>
>
> On Thu, Apr 10, 2014 at 12:26 PM, Masataka Saito <pg...@gm...> wrote:
>>
>> I can't believe pg_dumpall is working.
>>
>> pg_dumpall uses pg_dump internally to dump each database. pg_dump uses
>> nextval() to obtain sequce values in a read only transaction. It's
>> invalid operation because nextval() changes a sequce value regardless
>> of being read-only transaction.
>>
>> Regards.
>>
>> On 9 April 2014 17:43, 鈴木 幸市 <ko...@in...> wrote:
>> > Please try pg_dumpall if it works.
>> >
>> > Regards;
>> > ---
>> > Koichi Suzuki
>> >
>> > 2014/04/09 17:31、Juned Khan <jkh...@gm...> のメール：
>> >
>> > Hi All,
>> >
>> > recently i have just installed the pgxc-1.2.1 on one of my production
>> > server
>> > but when i tried to take backup of all data it gave me below errors.
>> >
>> > PGXC pg_dump mydatabase > mydatabase.sql
>> > pg_dump: [archiver (db)] query failed: ERROR: cannot execute nextval()
>> > in a
>> > read-only transaction
>> > pg_dump: [archiver (db)] query was: SELECT
>> > pg_catalog.nextval('account_package_id_seq');
>> >
>> > With some googling i found this
>> >
>> > http://www.postgresql.org/message-id/4DC...@po...
>> >
>> > How to solve this issue? even pg_dumpall is working
>> >
>> > Please suggest.
>> >
>> > --
>> >
>> > Thanks,
>> > Juned Khan
>> > iNextrix Technologies Pvt Ltd.
>> > www.inextrix.com
>> >
>> > ------------------------------------------------------------------------------
>> > Put Bad Developers to Shame
>> > Dominate Development with Jenkins Continuous Integration
>> > Continuously Automate Build, Test & Deployment
>> > Start a new project now. Try Jenkins in the cloud.
>> >
>> > http://p.sf.net/sfu/13600_Cloudbees_______________________________________________
>> > Postgres-xc-general mailing list
>> > Pos...@li...
>> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Put Bad Developers to Shame
>> > Dominate Development with Jenkins Continuous Integration
>> > Continuously Automate Build, Test & Deployment
>> > Start a new project now. Try Jenkins in the cloud.
>> > http://p.sf.net/sfu/13600_Cloudbees
>> > _______________________________________________
>> > Postgres-xc-general mailing list
>> > Pos...@li...
>> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>> >
>
>
>
>
> --
> Thanks,
> Juned Khan
> iNextrix Technologies Pvt Ltd.
> www.inextrix.com
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>
|
|
From: Aaron J. <aja...@re...> - 2014-04-11 06:08:16
|
I forgot to mention that if I injected a context switch (sleep(0) did the trick as did an elog statement) during the test in the ProcArrayRemove, that it no longer failed. Hopefully that will help in understanding the reasons why that may have triggered the ProcArrayRemove to succeed. |
|
From: Aaron J. <aja...@re...> - 2014-04-11 06:04:47
|
During my initialization process, I make several calls to psql in a row. What I notice is that if I call psql often enough, I cause the coordinator to exhaust the # of clients in can support. It shows up in the coordinator log as "PANIC: sorry, too many clients already" I took a deeper look into what was happening and I believe, the problem is that during one of the invocations to psql, the prepared procedures allocate themselves in the procarray improperly. ProcArrayRemove then fails to remove the procedure and the number of processes stays one client too high artificially. Once this happens enough, the clients in the procarray are exhausted and the panic occurs. The initial startup of the server allocated a total of 15 slots in the procarray - with one being released leaving an initial allocation of 14 processes in the array. Process 31098 (a coordinator) starts in response to an invocation of psql. It's assigned proc 0x7ff2ebe96c00 and adds that to the array via InitProcessPhase2. A prepared transaction is created and proc 0x7ff2ebe99ce0 is subsequently added to the proc array. I watched very carefully and did not see anywhere that process 31098 did anything to clear that proc from the proc array. ProcArrayRemove is called and does *not* find 0x7ff2ebe99ce0. This now leaves numProcs too large by +1 - eventually, we run out of slots. Oddly enough, right after the failure, we called MarkAsPrepared again with the same proc. Again it failed and we are +2. The process then terminated making me believe it corresponded to the "DROP TABLE" and "CREATE TABLE" that I had in one of my initialization files. I'm clearly not familiar with how GlobalTransactions are associated with a Proc so I will continue to research this. Is it possible for one of the other participants to have removed the Proc from the ProcArray? Aaron |
|
From: 鈴木 幸市 <ko...@in...> - 2014-04-10 10:58:36
|
Thank you Pavan for the quick work.
I’m still wondering if we should rewind transaction to read/write as in the case of 9.2. In the case of PG, pg_dump simply reads from the catalog. In our case, it is in GTM so we must use nextval, which needs transaction read/write.
To do this, we need one more function for sequence to get current value as read-only operation, which may take a bit longer.
Any more inputs?
---
Koichi Suzuki
2014/04/10 16:11、Pavan Deolasee <pav...@gm...<mailto:pav...@gm...>> のメール：
On Thu, Apr 10, 2014 at 12:29 PM, Juned Khan <jkh...@gm...<mailto:jkh...@gm...>> wrote:
Hi Masataka,
Yeah you are correct, even pg_dumpall is not working.
This code in pg_dump.c seems to be source of the bug. Sorry, I don't have time right now to study it further and suggest a fix. As a temporary work around so that you can make progress, you can try compiling with the attached patch. This bug must be fixed in a saner way in the XC core though.
/*
* In Postgres-XC it is possible that the current value of a
* sequence cached on each node is different as several sessions
* might use the sequence on different nodes. So what we do here
* to get a consistent dump is to get the next value of sequence.
* This insures that sequence value is unique as nextval is directly
* obtained from GTM.
*/
resetPQExpBuffer(query);
appendPQExpBuffer(query, "SELECT pg_catalog.nextval(");
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
<no-read-only-pg-dump.patch>------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_______________________________________________
Postgres-xc-general mailing list
Pos...@li...
https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
|
|
From: Juned K. <jkh...@gm...> - 2014-04-10 08:10:08
|
Hi Pavan,
Thanks a lot for your patch. its worked ;)
just tested out in local system, now just need to
apply it on server.
Regards,
On Thu, Apr 10, 2014 at 12:41 PM, Pavan Deolasee
<pav...@gm...>wrote:
>
> On Thu, Apr 10, 2014 at 12:29 PM, Juned Khan <jkh...@gm...> wrote:
>
>> Hi Masataka,
>>
>> Yeah you are correct, even pg_dumpall is not working.
>>
>
> This code in pg_dump.c seems to be source of the bug. Sorry, I don't have
> time right now to study it further and suggest a fix. As a temporary work
> around so that you can make progress, you can try compiling with the
> attached patch. This bug must be fixed in a saner way in the XC core though.
>
> /*
>
>
> * In Postgres-XC it is possible that the current value of a
>
>
> * sequence cached on each node is different as several sessions
>
>
> * might use the sequence on different nodes. So what we do here
>
>
> * to get a consistent dump is to get the next value of sequence.
>
>
> * This insures that sequence value is unique as nextval is directly
>
>
> * obtained from GTM.
>
>
> */
>
> resetPQExpBuffer(query);
>
> appendPQExpBuffer(query, "SELECT pg_catalog.nextval(");
>
> Thanks,
> Pavan
>
> --
> Pavan Deolasee
> http://www.linkedin.com/in/pavandeolasee
>
--
Thanks,
Juned Khan
iNextrix Technologies Pvt Ltd.
www.inextrix.com
|
|
From: Juned K. <jkh...@gm...> - 2014-04-10 06:59:27
|
Hi Masataka,
Yeah you are correct, even pg_dumpall is not working.
do you have any idea about how to solve this issue or any
alternative way to take dump ?
Regards,
On Thu, Apr 10, 2014 at 12:26 PM, Masataka Saito <pg...@gm...> wrote:
> I can't believe pg_dumpall is working.
>
> pg_dumpall uses pg_dump internally to dump each database. pg_dump uses
> nextval() to obtain sequce values in a read only transaction. It's
> invalid operation because nextval() changes a sequce value regardless
> of being read-only transaction.
>
> Regards.
>
> On 9 April 2014 17:43, 鈴木 幸市 <ko...@in...> wrote:
> > Please try pg_dumpall if it works.
> >
> > Regards;
> > ---
> > Koichi Suzuki
> >
> > 2014/04/09 17:31、Juned Khan <jkh...@gm...> のメール：
> >
> > Hi All,
> >
> > recently i have just installed the pgxc-1.2.1 on one of my production
> server
> > but when i tried to take backup of all data it gave me below errors.
> >
> > PGXC pg_dump mydatabase > mydatabase.sql
> > pg_dump: [archiver (db)] query failed: ERROR: cannot execute nextval()
> in a
> > read-only transaction
> > pg_dump: [archiver (db)] query was: SELECT
> > pg_catalog.nextval('account_package_id_seq');
> >
> > With some googling i found this
> >
> http://www.postgresql.org/message-id/4DC...@po...
> >
> > How to solve this issue? even pg_dumpall is working
> >
> > Please suggest.
> >
> > --
> >
> > Thanks,
> > Juned Khan
> > iNextrix Technologies Pvt Ltd.
> > www.inextrix.com
> >
> ------------------------------------------------------------------------------
> > Put Bad Developers to Shame
> > Dominate Development with Jenkins Continuous Integration
> > Continuously Automate Build, Test & Deployment
> > Start a new project now. Try Jenkins in the cloud.
> >
> http://p.sf.net/sfu/13600_Cloudbees_______________________________________________
> > Postgres-xc-general mailing list
> > Pos...@li...
> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Put Bad Developers to Shame
> > Dominate Development with Jenkins Continuous Integration
> > Continuously Automate Build, Test & Deployment
> > Start a new project now. Try Jenkins in the cloud.
> > http://p.sf.net/sfu/13600_Cloudbees
> > _______________________________________________
> > Postgres-xc-general mailing list
> > Pos...@li...
> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
> >
>
--
Thanks,
Juned Khan
iNextrix Technologies Pvt Ltd.
www.inextrix.com
|
|
From: Masataka S. <pg...@gm...> - 2014-04-10 06:56:22
|
I can't believe pg_dumpall is working.
pg_dumpall uses pg_dump internally to dump each database. pg_dump uses
nextval() to obtain sequce values in a read only transaction. It's
invalid operation because nextval() changes a sequce value regardless
of being read-only transaction.
Regards.
On 9 April 2014 17:43, 鈴木 幸市 <ko...@in...> wrote:
> Please try pg_dumpall if it works.
>
> Regards;
> ---
> Koichi Suzuki
>
> 2014/04/09 17:31、Juned Khan <jkh...@gm...> のメール：
>
> Hi All,
>
> recently i have just installed the pgxc-1.2.1 on one of my production server
> but when i tried to take backup of all data it gave me below errors.
>
> PGXC pg_dump mydatabase > mydatabase.sql
> pg_dump: [archiver (db)] query failed: ERROR: cannot execute nextval() in a
> read-only transaction
> pg_dump: [archiver (db)] query was: SELECT
> pg_catalog.nextval('account_package_id_seq');
>
> With some googling i found this
> http://www.postgresql.org/message-id/4DC...@po...
>
> How to solve this issue? even pg_dumpall is working
>
> Please suggest.
>
> --
>
> Thanks,
> Juned Khan
> iNextrix Technologies Pvt Ltd.
> www.inextrix.com
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>
|
|
From: Aaron J. <aja...@re...> - 2014-04-10 04:01:13
|
Actually, I think this may have cleared up the primary issue. Thank you ________________________________ From: Aaron Jackson [aja...@re...] Sent: Wednesday, April 09, 2014 10:36 AM To: pos...@li... Subject: Re: [Postgres-xc-general] Newbie Question So, I upgraded to 1.2.1 and rebuilt the databases from scratch to ensure there were no residual issues from a previous install. Again, the configuration is coord_1, data_node_1, data_node_2 and gtm on a single instance host. After rebuilding with initdb and initgtm; and restarting the server, I have clean logs with just a notification that the databse is ready to accept connections and autovacuum launcher starting. I connected to the coordinator and created two data nodes - no problems. Then I created the database as follows: CREATE DATABASE demo; This comes back from the coordinator successfully. However, the logs appear to have generated the following errors in the sequence shown. ==> data_node_1/pg_log/postgresql-2014-04-09_152532.log <== LOG: failed to find proc 0x7fabf3d9d7c0 in ProcArray STATEMENT: COMMIT PREPARED 'T10008' ==> data_node_2/pg_log/postgresql-2014-04-09_152532.log <== LOG: failed to find proc 0x7f7aa44ac7c0 in ProcArray STATEMENT: COMMIT PREPARED 'T10008' ==> data_coord/pg_log/postgresql-2014-04-09_152532.log <== LOG: failed to find proc 0x7fadfaa18240 in ProcArray STATEMENT: CREATE DATABASE demo ==> data_node_2/pg_log/postgresql-2014-04-09_152532.log <== LOG: failed to find proc 0x7f7aa4499700 in ProcArray ==> data_node_1/pg_log/postgresql-2014-04-09_152532.log <== LOG: failed to find proc 0x7fabf3d8a700 in ProcArray LOG: failed to find proc 0x7fabf3d8a700 in ProcArray As with before, subsequent items eventually fail and I have to believe it's related to this failure during database construction. I can't see anything special in the configuration as they seem incredibly simple, but clearly there is something I've overlooked here. Aaron ________________________________ From: 鈴木 幸市 [ko...@in...] Sent: Tuesday, April 08, 2014 8:30 PM To: Aaron Jackson Cc: pos...@li... Subject: Re: [Postgres-xc-general] Newbie Question 1.2.1 beta has an issue in adding node. 1.2.1 fixes this problem so please simply replace the binary to 1.2.1 and try. Because of the error, there could be some inconsistency among datanodes. So if possible, you can dump all the data and restore them. Regards; --- Koichi Suzuki 2014/04/09 4:47、Aaron Jackson <aja...@re...<mailto:aja...@re...>> のメール： My apologies if this seems far too simple. I'm looking at Postgres-XC 1.2beta to build out a datastore. I've been through the documentation several times and I built out what I believed was a reasonable first step, with a GTM, single coordinator and two data nodes on an amazon i2 instance. I start all four instances (gtm, coord, data_node_1 and data_node_2), add the nodes to the coordinator and build my schema - to this point, everything is scripted. At this point, I already see failures to find a procs in the database logs. The failures match transactions that are coming in and are as follows: STATEMENT: COMMIT PREPARED 'T10010' LOG: failed to find proc 0x7f6bcbc0a7c0 in ProcArray STATEMENT: COMMIT PREPARED 'T10012' LOG: failed to find proc 0x7f6bcbc0a7c0 in ProcArray STATEMENT: COMMIT PREPARED 'T10014' LOG: failed to find proc 0x7f6bcbc0a7c0 in ProcArray STATEMENT: COMMIT PREPARED 'T10016' As these appear to be mostly benign (I'm sure they're not). I begin building the tables in my schema and this is usually about the point I begin to experience a breakdown, usually resulting with the coordinator reporting that the database is in recovery mode. There is nothing special about the DDL - for example, it can be as simple as the following: DROP TABLE IF EXISTS Foo.Bar; CREATE TABLE Foo.Bar( Foo int NOT NULL, Bar smallint NOT NULL ) DISTRIBUTE HASH( Foo ); The first message to come back is "PANIC: sorry, too many clients already" - followed shortly thereafter by "FATAL: the database system is in recovery mode" The configurations were built using initdb or initgtm directly. gtm/gtm.conf ---------------------------------------- nodename = 'one' port = 6666 data_coord/postgresql.conf ---------------------------------------- max_connections = 100 shared_buffers = 128MB max_prepared_transactions = 20 log_destination = 'stderr' logging_collector = on log_directory = 'pg_log' log_timezone = 'UTC' datestyle = 'iso, mdy' timezone = 'UTC' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english' min_pool_size = 20 max_pool_size = 200 pgxc_node_name = 'coord_1' data_node_1/postgresql.conf ---------------------------------------- port = 15432 max_connections = 100 shared_buffers = 128MB max_prepared_transactions = 100 log_destination = 'stderr' logging_collector = on log_directory = 'pg_log' log_timezone = 'UTC' datestyle = 'iso, mdy' timezone = 'UTC' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english' min_pool_size = 1 max_pool_size = 100 pgxc_node_name = 'node_1' data_node_2/postgresql.conf ---------------------------------------- port = 15433 max_connections = 100 shared_buffers = 128MB max_prepared_transactions = 100 log_destination = 'stderr' logging_collector = on log_directory = 'pg_log' log_timezone = 'UTC' datestyle = 'iso, mdy' timezone = 'UTC' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english' min_pool_size = 1 max_pool_size = 100 pgxc_node_name = 'node_2' Any insight would be helpful in understanding what I've done wrong here. Thank you, Aaron ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_______________________________________________ Postgres-xc-general mailing list Pos...@li... https://lists.sourceforge.net/lists/listinfo/postgres-xc-general |
|
From: Aaron J. <aja...@re...> - 2014-04-09 15:53:00
|
So, I upgraded to 1.2.1 and rebuilt the databases from scratch to ensure there were no residual issues from a previous install. Again, the configuration is coord_1, data_node_1, data_node_2 and gtm on a single instance host. After rebuilding with initdb and initgtm; and restarting the server, I have clean logs with just a notification that the databse is ready to accept connections and autovacuum launcher starting. I connected to the coordinator and created two data nodes - no problems. Then I created the database as follows: CREATE DATABASE demo; This comes back from the coordinator successfully. However, the logs appear to have generated the following errors in the sequence shown. ==> data_node_1/pg_log/postgresql-2014-04-09_152532.log <== LOG: failed to find proc 0x7fabf3d9d7c0 in ProcArray STATEMENT: COMMIT PREPARED 'T10008' ==> data_node_2/pg_log/postgresql-2014-04-09_152532.log <== LOG: failed to find proc 0x7f7aa44ac7c0 in ProcArray STATEMENT: COMMIT PREPARED 'T10008' ==> data_coord/pg_log/postgresql-2014-04-09_152532.log <== LOG: failed to find proc 0x7fadfaa18240 in ProcArray STATEMENT: CREATE DATABASE demo ==> data_node_2/pg_log/postgresql-2014-04-09_152532.log <== LOG: failed to find proc 0x7f7aa4499700 in ProcArray ==> data_node_1/pg_log/postgresql-2014-04-09_152532.log <== LOG: failed to find proc 0x7fabf3d8a700 in ProcArray LOG: failed to find proc 0x7fabf3d8a700 in ProcArray As with before, subsequent items eventually fail and I have to believe it's related to this failure during database construction. I can't see anything special in the configuration as they seem incredibly simple, but clearly there is something I've overlooked here. Aaron ________________________________ From: 鈴木 幸市 [ko...@in...] Sent: Tuesday, April 08, 2014 8:30 PM To: Aaron Jackson Cc: pos...@li... Subject: Re: [Postgres-xc-general] Newbie Question 1.2.1 beta has an issue in adding node. 1.2.1 fixes this problem so please simply replace the binary to 1.2.1 and try. Because of the error, there could be some inconsistency among datanodes. So if possible, you can dump all the data and restore them. Regards; --- Koichi Suzuki 2014/04/09 4:47、Aaron Jackson <aja...@re...<mailto:aja...@re...>> のメール： My apologies if this seems far too simple. I'm looking at Postgres-XC 1.2beta to build out a datastore. I've been through the documentation several times and I built out what I believed was a reasonable first step, with a GTM, single coordinator and two data nodes on an amazon i2 instance. I start all four instances (gtm, coord, data_node_1 and data_node_2), add the nodes to the coordinator and build my schema - to this point, everything is scripted. At this point, I already see failures to find a procs in the database logs. The failures match transactions that are coming in and are as follows: STATEMENT: COMMIT PREPARED 'T10010' LOG: failed to find proc 0x7f6bcbc0a7c0 in ProcArray STATEMENT: COMMIT PREPARED 'T10012' LOG: failed to find proc 0x7f6bcbc0a7c0 in ProcArray STATEMENT: COMMIT PREPARED 'T10014' LOG: failed to find proc 0x7f6bcbc0a7c0 in ProcArray STATEMENT: COMMIT PREPARED 'T10016' As these appear to be mostly benign (I'm sure they're not). I begin building the tables in my schema and this is usually about the point I begin to experience a breakdown, usually resulting with the coordinator reporting that the database is in recovery mode. There is nothing special about the DDL - for example, it can be as simple as the following: DROP TABLE IF EXISTS Foo.Bar; CREATE TABLE Foo.Bar( Foo int NOT NULL, Bar smallint NOT NULL ) DISTRIBUTE HASH( Foo ); The first message to come back is "PANIC: sorry, too many clients already" - followed shortly thereafter by "FATAL: the database system is in recovery mode" The configurations were built using initdb or initgtm directly. gtm/gtm.conf ---------------------------------------- nodename = 'one' port = 6666 data_coord/postgresql.conf ---------------------------------------- max_connections = 100 shared_buffers = 128MB max_prepared_transactions = 20 log_destination = 'stderr' logging_collector = on log_directory = 'pg_log' log_timezone = 'UTC' datestyle = 'iso, mdy' timezone = 'UTC' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english' min_pool_size = 20 max_pool_size = 200 pgxc_node_name = 'coord_1' data_node_1/postgresql.conf ---------------------------------------- port = 15432 max_connections = 100 shared_buffers = 128MB max_prepared_transactions = 100 log_destination = 'stderr' logging_collector = on log_directory = 'pg_log' log_timezone = 'UTC' datestyle = 'iso, mdy' timezone = 'UTC' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english' min_pool_size = 1 max_pool_size = 100 pgxc_node_name = 'node_1' data_node_2/postgresql.conf ---------------------------------------- port = 15433 max_connections = 100 shared_buffers = 128MB max_prepared_transactions = 100 log_destination = 'stderr' logging_collector = on log_directory = 'pg_log' log_timezone = 'UTC' datestyle = 'iso, mdy' timezone = 'UTC' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english' min_pool_size = 1 max_pool_size = 100 pgxc_node_name = 'node_2' Any insight would be helpful in understanding what I've done wrong here. Thank you, Aaron ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_______________________________________________ Postgres-xc-general mailing list Pos...@li... https://lists.sourceforge.net/lists/listinfo/postgres-xc-general |
|
From: 鈴木 幸市 <ko...@in...> - 2014-04-09 08:43:23
|
Please try pg_dumpall if it works.
Regards;
---
Koichi Suzuki
2014/04/09 17:31、Juned Khan <jkh...@gm...<mailto:jkh...@gm...>> のメール：
Hi All,
recently i have just installed the pgxc-1.2.1 on one of my production server
but when i tried to take backup of all data it gave me below errors.
PGXC pg_dump mydatabase > mydatabase.sql
pg_dump: [archiver (db)] query failed: ERROR: cannot execute nextval() in a read-only transaction
pg_dump: [archiver (db)] query was: SELECT pg_catalog.nextval('account_package_id_seq');
With some googling i found this
http://www.postgresql.org/message-id/4DC...@po...
How to solve this issue? even pg_dumpall is working
Please suggest.
--
Thanks,
Juned Khan
iNextrix Technologies Pvt Ltd.
www.inextrix.com<http://www.inextrix.com/>
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_______________________________________________
Postgres-xc-general mailing list
Pos...@li...
https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
|
|
From: Juned K. <jkh...@gm...> - 2014-04-09 08:31:46
|
Hi All,
recently i have just installed the pgxc-1.2.1 on one of my production server
but when i tried to take backup of all data it gave me below errors.
PGXC pg_dump mydatabase > mydatabase.sql
pg_dump: [archiver (db)] query failed: ERROR: cannot execute nextval() in
a read-only transaction
pg_dump: [archiver (db)] query was: SELECT
pg_catalog.nextval('account_package_id_seq');
With some googling i found this
http://www.postgresql.org/message-id/4DC...@po...
How to solve this issue? even pg_dumpall is working
Please suggest.
--
Thanks,
Juned Khan
iNextrix Technologies Pvt Ltd.
www.inextrix.com
|
|
From: 鈴木 幸市 <ko...@in...> - 2014-04-09 01:30:41
|
1.2.1 beta has an issue in adding node. 1.2.1 fixes this problem so please simply replace the binary to 1.2.1 and try. Because of the error, there could be some inconsistency among datanodes. So if possible, you can dump all the data and restore them. Regards; --- Koichi Suzuki 2014/04/09 4:47、Aaron Jackson <aja...@re...<mailto:aja...@re...>> のメール： My apologies if this seems far too simple. I'm looking at Postgres-XC 1.2beta to build out a datastore. I've been through the documentation several times and I built out what I believed was a reasonable first step, with a GTM, single coordinator and two data nodes on an amazon i2 instance. I start all four instances (gtm, coord, data_node_1 and data_node_2), add the nodes to the coordinator and build my schema - to this point, everything is scripted. At this point, I already see failures to find a procs in the database logs. The failures match transactions that are coming in and are as follows: STATEMENT: COMMIT PREPARED 'T10010' LOG: failed to find proc 0x7f6bcbc0a7c0 in ProcArray STATEMENT: COMMIT PREPARED 'T10012' LOG: failed to find proc 0x7f6bcbc0a7c0 in ProcArray STATEMENT: COMMIT PREPARED 'T10014' LOG: failed to find proc 0x7f6bcbc0a7c0 in ProcArray STATEMENT: COMMIT PREPARED 'T10016' As these appear to be mostly benign (I'm sure they're not). I begin building the tables in my schema and this is usually about the point I begin to experience a breakdown, usually resulting with the coordinator reporting that the database is in recovery mode. There is nothing special about the DDL - for example, it can be as simple as the following: DROP TABLE IF EXISTS Foo.Bar; CREATE TABLE Foo.Bar( Foo int NOT NULL, Bar smallint NOT NULL ) DISTRIBUTE HASH( Foo ); The first message to come back is "PANIC: sorry, too many clients already" - followed shortly thereafter by "FATAL: the database system is in recovery mode" The configurations were built using initdb or initgtm directly. gtm/gtm.conf ---------------------------------------- nodename = 'one' port = 6666 data_coord/postgresql.conf ---------------------------------------- max_connections = 100 shared_buffers = 128MB max_prepared_transactions = 20 log_destination = 'stderr' logging_collector = on log_directory = 'pg_log' log_timezone = 'UTC' datestyle = 'iso, mdy' timezone = 'UTC' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english' min_pool_size = 20 max_pool_size = 200 pgxc_node_name = 'coord_1' data_node_1/postgresql.conf ---------------------------------------- port = 15432 max_connections = 100 shared_buffers = 128MB max_prepared_transactions = 100 log_destination = 'stderr' logging_collector = on log_directory = 'pg_log' log_timezone = 'UTC' datestyle = 'iso, mdy' timezone = 'UTC' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english' min_pool_size = 1 max_pool_size = 100 pgxc_node_name = 'node_1' data_node_2/postgresql.conf ---------------------------------------- port = 15433 max_connections = 100 shared_buffers = 128MB max_prepared_transactions = 100 log_destination = 'stderr' logging_collector = on log_directory = 'pg_log' log_timezone = 'UTC' datestyle = 'iso, mdy' timezone = 'UTC' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english' min_pool_size = 1 max_pool_size = 100 pgxc_node_name = 'node_2' Any insight would be helpful in understanding what I've done wrong here. Thank you, Aaron ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_______________________________________________ Postgres-xc-general mailing list Pos...@li... https://lists.sourceforge.net/lists/listinfo/postgres-xc-general |
|
From: 鈴木 幸市 <ko...@in...> - 2014-04-09 01:27:34
|
Could you let me know what release you used. I suppose 1.2.1 and 1.1.1 has this fix. Also let me know how you dropped node, manually or by pgxc_ctl? --- Koichi Suzuki 2014/04/09 1:46、Sergio Sinuco <ser...@da...<mailto:ser...@da...>> のメール： Hi. I decided to modify my configuration like this: Node A: 1 gtm master Node B: 1 gtm_proxy, 1 coordinator master, 1 coordinator slave (for node C coordinator), 1 datanode master, 1 datanode slave (for node C data node) Node C: 1 gtm_proxy, 1 coordinator master, 1 coordinator slave (for node B coordinator), 1 datanode master, 1 datanode slave (for node B data node) Node D: 1 gtm slave I added following lines in postgresql.conf of each data node slave. pgxc_ctl script didn't add them. archive_mode = off archive_command = '' max_wal_senders = 0 wal_level = minimal In normal operation, everything worked fine. Fist I killed data node master in Node B, I promoted corresponding data node slave to master with pgxc_ctl. I got the following error: ERROR: PGXC node datanode1: two nodes cannot be primary pgxc_pool_reload ------------------ t (1 row) ERROR: PGXC node datanode1: two nodes cannot be primary pgxc_pool_reload ------------------ t (1 row) In both master coordinators, I queried pgxc_node and the failed datanode still pointed to node B. I had to execute ALTER NODE for change host and primary property. After that, everything worked fine. Then, I killed coordinator master in Node B, I promoted corresponding coordinator slave to master. I got the following results: ALTER NODE pgxc_pool_reload ------------------ t (1 row) ERROR: Failed to get pooled connections CONTEXT: SQL statement "EXECUTE DIRECT ON (coord1) 'SELECT pg_catalog.pg_try_advisory_xact_lock_shared(65535, 0)'" pgxc_pool_reload ------------------ t (1 row) So in new master coordinator, when I queried pgxc_node the failed coordinator pointed correctly to node C. But in the original master coordinator of node C, when I queried pgxc_node the failed coordinator pointed to node B. In this coordinator I tried to modify failed coordinator with ALTER NODE but I got the same error Failed to get pooled connections. Finally when I execute ALTER TALBE … DELETE NODE for a table, in the new master coordinator it executed ok. But in the original master coordinator of node C I got the same error Failed to get pooled connections. Is this behaviour normal? What can i do? 2014-04-02 23:19 GMT-05:00 鈴木 幸市 <ko...@in...<mailto:ko...@in...>>: Before removing a datanode, you should drop the datanode from tables before you drop the datanode. You can do this with ALTER TALBE … DELETE NODE as seen in http://postgres-xc.sourceforge.net/docs/1_1/sql-altertable.html. This will extract all the rows from the node and redistribute them (as well as others) to the new set of nodes. List of the nodes where a table is distributed/replicated in pgxc_class. Regards; --- Koichi Suzuki 2014/04/02 15:06、Sergio Sinuco <ser...@da...<mailto:ser...@da...>> のメール： I use pgxc_ctl. My configuration is: Node A: 1 gtm master Node B: 1 gtm_proxy, 1 coordinator, 1 datanode Node C: 1 gtm_proxy, 1 coordinator, 1 datanode Node D: 1 gtm slave First I stopped coordinator and data node from Node C. Then I executed pgxc_ctl remove datanode.... and pgxc_ctl remove coordinator... were ok. But I got "Failed to get pooled connections" message when I tried an insert or update in Node B. I also ran pgxc_pool_reload and restarted the cluster. If I run "SELECT * FROM pgxc_node" in Node B I only have one coordinator and one data node. The inserts and update commands was ran in a DISTRIBUTE BY REPLICATION table. 2014-04-02 0:32 GMT-05:00 鈴木 幸市 <ko...@in...<mailto:ko...@in...>>: Did you change your cluster configuration? Are you using pgxc_ctl or doing configuration/operation manually? They help to see what’s going on. Thank you; --- Koichi Suzuki 2014/04/02 14:02、Sergio Sinuco <ser...@da...<mailto:ser...@da...>> のメール： Hi. I dropped a coordinator node and a data node from a cluster, but when i try to make an insert or update I have a "Failed to get pooled connections" message. I executed pgxc_pool_reload() but it didn't work. What can I do? I use pgxc 1.1. -- Sergio E. Sinuco Leon Arquitecto de soluciones Datatraffic S.A.S. Móvil: (57) 310 884 26 50 Fijo (+571) 7426160 Ext 115<tel:%28%2B571%29%207426160%20Ext%20115> Calle 93 # 15-27 Ofc. 502 Calle 29 # 6 - 94 Ofc. 601 Bogotá, Colombia. www.datatraffic.com.co<http://www.datatraffic.com.co/> ------------------------------------------------------------------------------ _______________________________________________ Postgres-xc-general mailing list Pos...@li...<mailto:Pos...@li...> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general -- Sergio E. Sinuco Leon Arquitecto de soluciones Datatraffic S.A.S. Móvil: (57) 310 884 26 50 Fijo (+571) 7426160 Ext 115<tel:%28%2B571%29%207426160%20Ext%20115> Calle 93 # 15-27 Ofc. 502 Calle 29 # 6 - 94 Ofc. 601 Bogotá, Colombia. www.datatraffic.com.co<http://www.datatraffic.com.co/> -- Sergio E. Sinuco Leon Arquitecto de soluciones Datatraffic S.A.S. Móvil: (57) 310 884 26 50 Fijo (+571) 7426160 Ext 115 Calle 93 # 15-27 Ofc. 502 Calle 29 # 6 - 94 Ofc. 601 Bogotá, Colombia. www.datatraffic.com.co<http://www.datatraffic.com.co/> |
2 messages has been excluded from this view by a project administrator.
