Re: [HACKERS] src/tools/msvc usage instructions
On Tue, 3 Oct 2006, Magnus Hagander wrote: Looks like the gendef script is failing. Check the contents of release\postgres\postgres.def - it should have thousands of symbols, but I'm willing to bet it's empty... It contains one word: EXPORTS. I assume this means it is empty. What should I do about it? Is there something I can check to see why this is failing? //Magnus -- Honesty is the best policy, but insanity is a better defense. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] src/tools/msvc usage instructions
Looks like the gendef script is failing. Check the contents of release\postgres\postgres.def - it should have thousands of symbols, but I'm willing to bet it's empty... It contains one word: EXPORTS. I assume this means it is empty. What should I do about it? Is there something I can check to see why this is failing? Yup. Delete the DEF file and run the gendef command manually (see the project file for commandline, IIRC there are no parameters, but just to be sure). I'm wondering if you're seeing the samre problem as Joachim Wieland (off-list conversation) where the output from dumpbin.exe goes to the console instead of the pipe in the perl program... //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] src/tools/msvc usage instructions
On Tue, 3 Oct 2006, Magnus Hagander wrote: Looks like the gendef script is failing. Check the contents of release\postgres\postgres.def - it should have thousands of symbols, but I'm willing to bet it's empty... It contains one word: EXPORTS. I assume this means it is empty. What should I do about it? Is there something I can check to see why this is failing? Yup. Delete the DEF file and run the gendef command manually (see the project file for commandline, IIRC there are no parameters, but just to be sure). I'm wondering if you're seeing the samre problem as Joachim Wieland (off-list conversation) where the output from dumpbin.exe goes to the console instead of the pipe in the perl program... I was just checking this, I read the gendef script, and saw it would short-circut if postgres.def existed, so I deleted the file and ran a build in visual studio again and it printed all kinds of dumpbin output into the visual stuio output window, which I remember it did before. Since you have seen this before, what was the fix (or was there one)? -- It's raisins that make Post Raisin Bran so raisiny ... ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] src/tools/msvc usage instructions
Delete the DEF file and run the gendef command manually (see the project file for commandline, IIRC there are no parameters, but just to be sure). I'm wondering if you're seeing the samre problem as Joachim Wieland (off-list conversation) where the output from dumpbin.exe goes to the console instead of the pipe in the perl program... I was just checking this, I read the gendef script, and saw it would short-circut if postgres.def existed, so I deleted the file and ran a build in visual studio again and it printed all kinds of dumpbin output into the visual stuio output window, which I remember it did before. Since you have seen this before, what was the fix (or was there one)? No fix yet :-( Haven't had the time to dig into it properly, but I think we can now safely say it's not a local issue in Joachims build env :-) If you just run a dumpbin command (the same way) manually with a foo, does it redirect it properly then? Or is dumpbin for some reason not writing on stdout? It runs perfectly on two completely separate build envs I have here :-O Could someone who knows perl a bit more than me take a look at that script (src/tools/msvc/gendef.pl) and see if I'm doing something really stupid there? May be that I'm homesick when looking at the code and can't spot obvious things... Also, could it possibly be perl version dependent? I'm on ActiveState 5.8.7 build 815. //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] src/tools/msvc usage instructions
On Tue, 3 Oct 2006, Magnus Hagander wrote:
Funky.
Can you try having it run the dumpbin command into a tempfile, and then
open-and-read that tempfile, to see if that makes a difference?
(Assuming you know enough perl to do that, of course)
Doing it as
system(dumpbin /symbols $_ $tmpfn)
still output to the console.
But, I got it to work with the attached patch to the script. Note the use
of the handy /out:FILE parameter to dumpbin for redirecting the output ;)
Also, I changed the file glob to *.obj from * since I got an error trying
to run dumpbin on BuildLog.htm which is obviously not an object file.
Hopefully this is correct?
--
Q: Why do mountain climbers rope themselves together?
A: To prevent the sensible ones from going home.Index: gendef.pl
===
RCS file: X:\\postgres\\cvsuproot/pgsql/src/tools/msvc/gendef.pl,v
retrieving revision 1.1
diff -c -r1.1 gendef.pl
*** gendef.pl 4 Sep 2006 21:30:40 - 1.1
--- gendef.pl 3 Oct 2006 07:20:26 -
***
*** 10,18
print Generating $defname.DEF from directory $ARGV[0]\n;
! while ($ARGV[0]/*) {
print .;
! open(F,dumpbin /symbols $_|) || die Could not open $_\n;
while (F) {
s/\(\)//g;
next unless /^\d/;
--- 10,23
print Generating $defname.DEF from directory $ARGV[0]\n;
! while ($ARGV[0]/*.obj) {
print .;
! #open(F,dumpbin /symbols $_|) || die Could not open $_\n;
! s/\//\\/g;
! system(dumpbin /symbols $_ /out:$_.syms) == 0 or die Could not
dumpbin $_\n;
! my $tmpfn = $_.syms;
! open(F, $tmpfn) || die Could not open $tmpfn\n;
!
while (F) {
s/\(\)//g;
next unless /^\d/;
***
*** 31,36
--- 36,42
push @def, $pieces[6];
}
close(F);
+ unlink $tmpfn;
}
print \n;
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Faster StrNCpy
I'm still interested to experiment with MemSet-then-strlcpy for namestrcpy, but given the LENCPY results this may be a loser too. Um, why not strlcpy then MemSet the rest ? Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] src/tools/msvc usage instructions
On Tue, Oct 03, 2006 at 12:27:47AM -0700, Jeremy Drake wrote: On Tue, 3 Oct 2006, Magnus Hagander wrote: Funky. Can you try having it run the dumpbin command into a tempfile, and then open-and-read that tempfile, to see if that makes a difference? (Assuming you know enough perl to do that, of course) Doing it as system(dumpbin /symbols $_ $tmpfn) still output to the console. I could redirect it with ... 21 file IIRC, the /out:FILE seems to be the cleaner approach however :-) Joachim ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] timestamptz alias
Hi, Jim, Jim Nasby wrote: There's a difference between promoting and withholding info. I'd rather see us explicitly state which is preferred and why. Here's a small patch that adds an appropriate explanation. Index: doc/src/sgml/datatype.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/datatype.sgml,v retrieving revision 1.176 diff -u -r1.176 datatype.sgml --- doc/src/sgml/datatype.sgml 22 Sep 2006 16:20:00 - 1.176 +++ doc/src/sgml/datatype.sgml 3 Oct 2006 09:14:32 - @@ -1372,6 +1372,17 @@ /para /note + note +para + productnamePostgreSQL/productname also supports the aliases + typetimestamptz/type for typetimestamp with time zone/type + and typetimetz/type for typetime with time zone/type. It + is recommended to avoid them, as the more verbose variants comply + to the SQL standard, and thus are more portable. But there are no + plans to drop the short aliases in future versions. +/para + /note + para typetime/type, typetimestamp/type, and typeinterval/type accept an optional precision value HTH, Markus -- Markus Schaber | Logical TrackingTracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org signature.asc Description: OpenPGP digital signature
Re: [HACKERS] [PATCHES] Bad bug in fopen() wrapper code
Magnus, is this the right fix? Well, actually msdn states: Return Value If successful, _setmode returns the previous translation mode. A return value of -1 indicates an error So, shouldn't we be testing for -1 instead of 0 ? The thing is probably academic, since _setmode is only supposed to fail on invalid file handle or invalid mode. So basically, given our code, it should only fail if filemode is (O_BINARY | O_TEXT) both flags set. Andreas ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Faster StrNCpy
On Tue, Oct 03, 2006 at 10:24:10AM +0200, Zeugswetter Andreas DCP SD wrote: I'm still interested to experiment with MemSet-then-strlcpy for namestrcpy, but given the LENCPY results this may be a loser too. Um, why not strlcpy then MemSet the rest ? That's what strncpy() is supposed to be doing. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Faster StrNCpy
I'm still interested to experiment with MemSet-then-strlcpy for namestrcpy, but given the LENCPY results this may be a loser too. Um, why not strlcpy then MemSet the rest ? That's what strncpy() is supposed to be doing. Yes, but it obviously does not in some ports, and that was the main problem as I interpreted it. Andreas ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] PG qsort vs. Solaris
Postgres has own implementation of qsort. It is used only for Solaris, because in some cases Solaris implementation was terrible slow. Now, New qsort is present in the Solaris from version 9 update 6 and I performed some quick test and the speed is very similarly with pg implementation see bellow. The Solaris qsort only does not have test for preordered array. Is it time to remove PG qsort and use libc version for solaris 9, 10...? There some useful links: solaris qsort implementation http://cvs.opensolaris.org/source/xref/on/usr/src/common/util/qsort.c discuss about qsort http://momjian.postgresql.org/cgi-bin/pgtodo?qsort Regards Zdenek PS: Test program is located on http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4489885 There is test result: mode 1 2 3 4 5 6 7 8 pg 3.440 54.259 42.251 40.967 38.214 29.730 21.668 39.142 pg2 39.492 53.598 44.697 40.546 38.027 29.572 21.598 38.756 solaris 41.207 41.957 41.873 41.616 35.895 29.502 26.906 39.492 Pg2 test is without sort array prechecking. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Bad bug in fopen() wrapper code
Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes: If successful, _setmode returns the previous translation mode. A return value of -1 indicates an error So, shouldn't we be testing for -1 instead of 0 ? I think the usual convention is to test for 0, unless there are other negative return values that are legal. This is doubtless a silly cycle-shaving habit (on nearly all machines, test against 0 is a bit more compact than test against other constants), but it is a widespread habit anyway, and if you sometimes do it one way and sometimes another you just create a distraction for readers. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Faster StrNCpy
On Tue, Oct 03, 2006 at 01:56:57PM +0200, Zeugswetter Andreas DCP SD wrote: I'm still interested to experiment with MemSet-then-strlcpy for namestrcpy, but given the LENCPY results this may be a loser too. Um, why not strlcpy then MemSet the rest ? That's what strncpy() is supposed to be doing. Yes, but it obviously does not in some ports, and that was the main problem as I interpreted it. I think re-writing libc isn't really a PostgreSQL goal. strlcpy() is theoretically cheaper than strncpy() as it is not required by any standard to do as much work. memcpy() is cheaper because it can be more easily parallelized, and can increment multiple bytes with each loop interval, as it does not need to slow down to look for a '\0' in each byte. strlcpy() than memset() the remaining is strncpy(). If you are suggesting that a moderately tuned version of strncpy() be used in the ports directory, this is an option, but it can't be faster than strlcpy(). It's not possible. It would come down to whether there was a security requirements that the last bytes were '\0' or not. I haven't seen anybody mention this as a requirement. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Generic Monitoring Framework with DTrace patch
Robert Treat wrote: Also should installation.sgml mention the issueswith building 32 vs 64 bit binaries I'm not convinced there is an issue. dtrace will build the right binaries by default. If you're messing with mixed environments *and* delve into dtrace, you should probably be able to figure this out yourself. and/or the issue with static functions? The issue with that is simply that there is no released operating system version for which the dtrace support works. I'm not sure what to do about that. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Faster StrNCpy
Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes: I'm still interested to experiment with MemSet-then-strlcpy for namestrcpy, but given the LENCPY results this may be a loser too. Um, why not strlcpy then MemSet the rest ? Two reasons: * The main point is to do the zeroing using word-wide operations, and if you do the above then memset will probably be facing a zeroing request that is neither word-aligned nor word-length. It may be able to recover (doing it partly byte-wide and partly word-wide), but this will easily eat up the time savings of skipping the first couple words. * On compilers that treat memset as a builtin, there are significant advantages to doing memset with a constant length: the compiler might be able to unroll the loop entirely. (I was annoyed to find that FC5's gcc on x86_64 seems to understand very well how to inline a constant length memcpy, but not memset :-(.) I did actually do some experiments with the above yesterday, and found that it was a significant win on an old x86 (with about a 10-byte source string) but about a wash on newer architectures. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Faster StrNCpy
[EMAIL PROTECTED] writes: ... It would come down to whether there was a security requirements that the last bytes were '\0' or not. I haven't seen anybody mention this as a requirement. I think it is a requirement for namestrcpy (because the result might end up on disk), but not elsewhere. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] tsearch2 error msg
search=# select to_tsquery('foo bar');
ERROR: syntax error
Might want to enhance that message to include the information that it's
parsing the tsquery that's failing? I originally had it as part of a
much larger query, and it took me a while to remember that it's tsearch
that spits out that very generic error message.
//Magnus
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
[HACKERS] src/backend/parser/parse_expr.c:exprTypmod() question
I'm working on user-defined typmod and try to move all typmod calculations into
type-specific functions. But there is a strange place:
/*
* exprTypmod -
*returns the type-specific attrmod of the expression, if it can be
*determined. In most cases, it can't and we return -1.
*/
int32
exprTypmod(Node *expr)
{
skip
case T_Const:
{
/* Be smart about string constants... */
Const *con = (Const *) expr;
switch (con-consttype)
{
case BPCHAROID:
if (!con-constisnull)
{
int32 len =
VARSIZE(DatumGetPointer(con-constvalue)) - VARHDRSZ;
/* if multi-byte, take len and find # characters */
if (pg_database_encoding_max_length() 1)
len =
pg_mbstrlen_with_len(VARDATA(DatumGetPointer(con-constvalue)), len);
return len + VARHDRSZ;
}
break;
default:
break;
}
}
break;
So, I can't understand why it's needed at all. First, it's returns length as
typmod, second, it looks like optimization, but I don't believe in significant
benefits... It's a constant coming from query. Am I missing something?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] tsearch2 error msg
Might want to enhance that message to include the information that it's
parsing the tsquery that's failing? I originally had it as part of a
much larger query, and it took me a while to remember that it's tsearch
that spits out that very generic error message.
It possible, but not for 8.2 :(
BTW, try
# select plainto_tsquery('foo bar');
plainto_tsquery
-
'foo' 'bar'
(1 row)
It parses plain text and makes tsquery. Function exists only in 8.2 - some later
we add docs about changes in tsearch2.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] tsearch2 error msg
Might want to enhance that message to include the information
that
it's parsing the tsquery that's failing? I originally had it as
part
of a much larger query, and it took me a while to remember that
it's
tsearch that spits out that very generic error message.
It possible, but not for 8.2 :(
Ok :-( Might want to put on TIDI?
BTW, try
# select plainto_tsquery('foo bar');
plainto_tsquery
-
'foo' 'bar'
(1 row)
It parses plain text and makes tsquery. Function exists only in 8.2
- some later we add docs about changes in tsearch2.
Ah, just what i've been looking for. The tsearch2 enhancements in 8.2
just get better and better :-)
(And I'm working on 8.2beta, so it's not a problem)
//Magnus
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] PG qsort vs. Solaris
Zdenek Kotala [EMAIL PROTECTED] writes: Is it time to remove PG qsort and use libc version for solaris 9, 10...? I have no particular desire to introduce a version number check until we have to. If you can show that the newer versions have a qsort that substantially *out-performs* ours, it would be worth doing that, but merely being competitive isn't enough to make it worth the trouble. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] src/backend/parser/parse_expr.c:exprTypmod() question
Teodor Sigaev [EMAIL PROTECTED] writes: I'm working on user-defined typmod and try to move all typmod calculations into type-specific functions. But there is a strange place: /* * exprTypmod - *returns the type-specific attrmod of the expression, if it can be *determined. In most cases, it can't and we return -1. */ ... So, I can't understand why it's needed at all. First, it's returns length as typmod, second, it looks like optimization, but I don't believe in significant benefits... It's a constant coming from query. Am I missing something? I think that comes into play in cases like the following: postgres=# create table qux as (select 'foo'::bpchar, 'foo'::varchar, 0::numeric); SELECT postgres=# \d qux Table public.qux Column | Type| Modifiers -+---+--- bpchar | character(3) | varchar | character varying | numeric | numeric | Note that unlike most of the built-in types bpchar doesn't actually make much sense without a typmod. NUMERIC, VARCHAR, etc can all exist without a typmod and behave sensibly but bpchar without a typmod would just be a varchar. The default for CHARACTER without a typmod is CHAR(1) which is what happens if you do ::CHAR but I guess we don't want to do that for ::bpchar. On the other hand I can manually create a table with a column of type bpchar and it does behave like a varchar with strange comparison semantics so I guess you could argue bpchar without a typmod isn't completely meaningless. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [pgsql-hackers] Daily digest v1.6352 (22 messages)
On Mon, 2006-10-02 at 12:02 -0300, Shaunak Godbole wrote: Hi, We are trying to introduce access control. For this we have to rewrite the input query by replacing each relation by its corresponding authorized view. I assume from this that you are trying to implement something like Oracle's Virtual Private Database. If you need access controls at the row or column level, and do not want to implement this whole thing yourself, please take a look at Veil (http://veil.projects.postgresql.org/) which can already accomplish the same sort of thing, though in a different way. If Veil is insufficient for your needs in some way, I'd be interested to hear about it. __ Marc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] timestamptz alias
Markus Schaber [EMAIL PROTECTED] writes: Here's a small patch that adds an appropriate explanation. If we're going to document these aliases, what of float4, float8, and bool? Also, although the docs mention int2/int4/int8, it's more or less left to the reader's imagination to deduce what they are. Perhaps it'd be better to provide a small table of recognized type aliases, rather than inserting equivalent notes into three or four places. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] src/backend/parser/parse_expr.c:exprTypmod() question
Gregory Stark [EMAIL PROTECTED] writes: Teodor Sigaev [EMAIL PROTECTED] writes: I'm working on user-defined typmod and try to move all typmod calculations into type-specific functions. But there is a strange place: Note that unlike most of the built-in types bpchar doesn't actually make much sense without a typmod. You may be reading too much into it. Looking at the patch that introduced exprTypmod(), I think I may have just been interested in avoiding an unnecessary length-coercion function call when assigning a constant that was already of the correct length to a CHAR(N) column. I concur with Teodor that embedding this type-specific knowledge into exprTypmod probably isn't all that great an idea. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] src/tools/msvc usage instructions
Magnus Hagander [EMAIL PROTECTED] writes: which looks like they figured out that they needed to check for MicroSoft C explicitly. I have no idea why they do not define __STDC__ however. Can we just define __STDC__ when compiling that file (or rather, when compiling any bison-generated output file)? Or is that likely to cause *other* issues? That seems pretty risky. Better to use the /Za switch or whatever it was to get the compiler to assert it for itself. We have precedent for adding yes-we'd-like-a-standard-compiler-please switches where necessary, for instance adding -Ae to CFLAGS for HP's compiler. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] timestamptz alias
Tom Lane wrote: Markus Schaber [EMAIL PROTECTED] writes: Here's a small patch that adds an appropriate explanation. If we're going to document these aliases, what of float4, float8, and bool? Also, although the docs mention int2/int4/int8, it's more or less left to the reader's imagination to deduce what they are. Perhaps it'd be better to provide a small table of recognized type aliases, rather than inserting equivalent notes into three or four places. you mean like the table here? http://momjian.us/main/writings/pgsql/sgml/datatype.html cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] src/tools/msvc usage instructions
From my experience with Visual C++, using /Za isn't a good idea. When you set that, the compiler become very pedantic about following the ANSI speck to the letter, which usually means common posix functions aren't available under their normal names (The ansi spec says if the compiler defines functions beyond what in the spec, it's recommended they start with _ to not conflict with application name space). Compatibility with GCC is reduced when you use /Za. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane Sent: Tuesday, October 03, 2006 8:51 AM To: Magnus Hagander Cc: Jeremy Drake; PostgreSQL Hackers Subject: Re: [HACKERS] src/tools/msvc usage instructions Magnus Hagander [EMAIL PROTECTED] writes: which looks like they figured out that they needed to check for MicroSoft C explicitly. I have no idea why they do not define __STDC__ however. Can we just define __STDC__ when compiling that file (or rather, when compiling any bison-generated output file)? Or is that likely to cause *other* issues? That seems pretty risky. Better to use the /Za switch or whatever it was to get the compiler to assert it for itself. We have precedent for adding yes-we'd-like-a-standard-compiler-please switches where necessary, for instance adding -Ae to CFLAGS for HP's compiler. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] timestamptz alias
Moving to -docs On Tue, Oct 03, 2006 at 12:13:46PM -0400, Andrew Dunstan wrote: Tom Lane wrote: Markus Schaber [EMAIL PROTECTED] writes: Here's a small patch that adds an appropriate explanation. If we're going to document these aliases, what of float4, float8, and bool? Also, although the docs mention int2/int4/int8, it's more or less left to the reader's imagination to deduce what they are. Perhaps it'd be better to provide a small table of recognized type aliases, rather than inserting equivalent notes into three or four places. you mean like the table here? http://momjian.us/main/writings/pgsql/sgml/datatype.html An issue I've seen with the docs is that for chapters that have a lot of sections (such as 8), the section list at the start of each chapter fills the screen, so it's easy to miss the fact that there's more info beneath the list (which is wy presumably most folks never knew that table existed). I think the ideal way to handle this would be to put the table of contents in a side-bar and flow the text around it. But that could be a real bear to do in docbook/sgml, so perhaps it would be better to just force the TOC for each chapter onto it's own page (and ensure the overview/introduction text shows up in the TOC). -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] tsearch2 error msg
On Oct 3, 2006, at 10:49 , Oleg Bartunov wrote:
On Tue, 3 Oct 2006, Magnus Hagander wrote:
BTW, try
# select plainto_tsquery('foo bar');
plainto_tsquery
-
'foo' 'bar'
(1 row)
It parses plain text and makes tsquery. Function exists only in 8.2
- some later we add docs about changes in tsearch2.
Current docs, covering 8.2 is available from http://www.sai.msu.su/
~megera/wiki/tsearch2slides
This is great news- previously, I was using various regexes to
sanitize input into user-accessible search fields. Would it be build
in some simple query language?
sam AND spade
blue OR yellow
(same AND spade) OR (blue AND yellow)
Obviously, the conjunctions would need to be defined on a per-locale
basis.
-M
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] PG qsort vs. Solaris
On Tue, 2006-10-03 at 10:48 -0400, Tom Lane wrote: I have no particular desire to introduce a version number check until we have to. If you can show that the newer versions have a qsort that substantially *out-performs* ours Are there any platform-local variants of qsort() that substantially outperform our implementation? (I don't remember hearing of one, but I might have missed it.) Given the time that has been spent working around the braindamaged behavior of qsort() on various platforms, I would be more inclined to *always* use our qsort() instead of the platform's version. That way we'd get the same behavior across all platforms, and we can at least verify that our implementation behaves reasonably for the special cases we're interested in (presorted input, many-equal-keys, etc.), and doesn't do crazy stuff like randomly switch to merge sort for certain inputs. -Neil ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] tsearch2 error msg
This is great news- previously, I was using various regexes to sanitize input into user-accessible search fields. Would it be build in some simple query language? sam AND spade blue OR yellow (same AND spade) OR (blue AND yellow) That's exactly to_tsquery syntax, just change AND to and OR to |. :) So, if you can validate AND/OR then you can validate /| syntax or validate AND/OR and change they to tsquery's equivalents. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] 7.4, 8.0 branches @ itanium2 icc
Sergey E. Koposov [EMAIL PROTECTED] writes: Having recently tried to build 7.4, and 8.0 branches on Itanium2 with ICC 7.4 is not going to work with ICC anyway without considerably more extensive changes (eg, configure hacking). It might make sense to apply this patch to 8.0 but I can't get all that excited about it. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] 7.4, 8.0 branches @ itanium2 icc
On Tue, 3 Oct 2006, Tom Lane wrote: Sergey E. Koposov [EMAIL PROTECTED] writes: Having recently tried to build 7.4, and 8.0 branches on Itanium2 with ICC 7.4 is not going to work with ICC anyway without considerably more extensive changes (eg, configure hacking). It might make sense to apply this patch to 8.0 but I can't get all that excited about it. It worked for me with both 7.4 8.0 after applying my patch. (and make check worked ...) ( at least with icc 9.1.x) Regards, Sergey *** Sergey E. Koposov Max Planck Institute for Astronomy/Sternberg Astronomical Institute Tel: +49-6221-528-349 Web: http://lnfm1.sai.msu.ru/~math E-mail: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] src/tools/msvc usage instructions
which looks like they figured out that they needed to check for MicroSoft C explicitly. I have no idea why they do not define __STDC__ however. Can we just define __STDC__ when compiling that file (or rather, when compiling any bison-generated output file)? Or is that likely to cause *other* issues? That seems pretty risky. Better to use the /Za switch or whatever it was to get the compiler to assert it for itself. We have precedent for adding yes-we'd-like-a-standard-compiler-please switches where necessary, for instance adding -Ae to CFLAGS for HP's compiler. Unfortunatly, that breaks things so bad it's not even funny. For a file as simple as src/port/win32error.c I get hundreds of errors - many in the win32 header files. Seems you ar eont allowed to pull in the win32 API headers without that flag - just the basic ANSI ones. So that' sjust not going to fly. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] PG qsort vs. Solaris
Neil Conway [EMAIL PROTECTED] writes: Given the time that has been spent working around the braindamaged behavior of qsort() on various platforms, I would be more inclined to *always* use our qsort() instead of the platform's version. I've been heard to argue against that in the past, but I'm beginning to see the merit of the idea. One good reason for doing it is that we could stop worrying about the possibility of large-scale memory leaks due to erroring out of glibc's qsort --- in particular it would be OK to add CHECK_FOR_INTERRUPTS into the comparison callback as was requested recently. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] src/tools/msvc usage instructions
Magnus Hagander [EMAIL PROTECTED] writes: That seems pretty risky. Better to use the /Za switch or whatever it was to get the compiler to assert it for itself. Unfortunatly, that breaks things so bad it's not even funny. Um. Well, then we tell people not to use bison 2.1 with MSVC. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] src/tools/msvc usage instructions
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: That seems pretty risky. Better to use the /Za switch or whatever it was to get the compiler to assert it for itself. Unfortunatly, that breaks things so bad it's not even funny. Um. Well, then we tell people not to use bison 2.1 with MSVC. Or add a configure test to prevent it, and display a proper error message. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] src/tools/msvc usage instructions
That seems pretty risky. Better to use the /Za switch or whatever it was to get the compiler to assert it for itself. Unfortunatly, that breaks things so bad it's not even funny. Um. Well, then we tell people not to use bison 2.1 with MSVC. Or add a configure test to prevent it, and display a proper error message. Yeha, I will do this. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Tsearch2 and Snowball
I'm looking at some of the code in contrib/tsearch2/snowball and see that the code there is *generated* code. The Snowball stemmer produces this C code in much the same way bison reads gram.y My understanding is that the Snowball code moves forwards regularly and there are many other stemmers we could be including with the distribution. Snowball has a BSD licence: http://snowball.tartarus.org/license.php Would it be possible to include the Snowball source directly and allow its execution to be part of the make process for tsearch2? Or have configure check for Snowball at make time? At the very least it would be good to have a Readme file explaining how to modify the Snowball stemmer and regenerate for tsearch2. That would then encourage people to improve the stemmers, as well as allow us to include French and Spanish versions etc.. Perhaps we should ask translators to provide stop word lists for their languages. It seems a shame to have docs in so many languages, but no language capability for Tsearch2. Also, why do we have another crc32 implementation in there? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] src/tools/msvc usage instructions
Magnus Hagander [EMAIL PROTECTED] writes: Or add a configure test to prevent it, and display a proper error message. Yeha, I will do this. As long as we're touching that code: the existing test for too-old bison seriously sucks, because all that it does is to print a warning that most people will never notice among all the other spewage from configure. However, erroring out is not better, because for people who're building from a tarball it won't matter what they have. The Right Thing is to print a warning and set up for the missing script to be invoked instead of bison if the files actually need to be built. It looks like all that's needed is to reset YACC to after determining that it's the wrong version, but that should be tested. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] src/tools/msvc usage instructions
Magnus Hagander [EMAIL PROTECTED] writes: Or add a configure test to prevent it, and display a proper error message. Yeha, I will do this. As long as we're touching that code: the existing test for too-old bison seriously sucks, because all that it does is to Oh, I'm not touching configure. This error was for the MSVC build, and it doesn't use configure. I'll be happy to leave the autoconf-fu to others :-) //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] Bad bug in fopen() wrapper code
I agree that this code is both wrong and unreadable (although in practice the _setmode will probably never fail, which is why our attention hasn't been drawn to it). Is someone going to submit a patch? I'm hesitant to change the code myself since I'm not in a position to test it. I can look at fixing that. Is it something we want to do for 8.2, or wait until 8.3? If there's a hidden bug, I guess 8.2? Magnus, is this the right fix? Claudio sent me some small updates to the patch; updated version attached. Tested, passes all regression tests on MingW. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Another idea for dealing with cmin/cmax
ITAGAKI Takahiro [EMAIL PROTECTED] writes: ITL-like approach is more efficient than per-tuple XIDs unless all tuples in a page are locked at the same time. However, MAXTRANS and PCTFREE issues may bother us. I'm not sure how Oracle gets away with MAXTRANS. Somehow it seems to never arise as a practical problem yet it seems like there must be instances where it would cause a serious problems. It's worse for Postgres since as I understand it Oracle only needs to track transaction ids that are actively locking the record. Postgres needs to track transaction ids for the inserting and deleting transaction even when there's no lock (or no lock remaining). I can imagine having a scheme where there's a short list of transaction ids in the footer and then each tuple just stores an index into that list. If you had space for 16 transaction ids set aside then you could store xmin and xmax in a single byte for example. If the space set aside for these transaction ids is full when you're inserting i suppose you could just go back to the FSM for another page. But I don't see any way out when you're deleting. You have to mark xmax one way or another and if there's no space left in the footer and you only have 4 bits in the tuple what are you going to do? As an aside doing vacuum freeze more aggressively might reduce the pressure on these ITL slots. But I don't see any way to guarantee a slot is available for xmax when deleting. We would need some sort of scheme where the space for transaction ids is able to grow but we're already growing from both ends of the page. We would either have to interleave transaction ids with line pointers or store them on another special page somewhere. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] PG qsort vs. Solaris
Neil Conway [EMAIL PROTECTED] writes: Given the time that has been spent working around the braindamaged behavior of qsort() on various platforms, I would be more inclined to *always* use our qsort() instead of the platform's version. I spent a bit of time looking into why we hadn't chosen to do this already. The remaining uncertainty was expressed by Greg Stark: glibc's mergesort has a small advantage over quicksort in terms of the average number of calls of the comparison function, and considering that we tend to use pretty heavyweight comparison functions, that seems like it ought to favor the mergesort. Nobody bothered to check this out back in March when the last discussion died off. I made a small hack in tuplesort.c to actually count the comparison-function calls, and then ran this test case with both our qsort and glibc's (from Fedora Core 5 current glibc): set trace_sort TO 1; set client_min_messages TO log; set work_mem TO '200MB'; select count(*) from (select random()::text from generate_series(1,100) order by 1) ss; In C locale the text comparison is relatively quick, and I see results like glibc: LOG: begin tuple sort: nkeys = 1, workMem = 204800, randomAccess = f LOG: performsort starting: CPU 0.15s/2.39u sec elapsed 2.54 sec LOG: performsort done: CPU 0.18s/7.09u sec elapsed 7.27 sec LOG: internal sort ended, 102701 KB used, 18674655 comparisons: CPU 0.18s/7.38u sec elapsed 7.56 sec ours: LOG: begin tuple sort: nkeys = 1, workMem = 204800, randomAccess = f LOG: performsort starting: CPU 0.18s/2.34u sec elapsed 2.51 sec LOG: performsort done: CPU 0.18s/5.18u sec elapsed 5.36 sec LOG: internal sort ended, 102701 KB used, 21277970 comparisons: CPU 0.18s/5.46u sec elapsed 5.64 sec In en_US.utf8 locale, strcoll is pretty slow, but: glibc: LOG: begin tuple sort: nkeys = 1, workMem = 204800, randomAccess = f LOG: performsort starting: CPU 0.17s/2.35u sec elapsed 2.52 sec LOG: performsort done: CPU 0.19s/15.94u sec elapsed 16.13 sec LOG: internal sort ended, 102701 KB used, 18674910 comparisons: CPU 0.19s/16.23u sec elapsed 16.43 sec ours: LOG: begin tuple sort: nkeys = 1, workMem = 204800, randomAccess = f LOG: performsort starting: CPU 0.18s/2.30u sec elapsed 2.49 sec LOG: performsort done: CPU 0.18s/15.30u sec elapsed 15.48 sec LOG: internal sort ended, 102701 KB used, 20972345 comparisons: CPU 0.18s/15.58u sec elapsed 15.76 sec If you're sorting integer or float keys it's a lot worse: postgres=# select count(*) from (select random() from generate_series(1,100) order by 1) ss; glibc: LOG: begin tuple sort: nkeys = 1, workMem = 204800, randomAccess = f LOG: performsort starting: CPU 0.16s/0.70u sec elapsed 0.86 sec LOG: performsort done: CPU 0.18s/5.10u sec elapsed 5.28 sec LOG: internal sort ended, 71452 KB used, 18674509 comparisons: CPU 0.18s/5.38u sec elapsed 5.56 sec ours: LOG: begin tuple sort: nkeys = 1, workMem = 204800, randomAccess = f LOG: performsort starting: CPU 0.11s/0.74u sec elapsed 0.86 sec LOG: performsort done: CPU 0.11s/3.22u sec elapsed 3.33 sec LOG: internal sort ended, 71452 KB used, 21123160 comparisons: CPU 0.11s/3.50u sec elapsed 3.62 sec So basically, glibc's qsort is bad enough that even a 10%-more-comparisons advantage doesn't save it. I propose that we do the following: 1. Switch to using port/qsort.c all the time. 2. Add a qsort_arg function that is identical to qsort except it also passes a void pointer through to the comparison function. This will allow us to get rid of the non-reentrant static variable and extra level of function call in tuplesort.c. 3. Insert a CHECK_FOR_INTERRUPTS() call as was requested back in July. With glibc out of the way, there's no longer a reason to fear memory leakage from cancelling a sort. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] vcbuild bison check
Magnus Hagander [EMAIL PROTECTED] writes: Attached patch adds a version check for bison when running the vc++ build. Shouldn't it be looking for 2.1 as well? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] PG qsort vs. Solaris
Tom Lane wrote: Zdenek Kotala [EMAIL PROTECTED] writes: Is it time to remove PG qsort and use libc version for solaris 9, 10...? I have no particular desire to introduce a version number check until we have to. If you can show that the newer versions have a qsort that substantially *out-performs* ours, it would be worth doing that, but merely being competitive isn't enough to make it worth the trouble. The implementation in the solaris uses same ideas like postgres implementation exclude sort array detection. There are small difference with threshold when median uses 9 items and threshold for insertion sort. Performance is similarly - no winer (only on sorted array). Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Pie-in-sky dreaming about reworking tuple layout entirely
I can't shake the feeling that merely tweaking the way our varlenas work with a shortvarlena or with compressed varlena headers is missing the real source of our headaches. It seems very strange to me to be trying to step through a tuple with length bits at the head of every field. It's a lot of work spent dealing with a terribly inconvenient format when we can pick the format to be whatever we like. If we were designing this from scratch I don't think would have picked this approach at all. We would instead store offsets to every field whose offset isn't static in the header so we can jump straight to a field without having to look at all the previous fields at all. I feel this would be far to invasive a change for me to contemplate currently though. I don't know enough about what consequences it would have. I just wanted to get the idea out there in case sometime down the line, perhaps even not for several releasees, I might be prepared or someone else might be prepared to tackle such a project. It might make a lot of things cleaner and easier such as dealing with user defined fixed length fields whose length depends on the typmod. What I picture would be basically be an array of offsets into the tuple. A field would be the data from its offset to the next. We would have to store an offset to the end of the tuple as well, and probably another field with the length of the array so we can find the end quickly without counting bits in the null bitmap. I also picture a kind of compression that store offsets modulo 256 as 1-byte offsets with a separate list of where the 256 byte boundaries are. That means we would probably still need a heap_deform tuple that steps through the list of offsets, null bitmap, and 256-boundary list, and builds a in-memory list of pointers to the fields with nulls for the null values. Actually for the in-memory storage instead of a simple array of pointers I picture an array of structs where each struct contains a pointer to the field, a 4-byte length value, and the typmod (for a total of 12 bytes on a 32-bit platform and 16 bytes on a 64-bit platform). Then instead of passing a Datum directly to functions we would pass one of these structs (possibly by reference?). That means no function would ever have to store the length of a field internal to the field itself, and it could always depend on having the typmod available. In real terms this actually doesn't reduce space usage, in fact it probably increases it. It's effectively storing a 1-byte header for every field even if it's something like an integer. But you could imagine some further refinements. If you store all the non-varlena fields first then you can just start the list of offsets at the first varlena. heap_deform tuple could step through the tupldescriptor and null bitmap first setting up the offsets to any field with an attlen without the help of any offsets. (Incidentally, to do that there's a tricky bit. You have to be able to put new fixed length fields before varlena fields even if they're added later. But that means you need to know they're missing on the old records so you can't insert them out of order in the null bitmap. So the null bitmap would have to be in the order they were added, and even if that's not the order they appear physically or the order they appear logically. Even more confusing than the original plan that got shot down as too confusing already.) The main inefficiency in this is it would mean passing 3x as much data (only 2x as much data on 64-bit platforms) to functions. But given the way functions are called with a pointer to 100-element arrays it doesn't seem like that should be a big concern. The upside is that data types could use different size storage for different typmods without having to define whole new types based on internal implementation details the user doesn't know about. NUMERIC could internally use integer for some typmods and just perform integer arithmetic. It wouldn't have to reserve any bits to indicate the scale or precision of the number since the typmod is available whenever it's processing an element from the table and it's passed around with the field by the system. There's no security concern because the system is responsible for passing the typmod, not the caller. Only C code would be able to construct arbitrary typmods; SQL or Pl/PgSQL would have to use casts to safely set the typmod on their output. On advantage of passing around this meta information automatically is that it obviates the need for many core data types whose main advantage is that they use more efficient storage than is possible with domains or user defined types. The recently discussed UUID type, for example, offers nothing that couldn't be implemented with a user-defined type using bytea storage internally -- except for the fact that it doesn't store an extra 4 bytes of length header in every value. Another advantage is that we wouldn't need a whole slew of functions in the
Re: [HACKERS] [PATCHES] MSVC build broken (again)
Magnus Hagander [EMAIL PROTECTED] writes: The code around errcode is definitly messy. In CVS now, it actually renames *our* errcode() function to __msvc_errcode, and exports this from postgres.exe. This is definitly very borken. Would it be possible to move the whole crtdefs.h block into win32.h? This would cause it to be included after stdio.h and friends, which maybe is too late, but taking it out of c.h would be a lot cleaner. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] vcbuild bison check
Attached patch adds a version check for bison when running the vc++ build. Shouldn't it be looking for 2.1 as well? 2.1 is the broken one. It seemd it was fixed in 2.2, but 2.2 isn't realeased for win32 from what I cna tell. //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PG qsort vs. Solaris
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: Given the time that has been spent working around the braindamaged behavior of qsort() on various platforms, I would be more inclined to *always* use our qsort() instead of the platform's version. snip I propose that we do the following: 1. Switch to using port/qsort.c all the time. 1.5 Move it to another directory - e.g. backend/utils/sort? 2. Add a qsort_arg function that is identical to qsort except it also passes a void pointer through to the comparison function. This will allow us to get rid of the non-reentrant static variable and extra level of function call in tuplesort.c. 3. Insert a CHECK_FOR_INTERRUPTS() call as was requested back in July. With glibc out of the way, there's no longer a reason to fear memory leakage from cancelling a sort. 4. replace KR function definition by the ANSI style :-) regards Zdenek ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] MSVC build broken (again)
The code around errcode is definitly messy. In CVS now, it actually renames *our* errcode() function to __msvc_errcode, and exports this from postgres.exe. This is definitly very borken. Would it be possible to move the whole crtdefs.h block into win32.h? This would cause it to be included after stdio.h and friends, which maybe is too late, but taking it out of c.h would be a lot cleaner. Nope, it needs to go before stdio.h and friends, unfortunatly. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Generic Monitoring Framework with DTrace patch
Peter Eisentraut wrote: Robert Treat wrote: Also should installation.sgml mention the issueswith building 32 vs 64 bit binaries I'm not convinced there is an issue. dtrace will build the right binaries by default. If you're messing with mixed environments *and* delve into dtrace, you should probably be able to figure this out yourself. and/or the issue with static functions? The issue with that is simply that there is no released operating system version for which the dtrace support works. I'm not sure what to do about that. Peter, dtrace is part of Solaris 10 as well. Latest version of opensolaris does not have this problem, but Solaris 10 will solve this in the update 3. Zdenek ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] MSVC build broken (again)
Magnus Hagander [EMAIL PROTECTED] writes: Would it be possible to move the whole crtdefs.h block into win32.h? Nope, it needs to go before stdio.h and friends, unfortunatly. OK, patch committed as-is then. The whole thing still looks awfully icky though, particularly the way pg_config_os.h is included in one place for WIN32 and a different place everywhere else. Would it make sense to split win32.h into two files, one that's included in the normal pg_config_os.h place and one included after the system includes? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] vcbuild bison check
Magnus Hagander [EMAIL PROTECTED] writes: Attached patch adds a version check for bison when running the vc++ build. Shouldn't it be looking for 2.1 as well? 2.1 is the broken one. Exactly. So we should reject it. It seemd it was fixed in 2.2, but 2.2 isn't realeased for win32 from what I cna tell. What's that got to do with rejecting 2.1? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] Bad bug in fopen() wrapper code
Applied.
---
Bruce Momjian wrote:
Bruce Momjian wrote:
Magnus Hagander wrote:
Now, I still twist my head around the lines:
if ((fd = _open_osfhandle((long) h, fileFlags O_APPEND)) 0
||
(fileFlags (O_TEXT | O_BINARY) (_setmode(fd, fileFlags
(O_TEXT
| O_BINARY)) 0)))
Without having studied it closely, it might also highlight a bug
on
failure of the second clause -- if the _setmode fails, shouldn't
_close be called instead of CloseHandle, and -1 returned?
(CloseHandle would still be called on failure of the
_open_osfhandle,
obviously)
I agree that this code is both wrong and unreadable (although in
practice the _setmode will probably never fail, which is why our
attention hasn't been drawn to it). Is someone going to submit a
patch? I'm hesitant to change the code myself since I'm not in a
position to test it.
I can look at fixing that. Is it something we want to do for 8.2, or
wait until 8.3? If there's a hidden bug, I guess 8.2?
Magnus, is this the right fix?
Claudio sent me some small updates to the patch; updated version
attached.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
[ text/x-diff is unsupported, treating like TEXT/PLAIN ]
Index: src/port/open.c
===
RCS file: /cvsroot/pgsql/src/port/open.c,v
retrieving revision 1.15
diff -c -c -r1.15 open.c
*** src/port/open.c 24 Sep 2006 17:19:53 - 1.15
--- src/port/open.c 3 Oct 2006 01:16:43 -
***
*** 105,113
}
/* _open_osfhandle will, on error, set errno accordingly */
! if ((fd = _open_osfhandle((long) h, fileFlags O_APPEND)) 0 ||
! (fileFlags (O_TEXT | O_BINARY) (_setmode(fd, fileFlags
(O_TEXT | O_BINARY)) 0)))
CloseHandle(h); /* will not affect errno */
return fd;
}
--- 105,119
}
/* _open_osfhandle will, on error, set errno accordingly */
! if ((fd = _open_osfhandle((long) h, fileFlags O_APPEND)) 0)
CloseHandle(h); /* will not affect errno */
+ else if (fileFlags (O_TEXT | O_BINARY)
+ _setmode(fd, fileFlags (O_TEXT | O_BINARY)) 0)
+ {
+ _close(fd);
+ return -1;
+ }
+
return fd;
}
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] PG qsort vs. Solaris
On Tue, 2006-10-03 at 15:44 -0400, Tom Lane wrote: I propose that we do the following: 1. Switch to using port/qsort.c all the time. 2. Add a qsort_arg function that is identical to qsort except it also passes a void pointer through to the comparison function. This will allow us to get rid of the non-reentrant static variable and extra level of function call in tuplesort.c. 3. Insert a CHECK_FOR_INTERRUPTS() call as was requested back in July. With glibc out of the way, there's no longer a reason to fear memory leakage from cancelling a sort. +1 from me. I can implement this (for 8.3, naturally), unless you'd prefer to do it yourself. -Neil ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] tsearch2 error msg
On Tue, Oct 03, 2006 at 04:34:06PM +0200, Magnus Hagander wrote:
search=# select to_tsquery('foo bar');
ERROR: syntax error
Seems to me, at the very least, the message should be:
ERROR: tsearch: syntax error
Then people have an idea where it comes from.
Have a nice day,
--
Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/
From each according to his ability. To each according to his ability to
litigate.
signature.asc
Description: Digital signature
Re: [HACKERS] PG qsort vs. Solaris
Neil Conway [EMAIL PROTECTED] writes: On Tue, 2006-10-03 at 15:44 -0400, Tom Lane wrote: 1. Switch to using port/qsort.c all the time. 2. Add a qsort_arg function that is identical to qsort except it also passes a void pointer through to the comparison function. This will allow us to get rid of the non-reentrant static variable and extra level of function call in tuplesort.c. 3. Insert a CHECK_FOR_INTERRUPTS() call as was requested back in July. With glibc out of the way, there's no longer a reason to fear memory leakage from cancelling a sort. +1 from me. I can implement this (for 8.3, naturally), unless you'd prefer to do it yourself. I was planning to do it right now, on the grounds that #2 and #3 are bug fixes, and that fixing the existing memory leakage hazard is a good thing too. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] PG qsort vs. Solaris
Tom Lane [EMAIL PROTECTED] writes: So basically, glibc's qsort is bad enough that even a 10%-more-comparisons advantage doesn't save it. Actually what I was more concerned about was things like on data structures with complex comparison routines. Things like sorting on arrays or ROWs. For that matter it seems to me that sorting on a single column is a pretty unrealistic scenario too. Most of the time I find queries have long lists of columns in the ORDER BY clause. Do those numbers look very different if you have lots of columns or if you're sorting on something like an array or a ROW? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Pie-in-sky dreaming about reworking tuple layout entirely
On 10/3/06, Gregory Stark [EMAIL PROTECTED] wrote: I can't shake the feeling that merely tweaking the way our varlenas work with a shortvarlena or with compressed varlena headers is missing the real source of our headaches. It seems very strange to me to be trying to step through a tuple with length bits at the head of every field. It's a lot of work spent dealing with a terribly inconvenient format when we can pick the format to be whatever we like. one advantage of the current system is that columns with nulls do not require any storage. so you can alter table add column for free on a really big table. ISTM that your approch would require moving all the static fields in if you added a static field regardless, right? merlin ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PG qsort vs. Solaris
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: On Tue, 2006-10-03 at 15:44 -0400, Tom Lane wrote: 1. Switch to using port/qsort.c all the time. 2. Add a qsort_arg function that is identical to qsort except it also passes a void pointer through to the comparison function. This will allow us to get rid of the non-reentrant static variable and extra level of function call in tuplesort.c. 3. Insert a CHECK_FOR_INTERRUPTS() call as was requested back in July. With glibc out of the way, there's no longer a reason to fear memory leakage from cancelling a sort. +1 from me. I can implement this (for 8.3, naturally), unless you'd prefer to do it yourself. I was planning to do it right now, on the grounds that #2 and #3 are bug fixes, and that fixing the existing memory leakage hazard is a good thing too. I am OK with doing it now, but calling it a bug fix seems like a stretch. ;-) -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PG qsort vs. Solaris
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: I was planning to do it right now, on the grounds that #2 and #3 are bug fixes, and that fixing the existing memory leakage hazard is a good thing too. I am OK with doing it now, but calling it a bug fix seems like a stretch. ;-) How so? The lack of a CHECK_FOR_INTERRUPTS was reported as a bug to start with; it was only while investigating that that we realized there was a memory-leak hazard, but that doesn't make the latter less real. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] scripts/common.c minor memory leak
Just a minor thing. In yesno_prompt(), the value is resp is allocated memory that is never freed. File: src/bin/scripts/common.c Line: 218 Not terribly important though, it's not used in critical utilities, but it's used often. Found by coverity. -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] Numeric overflow problem + patch
Patch applied. Thanks. --- David Fetter wrote: On Thu, Sep 28, 2006 at 11:16:56PM +0200, Martijn van Oosterhout wrote: On Thu, Sep 28, 2006 at 05:11:43PM -0400, Tom Lane wrote: David Fetter [EMAIL PROTECTED] writes: ! DETAIL: A field with precision 4, scale 4 must have an absolute value less than 1. [ becomes ] ! DETAIL: A field with precision 4, scale 4 must have an absolute value less than 1 - 5 * 10^-5. This strikes me as overly pedantic. The message needs to be clear, and the proposed change will just confuse people. I don't know if the code can detect the difference, but a message like: A field with precision 4, scale 4 must *round to* an absolute value less than 1 Since that more accurately describes the actual problem. Have a ncie day, Per your suggestion, how about this patch? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! [ Attachment, skipping... ] ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] scripts/common.c minor memory leak
Martijn van Oosterhout wrote: Just a minor thing. In yesno_prompt(), the value is resp is allocated memory that is never freed. File: src/bin/scripts/common.c Line: 218 Not terribly important though, it's not used in critical utilities, but it's used often. Found by coverity. It is surely not the only memory leak. We know there are some and in most cases (like this) they aren't worth the trouble to clean up. If it were used in psql or the backend I'd be worried, but it isn't, so I'm not. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] timetz storage vs timestamptz
Why is it timestamptz can store a date and time to 1 microsecond in 8 bytes but a timetz needs 12 to store just the time to 1 microsecond? -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] workaround for buggy strtod is not necessary
Solaris had broken strtod function when parse Inf and Nan. See solaris.h. This bug has been fixed for all current versions of Solaris ( 8, 9, 10). See http://sunsolve.sun.com/search/document.do?assetkey=1-21-108993-62-1searchclause=108993-62 http://sunsolve.sun.com/search/document.do?assetkey=1-21-112874-34-1searchclause=112874-34 Workaround is not necessary now, but I'm not sure if workaround removing is good idea. There are some possible variants: 1) keep workaround in the code for compatibility with unpatched system and adjust comment in solaris.h 2) remove workaround and mention required Solaris patch in the Solaris.FAQ document 3) add some test into configure script and use workaround only on unpatched system. (It should be nightmare for packagers) Any suggestion? Thanks Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] workaround for buggy strtod is not necessary
Zdenek Kotala wrote: Solaris had broken strtod function when parse Inf and Nan. See solaris.h. This bug has been fixed for all current versions of Solaris ( 8, 9, 10). See http://sunsolve.sun.com/search/document.do?assetkey=1-21-108993-62-1searchclause=108993-62 http://sunsolve.sun.com/search/document.do?assetkey=1-21-112874-34-1searchclause=112874-34 Workaround is not necessary now, but I'm not sure if workaround removing is good idea. There are some possible variants: 1) keep workaround in the code for compatibility with unpatched system and adjust comment in solaris.h 2) remove workaround and mention required Solaris patch in the Solaris.FAQ document 3) add some test into configure script and use workaround only on unpatched system. (It should be nightmare for packagers) #1. What do you want to change about the existing comment? /* * Many versions of Solaris have broken strtod() --- see bug #4751182. * For the moment we just assume they all do; it's probably not worth * the trouble to add a configure test for this. */ -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PG qsort vs. Solaris
Gregory Stark [EMAIL PROTECTED] writes: Actually what I was more concerned about was things like on data structures with complex comparison routines. Things like sorting on arrays or ROWs. The important point here is that blowing up the cost of the comparison function by a factor of 3 (by switching from strcmp to strcoll) was not sufficient to overcome the disadvantage --- which says to me that some of the disadvantage is inbuilt and actually scales with the cost of the comparisons. I suspect what we are looking at here is cache effect on the tuple accesses: quicksort has more locality of reference than mergesort, and that applies not only to the tuple pointers that qsort itself is manipulating, but the data they point at. For that matter it seems to me that sorting on a single column is a pretty unrealistic scenario too. Not really; even if you are sorting on multi keys, most of the time the first column determines the comparison result. But since you insist, here's a test case deliberately skewed to not do that: postgres=# select count(*) from (select (random()*3)::int,random() from generate_series(1,100) order by 1,2) ss; glibc: LOG: begin tuple sort: nkeys = 2, workMem = 204800, randomAccess = f LOG: performsort starting: CPU 0.10s/1.03u sec elapsed 1.14 sec LOG: performsort done: CPU 0.12s/5.83u sec elapsed 5.95 sec LOG: internal sort ended, 71452 KB used, 18675458 comparisons: CPU 0.12s/6.10u sec elapsed 6.22 sec ours: LOG: begin tuple sort: nkeys = 2, workMem = 204800, randomAccess = f LOG: performsort starting: CPU 0.10s/1.01u sec elapsed 1.12 sec LOG: performsort done: CPU 0.10s/3.96u sec elapsed 4.06 sec LOG: internal sort ended, 71452 KB used, 21047424 comparisons: CPU 0.10s/4.23u sec elapsed 4.33 sec In any case I don't see that there's anything much left to argue about: every single test we have done says that glibc's qsort is a loser. Speculating about how it might not lose on sufficiently unusual cases doesn't really counter the argument that it does lose on typical scenarios. Between that and the other advantages of controlling our own destiny sorting-wise, I think the decision has become pretty clear-cut. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PG qsort vs. Solaris
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: Given the time that has been spent working around the braindamaged behavior of qsort() on various platforms, I would be more inclined to *always* use our qsort() instead of the platform's version. I've been heard to argue against that in the past, but I'm beginning to see the merit of the idea. One good reason for doing it is that we could stop worrying about the possibility of large-scale memory leaks due to erroring out of glibc's qsort --- in particular it would be OK to add CHECK_FOR_INTERRUPTS into the comparison callback as was requested recently. I think this is a great idea - having predictable sort performance on all platforms makes a lot of sense. Cheers Mark ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] tsearch2 error msg
Martijn van Oosterhout kleptog@svana.org writes:
On Tue, Oct 03, 2006 at 04:34:06PM +0200, Magnus Hagander wrote:
search=3D# select to_tsquery('foo bar');
ERROR: syntax error
Seems to me, at the very least, the message should be:
ERROR: tsearch: syntax error
No, it should be something like
syntax error in tsearch query: contents of string
since it's not always the case that you know exactly what string got fed
to to_tsquery().
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] PG qsort vs. Solaris
+1 - Luke On 10/3/06 2:58 PM, Mark Kirkwood [EMAIL PROTECTED] wrote: Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: Given the time that has been spent working around the braindamaged behavior of qsort() on various platforms, I would be more inclined to *always* use our qsort() instead of the platform's version. I've been heard to argue against that in the past, but I'm beginning to see the merit of the idea. One good reason for doing it is that we could stop worrying about the possibility of large-scale memory leaks due to erroring out of glibc's qsort --- in particular it would be OK to add CHECK_FOR_INTERRUPTS into the comparison callback as was requested recently. I think this is a great idea - having predictable sort performance on all platforms makes a lot of sense. Cheers Mark ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] timetz storage vs timestamptz
Jim C. Nasby [EMAIL PROTECTED] writes: Why is it timestamptz can store a date and time to 1 microsecond in 8 bytes but a timetz needs 12 to store just the time to 1 microsecond? It's tracking the timezone explicitly ... something that timestamptz really ought to do too. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] buildfarm failures in ECPG-Check
It looks like something broke the ECPG-Check recently. A number of buildfarm members are failing. On Tue, 3 Oct 2006, PG Build Farm wrote: The PGBuildfarm member mongoose had the following event on branch HEAD: Failed at Stage: ECPG-Check The snapshot timestamp for the build that triggered this notification is: 2006-10-03 22:30:01 The specs of this machine are: OS: Gentoo / 1.6.14 Arch: i686 Comp: icc / 9.0.032 For more information, see http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=mongoosebr=HEAD -- Lewis's Law of Travel: The first piece of luggage out of the chute doesn't belong to anyone, ever. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PG qsort vs. Solaris
On Tue, Oct 03, 2006 at 03:44:38PM -0400, Tom Lane wrote: select count(*) from (select random()::text from generate_series(1,100) order by 1) ss; ... postgres=# select count(*) from (select random() from generate_series(1,100) order by 1) ss; I'm wondering whether 'order by 1' is representative of a real sort, from the perspective of benchmarks. I wonder why 'order by CONSTANT' might not be safe to optimize away as no sort at all? For sort functions that incrementally improve the sort order, I would expect 'order by 1' to be a worst case scenario. Is that the intention? Or is qsort unaffected by this use? Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] PG qsort vs. Solaris
[EMAIL PROTECTED] writes: I'm wondering whether 'order by 1' is representative of a real sort, from the perspective of benchmarks. Better re-read http://www.postgresql.org/docs/8.1/static/sql-select.html#SQL-ORDERBY regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] PG qsort vs. Solaris
Sorry. Stupid question. I didn't realize SQL allowed for the column to be identified by number. I've never seen that before. :-) Cheers, mark On Tue, Oct 03, 2006 at 06:47:35PM -0400, [EMAIL PROTECTED] wrote: On Tue, Oct 03, 2006 at 03:44:38PM -0400, Tom Lane wrote: select count(*) from (select random()::text from generate_series(1,100) order by 1) ss; ... postgres=# select count(*) from (select random() from generate_series(1,100) order by 1) ss; I'm wondering whether 'order by 1' is representative of a real sort, from the perspective of benchmarks. I wonder why 'order by CONSTANT' might not be safe to optimize away as no sort at all? For sort functions that incrementally improve the sort order, I would expect 'order by 1' to be a worst case scenario. Is that the intention? Or is qsort unaffected by this use? -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] buildfarm failures in ECPG-Check
Jeremy Drake [EMAIL PROTECTED] writes: It looks like something broke the ECPG-Check recently. A number of buildfarm members are failing. Looks like blow-back from the recent change in default GUC parameters. However, I think update the expected output is the wrong answer, because what we are looking at here is evidence that the ecpg checks will fail anyway against an installed system with nondefault settings. That test needs to be modified so that it doesn't depend on the value of any GUC parameter that it hasn't set for itself. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] cvsweb.cgi missing colors
What has our cvsweb.cgi recently lost its colors? It has made it almost completely unusable. Example: http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/postgresql.conf.sample.diff?r1=1.195;r2=1.196;f=h cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] 7.4, 8.0 branches @ itanium2 icc
On Tue, 3 Oct 2006, Tom Lane wrote: Sergey E. Koposov [EMAIL PROTECTED] writes: Having recently tried to build 7.4, and 8.0 branches on Itanium2 with ICC 7.4 is not going to work with ICC anyway without considerably more extensive changes (eg, configure hacking). It might make sense to apply this patch to 8.0 but I can't get all that excited about it. I guess that fix is just no-cost fix. I don't see any problems that may arise from it. So my personal opinion is that it should be applied... Regards, Sergey *** Sergey E. Koposov Max Planck Institute for Astronomy/Sternberg Astronomical Institute Tel: +49-6221-528-349 Web: http://lnfm1.sai.msu.ru/~math E-mail: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] pgindent has been run
I have run pgindent for 8.2. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] scripts/common.c minor memory leak
A good spot :)
Sorry for being no{isy}{vice}{wbie}, but what does it means found by
coverity ?
g.-
On 10/3/06, Martijn van Oosterhout kleptog@svana.org wrote:
Just a minor thing. In yesno_prompt(), the value is resp is allocated
memory that is never freed.
File: src/bin/scripts/common.c
Line: 218
Not terribly important though, it's not used in critical utilities, but
it's used often.
Found by coverity.
--
Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/
From each according to his ability. To each according to his ability to
litigate.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFFItO3IB7bNG8LQkwRAk2bAKCB3AKuon35YAMOEjixN7P9HQeoBgCeOWpF
5/GvkeMtRwlncGBP9MG2qXw=
=FBVw
-END PGP SIGNATURE-
--
Guido Barosio
---
http://www.globant.com
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] scripts/common.c minor memory leak
http://en.wikipedia.org/wiki/Coverity[]'s- WalterOn 10/3/06, Guido Barosio
[EMAIL PROTECTED] wrote:A good spot :)Sorry for being no{isy}{vice}{wbie}, but what does it means found by
coverity ?g.-On 10/3/06, Martijn van Oosterhout kleptog@svana.org wrote: Just a minor thing. In yesno_prompt(), the value is resp is allocated
memory that is never freed. File: src/bin/scripts/common.c Line: 218 Not terribly important though, it's not used in critical utilities, but it's used often.
Found by coverity. -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate.
-BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFItO3IB7bNG8LQkwRAk2bAKCB3AKuon35YAMOEjixN7P9HQeoBgCeOWpF 5/GvkeMtRwlncGBP9MG2qXw= =FBVw
-END PGP SIGNATURE---Guido Barosio---http://www.globant.com
[EMAIL PROTECTED]---(end of broadcast)---TIP 5: don't forget to increase your free space map settings
