Re: [HACKERS] Slaying the HYPOTamus
Tom Lane wrote:
> Greg Stark writes:
>
>> If there's a performance advantage then we could add a configure test
>> and define the macro to call hypot(). You said it existed before C99
>> though, how widespread was it? If it's in all the platforms we support
>> it might be reasonable to just go with it.
>>
>
> For one data point, I see hypot() in HPUX 10.20, released circa 1996.
> I suspect we would want a configure test and a substitute function
> anyway. Personally I wouldn't have a problem with the substitute being
> the naive sqrt(x*x+y*y), particularly if it's replacing existing code
> that overflows in the same places.
>
> regards, tom lane
>
>
A hypot() substitute might look something like this psudo-code, this is
how Python does it if the real hypot() is missing.
double hypot( double dx, double dy )
{
double yx;
if( isinf(dx) || ifinf(dy) ) {
return INFINITY;
}
dx = fabs(dx);
dy = fabs(dy);
if (dx < dy) {
double temp = dx;
dx = dy;
dy = temp;
}
if (x == 0.)
return 0.;
else {
yx = dy/dx;
return dx*sqrt(1.0+yx*yx);
}
}
As the following link shows, a lot of care could be put into getting a
substitute hypot() correct.
http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/hypot.c?rev=5677&root=mpfr&view=markup
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Slaying the HYPOTamus
On Sun, Aug 23, 2009 at 07:42, Tom Lane wrote: > Greg Stark writes: >> If there's a performance advantage then we could add a configure test >> and define the macro to call hypot(). You said it existed before C99 >> though, how widespread was it? If it's in all the platforms we support >> it might be reasonable to just go with it. > > For one data point, I see hypot() in HPUX 10.20, released circa 1996. > I suspect we would want a configure test and a substitute function > anyway. Personally I wouldn't have a problem with the substitute being > the naive sqrt(x*x+y*y), particularly if it's replacing existing code > that overflows in the same places. For another data point, Microsoft documentation says: "This POSIX function is deprecated beginning in Visual C++ 2005. Use the ISO C++ conformant _hypot instead." _hypot() has been there since Windows 95, so it shouldn't be a problem to use it - it just needs a define, like we have for some other such functions. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Slaying the HYPOTamus
2009/8/23 Magnus Hagander : > For another data point, Microsoft documentation says: > "This POSIX function is deprecated beginning in Visual C++ 2005. Use > the ISO C++ conformant _hypot instead." > > _hypot() has been there since Windows 95, so it shouldn't be a problem > to use it - it just needs a define, like we have for some other such > functions. FYI, according to [1], this warning is bogus (i.e., "hypot" without underscore should be entirely OK) and will be removed in VS 2010. Nicolas [1] http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=289653> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unicode UTF-8 table formatting for psql text output
On Sun, Aug 23, 2009 at 01:49:02AM +0100, Roger Leigh wrote:
> On Sat, Aug 22, 2009 at 07:42:10PM -0400, Robert Haas wrote:
> > On Sat, Aug 22, 2009 at 2:13 PM, Roger Leigh wrote:
> > > Further minor cleanups to tweak column alignment in a corner case,
> > > and to correct indentation to match the rest of the code.
> >
> > Please read the guidelines here:
> > http://wiki.postgresql.org/wiki/Submitting_a_Patch
> >
> > I don't think it's very helpful to submit a patch intended to do
> > basically one thing split up over 10 threads. The PostgreSQL style is
> > heavyweight commits, and I don't believe that there's any reason to
> > suppose that someone would want to commit any one of these 9 pieces
> > without the other 8.
>
> OK. I have attached a single patch which combines the nine patches
> into one. I did read the patch page above, but it didn't mention
A second patch is attached. This is identical to the previous one,
except that it's re-diffed against the REL8_4_STABLE branch for
anyone who wishes to use this with 8.4.
Again, apologies for the noise with my first set of patches.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 7505cd4..10faeb3 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -21,6 +21,9 @@
#endif
#include
+#ifdef HAVE_LANGINFO_H
+#include
+#endif
#include "catalog/pg_type.h"
#include "pqsignal.h"
@@ -356,38 +359,76 @@ print_unaligned_vertical(const printTableContent *cont, FILE *fout)
/* Aligned text */
//
+static const printTextFormat asciiformat =
+{
+ {
+ { "+", "+", "+" },
+ { "+", "+", "+" },
+ { "+", "+", "+" }
+ },
+ "-",
+ "|"
+};
+
+static const struct printTextFormat utf8format =
+{
+ {
+ /* ┌, ┬, ┐ */
+ { "\342\224\214", "\342\224\254", "\342\224\220" },
+ /* ├, ┼, ┤ */
+ { "\342\224\234", "\342\224\274", "\342\224\244" },
+ /* └, ┴, ┘ */
+ { "\342\224\224", "\342\224\264", "\342\224\230" }
+ },
+ "\342\224\200", /* ─ */
+ "\342\224\202" /* │ */
+};
/* draw "line" */
static void
_print_horizontal_line(const unsigned int ncolumns, const unsigned int *widths,
- unsigned short border, FILE *fout)
+ unsigned short border, printTextRule pos,
+ const printTextFormat *format,
+ FILE *fout)
{
unsigned int i,
j;
+ const printTextLineFormat *lformat = &format->lrule[pos];
+
if (border == 1)
- fputc('-', fout);
+ fputs(format->hrule, fout);
else if (border == 2)
- fputs("+-", fout);
+ {
+ fputs(lformat->leftvrule, fout);
+ fputs(format->hrule, fout);
+ }
for (i = 0; i < ncolumns; i++)
{
for (j = 0; j < widths[i]; j++)
- fputc('-', fout);
+ fputs(format->hrule, fout);
if (i < ncolumns - 1)
{
if (border == 0)
fputc(' ', fout);
else
-fputs("-+-", fout);
+ {
+fputs(format->hrule, fout);
+fputs(lformat->midvrule, fout);
+fputs(format->hrule, fout);
+ }
}
}
if (border == 2)
- fputs("-+", fout);
+ {
+ fputs(format->hrule, fout);
+ fputs(lformat->rightvrule, fout);
+ }
else if (border == 1)
- fputc('-', fout);
+ fputs(format->hrule, fout);
fputc('\n', fout);
}
@@ -397,7 +438,8 @@ _print_horizontal_line(const unsigned int ncolumns, const unsigned int *widths,
* Print pretty boxes around cells.
*/
static void
-print_aligned_text(const printTableContent *cont, FILE *fout)
+print_aligned_text(const printTableContent *cont, const printTextFormat *format,
+ FILE *fout)
{
bool opt_tuples_only = cont->opt->tuples_only;
bool opt_numeric_locale = cont->opt->numericLocale;
@@ -709,7 +751,7 @@ print_aligned_text(const printTableContent *cont, FILE *fout)
int curr_nl_line;
if (opt_border == 2)
-_print_horizontal_line(col_count, width_wrap, opt_border, fout);
+_print_horizontal_line(col_count, width_wrap, opt_border, PRINT_RULE_TOP, format, fout);
for (i = 0; i < col_count; i++)
pg_wcsformat((unsigned char *) cont->headers[i],
@@ -722,7 +764,7 @@ print_aligned_text(const printTableContent *cont, FILE *fout)
while (more_col_wrapping)
{
if (opt_border == 2)
- fprintf(fout, "|%c", curr_nl_line ? '+' : ' ');
+ fprintf(fout, "%s%c", format->vrule, curr_nl_line ? '+' : ' ');
else if (opt_border == 1)
fputc(curr_nl_line ? '+' : ' ', fout);
@@ -753,19 +795,22 @@ print_aligned_text(const printTableContent *cont, FILE *fout)
if (opt_border == 0)
fputc(curr_nl_line ? '+' : ' ', fout);
else
- fprintf(fout, " |%c", curr_nl_line ? '+' : ' ');
+ fprintf(fout, " %s%c", format->vrule, curr_nl_line ? '+' : ' ');
}
}
curr_nl_line++;
if (opt_border == 2)
- fputs(" |", fout);
+{
+ fputc(' ', fout);
+ fputs(format->
Re: [HACKERS] 8.5 release timetable, again
On Sun, Aug 23, 2009 at 1:57 AM, Tom Lane wrote: > Robert Haas writes: >> I posted a note about a week ago which drew far less commentary than I >> expected, regarding the timetable for the release of 8.5. > >> http://archives.postgresql.org/pgsql-hackers/2009-08/msg01256.php > >> Perhaps this is already being discussed on -core, but if so the >> conclusions haven't been shared publicly. > > Core hasn't discussed 8.5 schedule since the discussions that Peter > summarized in the message you cited above. I share your concern that > "release in time for PGCon" isn't very realistic if we don't get more > aggressive about schedule. On the other hand, we didn't get all that > much done in this fest. If we cut back to a three-fest schedule > I think we may succeed in releasing 8.5 early, but only because there > is nothing interesting in it :-(. Dunno where the right balance is. Here is my thinking on that point. We have several major features underway for the September CommitFest, including at least Hot Standby (Simon Riggs), Streaming Replication (Fujii Masao), and Index-Only Scans (Heikki). At the July CommitFest, none of these patches were in a state where they could be seriously reviewed. Simon Riggs and Fujii Masao have both committed to produce reviewable versions by 9/15, and it looks like Heikki will hit that date too, if not beat it. I am assuming that at least Hot Standby and Streaming Replication will likely require two CommitFests to go from the point where they are seriously reviewable to actual commit. So if they hit the 9/15 date, they should make 8.5 even with just three CommitFests. If they don't hit the 9/15 date, then a 3-CommitFest cycle will probably be too short for them to make it in. But if we schedule a fourth CommitFest in January in the hopes of seeing one of those patches committed, then ISTM we're basically speculating that the patch authors will not hit the 9/15 date but that they will hit an 11/15 date. To me, that's an entirely arbitrary and unfounded speculation. On the one hand, both patch authors have said they will hit 9/15, so why should we second-guess them? On the other hand, neither of those patches seems to have made a great deal of progress in the last 7 months, so it's unclear that tacking a few more months onto the schedule will help anything. Furthermore, even if we're right that four CommitFests is the right number to land one of those patches (rather than 3 or 5 or 6 or 7), we're then talking about committing a major feature in the very last CommitFest for this release. We tried that for 8.4 and it wasn't a stunning success. To some degree, what this boils down to is that you can have time-based releases or feature-based releases, but not both. And the problem with feature-based releases in a community environment is that there is no guarantee that patches will be delivered when promised. None of the people developing these major features work for the community and we do not have the ability to control any of their schedules. So saying that we're going to wait for them to be ready is potentially saying that we're going to wait forever. No one is proposing that, but we are sort of trying to read the tea leaves and try to guess when they might be ready and tailor the schedule to it. To me, it seems to make more sense to just decide we're going to ship the release on a time line that works for the project overall. If we get some new features in, good. If they slip a bit past the deadline, well, at least that should hopefully mean that they get committed right at the beginning of the 8.6 cycle. If they slip WAY past the deadline, bummer, but at least we didn't hold up the release to no benefit. I don't think there's anything wrong with having a release that has many small improvements but no major new features, and I think that is the worst that will happen. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] clang's static checker report.
So, after successful, and helpful Saturday with llvm's clang static checker, I decided to run it against postgresql's source code. Result can be seen at: http://zlew.org/postgresql_static_check/scan-build-2009-08-23-5/ . One directory below is the tar file, with the report. I am sure there's plenty of false positives, but I am also quite sure there's many real errors on that list. As I have rather bad experiences with any patches sent here - I hope that's least I can help with. To run clang-check I had to change one of the makefiles slightly, as the postgresql's build system seems to ignore $CC variable completely , always sticking to the one chosen by the configure script. The changed file is ./src/Makefile.global. Around line 210 I included ifdef CC, like that: ifndef CC CC = gcc -no-cpp-precomp GCC = yes endif Which later allowed me to run "scan-build make" without issues. hope that's helpfull. thanks. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] clang's static checker report.
On Sun, Aug 23, 2009 at 4:57 PM, Grzegorz Jaskiewicz wrote: > I am sure there's plenty of false positives, but I am also quite sure > there's many real errors on that list. Do you know how to teach clang about functions which never return? That seems to be causing most of the false positives because it doesn't recognize that our error checks stop execution and avoid the use of the unitialized variables afterwards. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH 5/6] psql: print_aligned_text uses table formatting
On Sun, Aug 23, 2009 at 11:47:02AM -0400, Alvaro Herrera wrote:
> Roger Leigh wrote:
> > Convert print_aligned_text, and its helper function, to use
> > table formatting in place of hardcoded ASCII characters.
>
> > @@ -841,7 +856,10 @@ print_aligned_text(const printTableContent *cont,
> > const printTextFormat *format,
> >
> > /* left border */
> > if (opt_border == 2)
> > - fputs("| ", fout);
> > + {
> > + fputs(format->vrule, fout);
> > + fputc(' ', fout);
> > + }
> > else if (opt_border == 1)
> > fputc(' ', fout);
>
> Wouldn't it be better to do a single fprintf call here instead of
> fputc + fputs?
It's certainly possible to change it; the above might be slightly more
efficient than a call to fprintf since you skip parsing the format
string, but otherwise I have no real preference for one over the
other.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
Re: [HACKERS] clang's static checker report.
On 23 Aug 2009, at 17:41, Greg Stark wrote: On Sun, Aug 23, 2009 at 4:57 PM, Grzegorz Jaskiewicz> wrote: I am sure there's plenty of false positives, but I am also quite sure there's many real errors on that list. Do you know how to teach clang about functions which never return? That seems to be causing most of the false positives because it doesn't recognize that our error checks stop execution and avoid the use of the unitialized variables afterwards. I am not the clang developer, so I honestly have no idea how to do it. But as far as I checked report myself, there's couple 'division by zero', and 'null reference' errors that looked plausible to someone as unfamiliar with the postgresql's source as myself. Like with all static checkers, this one will generate a lot of false positives, and it is the inevitable cost of using such a tool having to go through all errors and sieve out positives yourself. You probably refer to the functions that never return. Sadly, even tho llvm clang is capable of doing so (one of its strengths is linking optimization) - the checker is unable to cross reference files, or so it seems. Well, like I said - l hope at least part of that report is useful. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] clang's static checker report.
On Sun, Aug 23, 2009 at 05:41:24PM +0100, Greg Stark wrote: > On Sun, Aug 23, 2009 at 4:57 PM, Grzegorz Jaskiewicz > wrote: > > I am sure there's plenty of false positives, but I am also quite sure > > there's many real errors on that list. > > Do you know how to teach clang about functions which never return? > That seems to be causing most of the false positives because it > doesn't recognize that our error checks stop execution and avoid the > use of the unitialized variables afterwards. This caused many of the false positives in Coverity's tool as well. The way you work around it is by altering the definition of elog/ereport slightly so that after the usual expansion you add: if( level >= ERROR) exit(1) If it were just a matter of a function that didn't return it'd be easy. What we have is a function that doesn't return depending on the arguments, this is much trickier. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
Re: [HACKERS] clang's static checker report.
On 23 Aug 2009, at 17:41, Greg Stark wrote: Do you know how to teach clang about functions which never return? http://clang-analyzer.llvm.org/annotations.html#attr_noreturn -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] clang's static checker report.
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-5/report-MAVb5D.html#EndPath
for a very positive one - at least from strict language point of view.
consider: float f = 1; f++; printf("%f\n", f);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] clang's static checker report.
On Sun, Aug 23, 2009 at 6:11 PM, Grzegorz Jaskiewicz
wrote:
> http://zlew.org/postgresql_static_check/scan-build-2009-08-23-5/report-MAVb5D.html#EndPath
> for a very positive one - at least from strict language point of view.
>
> consider: float f = 1; f++; printf("%f\n", f);
I believe the maximum value of the numbers involved here is the sample
size which is currently capped at 10,000. But I'm not exactly sure.
--
greg
http://mit.edu/~gsstark/resume.pdf
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] clang's static checker report.
about the false positives around 'null reference'. I'll try sticking exit(1)'s at the end of each macro - and see if that makes most of them go away. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] clang's static checker report.
Greg Stark writes:
> On Sun, Aug 23, 2009 at 6:11 PM, Grzegorz Jaskiewicz
> wrote:
>> http://zlew.org/postgresql_static_check/scan-build-2009-08-23-5/report-MAVb5D.html#EndPath
>> for a very positive one - at least from strict language point of view.
>>
>> consider: float f = 1; f++; printf("%f\n", f);
> I believe the maximum value of the numbers involved here is the sample
> size which is currently capped at 10,000. But I'm not exactly sure.
No, the maximum value is somewhere around the maximum number of rows in
a table, which is on the rough order of 4e12, which is several orders of
magnitude below the threshold at which counting in a double becomes
inaccurate. It is, however, above the point at which counting in an
int32 will overflow. So the alternative would be to assume that we have
a working int64 data type, which doesn't strike me as an improvement
in the portability of the code.
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: [HACKERS] clang's static checker report.
memory leak: http://zlew.org/postgresql_static_check/scan-build-2009-08-23-5/report-46wcmJ.html#EndPath -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH 5/6] psql: print_aligned_text uses table formatting
Roger Leigh wrote:
> Convert print_aligned_text, and its helper function, to use
> table formatting in place of hardcoded ASCII characters.
> @@ -841,7 +856,10 @@ print_aligned_text(const printTableContent *cont, const
> printTextFormat *format,
>
> /* left border */
> if (opt_border == 2)
> - fputs("| ", fout);
> + {
> + fputs(format->vrule, fout);
> + fputc(' ', fout);
> + }
> else if (opt_border == 1)
> fputc(' ', fout);
Wouldn't it be better to do a single fprintf call here instead of
fputc + fputs?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] clang's static checker report.
this one should contain substantialy less false positives, because error functions were marked as the 'never exit' points: http://zlew.org/postgresql_static_check/scan-build-2009-08-23-9/ for the record, here's patch that marks elog, etc as dead ends: Index: src/include/utils/elog.h === RCS file: /projects/cvsroot/pgsql/src/include/utils/elog.h,v retrieving revision 1.101 diff -u -b -r1.101 elog.h --- src/include/utils/elog.h11 Jun 2009 14:49:13 - 1.101 +++ src/include/utils/elog.h23 Aug 2009 19:20:55 - @@ -112,8 +112,8 @@ #define TEXTDOMAIN NULL extern bool errstart(int elevel, const char *filename, int lineno, -const char *funcname, const char *domain); -extern void errfinish(int dummy,...); + const char *funcname, const char *domain) __attribute__((analyzer_noreturn)); +extern void errfinish(int dummy,...) __attribute__((analyzer_noreturn)); extern int errcode(int sqlerrcode); @@ -197,7 +197,7 @@ elog_finish(int elevel, const char *fmt,...) /* This extension allows gcc to check the format string for consistency with the supplied arguments. */ -__attribute__((format(printf, 2, 3))); +__attribute__((format(printf, 2, 3))) __attribute__((analyzer_noreturn)); /* Support for attaching context information to error reports */ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slow commits with heavy temp table usage in 8.4.0
"Todd A. Cook" writes: > Tom Lane wrote: >>> If you roll back a truncate, do you get the expected state? > I did a number of variations on the test below, with and without "on drop > commit", > and similar tests where the "create table" is done before the "begin". After > the > checkpoint, the number of files in the database directory always returned to > the > value before the "begin" (210 in this case). Everything behaved as expected. Thanks for doing the testing. I've applied this patch to CVS HEAD. 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: [HACKERS] clang's static checker report.
Grzegorz Jaskiewicz writes: > for the record, here's patch that marks elog, etc as dead ends: That does not look like the right thing at all, since now the checker will believe that elog(NOTICE) and such don't return. I think you need to use Martijn's suggestion instead. 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: [HACKERS] clang's static checker report.
On 23 Aug 2009, at 20:31, Tom Lane wrote: Grzegorz Jaskiewicz writes: for the record, here's patch that marks elog, etc as dead ends: That does not look like the right thing at all, since now the checker will believe that elog(NOTICE) and such don't return. I think you need to use Martijn's suggestion instead. Still, there are few worrying finds on that list as it is anyway. I hope you guys will find it useful. I'll modify macro according to Martijn's suggesion, and rerun it again. My laptop is pretty slow, so it will be probably another 1-1.5h before I'll get it. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] clang's static checker report.
ok folks, here's the last one for Today: http://zlew.org/postgresql_static_check/scan-build-2009-08-23-29/ tar ball with report can be downloaded from here: http://zlew.org/postgresql_static_check/postgresql_static_check_23rdAugust2009.tar.xz (compressed with lzma's xz tool). here's the patch for elog stuff: Index: src/include/utils/elog.h === RCS file: /projects/cvsroot/pgsql/src/include/utils/elog.h,v retrieving revision 1.101 diff -u -b -r1.101 elog.h --- src/include/utils/elog.h11 Jun 2009 14:49:13 - 1.101 +++ src/include/utils/elog.h23 Aug 2009 22:16:05 - @@ -104,7 +104,7 @@ */ #define ereport_domain(elevel, domain, rest) \ (errstart(elevel, __FILE__, __LINE__, PG_FUNCNAME_MACRO, domain) ? \ -(errfinish rest) : (void) 0) +(errfinish rest) : (void) 0), (elevel >= ERROR) ? exit(1) : 0 #define ereport(elevel, rest) \ ereport_domain(elevel, TEXTDOMAIN, rest) @@ -190,7 +190,7 @@ * elog(ERROR, "portal \"%s\" not found", stmt->portalname); *-- */ -#define elog elog_start(__FILE__, __LINE__, PG_FUNCNAME_MACRO), elog_finish +#define elog(A, ...) elog_start(__FILE__, __LINE__, PG_FUNCNAME_MACRO), elog_finish(A, __VA_ARGS__), (A >= ERROR) ? exit(1) : 0 extern void elog_start(const char *filename, int lineno, const char *funcname); extern void hopefully satisfying everyone. Hope to see few fixes out of that ;) thanks. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH 5/6] psql: print_aligned_text uses table formatting
Roger Leigh wrote: > On Sun, Aug 23, 2009 at 11:47:02AM -0400, Alvaro Herrera wrote: > > Wouldn't it be better to do a single fprintf call here instead of > > fputc + fputs? > > It's certainly possible to change it; the above might be slightly more > efficient than a call to fprintf since you skip parsing the format > string, but otherwise I have no real preference for one over the > other. There are already other fprintf calls in the same function -- I wouldn't worry too much about some hypothetical performance gain. Let's keep things simple and readable. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unicode UTF-8 table formatting for psql text output
Roger Leigh escribió: > +#if (defined(HAVE_LANGINFO_H) && defined(CODESET)) > + if (!strcmp(nl_langinfo(CODESET), "UTF-8")) > + text_format = &utf8format; > +#endif I think you should also try to match to "UTF8", and do it in case-insensitive manner (pg_strcasecmp), just like chklocale.c. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] clang's static checker report.
On Sun, Aug 23, 2009 at 11:16 PM, Grzegorz Jaskiewicz wrote: > ok folks, here's the last one for Today: > > http://zlew.org/postgresql_static_check/scan-build-2009-08-23-29/ This does look better. The first one I looked at looks like a legitimate bug. The nice thing is that this seems to be picking up a lot of error handling cases that we don't bother to have regression tests for. One more request though. Can you configure with --enable-assertions so that it doesn't pick up failures where we have already documented that the case it's claiming can happen can't happen. Those could possibly be bugs but they're more likely to be cases where we know that a given data structure's rep invariant prohibits the combination of states that it's assuming. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] clang's static checker report.
On 24 Aug 2009, at 00:15, Greg Stark wrote: On Sun, Aug 23, 2009 at 11:16 PM, Grzegorz Jaskiewicz wrote: ok folks, here's the last one for Today: http://zlew.org/postgresql_static_check/scan-build-2009-08-23-29/ This does look better. The first one I looked at looks like a legitimate bug. The nice thing is that this seems to be picking up a lot of error handling cases that we don't bother to have regression tests for. true One more request though. Can you configure with --enable-assertions so --enable-cassert, enabled, and also added exit_* in pg_dump to list of functions that never return. new report's at: http://zlew.org/postgresql_static_check/scan-build-2009-08-24-2/ the archive is at : http://zlew.org/postgresql_static_check/postgresql_static_check_24thAugust2009.tar.xz So that the overall 'static check' patch now looks like this: Index: src/bin/pg_dump/pg_backup.h === RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_backup.h,v retrieving revision 1.52 diff -u -b -r1.52 pg_backup.h --- src/bin/pg_dump/pg_backup.h 11 Jun 2009 14:49:07 - 1.52 +++ src/bin/pg_dump/pg_backup.h 23 Aug 2009 23:31:43 - @@ -150,7 +150,7 @@ extern void exit_horribly(Archive *AH, const char *modulename, const char *fmt,...) -__attribute__((format(printf, 3, 4))); +__attribute__((format(printf, 3, 4))) __attribute__((analyzer_noreturn)); /* Lets the archive know we have a DB connection to shutdown if it dies */ Index: src/bin/pg_dump/pg_dump.h === RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_dump.h,v retrieving revision 1.156 diff -u -b -r1.156 pg_dump.h --- src/bin/pg_dump/pg_dump.h 2 Aug 2009 22:14:52 - 1.156 +++ src/bin/pg_dump/pg_dump.h 23 Aug 2009 23:31:43 - @@ -481,7 +481,7 @@ extern void *pg_realloc(void *ptr, size_t size); extern void check_conn_and_db(void); -extern void exit_nicely(void); +extern void exit_nicely(void) __attribute__((analyzer_noreturn)); extern void parseOidArray(const char *str, Oid *array, int arraysize); Index: src/include/postgres.h === RCS file: /projects/cvsroot/pgsql/src/include/postgres.h,v retrieving revision 1.92 diff -u -b -r1.92 postgres.h --- src/include/postgres.h 1 Jan 2009 17:23:55 - 1.92 +++ src/include/postgres.h 23 Aug 2009 23:31:43 - @@ -691,6 +691,6 @@ extern int ExceptionalCondition(const char *conditionName, const char *errorType, -const char *fileName, int lineNumber); + const char *fileName, int lineNumber) __attribute__((analyzer_noreturn)); #endif /* POSTGRES_H */ Index: src/include/utils/elog.h === RCS file: /projects/cvsroot/pgsql/src/include/utils/elog.h,v retrieving revision 1.101 diff -u -b -r1.101 elog.h --- src/include/utils/elog.h11 Jun 2009 14:49:13 - 1.101 +++ src/include/utils/elog.h23 Aug 2009 23:31:43 - @@ -104,7 +104,7 @@ */ #define ereport_domain(elevel, domain, rest) \ (errstart(elevel, __FILE__, __LINE__, PG_FUNCNAME_MACRO, domain) ? \ -(errfinish rest) : (void) 0) +(errfinish rest) : (void) 0), (elevel >= ERROR) ? exit(1) : 0 #define ereport(elevel, rest) \ ereport_domain(elevel, TEXTDOMAIN, rest) @@ -190,7 +190,7 @@ * elog(ERROR, "portal \"%s\" not found", stmt->portalname); *-- */ -#define elog elog_start(__FILE__, __LINE__, PG_FUNCNAME_MACRO), elog_finish +#define elog(A, ...) elog_start(__FILE__, __LINE__, PG_FUNCNAME_MACRO), elog_finish(A, __VA_ARGS__), (A >= ERROR) ? exit(1) : 0 extern void elog_start(const char *filename, int lineno, const char *funcname); That's it folks for Today, gotta go to sleep. Have fun... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Install from Source On Windows - University of Sydney Research
Hello, I have downloaded and built the 8.2.4 postgreSQL from source. This was done by running the build.bat file under src\tools\msvc. I do get a few errors with some contrib projects, but I do not care about them. When i do install(install.pl), there is a destination directory created. Now my question is how do i run postgreSQL from within here. Is there a command line script etc. for this ? Or how can i connect it to pgADMin i.e. the new exe as well as bki file. Thanks Kushal
[HACKERS] help:how to write a planner_hook and other hooks in pg
Hi all: I am doing some experiments programming on PG. I tried to modify planner and I find the ‘planner_hook’ in source code, but I don’t know how to use it. Anybody knows? If any code sample, very precious. Thanks 张茂森 ZhangMaosen
Re: [HACKERS] help:how to write a planner_hook and other hooks in pg
Hello http://archives.postgresql.org/pgsql-patches/2007-05/msg00421.php regards Pavel Stehule 2009/8/24 张中 : > Hi all: > > I am doing some experiments programming on PG. I tried to modify planner and > I find the ‘planner_hook’ in source code, but I don’t know how to use it. > > Anybody knows? If any code sample, very precious. > > Thanks > > > > 张茂森 ZhangMaosen > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 答复: [HACKERS] help:how to write a plan ner_hook and other hooks in pg
Thank you very much! ZhangMaosen -邮件原件- 发件人: Pavel Stehule [mailto:pavel.steh...@gmail.com] 发送时间: 2009年8月24日 10:54 收件人: 张中 抄送: pgsql-hackers@postgresql.org 主题: Re: [HACKERS] help:how to write a planner_hook and other hooks in pg Hello http://archives.postgresql.org/pgsql-patches/2007-05/msg00421.php regards Pavel Stehule 2009/8/24 张中 : > Hi all: > > I am doing some experiments programming on PG. I tried to modify planner and > I find the ‘planner_hook’ in source code, but I don’t know how to use it. > > Anybody knows? If any code sample, very precious. > > Thanks > > > > 张茂森 ZhangMaosen > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Install from Source On Windows - University of Sydney Research
On Sun, Aug 23, 2009 at 11:16 AM, Kushal Vaghani wrote: > I have downloaded and built the 8.2.4 postgreSQL from source. This was done > by running the build.bat file under src\tools\msvc. I do get a few errors > with some contrib projects, but I do not care about them. > > When i do install(install.pl), there is a destination directory created. Now > my question is how do i run postgreSQL from within here. Is there a command > line script etc. for this ? Or how can i connect it to pgADMin i.e. the new > exe as well as bki file. I think you are posting to the wrong mailing list. http://www.postgresql.org/community/lists/ The description of this list is: "The PostgreSQL developers team lives here. Discussion of current development issues, problems and bugs, and proposed new features. If your question cannot be answered by people in the other lists, and it is likely that only a developer will know the answer, you may re-post your question in this list. You must try elsewhere first!" You should probably try this question on pgsql-general or pgsql-novice, but at a guess, you're going to need to run the initdb program to initialize your database cluster, and then pg_ctl to fire up the server. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
