Re: [BUGS] [ODBC] Segmentation Fault in Postgres server when using psqlODBC
(2013/06/12 1:26), Andres Freund wrote:
On 2013-06-11 19:20:57 +0300, Heikki Linnakangas wrote:
On 11.06.2013 19:04, Joshua Berry wrote:
Hiroshi Inoue has developed the attached patch to correct the issue that
was reported. More of the dialogue can be found in the pgsql-odbc list.
I tried to follow that thread over at pgsql-odbc, but couldn't quite
understand what the problem is. Did you have a test program to reproduce it?
Or failing that, what is the sequence of protocol messages that causes the
problem?
I'd guess creating a SQL level WITH HOLD cursor and then fetching that
via the extended protocol, outside the transaction, should do the trick.
OK I made a test C program which reproduces the crash.
The program uses libpq and a hack.
I attached the program.
Please modify the connect operation suitable for your environment.
Note that the connection should be non-ssl.
Also add error checkings if needed.
regards,
Hiroshi Inoue
#include libpq-fe.h
#ifdef WIN32
#include WinSock2.h
#else
#include sys/types.h
#include sys/socket.h
#endif
#define MY_CUR mycur
int main(int argc, const char **argv)
{
const char *connstr;
PGconn *conn;
PGresult *result;
int sock;
int len, count;
if (argc 1)
connstr = argv[1];
else
connstr = host=localhost port=5432 dbname=x user=x password=x;
conn = PQconnectdb(connstr);
result = PQexec(conn, declare MY_CUR cursor with hold for select * from generate_series(1, 2) as i);
if (PQgetssl(conn) != NULL)
{
printf(Use non-ssl connection\n);
return 1;
}
sock = PQsocket(conn);
if (sock 0)
{
printf(socket error\n);
return 1;
}
// send execute message
send(sock, E, 1, 0);
len = sizeof(len) + strlen(MY_CUR) + 1 + sizeof(count);
len = htonl(len);
send(sock, (const char *) len, sizeof(len), 0);
send(sock, MY_CUR, strlen(MY_CUR) + 1, 0);
count = htonl(1);
send(sock, (const char *) count, sizeof(count), 0);
result = PQexec(conn, close MY_CUR);
if (!result)
printf(close error\n);
else
printf(result error=%s\n, PQresultErrorMessage(result));
PQfinish(conn);
return 0;
}
--
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] [ODBC] Segmentation Fault in Postgres server when using psqlODBC
Hiroshi Inoue in...@tpf.co.jp writes: OK I made a test C program which reproduces the crash. The program uses libpq and a hack. Oh, thank you, I was just about to go spend an hour doing 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] [ODBC] Segmentation Fault in Postgres server when using psqlODBC
Hiroshi Inoue in...@tpf.co.jp writes: (2013/06/12 1:26), Andres Freund wrote: I'd guess creating a SQL level WITH HOLD cursor and then fetching that via the extended protocol, outside the transaction, should do the trick. OK I made a test C program which reproduces the crash. The program uses libpq and a hack. I've committed a fix for this. Thanks again for the test case. 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] [ODBC] Segmentation Fault in Postgres server when using psqlODBC
Hiroshi, Tom, and Andres, On Thu, Jun 13, 2013 at 12:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: Hiroshi Inoue in...@tpf.co.jp writes: OK I made a test C program which reproduces the crash. The program uses libpq and a hack. I've committed a fix for this. Thanks again for the test case. Many thanks for your time and effort in debugging, testing, and patching this. Kind Regards, -Joshua
[BUGS] BUG #8228: Unexpected set-valued function with varchar(n) but not varchar
The following bug has been logged on the website: Bug reference: 8228 Logged by: David Johnston Email address: david.g.johns...@gmail.com PostgreSQL version: 9.0.13 Operating system: Ubuntu Linux 10.04 Description: The following query results in SQL Error: ERROR: set-valued function called in context that cannot accept a set SELECT *, CASE WHEN id = 2 THEN (regexp_matches(input_string,'^0*([1-9]\d+)$'))[1] ELSE input_string END::varchar(30) AS o_l2_a FROM ( VALUES (1,''), (2,'49404'),(3,'FROM 1000876') ) l0_src (id, input_string) The nearly identical query: SELECT *, CASE WHEN id = 2 THEN (regexp_matches(input_string,'^0*([1-9]\d+)$'))[1] ELSE input_string END::varchar AS o_l2_a FROM ( VALUES (1,''), (2,'49404'),(3,'FROM 1000876') ) l0_src (id, input_string) returns 3 records as expected. The only difference is that the cast at the end of the case construct uses varchar(30) in the failure situation but a plain varchar in the successful situation. version PostgreSQL 9.0.13 on x86_64-unknown-linux-gnu, compiled by GCC gcc-4.4.real (Ubuntu 4.4.3-4ubuntu5) 4.4.3, 64-bit Using substring(CASE ... END::varchar,1,30) also results in the set-valued function error message. David J. -- 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 #8228: Unexpected set-valued function with varchar(n) but not varchar
david.g.johns...@gmail.com writes: The following query results in SQL Error: ERROR: set-valued function called in context that cannot accept a set SELECT *, CASE WHEN id = 2 THEN (regexp_matches(input_string,'^0*([1-9]\d+)$'))[1] ELSE input_string END::varchar(30) AS o_l2_a FROM ( VALUES (1,''), (2,'49404'),(3,'FROM 1000876') ) l0_src (id, input_string) Hm, interesting example. What seems to be happening is that during evaluation of the SELECT list for the first VALUES row, the CASE expression doesn't call regexp_matches() but just returns the ELSE expression. The ExecMakeFunctionResult() call for the cast function then decides that the function's argument expression doesn't return a set, so it changes the node execution pointer so that subsequent executions go through the much simpler ExecMakeFunctionResultNoSets() execution function. And then that spits up when on the next row, the argument expression *does* return a set :-( You could work around that using the trick documented in the regexp_matches documentation to force it to return exactly one row, ie interpose a sub-SELECT: regression=# SELECT *, CASE WHEN id = 2 THEN (select (regexp_matches(input_string,'^0*([1-9]\d+)$'))[1]) ELSE input_string END::varchar(30) AS o_l2_a FROM ( VALUES (1,''), (2,'49404'),(3,'FROM 1000876') ) l0_src (id, input_string); id | input_string | o_l2_a +--+-- 1 | | 2 | 49404| 49404 3 | FROM 1000876 | FROM 1000876 (3 rows) Not sure about non-hack fixes. I guess we need to analyze can-it-return-a-set statically instead of believing the first execution result, but that might add an unpleasant amount of startup overhead. 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 #8229: Dropuser and create user segfault for users in ldap
The following bug has been logged on the website: Bug reference: 8229 Logged by: Matthew Schumacher Email address: mat...@aptalaska.com PostgreSQL version: 9.2.4 Operating system: Slackware Linux 14.0 x86_64 Description: I have a slackware 14.0 host, and have added nss_ldap-265 then set nsswitch to use ldap for users. When calling dropuser as an ldap user, it segfaults. Here is the backtrace: schu@ancdev:~$ gdb dropuser GNU gdb (GDB) 7.5 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-slackware-linux. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/dropuser...done. (gdb) run -U postgres asdf Starting program: /usr/bin/dropuser -U postgres asdf warning: Could not load shared library symbols for linux-vdso.so.1. Do you need set solib-search-path or set sysroot? [Thread debugging using libthread_db enabled] Using host libthread_db library /lib64/libthread_db.so.1. dropuser: removal of role asdf failed: ERROR: role asdf does not exist Program received signal SIGSEGV, Segmentation fault. 0x7787115c in free () from /lib64/libc.so.6 (gdb) bt #0 0x7787115c in free () from /lib64/libc.so.6 #1 0x75e8ff30 in ?? () from /usr/lib64/libldap-2.4.so.2 #2 0x75e9003f in ?? () from /usr/lib64/libldap-2.4.so.2 #3 0x00618870 in ?? () #4 0x0001 in ?? () #5 0x7fffe240 in ?? () #6 0x75eba7e1 in _fini () from /usr/lib64/libldap-2.4.so.2 #7 0x7fffe240 in ?? () #8 0x77de9c97 in _dl_fini () from /lib64/ld-linux-x86-64.so.2 Backtrace stopped: previous frame inner to this frame (corrupt stack?) schu@ancdev:~$ id uid=10001(schu) gid=1(netgroup) groups=1(netgroup),100(users) Please let me know if I can provide more information. -- 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 #8228: Unexpected set-valued function with varchar(n) but not varchar
David Johnston david.g.johns...@gmail.com writes: The issue with the regexp_matches call generally is that absence of a g modifier means that the set-returning function will never return a set. It would seem to make more sense to not make that a modifier but instead have one function defined to return a set (i.e., the current definition) and another one defined to return a simply text[]. Well, it does return a set, namely either zero or one row. The point of the sub-SELECT workaround is to transform the zero-row case to a scalar NULL. I tend to agree that this API wasn't that well thought out, but it's really not regexp_matches()'s fault that you're running into this problem --- rather, it's the fact that one arm of the CASE can return a set while the other can't. 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 #8228: Unexpected set-valued function with varchar(n) but not varchar
On Thu, Jun 13, 2013 at 4:02 PM, Tom Lane t...@sss.pgh.pa.us wrote: david.g.johns...@gmail.com writes: The following query results in SQL Error: ERROR: set-valued function called in context that cannot accept a set SELECT *, CASE WHEN id = 2 THEN (regexp_matches(input_string,'^0*([1-9]\d+)$'))[1] ELSE input_string END::varchar(30) AS o_l2_a FROM ( VALUES (1,''), (2,'49404'),(3,'FROM 1000876') ) l0_src (id, input_string) Hm, interesting example. What seems to be happening is that during evaluation of the SELECT list for the first VALUES row, the CASE expression doesn't call regexp_matches() but just returns the ELSE expression. Does all this explain why it DOES work if the cast on the END is a plain varchar? Not sure about non-hack fixes. I guess we need to analyze can-it-return-a-set statically instead of believing the first execution result, but that might add an unpleasant amount of startup overhead. regards, tom lane The issue with the regexp_matches call generally is that absence of a g modifier means that the set-returning function will never return a set. It would seem to make more sense to not make that a modifier but instead have one function defined to return a set (i.e., the current definition) and another one defined to return a simply text[]. This would make using the call in a scalar context easier. Is there any reason why a UDF defined as such would have a problem? The set-returning one accepting the parameter is nice since you can toggle global/single within the same query - but in many use-cases only the single-match mode is desired. Are there any other functions that have this same risk profile that would increase the applicability of such a patch? David J.
Re: [BUGS] BUG #8225: logging options don't change after reload
j...@pgexperts.com writes: What happens is that we change various logging options in postgresql.conf, then reload, and every so often, the settings don't seem to take effect even though they are logged as being changed. FWIW, the parameter changed messages are logged when the postmaster process updates its values of the GUCs. The particular options you're complaining of here, though, are not actually checked in the postmaster --- they're used in the checkpointer or syslogger processes respectively. So one theory about this would be that those processes aren't absorbing the GUC updates, perhaps because the SIGHUP signals the postmaster should be sending them are getting lost. I'm not sure how we might track down the cause though. How various are the platforms you're seeing this on? 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 #8225: logging options don't change after reload
On Jun 13, 2013, at 4:50 PM, Tom Lane t...@sss.pgh.pa.us wrote: j...@pgexperts.com writes: What happens is that we change various logging options in postgresql.conf, then reload, and every so often, the settings don't seem to take effect even though they are logged as being changed. FWIW, the parameter changed messages are logged when the postmaster process updates its values of the GUCs. The particular options you're complaining of here, though, are not actually checked in the postmaster --- they're used in the checkpointer or syslogger processes respectively. So one theory about this would be that those processes aren't absorbing the GUC updates, perhaps because the SIGHUP signals the postmaster should be sending them are getting lost. I'm not sure how we might track down the cause though. How various are the platforms you're seeing this on? I've seen it on 9.0, 9.1 and 9.2 recent versions running on Ubuntu 10.04/12.04, Centos 5/6 and Scientific Linux 6. I've not tried on Windows. Interestingly, it will often pick them up if you wait a few seconds and send it another reload. I've been seeing it for a while, but haven't reported it since I couldn't come up with a reproducible test case. -- 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 #8225: logging options don't change after reload
Jeff Frost j...@pgexperts.com writes: On Jun 13, 2013, at 4:50 PM, Tom Lane t...@sss.pgh.pa.us wrote: ... So one theory about this would be that those processes aren't absorbing the GUC updates, perhaps because the SIGHUP signals the postmaster should be sending them are getting lost. Interestingly, it will often pick them up if you wait a few seconds and send it another reload. Hmm, that definitely lends some credence to the lost-signal theory, since another reload would cause the postmaster to again signal all its children, and this time the signal might go through. But I still have no idea how we might debug further. You could possibly try something like strace'ing the processes, but it seems fairly likely that the Heisenberg principle would apply if you did. 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 #8225: logging options don't change after reload
Tom Lane wrote: j...@pgexperts.com writes: What happens is that we change various logging options in postgresql.conf, then reload, and every so often, the settings don't seem to take effect even though they are logged as being changed. FWIW, the parameter changed messages are logged when the postmaster process updates its values of the GUCs. The particular options you're complaining of here, though, are not actually checked in the postmaster --- they're used in the checkpointer or syslogger processes respectively. So one theory about this would be that those processes aren't absorbing the GUC updates, perhaps because the SIGHUP signals the postmaster should be sending them are getting lost. Another idea is that postmaster sees the changed file but the other processes see an older version of it -- which would be pretty bizarre, but .. -- Á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] BUG #8225: logging options don't change after reload
On Jun 13, 2013, at 5:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: Jeff Frost j...@pgexperts.com writes: On Jun 13, 2013, at 4:50 PM, Tom Lane t...@sss.pgh.pa.us wrote: ... So one theory about this would be that those processes aren't absorbing the GUC updates, perhaps because the SIGHUP signals the postmaster should be sending them are getting lost. Interestingly, it will often pick them up if you wait a few seconds and send it another reload. Hmm, that definitely lends some credence to the lost-signal theory, since another reload would cause the postmaster to again signal all its children, and this time the signal might go through. But I still have no idea how we might debug further. You could possibly try something like strace'ing the processes, but it seems fairly likely that the Heisenberg principle would apply if you did. What I don't understand is the new log file being created from the new log_filename setting but then nothing being logged into it. Is it the postmaster which creates that file? I would've thought it would be the logger process? -- 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 #8225: logging options don't change after reload
Jeff Frost j...@pgexperts.com writes: What I don't understand is the new log file being created from the new log_filename setting but then nothing being logged into it. Is it the postmaster which creates that file? I would've thought it would be the logger process? Hm, I hadn't focused on that --- that *is* pretty bizarre. The postmaster creates the log file initially before forking the syslogger, but subsequent rotations are handled by the syslogger process. Is it possible that your systems are running on the hairy edge of ENFILE limits? I notice that the syslogger will silently fail to rotate if it gets ENFILE while trying to open the new log file. That doesn't look like it'd explain the lack of log_checkpoint activity, though. Also, usually people notice this state because everything else on the box starts to fall over ... 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 #8225: logging options don't change after reload
On Jun 13, 2013, at 7:48 PM, Tom Lane t...@sss.pgh.pa.us wrote: Jeff Frost j...@pgexperts.com writes: What I don't understand is the new log file being created from the new log_filename setting but then nothing being logged into it. Is it the postmaster which creates that file? I would've thought it would be the logger process? Hm, I hadn't focused on that --- that *is* pretty bizarre. The postmaster creates the log file initially before forking the syslogger, but subsequent rotations are handled by the syslogger process. Is it possible that your systems are running on the hairy edge of ENFILE limits? I notice that the syslogger will silently fail to rotate if it gets ENFILE while trying to open the new log file. That doesn't look like it'd explain the lack of log_checkpoint activity, though. Also, usually people notice this state because everything else on the box starts to fall over ... These are definitely busy systems, but usually not running close to the edge, I'll see if I can make a test case using pgbench on 9.2.4. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
