[BUGS] BUG #8167: false EINVAL -22 for opening a file
The following bug has been logged on the website: Bug reference: 8167 Logged by: Nelson Minar Email address: nel...@monkey.org PostgreSQL version: 9.2.4 Operating system: MacOS 10.8.3 Description: This report and supporting files are available at https://gist.github.com/NelsonMinar/5588719 I have a PostGIS insert/select operation that creates rows in a table. Mostly these operations succeed, but every once in awhile one fails with an error like ERROR: could not open file base/16384/24738_fsm: Invalid argument Googling for this error shows it's occurred occasionally for other Mac users, but I haven't seen any consistent explanation or solution. I traced this down with the help of RhodiumToad and anders on IRC #postgresql. Their guess was that the problem is that Postgres is calling open() followed by free() before checking errno for open(). The call to free() subsequently calls madvise(), which throws EINVAL, clobbering the ENOENT that open() set. When Postgres finally checks if the open() worked it sees the EINVAL from the madvise() instead and mistakenly reports a problem opening the file. It's unclear whether the EINVAL from madvise() is a real error or just part of the normal operation of free() on MacOS. RhodiumToad asked me to report pg in PathNameOpenFile / mdopen is assuming that errno is preserved over calls to free() which is not required by the spec and madvise is using MADV_FREE_REUSABLE. I've attached dtruss output to this gist for both a successful query and a failed query. Here's the essential part of the trace of a failure: open(base/16384/24738_fsm\0, 0x2, 0x180) = -1 Err#2 madvise(0x7FB983489000, 0x1000, 0x7) = -1 Err#22 sigprocmask(0x3, 0x7FFF580A0420, 0x0)= 0x0 0 sigreturn(0x0, 0x8000, 0x0) = 0 0 write(0x2, ERROR: could not open file \base/16384/24738_fsm\: Invalid argument\nSTATEMENT: insert into merged_rivers(gnis_id, name, strahler, huc8, geometry)\n\tselect\n\t MAX(gnis_id) as gnis_id,\n\tMAX(name) as name, 0x204) = 516 0 sendto(0xC, 0x7FB983841030, 0x65)= 101 0 Environment: MacOS 10.8.3 Postgres 9.2.4 installed via Homebrew I'm not positive if Postgres was built with gcc or clang. Here's the compiler versions: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) Target: x86_64-apple-darwin12.3.0 Thread model: posix -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Postgresql 9.12 support cluster mode
Dear hello： Postgresql 9.12 support cluster mode? Equivalent of main spare automatic switching 电话：010-87120766-5738 手机：13371663316 邮件：wei...@ti-net.com.cn
[BUGS] 回复: Postgresql 9.12 support cluster mode
Dear hello： Postgresql 9.12 support cluster mode? Equivalent of main spare automatic switching weiwei 发件人： weiwei 发送时间： 2013-05-16 17:14 收件人： pgsql-bugs 主题： Postgresql 9.12 support cluster mode 电话：010-87120766-5738 手机：13371663316 邮件：wei...@ti-net.com.cn
Re: [BUGS] BUG #8167: false EINVAL -22 for opening a file
nel...@monkey.org writes:
RhodiumToad asked me to report pg in PathNameOpenFile / mdopen is
assuming that errno is preserved over calls to free() which is not
required by the spec
Good catch! The proximate problem appears to be this bit in
PathNameOpenFile:
vfdP-fd = BasicOpenFile(fileName, fileFlags, fileMode);
if (vfdP-fd 0)
{
FreeVfd(file);
free(fnamecopy);
return -1;
}
The other code layers in this stack seem to be careful about preserving
errno where needed, but this bit isn't.
I've not really reviewed fd.c for other instances of the same bug,
but I do see some places where there are DO_DB(...) debug calls in
places where errno had better not change. I'm thinking maybe we should
improve that macro to include save/restore errno. Or else rip that
stuff out entirely --- I've sure never built this code with FDDEBUG
set, has anyone else?
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] Postgresql 9.12 support cluster mode
On 5/16/2013 2:14 AM, weiwei wrote: Postgresql 9.12 support cluster mode? Equivalent of main spare automatic switching there's no such thing as PostgreSQL 9.12, there's 9.1 of which the current build is 9.1.9, and there's 9.2 which is currently 9.2.4. You can build a active/standby failover cluster with PostgreSQL, but you will need external cluster management software to manage the automatic failover. You can use the built in streaming replication available in 9.0 and later to keep the standby server updated, or you can use traditional shared storage managed by your cluster software. btw, this is NOT a 'bug report' and does NOT belong on the pgsql-bugs mail list, you should subscribe to the pgsql-general list for further discussions. -- john r pierce 37N 122W somewhere on the middle of the left coast
[BUGS] easy crash on HEAD
I am pretty sure this is an easily-reproducible crash on git head (well, as of a2a480af889b5), helpfully confirmed on IRC by wulczer and deko. I reproduced the crash myself on OS X and 64-bit Debian. --- create table foo (a int); CREATE RULE notify_foo_updates AS ON UPDATE TO foo DO NOTIFY foo; \d foo --- Backtrace looks like this: (gdb) bt #0 0x7fff837ce954 in recvfrom () #1 0x000100188fe3 in secure_read (port=0x100802280, ptr=0x10055d340, len=8192) at be-secure.c:304 #2 0x000100191bdc in pq_recvbuf () at pqcomm.c:854 #3 0x000100192053 in pq_getbyte () at pqcomm.c:895 #4 0x000100257fec in SocketBackend [inlined] () at /media/src/OSS/postgresql/src/backend/tcop/postgres.c:344 #5 0x000100257fec in ReadCommand (inBuf=0x7fff5fbfe0d0) at postgres.c:492 #6 0x000100258746 in PostgresMain (argc=1, argv=0x10101a010, dbname=0x101019e78 adsync, username=value temporarily unavailable, due to optimizations) at postgres.c:3946 #7 0x000100204a95 in BackendRun [inlined] () at /media/src/OSS/postgresql/src/backend/postmaster/postmaster.c:3985 #8 0x000100204a95 in ServerLoop () at postmaster.c:3674 #9 0x0001002083d4 in PostmasterMain (argc=3, argv=0x100800700) at postmaster.c:1244 #10 0x000100194089 in main (argc=3, argv=0x100800700) at main.c:196 Josh -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] pg_ctl -D /absolute/path -m fast restart - doesn't work in some cases
hi, I have 9.3beta1, and strange problem. Have running slave pg in directory /home/test/test/slave: =$ pwd /home/test/test/slave =$ cat postmaster.pid 16961 /home/test/test/slave 1368736261 5433 /tmp * 5433001 7241781 =$ ps uxf USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND ... test 16961 0.2 0.1 173528 12912 pts/7S22:31 0:00 /home/pgdba/work/bin/postgres -D test/slave test 16970 0.0 0.0 27020 812 ?Ss 22:31 0:00 \_ postgres: logger process test 16971 4.0 0.0 173640 5724 ?Ss 22:31 0:00 \_ postgres: startup process recovering 0001001B test 17008 0.0 0.0 173528 972 ?Ss 22:31 0:00 \_ postgres: checkpointer process test 17009 0.0 0.0 173528 1244 ?Ss 22:31 0:00 \_ postgres: writer process test 17028 0.0 0.0 29116 888 ?Ss 22:31 0:00 \_ postgres: stats collector process test 17029 2.8 0.0 190652 4232 ?Ds 22:31 0:00 \_ postgres: wal receiver process streaming 0/1B7917E0 ... All looks fine. But when I'll try to restart it: =$ pg_ctl -D $( pwd ) -m fast restart waiting for server to shut down done server stopped server starting postgres cannot access the server configuration file /home/test/test/slave/test/slave/postgresql.conf: No such file or directory The problem doesn't exist when I'd start pg with: 1. cd test/slave; pg_ctl -D . start or 2. pg_ctl -D /home/test/test/slave start only when Pg is started with relative path, and restarted with absolute, the problem shows. I know that it's probably not a big deal for most of the people, but it did bite me, so I'm reporting it. Best regards, depesz -- The best thing about modern society is how easy it is to avoid contact with it. http://depesz.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] pg_ctl -D /absolute/path -m fast restart - doesn't work in some cases
On Thu, May 16, 2013 at 4:34 PM, hubert depesz lubaczewski dep...@depesz.com wrote: =$ pg_ctl -D $( pwd ) -m fast restart waiting for server to shut down done server stopped server starting postgres cannot access the server configuration file /home/test/test/slave/test/slave/postgresql.conf: No such file or directory The problem doesn't exist when I'd start pg with: 1. cd test/slave; pg_ctl -D . start or 2. pg_ctl -D /home/test/test/slave start only when Pg is started with relative path, and restarted with absolute, the problem shows. I know that it's probably not a big deal for most of the people, but it did bite me, so I'm reporting it. It has been a nuisance for me too. Possible patch for pg_ctl is in the next CF: http://www.postgresql.org/message-id/cak3ujrfk8-izau1smpnzr5muc+6crwbk0_7byjnwuoapj3e...@mail.gmail.com Josh -- 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] pg_ctl -D /absolute/path -m fast restart - doesn't work in some cases
Josh Kupershmidt escribió: On Thu, May 16, 2013 at 4:34 PM, hubert depesz lubaczewski dep...@depesz.com wrote: only when Pg is started with relative path, and restarted with absolute, the problem shows. It has been a nuisance for me too. Possible patch for pg_ctl is in the next CF: http://www.postgresql.org/message-id/cak3ujrfk8-izau1smpnzr5muc+6crwbk0_7byjnwuoapj3e...@mail.gmail.com Um, if this is a bug introduced during the 9.3 timeframe surely we ought to fix it now instead of waiting for the CF. -- Á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] pg_ctl -D /absolute/path -m fast restart - doesn't work in some cases
On czw, maj 16, 2013 at 05:55:54 -0400, Alvaro Herrera wrote: only when Pg is started with relative path, and restarted with absolute, the problem shows. It has been a nuisance for me too. Possible patch for pg_ctl is in the next CF: http://www.postgresql.org/message-id/cak3ujrfk8-izau1smpnzr5muc+6crwbk0_7byjnwuoapj3e...@mail.gmail.com Um, if this is a bug introduced during the 9.3 timeframe surely we ought to fix it now instead of waiting for the CF. Apparently not. Retried with 9.1.9, and got exactly same result: =$ pg_ctl -D q -l logfile start server starting =$ cd q =$ pg_ctl -D $( pwd ) -m fast restart waiting for server to shut down done server stopped server starting postgres cannot access the server configuration file /home/depesz/q/q/postgresql.conf: No such file or directory Best regards, depesz -- 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] pg_ctl -D /absolute/path -m fast restart - doesn't work in some cases
Alvaro Herrera alvhe...@2ndquadrant.com writes: Um, if this is a bug introduced during the 9.3 timeframe surely we ought to fix it now instead of waiting for the CF. I think it's been that way all along. Nonetheless, if you feel motivated to review the patch now, there's nothing wrong with that. 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 #8167: false EINVAL -22 for opening a file
On Thu, May 16, 2013 at 11:55 AM, Tom Lane t...@sss.pgh.pa.us wrote: I've not really reviewed fd.c for other instances of the same bug, but I do see some places where there are DO_DB(...) debug calls in places where errno had better not change. I'm thinking maybe we should improve that macro to include save/restore errno. Or else rip that stuff out entirely --- I've sure never built this code with FDDEBUG set, has anyone else? Not me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Inconsistency between TO_CHAR() and TO_NUMBER()
On Fri, May 10, 2013 at 11:49:18AM -0400, Tom Lane wrote: Patryk Kordylewski p...@fooby.de writes: SET lc_numeric TO 'de_DE.UTF-8'; SET SELECT TO_CHAR(123456789.123, 'FM99G999G999G999G999G999G999D000'), TO_NUMBER(TO_CHAR(123456789.123, 'FM99G999G999G999G999G999G999D000'), 'FM99G999G999G999G999G999G999D000'); to_char | to_number -+--- 123.456.789,123 | 123.456 (1 row) I looked into this, and find that the reason it misbehaves is that NUM_numpart_from_char() will treat a '.' as being a decimal point *without any regard to locale considerations*. So even if we have a locale-dependent format string and a locale that says '.' is a thousands separator, it does the wrong thing. It's a bit surprising nobody's complained of this before. I propose the attached patch. I'm slightly worried though about whether this might break any existing applications that are (incorrectly) depending on a D format specifier being able to match '.' regardless of locale. Perhaps we should only apply this to HEAD and not back-patch? I never trust to_char() changes for backpatching. ;-) -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
