Re: [BUGS] BUG #5452: Server core dumps coming out of recovery mode
Chris Copeland wrote: > I have two servers with the same hardware, OS, and pg binaries. Log files > are copied from the master to the standby and the standby is run in recovery > mode. > > When the standby is triggered to come out of recovery mode, it fails and > generates a core dump. Upon trying to start it after failure, it starts > looking for WAL files that it has already recovered. >... > 2010-05-06 10:57:30 CDT :LOG: restored log file "000100AF0059" > from archive >>> >> Now I trigger the restore command to return 1 to stop the recovery > 2010-05-06 10:59:30 CDT :LOG: could not open file > "pg_xlog/000100AF005A" (log file 175, segment 90): No such file > or directory > 2010-05-06 10:59:30 CDT :LOG: redo done at AF/5968 > 2010-05-06 10:59:30 CDT :PANIC: could not open file > "pg_xlog/000100AF0059" (log file 175, segment 89): No such file > or directory At startup, the server needs to re-fetch the last checkpoint record. That means calling restore_command again for a file that was already restored. It looks like restore_command is failing at the re-fetch, which causes the PANIC. To trigger failover, restore_command needs to return 1, once, but it must return 0 again on any subsequent calls. I suspect your restore_command keeps returning 1 on the subsequent calls. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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 #5450: system lacked sufficient buffer space, or because a queue was full, could not perform the operation
Hi Takahiro san, Thanks a lot for mail. Our application has to take backup aroung 200GB or more data based on Database. Physical files in the local system will be uploaded to NAS raid server based on Database records. for each and every database record associated files wil be available. So, more than 30 times database queries and updates to DB and around 60 files to be uploaded to NAS. Regards Goutham J On Thu, May 6, 2010 at 12:44 AM, Takahiro Itagaki < itagaki.takah...@oss.ntt.co.jp> wrote: > > "gouthamj" wrote: > > > PostgreSQL version: 8.1.5 > > Operating system: Window xp(sp2) > > Sorry, PostgreSQL 8.1 on Windows is no longer supported. > Please upgrade to 8.2 or newer versions, and test your sequence again. > > BTW, your message comes from WSAENOBUFS (10055). The error could be > raised by various reasons. We need what you did when you receive > the message to research your problem. > > > Description:system lacked sufficient buffer space, or because a > > queue was full, could not perform the operation > > Details: > > > > 2010-04-20 00:53:29 LOG: unexpected EOF on client connection > > 2010-04-20 00:55:47 LOG: could not receive data from client: the system > > lacked sufficient buffer space, or because a queue was full, could not > > perform the operation on a socket. > > Regards, > --- > Takahiro Itagaki > NTT Open Source Software Center > > >
Re: [BUGS] BUG #5451: pg_restore doesn't close input .tar archive
Pavel Golub writes: > TL> I'm not sure what distinction you're trying to draw. Do you want us to > TL> add a close() just before exit()? If so, what for? > First of all, for uniformity I guess. :) .backup files are closed > properly. > And secondly, I'm using these sources in my project and I > need input file to be closed. Of course, I can find the place > where to insert close() by myself, but I beleive that this must be done in the > official release. I don't think so. The pg_restore code is not written to be a library. (Some have proposed making it into one, but there's a lot of work needed to make that happen.) Even if it were designed as a library, I don't think it would be the library's job to close the input file --- what if the surrounding app passes it stdin, for instance? 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
