[BUGS] BUG #5450: system lacked sufficient buffer space, or because a queue was full, could not perform the operation
The following bug has been logged online: Bug reference: 5450 Logged by: gouthamj Email address: jgowt...@gmail.com PostgreSQL version: 8.1.5 Operating system: Window xp(sp2) 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. -- 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
"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 -- 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 #5451: pg_restore doesn't close input .tar archive
The following bug has been logged online: Bug reference: 5451 Logged by: Pavel Golub Email address: pa...@microolap.com PostgreSQL version: 8.4.x Operating system: Windows Description:pg_restore doesn't close input .tar archive Details: pg_restore doesn't close input .tar archive file after restore process. However, file is closed after pg_restore termination, I suppose it's not correct behaviour. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] "SET search_path" clause ignored during function creation
As discussed in irc://freenode/postgresql (2010-05-06 16:20) Function bodies are checked using the _current_ search_path instead of the search_path supplied by the "SET search_path" clause. This leads to wrong error messages during creation. On the other hand it can make a function body pass the check, even though it will raise an error is use. Proposed solution: Function bodies should be checked with the search_path provided by "SET search_path" an _not_ with the current search path at the time pof creation. Ho to reproduce the bug: /* event=# show search_path; search_path - public */ CREATE SCHEMA foo; CREATE TABLE foo.adr ( adr_id integer primary key, note text); INSERT INTO foo.adr VALUES (1, 'note from table foo.adr'); CREATE FUNCTION f_test() RETURNS text AS 'SELECT note FROM adr where adr_id = 1' LANGUAGE 'sql' SET search_path=foo; -- ERROR: relation "adr" does not exist -- LINE 3: 'SELECT note FROM adr where adr_id = 1' -- Function body is falsely checked with "search_path= public" (current search_path) instead of "search_path=foo" AS it should be! -- If I disable check_function_bodies before creation, creation works and the function call works and returns the value of foo.adr correctly. SET check_function_bodies=false; Regards Erwin Brandstetter -- 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 #5451: pg_restore doesn't close input .tar archive
"Pavel Golub" writes: > pg_restore doesn't close input .tar archive file after restore process. > However, file is closed after pg_restore termination, I suppose it's not > correct behaviour. I'm not sure what distinction you're trying to draw. Do you want us to add a close() just before exit()? If so, what for? 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
[BUGS] BUG #5452: Server core dumps coming out of recovery mode
The following bug has been logged online: Bug reference: 5452 Logged by: Chris Copeland Email address: ch...@cope360.com PostgreSQL version: 8.2.16 Operating system: Solaris 10 x86 Description:Server core dumps coming out of recovery mode Details: I originally had this problem in 8.2.4 and have not upgraded to 8.2.16 and I am still having it. 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. Here are the log files. My annotations start with >> :: postgresql-2010-05-06_102646.log :: >> First time starting the server after the data directory was copied from the master 2010-05-06 10:26:46 CDT :LOG: database system was interrupted at 2010-05-06 09:32:20 CDT 2010-05-06 10:26:46 CDT :LOG: starting archive recovery 2010-05-06 10:26:46 CDT :LOG: restore_command = "/opt/data/restore.sh /opt/wal/archwalremote/%f %p" 2010-05-06 10:26:46 CDT :LOG: restored log file "000100AF0048.0020.backup" from archive 2010-05-06 10:26:47 CDT :LOG: restored log file "000100AF0048" from archive 2010-05-06 10:26:47 CDT :LOG: checkpoint record is at AF/4820 2010-05-06 10:26:47 CDT :LOG: redo record is at AF/4820; undo record is at 0/0; shutdown FALSE 2010-05-06 10:26:47 CDT :LOG: next transaction ID: 0/326126241; next OID: 862575 2010-05-06 10:26:47 CDT :LOG: next MultiXactId: 2128; next MultiXactOffset: 4280 2010-05-06 10:26:47 CDT :LOG: automatic recovery in progress 2010-05-06 10:26:47 CDT :LOG: redo starts at AF/4868 2010-05-06 10:26:48 CDT :LOG: restored log file "000100AF0049" from archive 2010-05-06 10:26:50 CDT :LOG: restored log file "000100AF004A" from archive 2010-05-06 10:26:51 CDT :LOG: restored log file "000100AF004B" from archive 2010-05-06 10:26:52 CDT :LOG: restored log file "000100AF004C" from archive 2010-05-06 10:26:54 CDT :LOG: restored log file "000100AF004D" from archive 2010-05-06 10:26:56 CDT :LOG: restored log file "000100AF004E" from archive 2010-05-06 10:26:58 CDT :LOG: restored log file "000100AF004F" from archive 2010-05-06 10:27:00 CDT :LOG: restored log file "000100AF0050" from archive 2010-05-06 10:27:02 CDT :LOG: restored log file "000100AF0051" from archive 2010-05-06 10:27:04 CDT :LOG: restored log file "000100AF0052" from archive 2010-05-06 10:27:24 CDT :LOG: restored log file "000100AF0053" from archive >> WAL files now being restored as they arrive from the master 2010-05-06 10:32:25 CDT :LOG: restored log file "000100AF0054" from archive 2010-05-06 10:37:26 CDT :LOG: restored log file "000100AF0055" from archive 2010-05-06 10:42:27 CDT :LOG: restored log file "000100AF0056" from archive 2010-05-06 10:47:28 CDT :LOG: restored log file "000100AF0057" from archive 2010-05-06 10:52:29 CDT :LOG: restored log file "000100AF0058" from archive 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 2010-05-06 10:59:34 CDT :LOG: startup process (PID 24763) was terminated by signal 6 2010-05-06 10:59:34 CDT :LOG: aborting startup due to startup process failure 2010-05-06 10:59:34 CDT :LOG: logger shutting down :: postgresql-2010-05-06_105934.log :: >> Attempting to restart server 2010-05-06 10:59:34 CDT :LOG: database system was interrupted while in recovery at log time 2010-05-06 10:57:20 CDT 2010-05-06 10:59:34 CDT :HINT: If this has occurred more than once some data may be corrupted and you may need to choose an earlier recovery target. 2010-05-06 10:59:34 CDT :LOG: starting archive recovery 2010-05-06 10:59:34 CDT :LOG: restore_command = "/opt/data/restore.sh /opt/wal/archwalremote/%f %p" 2010-05-06 10:59:34 CDT :LOG: could not open file "pg_xlog/000100AF0059" (log file 175, segment 89): No such file or directory 2010-05-06 10:59:34 CDT :LOG: invalid primary checkpoint record 2010-05-06 10:59:34 CDT :LOG: could not open file "pg_xlog/000100AF0058" (log file 175, segment 88): No such file or directory 2010-05-06 10:59:34 CDT :LOG: invalid secondary checkpoint record 2010-05-06 10:59:34 CDT :
Re: [BUGS] BUG #5451: pg_restore doesn't close input .tar archive
Hello, Tom. You wrote: TL> "Pavel Golub" writes: >> pg_restore doesn't close input .tar archive file after restore process. >> However, file is closed after pg_restore termination, I suppose it's not >> correct behaviour. 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. TL> regards, tom lane -- With best wishes, Pavel mailto:pa...@gf.microolap.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
