Re: [BUGS] BUG #8294: new timeline 6 forked off current dat abase system timeline 5 before current recovery point 0/100000
(Quoted pg_controldata output edited to highlight the important parts) On 11.07.2013 06:26, dig...@126.com wrote: PostgreSQL 9.3 beta2 stream replication primary and standby cann't switchover. ... Primary : psql checkpont; pg_controldata ... Database cluster state: in production Latest checkpoint location: 0/C60 Prior checkpoint location:0/B60 Latest checkpoint's REDO location:0/C28 Latest checkpoint's TimeLineID: 4 Latest checkpoint's PrevTimeLineID: 4 Minimum recovery ending location: 0/0 Min recovery ending loc's timeline: 0 Standby : Database cluster state: in archive recovery Latest checkpoint location: 0/B60 Prior checkpoint location:0/B60 Latest checkpoint's REDO location:0/B28 Latest checkpoint's TimeLineID: 4 Latest checkpoint's PrevTimeLineID: 4 Minimum recovery ending location: 0/BF0 Min recovery ending loc's timeline: 4 So at this point you have a primary, and a standby server following the primary through streaming replication. Primary : pg_ctl stop waiting for server to shut down done server stopped pg_controldata Database cluster state: shut down Latest checkpoint location: 0/D28 Prior checkpoint location:0/C60 Latest checkpoint's REDO location:0/D28 Latest checkpoint's TimeLineID: 4 Latest checkpoint's PrevTimeLineID: 4 Minimum recovery ending location: 0/0 Min recovery ending loc's timeline: 0 standby : pg_controldata Database cluster state: in archive recovery Latest checkpoint location: 0/B60 Prior checkpoint location:0/B60 Latest checkpoint's REDO location:0/B28 Latest checkpoint's TimeLineID: 4 Latest checkpoint's PrevTimeLineID: 4 Minimum recovery ending location: 0/BF0 Min recovery ending loc's timeline: 4 pg_ctl promote server promoting pg_controldata Database cluster state: in production Latest checkpoint location: 0/D90 Prior checkpoint location:0/B60 Latest checkpoint's REDO location:0/D58 Latest checkpoint's TimeLineID: 5 Latest checkpoint's PrevTimeLineID: 5 The primary is shut down, and the standby is promoted to become new master. primary : cd $PGDATA mv recovery.done recovery.conf pg_ctl start log : 2013-07-11 11:10:11.386 CST,,,14911,,51de2213.3a3f,1,,2013-07-11 11:10:11 CST,,0,LOG,0,database system was shut down in recovery at 2013-07-11 11:09:51 CSTStartupXLOG, xlog.c:4895, 2013-07-11 11:10:11.387 CST,,,14911,,51de2213.3a3f,2,,2013-07-11 11:10:11 CST,,0,LOG,0,entering standby modeStartupXLOG, xlog.c:4968, 2013-07-11 11:10:11.391 CST,,,14911,,51de2213.3a3f,3,,2013-07-11 11:10:11 CST,1/0,0,LOG,0,consistent recovery state reached at 0/D90CheckRecoveryConsistency, xlog.c:6187, 2013-07-11 11:10:11.391 CST,,,14911,,51de2213.3a3f,4,,2013-07-11 11:10:11 CST,1/0,0,LOG,0,record with zero length at 0/D90ReadRecord, xlog.c:3285, 2013-07-11 11:10:11.392 CST,,,14909,,51de2213.3a3d,1,,2013-07-11 11:10:11 CST,,0,LOG,0,database system is ready to accept read only connectionssigusr1_handler, postmaster.c:4658, 2013-07-11 11:10:11.407 CST,,,14915,,51de2213.3a43,1,,2013-07-11 11:10:11 CST,,0,LOG,0,fetching timeline history file for timeline 5 from primary serverWalRcvFetchTimeLineHistoryFiles, walreceiver.c:666, 2013-07-11 11:10:11.411 CST,,,14915,,51de2213.3a43,2,,2013-07-11 11:10:11 CST,,0,LOG,0,primary server contains no more WAL on requested timeline 4WalReceiverMain, walreceiver.c:529, 2013-07-11 11:10:11.411 CST,,,14911,,51de2213.3a3f,5,,2013-07-11 11:10:11 CST,1/0,0,LOG,0,new timeline 5 forked off current database system timeline 4 before current recovery point 0/D90rescanLatestTimeLine, xlog.c:3441, The old primary is restarted in standby-mode. It tries to connect to the new primary, but it refuses to follow it because there is some WAL applied on the old primary that was not replicated to the new primary before the switchover. I believe this is the same issue that Fujii reported in June: http://www.postgresql.org/message-id/CAHGQGwHLjEROTMtSWJd=xg_vfwre3ojwntysybdubrya6rr...@mail.gmail.com. This was fixed in commit 0b958f3efcfcc3d9b0e39d550b705a28763bc9e2 on June 25th: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0b958f3efcfcc3d9b0e39d550b705a28763bc9e2 Unfortunately that commit didn't make it into 9.3beta2, which was wrapped just one day before that commit. Could you try again with a fresh checkout from REL9_3_STABLE branch? Or if you can't easily build from sources, you can wait for the 9.3rc1 release, which should be available later this week (http://www.postgresql.org/message-id/24973.1376419...@sss.pgh.pa.us). Thanks for the report! Please let us know if the next version
Re: [JDBC] [BUGS] Incorrect response code after XA recovery
On 05.08.2013 17:58, Jeremy Whiting wrote: Hello Tom, A quick update on progress. A second PR was created to provide a patch. https://github.com/pgjdbc/pgjdbc/pull/76 Thanks. Looks good to me. I wish the backend would throw a more specific error code for this, 42704 is used for many other errors as well. But at COMMIT/ROLLBACK PREPARED, it's probably safe to assume that it means that the transaction does not exist. - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8384: Missing dll
Hi libpq is not supposed to be used from lib/. May be we should consider to remove it from there. On Thu, Aug 15, 2013 at 3:55 AM, barnhart@gmail.com wrote: The following bug has been logged on the website: Bug reference: 8384 Logged by: Jon Barnhart Email address: barnhart@gmail.com PostgreSQL version: 9.2.4 Operating system: Win 7 ultimate Description: pgsql/lib is missing libintl.dll so if you try to use libpq from pgsql/lib rather than pgsql/bin it will fail. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs -- Sandeep Thakkar
[BUGS] BUG #8386: function crosstab(unknown) does not exist
The following bug has been logged on the website: Bug reference: 8386 Logged by: pradeep v Email address: pradeep.v.pr...@gmail.com PostgreSQL version: 9.2.1 Operating system: windows 7 Description: when i execute query SELECT * FROM crosstab( 'SELECT section, status, count FROM t ORDER BY 1,2') AS ct (Section text, Active text, Inactive int); the function crosstab(unknown) does not exist error comes may i know why? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8388: Remote connections
The following bug has been logged on the website: Bug reference: 8388 Logged by: Phil Heverly Email address: pah...@psu.edu PostgreSQL version: 9.1.9 Operating system: Mac OS 10.7 and 10.8 Description: I doubt this is a bug, but I cannot connect to remote systems running Postgres 9.1 on Mac OSes. I edited both the pg_hba and postgresql files correctly but it continues to error out on two systems. After making the changes on my Windows box connections work fine. Only seeing this on the Macs -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8387: Error while make of the source code
The following bug has been logged on the website: Bug reference: 8387 Logged by: Nitish Email address: nitishsaur...@gmail.com PostgreSQL version: 9.2.4 Operating system: AIX7.1 Description: Gives Error while compiling (configure goes well but while running make it gives error) the source code as shown below. Is there any compatibility issue between PostgreSQl 9.2.4 and AIX7.1 ? /tmp//ccIZry3K.s: line 23872: 1252-142 Syntax error. /tmp//ccIZry3K.s: line 23873: 1252-142 Syntax error. /tmp//ccIZry3K.s: line 23876: 1252-142 Syntax error. gmake[4]: *** [xlog.o] Error 1 gmake[4]: Leaving directory `/usr/src/postgresql-9.2.4/src/backend/access/transam' gmake[3]: *** [transam-recursive] Error 2 gmake[3]: Leaving directory `/usr/src/postgresql-9.2.4/src/backend/access' gmake[2]: *** [access-recursive] Error 2 gmake[2]: Leaving directory `/usr/src/postgresql-9.2.4/src/backend' gmake[1]: *** [all-backend-recurse] Error 2 gmake[1]: Leaving directory `/usr/src/postgresql-9.2.4/src' gmake: *** [all-src-recurse] Error 2 make: 1254-004 The error code from the last command is 2. Stop. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8387: Error while make of the source code
On 19.08.2013 13:33, nitishsaur...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 8387 Logged by: Nitish Email address: nitishsaur...@gmail.com PostgreSQL version: 9.2.4 Operating system: AIX7.1 Description: Gives Error while compiling (configure goes well but while running make it gives error) the source code as shown below. Is there any compatibility issue between PostgreSQl 9.2.4 and AIX7.1 ? Not that I'm aware of. Then again, there is no AIX 7.1 box in the buildfarm, the closes thing is grebe running AIX 5.3 (see http://buildfarm.postgresql.org/cgi-bin/show_status.pl). - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8387: Error while make of the source code
What compiler are you using? If it helps, some time ago I built PG v9.2.2 using the IBM xlc compiler at version 12 successfully. From my notes I used the following compiler configuration:- ./configure CC=xlc LIBS=-lssl -lcrypto -lz -lreadline -lcurses -lld -lmass -lm CFLAGS=-qlanglvl=extc89 --with-template=aix --prefix=/home/ahastie/pgbuild --with-includes=/opt/freeware/include:/home/ahastie/gnu/zlib-1.2.7:/home/ahastie/gnu/readline-6.2 --with-libraries=/opt/freeware/lib (Note: For various reasons I used my own downloads of zlib and readline for the build.) Hope the above helps. On 19/08/13 11:33, nitishsaur...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 8387 Logged by: Nitish Email address: nitishsaur...@gmail.com PostgreSQL version: 9.2.4 Operating system: AIX7.1 Description: Gives Error while compiling (configure goes well but while running make it gives error) the source code as shown below. Is there any compatibility issue between PostgreSQl 9.2.4 and AIX7.1 ? /tmp//ccIZry3K.s: line 23872: 1252-142 Syntax error. /tmp//ccIZry3K.s: line 23873: 1252-142 Syntax error. /tmp//ccIZry3K.s: line 23876: 1252-142 Syntax error. gmake[4]: *** [xlog.o] Error 1 gmake[4]: Leaving directory `/usr/src/postgresql-9.2.4/src/backend/access/transam' gmake[3]: *** [transam-recursive] Error 2 gmake[3]: Leaving directory `/usr/src/postgresql-9.2.4/src/backend/access' gmake[2]: *** [access-recursive] Error 2 gmake[2]: Leaving directory `/usr/src/postgresql-9.2.4/src/backend' gmake[1]: *** [all-backend-recurse] Error 2 gmake[1]: Leaving directory `/usr/src/postgresql-9.2.4/src' gmake: *** [all-src-recurse] Error 2 make: 1254-004 The error code from the last command is 2. Stop. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8386: function crosstab(unknown) does not exist
Have you installed the tablefunc extension？ please show the \dx results in psql? Jov blog: http:amutu.com/blog http://amutu.com/blog 2013/8/19 pradeep.v.pr...@gmail.com The following bug has been logged on the website: Bug reference: 8386 Logged by: pradeep v Email address: pradeep.v.pr...@gmail.com PostgreSQL version: 9.2.1 Operating system: windows 7 Description: when i execute query SELECT * FROM crosstab( 'SELECT section, status, count FROM t ORDER BY 1,2') AS ct (Section text, Active text, Inactive int); the function crosstab(unknown) does not exist error comes may i know why? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8387: Error while make of the source code
Heikki Linnakangas hlinnakan...@vmware.com writes: On 19.08.2013 13:33, nitishsaur...@gmail.com wrote: Gives Error while compiling (configure goes well but while running make it gives error) the source code as shown below. Is there any compatibility issue between PostgreSQl 9.2.4 and AIX7.1 ? Not that I'm aware of. Then again, there is no AIX 7.1 box in the buildfarm, the closes thing is grebe running AIX 5.3 (see http://buildfarm.postgresql.org/cgi-bin/show_status.pl). I'm wondering if the OP's configuration doesn't support LWARX mutex hints (see the comment for USE_PPC_LWARX_MUTEX_HINT in pg_config_manual.h). We do have a configure-time check for that, but maybe it's not working for him? Without any info as to the compiler or assembler in use, nor a look at the failing bits of assembly code, we're just guessing. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8388: Remote connections
On Mon, Aug 19, 2013 at 7:32 AM, pah...@psu.edu wrote: The following bug has been logged on the website: Bug reference: 8388 Logged by: Phil Heverly Email address: pah...@psu.edu PostgreSQL version: 9.1.9 Operating system: Mac OS 10.7 and 10.8 Description: I doubt this is a bug, but I cannot connect to remote systems running Postgres 9.1 on Mac OSes. I edited both the pg_hba and postgresql files correctly but it continues to error out on two systems. After making the changes on my Windows box connections work fine. Only seeing this on the Macs 1). You will generally get pretty good responses by posting to the pgsql-* mailing lists. You can sign up on this page: http://www.postgresql.org/community/lists/. Probably the pgsql-general list will be the appropriate one for your question. 2). More details are needed for useful help, such as the errors or relevant sections from your error logs. A much better description can be found here: https://wiki.postgresql.org/wiki/Guide_to_reporting_problems
Re: [BUGS] 9.3beta2: Failure to pg_upgrade
Jesse Denardo escribió: Alvaro, I applied the patch and tried upgrading again, and everything seemed to work as expected. We are now up and running the beta! Pushed, thanks. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Completely broken replica after PANIC: WAL contains references to invalid pages
Hi all, I recently noticed that I continue to receive allocation failure messages from postmaster in /var/log/messages on the server where the problem occurred. Aug 17 23:00:51 tms2 kernel: : postmaster: page allocation failure. order:5, mode:0xd0 Aug 17 23:00:51 tms2 kernel: : Pid: 21223, comm: postmaster Not tainted 2.6.32-279.22.1.el6.x86_64 #1 Aug 17 23:00:51 tms2 kernel: : Call Trace: Aug 17 23:00:51 tms2 kernel: : [8112343f] ? __alloc_pages_nodemask+0x77f/0x940 Aug 17 23:00:51 tms2 kernel: : [8115d3e2] ? kmem_getpages+0x62/0x170 Aug 17 23:00:51 tms2 kernel: : [8115dffa] ? fallback_alloc+0x1ba/0x270 Aug 17 23:00:51 tms2 kernel: : [8115da4f] ? cache_grow+0x2cf/0x320 Aug 17 23:00:51 tms2 kernel: : [8115dd79] ? cache_alloc_node+0x99/0x160 Aug 17 23:00:51 tms2 kernel: : [813fd455] ? dma_pin_iovec_pages+0xb5/0x230 Aug 17 23:00:51 tms2 kernel: : [8115eb49] ? __kmalloc+0x189/0x220 Aug 17 23:00:51 tms2 kernel: : [813fd455] ? dma_pin_iovec_pages+0xb5/0x230 Aug 17 23:00:51 tms2 kernel: : [8141a47c] ? lock_sock_nested+0xac/0xc0 Aug 17 23:00:51 tms2 kernel: : [8146edaa] ? tcp_recvmsg+0x4ca/0xe80 Aug 17 23:00:51 tms2 kernel: : [8148f90a] ? inet_recvmsg+0x5a/0x90 Aug 17 23:00:51 tms2 kernel: : [81418b93] ? sock_recvmsg+0x133/0x160 Aug 17 23:00:51 tms2 kernel: : [81090be0] ? autoremove_wake_function+0x0/0x40 Aug 17 23:00:51 tms2 kernel: : [8117660a] ? do_sync_read+0xfa/0x140 Aug 17 23:00:51 tms2 kernel: : [81418d0e] ? sys_recvfrom+0xee/0x180 Aug 17 23:00:51 tms2 kernel: : [8118b09d] ? poll_select_set_timeout+0x8d/0xa0 Aug 17 23:00:51 tms2 kernel: : [810d3f47] ? audit_syscall_entry+0x1d7/0x200 Aug 17 23:00:51 tms2 kernel: : [8100b072] ? system_call_fastpath+0x16/0x1b Except these messages everything is just fine. The server is a passive (very rarely queried) hot standby. Are there any ideas of why and what could it be? Thank you. On Tue, Jun 11, 2013 at 6:50 AM, Tom Lane t...@sss.pgh.pa.us wrote: Sergey Konoplev gray...@gmail.com writes: Just curious, what is the planned date for the next minor release, and BTW where is it possible to see the roadmap for minor releases? There is no planned date, and certainly no roadmap. We make minor releases when the core team judges that enough (or severe enough) fixes have accumulated since the last time. Historically we've averaged about four minor releases a year, but that's not set in stone anywhere. regards, tom lane -- Kind regards, Sergey Konoplev PostgreSQL Consultant and DBA http://www.linkedin.com/in/grayhemp +1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979 gray...@gmail.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
