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
|
From: Michael P. <mic...@gm...> - 2014-04-17 01:11:13
|
On Wed, Apr 16, 2014 at 9:53 PM, Juned Khan <jkh...@gm...> wrote: > Hi All, > > When i tried to set max_connection value to 1000 it gave me this error > That's a lot, man! Concurrency between sessions is going to blow up your performance. >From the docs i came to know that to use than much connection i have to > modify kernel configuration > > But now i am now trying to set 500 connection instead of 1000 then its > giving below error. > > LOG: database system was interrupted while in recovery at log time > 2014-04-16 09:06:06 WAT > HINT: If this has occurred more than once some data might be corrupted > and you might need to choose an earlier recovery target. > LOG: entering standby mode > LOG: restored log file "000000010000000B00000011" from archive > FATAL: hot standby is not possible because max_connections = 500 is a > lower setting than on the master server (its value was 1000) > LOG: startup process (PID 16829) exited with exit code 1 > LOG: aborting startup due to startup process failure > Anyone please suggest if any other way is there to fix this like clearing > cache or something so it can read correct values. > Update the master first, then the slave. -- Michael |
From: 鈴木 幸市 <ko...@in...> - 2014-04-17 01:07:50
|
The setup of max_connection=1000 might have written to WAL and shipped to the slave. This could be the cause of the issue. You can do the following to recover from the issue. 1. Run checkpoint and vacuum full at the master, 2. Build the slave from the scotch using pg_basebackup (pgxc_ctl provides this means). 3. Start the slave. Regards; --- Koichi Suzuki 2014/04/16 21:53、Juned Khan <jkh...@gm...> のメール: > Hi All, > > When i tried to set max_connection value to 1000 it gave me this error > > FATAL: could not create semaphores: No space left on device > DETAIL: Failed system call was semget(20008064, 17, 03600). > > From the docs i came to know that to use than much connection i have to modify kernel configuration > > But now i am now trying to set 500 connection instead of 1000 then its giving below error. > > LOG: database system was interrupted while in recovery at log time 2014-04-16 09:06:06 WAT > HINT: If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target. > LOG: entering standby mode > LOG: restored log file "000000010000000B00000011" from archive > FATAL: hot standby is not possible because max_connections = 500 is a lower setting than on the master server (its value was 1000) > LOG: startup process (PID 16829) exited with exit code 1 > LOG: aborting startup due to startup process failure > > It says master value is 1000 but i have set it to 500. seems it reading old values i guess. > > database=# show max_connections; > max_connections > ----------------- > 500 > (1 row) > > I have restarted all components several times but no luck. > > Anyone please suggest if any other way is there to fix this like clearing cache or something so it can read correct values. > > > Regards > Juned Khan > ------------------------------------------------------------------------------ > 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-16 12:53:23
|
Hi All, When i tried to set max_connection value to 1000 it gave me this error FATAL: could not create semaphores: No space left on device DETAIL: Failed system call was semget(20008064, 17, 03600). >From the docs i came to know that to use than much connection i have to modify kernel configuration But now i am now trying to set 500 connection instead of 1000 then its giving below error. LOG: database system was interrupted while in recovery at log time 2014-04-16 09:06:06 WAT HINT: If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target. LOG: entering standby mode LOG: restored log file "000000010000000B00000011" from archive FATAL: hot standby is not possible because max_connections = 500 is a lower setting than on the master server (its value was 1000) LOG: startup process (PID 16829) exited with exit code 1 LOG: aborting startup due to startup process failure It says master value is 1000 but i have set it to 500. seems it reading old values i guess. database=# show max_connections; max_connections ----------------- 500 (1 row) I have restarted all components several times but no luck. Anyone please suggest if any other way is there to fix this like clearing cache or something so it can read correct values. Regards Juned Khan |
From: 鈴木 幸市 <ko...@in...> - 2014-04-16 07:02:48
|
It is what we’d like to have in the next release. I’m planning to discuss next XC major feature in XC days in Ottawa, May. This meeting will be held as one of the PGCon-related meetings. This is definitely the one we want to have, as well as enforcing cross-node referential constraint. Thank you. --- Koichi Suzuki 2014/04/16 15:53、Aaron Jackson <aja...@re...<mailto:aja...@re...>> のメール: Yes, I completely understand why it has to be done. I was working with an in-memory distributed database earlier this year and they allowed constraints like these as long as the constraint included the partitioned / distributed key. In theory, I guess that's viable because it means that the data node alone be capable of guaranteeing uniqueness without any further coordination. I'll try adding a unique index post creation to see if it works. Thank you ________________________________ From: 鈴木 幸市 [ko...@in...<mailto:ko...@in...>] Sent: Tuesday, April 15, 2014 7:54 PM To: Aaron Jackson Cc: pos...@li...<mailto:pos...@li...> Subject: Re: [Postgres-xc-general] Creating Unique Indices It is in the list of the future work. To enforce this, we need cross-node operation which need additional infrastructure. So at present, you can add unique index to distributed table if distribution column is involved. You can add unique index freely to replicated tables. For the same reason, you cannot add reference integrity between distributed tables. Regards; --- Koichi Suzuki 2014/04/16 4:36、Aaron Jackson <aja...@re...<mailto:aja...@re...>> のメール: 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 ------------------------------------------------------------------------------ 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...<mailto:Pos...@li...> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general |
From: Aaron J. <aja...@re...> - 2014-04-16 06:54:39
|
Yes, I completely understand why it has to be done. I was working with an in-memory distributed database earlier this year and they allowed constraints like these as long as the constraint included the partitioned / distributed key. In theory, I guess that's viable because it means that the data node alone be capable of guaranteeing uniqueness without any further coordination. I'll try adding a unique index post creation to see if it works. Thank you ________________________________ From: 鈴木 幸市 [ko...@in...] Sent: Tuesday, April 15, 2014 7:54 PM To: Aaron Jackson Cc: pos...@li... Subject: Re: [Postgres-xc-general] Creating Unique Indices It is in the list of the future work. To enforce this, we need cross-node operation which need additional infrastructure. So at present, you can add unique index to distributed table if distribution column is involved. You can add unique index freely to replicated tables. For the same reason, you cannot add reference integrity between distributed tables. Regards; --- Koichi Suzuki 2014/04/16 4:36、Aaron Jackson <aja...@re...<mailto:aja...@re...>> のメール: 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 ------------------------------------------------------------------------------ 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: Aaron J. <aja...@re...> - 2014-04-16 06:52:15
|
Yes, I was able to isolate it down to the test clause of the loop evaluation at the end of ProcArray. To ensure I wasn't looking at volatile values, I copied the values used during the test so they weren't subject to changes to memory. I'll put the exact scenario back together again for you and post it here. It was pretty obvious when the loop began to exit prematurely and post-test values indicated that things which should be truths weren't (e.g. 1 < 3 = 1 but the test was returning 0). I will have an answer by the weekend. Aaron ________________________________ From: 鈴木 幸市 [ko...@in...] Sent: Sunday, April 13, 2014 7:55 PM To: Aaron Jackson Cc: pos...@li... Subject: Re: [Postgres-xc-general] failed to find proc - increasing numProcs 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: Masataka S. <pg...@gm...> - 2014-04-16 06:24:40
|
It is worth trying at a glance to the proxy log. AFAIK you're needless to remove register.node with typical operations. If you meet this issue, I think you'd better review your operations. Regards. On 15 April 2014 20:30, Juned Khan <jkh...@gm...> wrote: > 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: 鈴木 幸市 <ko...@in...> - 2014-04-16 00:55:03
|
It is in the list of the future work. To enforce this, we need cross-node operation which need additional infrastructure. So at present, you can add unique index to distributed table if distribution column is involved. You can add unique index freely to replicated tables. For the same reason, you cannot add reference integrity between distributed tables. Regards; --- Koichi Suzuki 2014/04/16 4:36、Aaron Jackson <aja...@re...<mailto:aja...@re...>> のメール: 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 ------------------------------------------------------------------------------ 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: 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 |