[BUGS] abort()/segfault when starting postgres in inaccessible CWD
Hi, Starting postgres with a CWD that's not readable will trigger an Assert and if those are disabled it presumably will segfault. #0 0x775621e5 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x77565398 in __GI_abort () at abort.c:90 #2 0x0089031d in ExceptionalCondition ( conditionName=0xa6e530 !(((CurrentMemoryContext) != ((void *)0) (const Node*)((CurrentMemoryContext)))-type) == T_AllocSetContext, errorType=0xa6e2c9 BadArgument, fileName=0xa6e240 /home/andres/src/postgresql/src/backend/utils/mmgr/mcxt.c, lineNumber=649) at /home/andres/src/postgresql/src/backend/utils/error/assert.c:54 #3 0x008bc206 in palloc (size=1024) at /home/andres/src/postgresql/src/backend/utils/mmgr/mcxt.c:649 #4 0x006597b2 in initStringInfo (str=0x7fffc410) at /home/andres/src/postgresql/src/backend/lib/stringinfo.c:50 #5 0x00896383 in expand_fmt_string (fmt=0xa8d3e8 could not change directory to \%s\: %s, edata=0xd587e0 errordata) at /home/andres/src/postgresql/src/backend/utils/error/elog.c:3167 #6 0x00892c52 in elog_finish (elevel=15, fmt=0xa8d3e8 could not change directory to \%s\: %s) at /home/andres/src/postgresql/src/backend/utils/error/elog.c:1297 #7 0x008d932a in resolve_symlinks (path=0x7fffdad0 /home/andres/build/postgres/dev-assert/vpath/src/backend/postgres) at /home/andres/src/postgresql/src/port/exec.c:293 #8 0x008d8e10 in find_my_exec (argv0=0xd60bb0 /home/andres/build/postgres/dev-assert/vpath/src/backend/postgres, retpath=0x7fffdad0 /home/andres/build/postgres/dev-assert/vpath/src/backend/postgres) at /home/andres/src/postgresql/src/port/exec.c:144 #9 0x008d96aa in set_pglocale_pgservice (argv0=0xd60bb0 /home/andres/build/postgres/dev-assert/vpath/src/backend/postgres, app=0xa05440 postgres-9.4) at /home/andres/src/postgresql/src/port/exec.c:561 #10 0x00668932 in main (argc=21, argv=0xd60af0) at /home/andres/src/postgresql/src/backend/main/main.c:98 So, the problem is that we're calling set_pglocale_pgservice() which indirectly can call elog() long before we've initialized memory contexts. To reproduce do something like: # become root su # change into root-only directory cd /root # switch user, without changing directory su postgres # execute postgres /path/to/postgres -D frakbar Greetings, Andres Freund -- Andres Freund http://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] abort()/segfault when starting postgres in inaccessible CWD
Andres Freund and...@2ndquadrant.com writes: Starting postgres with a CWD that's not readable will trigger an Assert and if those are disabled it presumably will segfault. Yeah, we've discussed that before. I'm not sure it's worth fixing, or that it could be counted on to stay fixed even if we removed the current source(s) of trouble. There's a bigger problem with the scenario you show, which is that the postmaster is started with root's environment variables not postgres'. That's likely to lead to assorted surprises that we can't really do anything about, even if we fixed the CWD issue. So I'm inclined to think this scenario is a don't do that. Having said that, though, it seems like a bad idea to be calling set_pglocale_pgservice() before palloc is functional. It's not at all obvious that that function can't be allowed to use palloc. 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] abort()/segfault when starting postgres in inaccessible CWD
On 2013-10-03 19:07:37 +0200, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: Starting postgres with a CWD that's not readable will trigger an Assert and if those are disabled it presumably will segfault. Yeah, we've discussed that before. I'm not sure it's worth fixing, or that it could be counted on to stay fixed even if we removed the current source(s) of trouble. There's a bigger problem with the scenario you show, which is that the postmaster is started with root's environment variables not postgres'. That's likely to lead to assorted surprises that we can't really do anything about, even if we fixed the CWD issue. So I'm inclined to think this scenario is a don't do that. I have no problem not supporting the scenario of an inaccessible CWD - I'd just like to have a better error message than a segfault... Having said that, though, it seems like a bad idea to be calling set_pglocale_pgservice() before palloc is functional. It's not at all obvious that that function can't be allowed to use palloc. Yes, and it seems hard to control - as proven here - that it doesn't make any calls to functions using palloc() in some edge cases. Greetings, Andres Freund -- Andres Freund http://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
[BUGS] BUG #8498: pg_trgm is missing from windows edb package
The following bug has been logged on the website: Bug reference: 8498 Logged by: Regina Obe Email address: l...@pcorp.us PostgreSQL version: 9.3.0 Operating system: Windows 2003 x 64-bit Description: I noticed when restoring my 9.2 databases to 9.3 that my pg_trgm extension is missing. In looking it doesn't seem to be packaged with the PostgreSQL 9.3 EDB installer (at least for 64-bit) but I assume it is still a separate extension since it's still in separate modules section http://www.postgresql.org/docs/9.3/static/pgtrgm.html Am I missing something? Sorry if this is an oversight on my part. -- 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 #8498: pg_trgm is missing from windows edb package
Disregard my bug complaint. Stupid user error. Thanks, Regina -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
