Re: [SPAM] Re: [HACKERS] posix_fadvise v22
Peter Eisentraut pete...@gmx.net writes: The way I read this is that this was a temporary kernel/libc mismatch in a development version of Debian 3 years ago that was fixed within 2 months of being reported and was never released to the general public. So it would be on the same level as any of a million temporary breakages in Linux distributions under development. This is incorrect, as the problem was in fact present on Red Hat and presumably all other distros as well. Unless there are other reports of this problem, I wouldn't bother testing or working around this at all. If people are running PostgreSQL 8.4+ on Debian unstable June 2005 with kernel 2.4, they cannot be helped. While I would like to agree with that position, I can't help noticing lines 2438-2461 of xlog.c, which represent the still-smoking wreckage of our last attempt to do something with posix_fadvise. It's not that old either --- we gave up on it less than three years ago: http://archives.postgresql.org/pgsql-hackers/2006-06/msg01481.php I think at a minimum there should be a manual configuration switch (ie something in pg_config_manual.h) to allow the builder to disable use of posix_fadvise, even if configure thinks it's there. Depending on buildfarm results we may have to do more than that. BTW, I intend to un-disable the xlog change when committing the fadvise patch. In for a penny, in for a pound ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [SPAM] Re: [HACKERS] posix_fadvise v22
Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: The way I read this is that this was a temporary kernel/libc mismatch in a development version of Debian 3 years ago that was fixed within 2 months of being reported and was never released to the general public. So it would be on the same level as any of a million temporary breakages in Linux distributions under development. This is incorrect, as the problem was in fact present on Red Hat and presumably all other distros as well. Unless there are other reports of this problem, I wouldn't bother testing or working around this at all. If people are running PostgreSQL 8.4+ on Debian unstable June 2005 with kernel 2.4, they cannot be helped. While I would like to agree with that position, I can't help noticing lines 2438-2461 of xlog.c, which represent the still-smoking wreckage of our last attempt to do something with posix_fadvise. It's not that old either --- we gave up on it less than three years ago: http://archives.postgresql.org/pgsql-hackers/2006-06/msg01481.php I think at a minimum there should be a manual configuration switch (ie something in pg_config_manual.h) to allow the builder to disable use of posix_fadvise, even if configure thinks it's there. Depending on buildfarm results we may have to do more than that. BTW, I intend to un-disable the xlog change when committing the fadvise patch. In for a penny, in for a pound ... I assumed if effective_io_concurrency 2 that no posix_fadvise() calls would be made. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [SPAM] Re: [HACKERS] posix_fadvise v22
I think at a minimum there should be a manual configuration switch (ie something in pg_config_manual.h) to allow the builder to disable use of posix_fadvise, even if configure thinks it's there. Depending on buildfarm results we may have to do more than that. This seems pretty pointless, since there is already a GUC to control the behavior, and the default is off. The only value here would be if you could demonstrate that even with effective_io_concurrency set to 1 there is a significant performance dropoff. But that would probably be an argument for rejecting the patch outright, not adding a compile-time switch. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [SPAM] Re: [HACKERS] posix_fadvise v22
Gregory Stark wrote: Peter Eisentraut pete...@gmx.net writes: On Friday 02 January 2009 06:49:57 Greg Stark wrote: The guc run-time check is checking for known-buggy versions of glibc using sysconf to check what version of glibc you have. Could you please mention the bug number in the relevant source code comments? It's Debian bug# 312406 which was fixed in Debian release 2.3.5-3. So it's probably one of these but searching for posix_fadvise doesn't find anything in their bug tracker: The way I read this is that this was a temporary kernel/libc mismatch in a development version of Debian 3 years ago that was fixed within 2 months of being reported and was never released to the general public. So it would be on the same level as any of a million temporary breakages in Linux distributions under development. Unless there are other reports of this problem, I wouldn't bother testing or working around this at all. If people are running PostgreSQL 8.4+ on Debian unstable June 2005 with kernel 2.4, they cannot be helped. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [SPAM] Re: [HACKERS] posix_fadvise v22
Peter Eisentraut pete...@gmx.net writes: On Friday 02 January 2009 06:49:57 Greg Stark wrote: The guc run-time check is checking for known-buggy versions of glibc using sysconf to check what version of glibc you have. Could you please mention the bug number in the relevant source code comments? It's Debian bug# 312406 which was fixed in Debian release 2.3.5-3. So it's probably one of these but searching for posix_fadvise doesn't find anything in their bug tracker: Version 2.3.6 * The following bugs are resolved with this release: 38, 253, 549, 622, 653, 721, 758, 851, 877, 915, 934, 955, 961, 1016, 1037, 1076, 1079, 1080, 1081, 1082, 1083, 1084, 1085, 1086, 1087, 1088, 1090, 1091, 1092, 1093, 1094, 1095, 1096, 1097, 1098, 1099, 1100, 1101, 1102, 1103, 1104, 1105, 1106, 1107, 1108, 1109, 1110, , 1112, 1113, 1125, 1137, 1138, 1249, 1250, 1251, 1252, 1253, 1254, 1350, 1358, 1394, 1438, 1498, 1534 Visit http://sources.redhat.com/bugzilla/ for the details of each bug. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
