Re: [HACKERS] Two weeks to feature freeze
Dann Corbit wrote: -Original Message- From: Jan Wieck [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 10:30 PM To: Dann Corbit Cc: scott.marlowe; Bruce Momjian; Tom Lane; Jason Earl; PostgreSQL-development Subject: Re: [HACKERS] Two weeks to feature freeze [snip] I personally think you don't actually ever did any software testing yourself. You are not really talking from experience, are you? So please, show me what you have now, or get one more plus on my minus-list. I have already posted enough information to show my qualitications. Whether I am qualified or not is irrelevant to whether the argument has merit or not. I have raised what I consider to be an important issue. Astute members of the list have noticed that I have not volunteered to perform the work. I may or may not produce some efforts towards testing PostgreSQL. Whether I decide to help or not is irrelevant towards the concept of what needs to be done. Right! Whatever you decide is totally irrelevant towards the concept of what needs to be done. But that wasn't the question and you wheren't in the position or asked for making any decisions. And after this mail I doubt more than before that the input you can provide will lead to any meaningful improvement of PostgreSQL. Then again, you still have the chance to surprise me. I know by now that you're not a programmer and don't know SQL very well. But do you at least have some concept of your own, other than URL's pointing to someone elses work? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] interval's and printing...
--On Monday, June 23, 2003 23:41:29 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Add to TODO: * Have SELECT '13 minutes'::interval display zero seconds you might want to clarify the TODO to include in ISO DateStyle. (Per tom's comments). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] again: Bug #943: Server-Encoding from EUC_TW toUTF-8
I reported bug #943 (I found in 7.3.2) and you checked in some change against integer overflow. Now I upgraded to 7.3.3 and I'm not happy with this. The exact error as I described is fixed, but I found new errors in conversion UTF-8 - EUC_TW and BIG5: Copy to table (DB has UTF-8 encoding) from file: for PGCLIENTENCODING=BIG5: WARNING: copy: line 1, LocalToUtf: could not convert (0xf9d6) BIG5 to UTF-8. Ignored WARNING: copy: line 2, LocalToUtf: could not convert (0xf9d7) BIG5 to UTF-8. Ignored WARNING: copy: line 3, LocalToUtf: could not convert (0xf9d8) BIG5 to UTF-8. Ignored WARNING: copy: line 4, LocalToUtf: could not convert (0xf9db) BIG5 to UTF-8. Ignored I see no problem here. The only standard conversion map I could found on-line form so far (see below URL) does not include entries 0xf9d6 or above. http://www.unicode.org/Public/UNIDATA/Unihan.txt I found in this file: U+F9D7 in line 604519 U+F9D8 in line 219540 U+F9D6...U+F9DB in lines 730707...730766. No. U+F9D6 means *Unicode* code point, not BIG5 code point. for EUC_TW WARNING: copy: line 1, LocalToUtf: could not convert (0x8ea3c3b7) EUC_TW to UTF-8. Ignored WARNING: copy: line 2, LocalToUtf: could not convert (0x8ea3cfd0) EUC_TW to UTF-8. Ignored WARNING: copy: line 3, LocalToUtf: could not convert (0x8ea3c4ce) EUC_TW to UTF-8. Ignored WARNING: copy: line 4, LocalToUtf: could not convert (0x8ea3bdfe) EUC_TW to UTF-8. Ignored Hum. These seem to be CNS 11643-1993, plane 3. Currently PostgreSQL supports only: CNS 11643-1993, plane 0 CNS 11643-1993, plane 1 CNS 11643-1993, plane 2 CNS 11643-1993, plane 15 Would you like to have support for rest of CNS 11643-1993 planes: CNS 11643-1993, plane 3 CNS 11643-1993, plane 4 CNS 11643-1993, plane 5 CNS 11643-1993, plane 6 CNS 11643-1993, plane 7 support for upcoming 7.4? Copy out to file from table (UTF-8 data): to BIG5 WARNING: UtfToLocal: could not convert UTF-8 (0xe7a281). Ignored WARNING: UtfToLocal: could not convert UTF-8 (0xe98ab9). Ignored WARNING: UtfToLocal: could not convert UTF-8 (0xe8a38f). Ignored WARNING: UtfToLocal: could not convert UTF-8 (0xe7b2a7). Ignored to EUC_TW is ok! BIG5 and EUC_TW have different code points. So this is not very strange. But it is very strange that I can (for EUC_TW) copy to file without error but I can not copy from file without error. Michael ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] TO_CHAR SO SLOW???
On Mon, Jun 23, 2003 at 06:08:19PM -0700, Maksim Likharev wrote: Hi, I have some SQL function, just regular function selects data by using 4 joins nothing fancy, but one thing pretty noticeable, I have to display 3 different columns with same date formatted differently, here are 3 different snippets: 1. SELECT t.x,t.y,TO_CHAR(t.dt, 'DD/MM/') FROM ( SELECT x, y, dt FROM ) AS t ... 2. SELECT t.x,t.y,TO_CHAR(t.dt, 'DD/MM/'), TO_CHAR(t.dt, 'Mon-') FROM ( SELECT x, y, dt FROM ) AS t .. 3. SELECT t.x,t.y,TO_CHAR(t.dt, 'DD/MM/'), TO_CHAR(t.dt, 'Mon-'), TO_CHAR(t.dt, '') FROM ( SELECT x, y, dt FROM ) AS t ... # 1: 15000 rows, I getting data for 130 sec # 2: 15000 rows, I getting data for 160 sec # 3: 15000 rows, I getting data for 220 sec adding different fields into output change query time only marginally but adding or removing to_char, just heavily knocks performance. is it TO_CHAR so slow?? I don't think to_char() is so slow. What happen with performance if you use t.dt without formatting or if try some other function an example extract()? SELECT t.x, t.y, t.dt FROM ( SELECT x, y, dt FROM ) AS t; SELECT t.x, t.y, EXTRACT(year from t.dt) FROM ( SELECT x, y, dt FROM ) AS t; Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ftp mirror
-Original Message- From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED] Sent: 24 June 2003 02:55 To: [EMAIL PROTECTED]; pgsql-hackers list Subject: Re: [HACKERS] ftp mirror Is it me or is there a problem with ftp mirrors? The latest shapshots I have here are from June 2; seems rather old.. Also, what happened to www.au.postgresql.org??? My fault, sorry. I've asked Marc to fix the DNS. Regards, Dave. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [GENERAL] Many Pl/PgSQL parameters - AllocSetAlloc(128)?
(cross-posting to HACKERS)
Reuven M. Lerner wrote:
I'm creating a new OpenACS package that uses PostgreSQL, and in doing
so have encountered what seems to be a problem in PostgreSQL.
[...snip...]
CREATE OR REPLACE FUNCTION add_news__test
(integer,varchar,timestamptz,varchar,varchar,varchar,
varchar,integer,timestamptz,integer,timestamptz,varchar,varchar,
varchar,integer,boolean, varchar, varchar, varchar, timestamptz,
integer, varchar, integer, integer)
[...snip...]
p_last_mod_date alias for $20; -- default null/timestamptz
p_modified_by alias for $21; -- default null/integer
p_last_mod_date alias for $20; -- default null/timestamptz
p_modified_by alias for $21; -- default null/integer
^ above two lines repeated
p_image_filename alias for $22; -- default null/text
p_headline_page alias for $23; -- default null/integer
more importantly, you call the function (below) with a varchar here, not
integer
p_headline_position alias for $24; -- default null/integer
[...snip...]
now(), -- p_last_mod_date
^^^ try 'now'::timestamptz
'298'::integer,-- p_modified_by
'image.jpeg'::varchar, -- p_image_filename
'Category page'::varchar, -- p_headline_page
^^^ this one should be an integer
'1'::integer -- p_headline_position
);
You found a real bug, I can confirm it on CVS tip.
However your workaround is to call the function *exactly* as declared.
Otherwise in parse_func.c:gen_cross_product() the following code is
executed:
snippet
nanswers = 1;
for (i = 0; i nargs; i++)
{
nanswers *= (arginh[i].nsupers + 2);
cur[i] = 0;
}
iter = result = (Oid **) palloc(sizeof(Oid *) * nanswers);
/snippet
I get nanswers = 16777216, so right off the bat 67MB or so is allocated.
Then there's this:
snippet
/* compute the cross product from right to left */
for (;;)
{
oneres = (Oid *) palloc0(FUNC_MAX_ARGS * sizeof(Oid));
/snippet
I'm guessing this gets executed nanswers times. I saw memory usage grow
to 880 MB and then killed the process.
I'm not sure of the best way to fix this yet, but I found that when
calling the function with argument types matching the prototype
perfectly, this code never gets executed.
HTH,
Joe
p.s. here's a backtrace:
#0 AllocSetAlloc (context=0x830a624, size=128) at aset.c:731
#1 0x081bcb14 in MemoryContextAllocZero (context=0x830a624, size=128)
at mcxt.c:505
#2 0x080c5c03 in gen_cross_product (arginh=0xbfffd120, nargs=24) at
parse_func.c:1094
#3 0x080c59b6 in argtype_inherit (nargs=24, argtypes=0xbfffd350) at
parse_func.c:975
#4 0x080c5836 in func_get_detail (funcname=0x831451c, fargs=0x83178e8,
nargs=24, argtypes=0xbfffd350, funcid=0xbfffd33c,
rettype=0xbfffd340, retset=0xbfffd347 \bÁ\002,
true_typeids=0xbfffd348) at parse_func.c:891
#5 0x080c4c4c in ParseFuncOrColumn (pstate=0x8317810,
funcname=0x831451c, fargs=0x83178e8, agg_star=0 '\0',
agg_distinct=0 '\0', is_column=0 '\0') at parse_func.c:241
#6 0x080c41de in transformExpr (pstate=0x8317810, expr=0x8317714) at
parse_expr.c:399
#7 0x080cb4ed in transformTargetEntry (pstate=0x8317810,
node=0x8317714, expr=0x0, colname=0x0, resjunk=0 '\0')
at parse_target.c:60
#8 0x080cb53b in transformTargetList (pstate=0x8317810,
targetlist=0x831774c) at parse_target.c:193
#9 0x080b61c8 in transformSelectStmt (pstate=0x8317810, stmt=0x8317768)
at analyze.c:1771
#10 0x080b41b7 in transformStmt (pstate=0x8317810, parseTree=0x8317768,
extras_before=0xbfffd574, extras_after=0xbfffd578)
at analyze.c:407
#11 0x080b402b in do_parse_analyze (parseTree=0x8317768,
pstate=0x8317810) at analyze.c:234
#12 0x080b3f44 in parse_analyze (parseTree=0x8317768,
paramTypes=0x830a624, numParams=137405988) at analyze.c:159
#13 0x08159c3c in pg_analyze_and_rewrite (parsetree=0x8317768,
paramTypes=0x0, numParams=0) at postgres.c:482
#14 0x08159f83 in exec_simple_query (
query_string=0x8313c40 select add_news__test(\n
1000::integer,, ' ' repeats 15 times, \n'en_US'::varchar,, ' '
repeats 15 times, \n'2003-6-23'::timestamptz, \n'text text
text'::varchar, \n'language'::varchar, ...) at
postgres.c:795
#15 0x0815bd1b in PostgresMain (argc=4, argv=0x829aa9c,
username=0x829aa64 postgres) at postgres.c:2753
#16 0x0813a531 in BackendFork (port=0x82a80c0) at postmaster.c:2471
#17 0x0813a026 in BackendStartup (port=0x82a80c0) at postmaster.c:2118
#18 0x08138b5f in ServerLoop () at postmaster.c:1090
#19 0x081384dd in PostmasterMain (argc=5, argv=0x829a4c8) at
postmaster.c:872
#20 0x0810f713 in main (argc=5, argv=0xbfffe334) at main.c:211
#21 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
---(end of
Re: [HACKERS] [GENERAL] Many Pl/PgSQL parameters - AllocSetAlloc(128)?
Joe Conway wrote:
I get nanswers = 16777216, so right off the bat 67MB or so is allocated.
Then there's this:
snippet
/* compute the cross product from right to left */
for (;;)
{
oneres = (Oid *) palloc0(FUNC_MAX_ARGS * sizeof(Oid));
/snippet
I'm guessing this gets executed nanswers times. I saw memory usage grow
to 880 MB and then killed the process.
I'm not sure of the best way to fix this yet, but I found that when
calling the function with argument types matching the prototype
perfectly, this code never gets executed.
Actually, adding a pfree(oneres); to the end of that for loop plugs
the memory leak and allows me to see the error message:
ERROR: Function add_news__test(integer, character varying, timestamp
with time zone, character varying, character varying, character varying,
character varying, integer, timestamp with time zone, integer, timestamp
with time zone, character varying, character varying, character varying,
integer, boolean, character varying, character varying, character
varying, timestamp with time zone, integer, character varying, character
varying, integer) does not exist
Unable to identify a function that satisfies the given argument
types
You may need to add explicit typecasts
Takes a while to check all 16777216 possibilities though, so I'm still
not sure more isn't needed here.
Joe
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] pg_get_triggerdef in pg_dump
Bruce Momjian wrote:
OK, added to TODO:
Modify pg_get_triggerdef() to take a boolean to pretty-print,
and use that as part of pg_dump along with psql
Andreas, can you work on this? I like the idea of removing extra
parens, and merging it into the existing code rather than into contrib
makes sense.
Yes, I can. At the moment, I have a runnable contrib module, which
replaces all pg_get_xxxdef by pg_get_xxxdef2 functions. It's no problem
to apply that code back to the original ruleutils.c when the
isSimpleNode algorithm is reviewed independently and proved being correct.
For safety reasons, I can make this dependent on a bool pretty-print
parameter.
I also could implement line break and indentation formatting. I
implemented a keyword-based algorithm in pgAdmin3, and having the
original tree the job is obviously easier. Do we need any flexibility
about indent char (tab or space) and indentation size (2 chars)? The
pgAdmin3 algorithm uses 4 spaces, and tries to align keywords so they
line up nicely, and I'd prefer doing it this way again.
SELECT foo
FROM bar b
JOIN chair c USING (thekeycol)
WHERE ...
Regards,
Andreas
/***
* check if given node is simple.
* false : not simple
* true : simple in the context of parent node's type
***/
static bool isSimpleNode(Node *node, NodeTag parentNodeType)
{
if (!node)
return true;
switch (nodeTag(node))
{
// single words: always simple
case T_Var:
case T_Const:
case T_Param:
// function-like: name(..) or name[..]
case T_ArrayRef:
case T_FuncExpr:
case T_ArrayExpr:
case T_CoalesceExpr:
case T_NullIfExpr:
case T_Aggref:
// CASE keywords act as parentheses
case T_CaseExpr:
return true;
// appears simple since . has top precedence, unless parent is T_FieldSelect
itself!
case T_FieldSelect:
return (parentNodeType == T_FieldSelect ? false : true);
// maybe simple, check args
case T_CoerceToDomain:
return isSimpleNode((Node*) ((CoerceToDomain*)node)-arg,
T_CoerceToDomain);
case T_RelabelType:
return isSimpleNode((Node*) ((RelabelType*)node)-arg, T_RelabelType);
// depends on parent node type; needs further checking
case T_SubLink:
case T_NullTest:
case T_BooleanTest:
case T_OpExpr:
case T_DistinctExpr:
if (parentNodeType == T_BoolExpr)
return true;
// else check the same as for T_BoolExpr; no break here!
case T_BoolExpr:
switch (parentNodeType)
{
case T_ArrayRef:
case T_FuncExpr:
case T_ArrayExpr:
case T_CoalesceExpr:
case T_NullIfExpr:
case T_Aggref:
case T_CaseExpr:
return true;
default:
break;
}
return false;
// these are not completely implemented; so far, they're simple
case T_SubPlan:
case T_CoerceToDomainValue:
return true;
default:
break;
}
// those we don't know: in dubio complexo
return false;
}
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] sa_family_t in cygwin compile of cvs + regression failure
Bruce, On Mon, Jun 23, 2003 at 09:50:49PM -0400, Bruce Momjian wrote: OK, patch applied to typedef sa_family_t for cygwin. If other platforms need it, I will have to do something more generic. I'm happy to report that the above patch solves one of Cygwin's current build problems. However, Cygwin still needs the following patch: http://archives.postgresql.org/pgsql-patches/2003-06/msg00186.php Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 2Q implementaion for PostgreSQL buffer replacement.
On Mon, 23 Jun 2003 23:49:17 -0400 (EDT) Bruce Momjian [EMAIL PROTECTED] wrote: Looks good to me --- we will include it in 7.4. Thanks.But please note it is not completed yet. I must implement more , and move configurable parameter to postgresql.conf file. -- Yutaka tanida [EMAIL PROTECTED] http://www.nonsensecorner.com/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] lru cache replacement
xoror, On Tue, 24 Jun 2003 12:13:51 +0200 (MEST) [EMAIL PROTECTED] wrote: I was researching on cache replacement strategy as well. 2Q has one disadvantage see this exellent paper: http://www.almaden.ibm.com/cs/people/dmodha/#ARC see the paper ARC: A Self-Tuning, Low Overhead Replacement Cache for theory and One Up on LRU for implementation details. ARC requires no tuning and can switch fast between chaging patterns. Best of all is it is resistant to a sequential scan pattern. and i think it's even easier to implement then 2q :) Thanks for your information. I check the paper and implement it by Java for testing. does pgbench test with relatively large sequential scans? Probably no. -- Yutaka tanida [EMAIL PROTECTED] http://www.nonsensecorner.com/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] How to use pset command in my program!!
Hi! I want to use 'pset'command in my program it's like this. I want to do the execute the following in my program. \pset null 'ALL' how can this be done bye srikanth ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_get_triggerdef in pg_dump
Great. I recommend using spaces rather than tabs for indenting in psql
and pg_dump.
---
Andreas Pflug wrote:
Bruce Momjian wrote:
OK, added to TODO:
Modify pg_get_triggerdef() to take a boolean to pretty-print,
and use that as part of pg_dump along with psql
Andreas, can you work on this? I like the idea of removing extra
parens, and merging it into the existing code rather than into contrib
makes sense.
Yes, I can. At the moment, I have a runnable contrib module, which
replaces all pg_get_xxxdef by pg_get_xxxdef2 functions. It's no problem
to apply that code back to the original ruleutils.c when the
isSimpleNode algorithm is reviewed independently and proved being correct.
For safety reasons, I can make this dependent on a bool pretty-print
parameter.
I also could implement line break and indentation formatting. I
implemented a keyword-based algorithm in pgAdmin3, and having the
original tree the job is obviously easier. Do we need any flexibility
about indent char (tab or space) and indentation size (2 chars)? The
pgAdmin3 algorithm uses 4 spaces, and tries to align keywords so they
line up nicely, and I'd prefer doing it this way again.
SELECT foo
FROM bar b
JOIN chair c USING (thekeycol)
WHERE ...
Regards,
Andreas
/***
* check if given node is simple.
* false : not simple
* true : simple in the context of parent node's type
***/
static bool isSimpleNode(Node *node, NodeTag parentNodeType)
{
if (!node)
return true;
switch (nodeTag(node))
{
// single words: always simple
case T_Var:
case T_Const:
case T_Param:
// function-like: name(..) or name[..]
case T_ArrayRef:
case T_FuncExpr:
case T_ArrayExpr:
case T_CoalesceExpr:
case T_NullIfExpr:
case T_Aggref:
// CASE keywords act as parentheses
case T_CaseExpr:
return true;
// appears simple since . has top precedence, unless parent is T_FieldSelect
itself!
case T_FieldSelect:
return (parentNodeType == T_FieldSelect ? false : true);
// maybe simple, check args
case T_CoerceToDomain:
return isSimpleNode((Node*) ((CoerceToDomain*)node)-arg,
T_CoerceToDomain);
case T_RelabelType:
return isSimpleNode((Node*) ((RelabelType*)node)-arg, T_RelabelType);
// depends on parent node type; needs further checking
case T_SubLink:
case T_NullTest:
case T_BooleanTest:
case T_OpExpr:
case T_DistinctExpr:
if (parentNodeType == T_BoolExpr)
return true;
// else check the same as for T_BoolExpr; no break here!
case T_BoolExpr:
switch (parentNodeType)
{
case T_ArrayRef:
case T_FuncExpr:
case T_ArrayExpr:
case T_CoalesceExpr:
case T_NullIfExpr:
case T_Aggref:
case T_CaseExpr:
return true;
default:
break;
}
return false;
// these are not completely implemented; so far, they're simple
case T_SubPlan:
case T_CoerceToDomainValue:
return true;
default:
break;
}
// those we don't know: in dubio complexo
return false;
}
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 3: 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_get_triggerdef in pg_dump
Andreas Pflug wrote: I also could implement line break and indentation formatting. I implemented a keyword-based algorithm in pgAdmin3, and having the original tree the job is obviously easier. Do we need any flexibility about indent char (tab or space) and indentation size (2 chars)? The pgAdmin3 algorithm uses 4 spaces, and tries to align keywords so they line up nicely, and I'd prefer doing it this way again. SELECT foo FROM bar b JOIN chair c USING (thekeycol) WHERE ... Oh, one more thing --- right justify isn't as accepted as left-justify --- sorry. SELECT foo FROM bar b JOIN chair c USING (thekeycol) WHERE ... -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL Core Welcomes New Member
It's rumoured that Vince Vielhaber once said: Whut? Please drop www.us as a postgresql mirror. Just stop rsyncing and your mirror will be dropped automatically. Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] interval's and printing...
Larry Rosenman wrote: Add to TODO: * Have SELECT '13 minutes'::interval display zero seconds you might want to clarify the TODO to include in ISO DateStyle. (Per tom's comments). Can you supply an example/text? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 2Q implementaion for PostgreSQL buffer replacement.
OK, thanks. I will remove it from the queue, and someone suggested a different algorithm today: I was researching on cache replacement strategy as well. 2Q has one disadvantage see this exellent paper: http://www.almaden.ibm.com/cs/people/dmodha/#ARC see the paper ARC: A Self-Tuning, Low Overhead Replacement Cache for theory and One Up on LRU for implementation details. ARC requires no tuning and can switch fast between chaging patterns. Best of all is it is resistant to a sequential scan pattern. and i think it's even easier to implement then 2q :) --- Yutaka tanida wrote: On Mon, 23 Jun 2003 23:49:17 -0400 (EDT) Bruce Momjian [EMAIL PROTECTED] wrote: Looks good to me --- we will include it in 7.4. Thanks.But please note it is not completed yet. I must implement more , and move configurable parameter to postgresql.conf file. -- Yutaka tanida [EMAIL PROTECTED] http://www.nonsensecorner.com/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 2Q implementaion for PostgreSQL buffer replacement.
Patch removed at author's request. --- Yutaka tanida wrote: Hi. I implement 2Q algorithm to PostgreSQL for buffer management , instead of LRU. It's known as low overhead and high performance than LRU. If you have some interests , see following URL. http://www.vldb.org/conf/1994/P439.PDF In my test (pgbench -S) , it improves 4% cache hit rate and 2% up performance comparing from LRU. Do you have any interest about this patch? -- Yutaka tanida [EMAIL PROTECTED] http://www.nonsensecorner.com/ [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] dblink_ora - a first shot on Oracle ...
Joe Conway [EMAIL PROTECTED] writes: Yeah. But we'd need to detect whether or not the Oracle client libs are available. I'm not sure how to do that with the contrib build system. And we'd need a fair amount of integration/reorganizing the existing code. Also, I've got the same issues with integrating jdbclink. I don't think I'll be able to get that done between now and July 1st. Seems reasonable to put integrating both of 'em as a TODO for 7.5. I think you're clearly the guy who has to review those patches, so if you don't have time right now, it's not gonna happen for 7.4. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] a problem with index and user define type
Weiping He [EMAIL PROTECTED] writes: we found the problem: We used IMMUTABLE modifier in our CREATE FUNCTION definition, though it's correct for our function to return same value if input the same *data*, but our data are passed by reference, not by value, so, some times we can't retrive out data. Remove IMMUTABLE fixed the problem. So, it seems to make it clear in docs would be a good help to function writers, would commit a documentation patch later if necessary. I'm not sure what problem you're really describing, but it would be entirely wrong for the docs to claim that pass-by-reference datatypes shouldn't have immutable functions. float8 is pass-by-ref, for instance, but they don't come any more immutable than sqrt(x) ... I'd suggest taking a closer look to understand what the problem really is. Trying to index on a non-immutable function makes no sense, which is why the system forbids it. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] interval's and printing...
--On Tuesday, June 24, 2003 09:46:33 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: Add to TODO: * Have SELECT '13 minutes'::interval display zero seconds you might want to clarify the TODO to include in ISO DateStyle. (Per tom's comments). Can you supply an example/text? * Have SELECT '13 minutes'::interval display zero seconds when using DateStyle ISO -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] lru cache replacement
Yutaka tanida [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: does pgbench test with relatively large sequential scans? Probably no. pgbench tries to avoid any seqscans at all, I believe, so it wouldn't be very useful for testing a method that's mainly intended to prevent seqscans from blowing out the cache. I tried to implement LRU-2 awhile ago, and got discouraged when I couldn't see any performance improvement. But I was using pgbench as the test case, and failed to think about its lack of seqscans. We could probably resurrect that code for comparison to 2Q, if anyone can devise more interesting benchmark cases to test. BTW, when you were running your test case, what shared_buffers did you use? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] interval's and printing...
--On Tuesday, June 24, 2003 10:44:25 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: * Have SELECT '13 minutes'::interval display zero seconds you might want to clarify the TODO to include in ISO DateStyle. (Per tom's comments). Can you supply an example/text? * Have SELECT '13 minutes'::interval display zero seconds when using DateStyle ISO I am still confused. What does such output look like. Right now I get: test= SELECT '13 minutes'::interval; interval -- 00:13 (1 row) I assume the idea is to display it as 00:13:00, right? Correct, but with Postgres DateStyle or SQL, it does other stuff: $ psql Welcome to psql 7.3.3, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit ler=# set datestyle='postgres' ler-# ; SET ler=# select '13 minutes'::interval ler-# ; interval --- @ 13 mins (1 row) ler=# set datestyle='sql'; SET ler=# select '13 minutes'::interval; interval --- @ 13 mins (1 row) ler=# set datestyle='iso,us'; SET ler=# select '13 minutes'::interval; interval -- 00:13 (1 row) ler=# -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 3: 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] lru cache replacement
Yutaka tanida [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: does pgbench test with relatively large sequential scans? Probably no. pgbench tries to avoid any seqscans at all, I believe, so it wouldn't be very useful for testing a method that's mainly intended to prevent seqscans from blowing out the cache. I tried to implement LRU-2 awhile ago, and got discouraged when I couldn't see any performance improvement. But I was using pgbench as the test case, and failed to think about its lack of seqscans. We could probably resurrect that code for comparison to 2Q, if anyone can devise more interesting benchmark cases to test. BTW, when you were running your test case, what shared_buffers did you use? It's very easy to test sequencial scans using pgbench: just drop the index from account table. I am using this technique to generate heavy loads. -- Tatsuo Ishii ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pg_get_triggerdef in pg_dump
Oh, one more thing --- right justify isn't as accepted as left-justify But it looks so much better... -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] a problem with index and user define type
Tom Lane wrote:
Weiping He [EMAIL PROTECTED] writes:
we found the problem:
We used IMMUTABLE modifier in our CREATE FUNCTION definition,
though it's correct for our function to return same value if input the
same *data*,
but our data are passed by reference, not by value, so, some times we can't
retrive out data. Remove IMMUTABLE fixed the problem.
So, it seems to make it clear in docs would be a good help to function
writers, would commit a documentation patch later if necessary.
I'm not sure what problem you're really describing, but it would be
entirely wrong for the docs to claim that pass-by-reference datatypes
shouldn't have immutable functions. float8 is pass-by-ref, for
instance, but they don't come any more immutable than sqrt(x) ...
I'd suggest taking a closer look to understand what the problem really
is. Trying to index on a non-immutable function makes no sense, which
is why the system forbids it.
regards, tom lane
Sorry for didn't describe my problem clearly. I mean the function implement
the operator, like compare function for equal ('=') etc, not to build an
index
on an function.
Here is full version:
First we build a user type using CREATE FUNCTION, CREATE TYPE, CREATE
OPERATOR
and CREATE OPERATOR CLASS command, of course we wrote those C functions
needed for operator, type etc.
Then we try to test if our type (which is named UUID) could be
indexable, and found
it didn't use the index, but, we don't know why.
Later, we ask the question here why the index didn't get used, and you
point out that we
should assign the selective restriction function for our operators,
espically for '=' operator,
we use 'eqsel' per your suggestion. But found out that though the idnex
got used, but sometimes
not data row return (and sometimes we could get the data row)!
Then we re-check our definition, and found out may be we shouldn't use
IMMUTABLE
key word in the function definition used by the '=' operator to
implement the equation compare,
the wrong definition is:
Datum uuid_eq(PG_FUNCTION_ARGS)
{
struct uuid *uptr1 = (struct uuid *) PG_GETARG_POINTER(0);
struct uuid *uptr2 = (struct uuid *) PG_GETARG_POINTER(1);
PG_RETURN_BOOL(uuidcmp(uptr1, uptr2) == 0);
}
CREATE OR REPLACE FUNCTION uuid_eq(uuid, uuid)
RETURNS boolean
IMMUTABLE
STRICT
AS '$libdir/uuid'
LANGUAGE 'C';
CREATE OPERATOR = (
LEFTARG = uuid,
RIGHTARG = uuid,
COMMUTATOR = =,
NEGATOR = ,
PROCEDURE = uuid_eq,
RESTRICT = eqsel,
JOIN = eqjoinsel
);
because the data type (UUID) is a struct,
and the uuid_eq() function accept two pointer to the value of struct uuid,
if make it IMMUTABLE, postgresql would think it should not try to run
the function, but return the cached value instead when it get two same
pointers input,
but, the pointers may be unchanged, the data pointers point to may have
changed.
So it will cause the weird symptom we found. And removed IMMUTABLE fix the
problem. So we think may be the doc for CREATE FUNCTION should point out
the difference of passed by ref and passed by value. Thus may avoid this
kind of
error.
Thanks and Regards
Laser
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] lru cache replacement
On Tue, 24 Jun 2003 10:27:09 -0400 Tom Lane [EMAIL PROTECTED] wrote: I tried to implement LRU-2 awhile ago, and got discouraged when I couldn't see any performance improvement. But I was using pgbench as the test case, and failed to think about its lack of seqscans. How about cache hit rate? BTW, when you were running your test case, what shared_buffers did you use? I use 16,64,256 and 4096. --- Yutaka tanida[EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] lru cache replacement
(BOn Wed, 25 Jun 2003 00:43:56 +0900 (BYutaka tanida [EMAIL PROTECTED] wrote: (B (B BTW, when you were running your test case, what shared_buffers did you (B use? (B (B I use 16,64,256 and 4096. (B (BI missed. My shown result(+4% cache hit rate) is shared_buffers=64. (B (B--- (BYutaka tanida[EMAIL PROTECTED] $BFf$N(BWebsite http://www.nonsensecorner.com/ (B (B (B---(end of broadcast)--- (BTIP 3: if posting/reading through Usenet, please send an appropriate (B subscribe-nomail command to [EMAIL PROTECTED] so that your (B message can get through to the mailing list cleanly
Re: [HACKERS] TO_CHAR SO SLOW???
Yes it is TO_CHAR, look like that OS ( SUN ) related issue, I assume PG uses some of the lib functions. Looks like nonsense for me, what is damn difficult in that ( formating dates ). going to try date_part, might help me. Too bad EXPLAIN does not provide statistic of time that spent inside a function call, would be much helpful in such case. In comparison with Microsoft SQL, productivity of using profiling/debugging tools sorry to say that, far behind. -Original Message- From: Karel Zak [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 1:04 AM To: Maksim Likharev Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] TO_CHAR SO SLOW??? On Mon, Jun 23, 2003 at 06:08:19PM -0700, Maksim Likharev wrote: Hi, I have some SQL function, just regular function selects data by using 4 joins nothing fancy, but one thing pretty noticeable, I have to display 3 different columns with same date formatted differently, here are 3 different snippets: 1. SELECT t.x,t.y,TO_CHAR(t.dt, 'DD/MM/') FROM ( SELECT x, y, dt FROM ) AS t ... 2. SELECT t.x,t.y,TO_CHAR(t.dt, 'DD/MM/'), TO_CHAR(t.dt, 'Mon-') FROM ( SELECT x, y, dt FROM ) AS t .. 3. SELECT t.x,t.y,TO_CHAR(t.dt, 'DD/MM/'), TO_CHAR(t.dt, 'Mon-'), TO_CHAR(t.dt, '') FROM ( SELECT x, y, dt FROM ) AS t ... # 1: 15000 rows, I getting data for 130 sec # 2: 15000 rows, I getting data for 160 sec # 3: 15000 rows, I getting data for 220 sec adding different fields into output change query time only marginally but adding or removing to_char, just heavily knocks performance. is it TO_CHAR so slow?? I don't think to_char() is so slow. What happen with performance if you use t.dt without formatting or if try some other function an example extract()? SELECT t.x, t.y, t.dt FROM ( SELECT x, y, dt FROM ) AS t; SELECT t.x, t.y, EXTRACT(year from t.dt) FROM ( SELECT x, y, dt FROM ) AS t; Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] interval's and printing...
TODO updated: * Have SELECT '13 minutes'::interval display zero seconds in ISO datestyle --- Larry Rosenman wrote: --On Tuesday, June 24, 2003 10:44:25 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: * Have SELECT '13 minutes'::interval display zero seconds you might want to clarify the TODO to include in ISO DateStyle. (Per tom's comments). Can you supply an example/text? * Have SELECT '13 minutes'::interval display zero seconds when using DateStyle ISO I am still confused. What does such output look like. Right now I get: test= SELECT '13 minutes'::interval; interval -- 00:13 (1 row) I assume the idea is to display it as 00:13:00, right? Correct, but with Postgres DateStyle or SQL, it does other stuff: $ psql Welcome to psql 7.3.3, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit ler=# set datestyle='postgres' ler-# ; SET ler=# select '13 minutes'::interval ler-# ; interval --- @ 13 mins (1 row) ler=# set datestyle='sql'; SET ler=# select '13 minutes'::interval; interval --- @ 13 mins (1 row) ler=# set datestyle='iso,us'; SET ler=# select '13 minutes'::interval; interval -- 00:13 (1 row) ler=# -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pg_get_triggerdef in pg_dump
I don't think an option to do such justification would be good unless we can do it consistenly in the code, and there is enough demand. --- Andreas Pflug wrote: Rod Taylor wrote: Oh, one more thing --- right justify isn't as accepted as left-justify But it looks so much better... Ye! Consider this: SELECT foo FROM bar b LEFT JOIN chair c USING (thekeycol) WHERE ... :-) versus SELECT foo FROM bar b LEFT JOIN chair c USING (thekeycol) WHERE ... The keywords are separated :-( SELECT foo FROM bar b LEFT JOIN chair c USING (thekeycol) WHERE ... No more lineup :-( Admittedly, when you type it yourself, it's a bit annoying, because you can't use just tabs. But if it's generated, it won't do any harm. Why not giving PostgreSQL this extra portion of elegance... Regards, Andreas -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] ss_family in hba.c
Kurt Roeckx wrote: On Mon, Jun 23, 2003 at 07:49:11PM -0400, Bruce Momjian wrote: I have applied a patch to CVS to fix the problem. It is all your patch, except for the part you got from me, which was wrong. :-( It took me a while to realize the subtlety of your patch. First, it removes the use of sa_family_t _except_ for cases that don't have SOCKADDR_STORAGE, where it is required. Second, it allows for a structure member named ss_family or __ss_family, tested via configure. This should fix most platforms. I am not sure how cygwin is going to handle this --- we might have to add a specific sa_family_t typedef for that platform --- MinGW does have sa_family_t, but probably doesn't need it anyway. Testing for the size of sa_family_t is possible via configure, but if only cygwin needs it, we can just hard-code that platform in the template files. Cygwin folks, would you test CVS and let me know. There are probably other systems that don't have sa_family_t yet, but they should be rather old. Even my Solaris 2.6 already seems to have it. What I was confused about is, is that cygwin seems to have a struct sockaddr_storage in the first place (in winsock2.h). I'm not sure what problem he really had since he only told it how he solved it. All that probably needed to change for cygwin was to no longer use sa_family_t in the getaddrinfo.c. But Jason reported he needed that typedef for sa_family_t. Jason, is that accurate. If you remove the Cygwin typedef in pqcomm.h, does the compile fail? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: 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_get_triggerdef in pg_dump
SELECT foo FROM bar b LEFT JOIN chair c USING (thekeycol) WHERE ... :-) Sub-selects are much nicer: SELECT foo , bar , (SELECT anotherfoo FROM tab2 WHERE tab2.col = tab1.col) FROM tab JOIN yet_another_table AS yat ON (yat.c = tab.c) LEFT JOIN tab1 USING (anothercol) WHERE stuff IS TRUE AND ( optional IS NULL OR optional 5) HAVING count(*) (SELECT total FROM total_table) ORDER BY foo GROUP BY foo , bar , 3; -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] ss_family in hba.c
Bruce, On Tue, Jun 24, 2003 at 03:04:05PM -0400, Bruce Momjian wrote: Kurt Roeckx wrote: All that probably needed to change for cygwin was to no longer use sa_family_t in the getaddrinfo.c. But Jason reported he needed that typedef for sa_family_t. Jason, is that accurate. Yes. If you remove the Cygwin typedef in pqcomm.h, does the compile fail? Yes: gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -DBUILDING_DLL -c -o printtup.o printtup.c In file included from ../../../../src/include/libpq/libpq-be.h:22, from ../../../../src/include/libpq/libpq.h:21, from printtup.c:20: ../../../../src/include/libpq/pqcomm.h:54: parse error before sa_family_t [snip] Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Two weeks to feature freeze
On Mon, 2003-06-23 at 21:36, The Hermit Hacker wrote:
On Mon, 23 Jun 2003, Robert Treat wrote:
The target-date-based approach we've taken in the last couple of
releases seems much more productive.
productive on a small scale; for sure. productive for large scale
features... well, that's why it's being discussed.
'K, but if we extend the dev cycle in order to get 'foo' in, how is that
better then having 'foo' continue to be developed thru the release and
committed in the next cycle?
I think it makes it easier to code 'foo' since you're not coding against
(quite as much of) a moving target. I could also help developers stay
focused on particular projects since they are the hot potato for a
given release. It could also help people plan better since they would
know that foo is coming in the next release.
If it takes foo 6 months to develop, I'd rather have the release happen
after 4 months as per normal (or close to it) and have 'foo' brought in
part way into dev cycle 2 ... at least then, if 'foo' ends up taking 7
months, we aren't delaying even further ...
i'm sure everyone who doesn't want foo would agree with that position.
The counter though is those folks who did want foo but now have to wait
4-6 months for the next release since foo took a month longer to develop
than was initially planned.
Its not like our dev cycles have 'idle periods' where nothing is happening
and we're waiting for a feature to come along ... there is *alot* of
changes going on that affect alot of ppl that don't really care about
feature 'foo' coming along ...
this doesn't really change anything for those folks, since the only
rational is every 6 months we do a release. ie. there are *alot* of
changes going on that affect alot of ppl that don't really care about
waiting n more months...
the whole discussion is based on how do we get big projects done when no
one is motivated to work on 'foo' until there faced with a deadline;
this idea puts the pressure on 'foo' developers from the get go. i'm not
saying this a guaranteed way to solve that problem but i think it is a
possible solution. i'm sure there will be big projects most people don't
care about (win32) and big projects most people would like (replication)
so the amount of like or dislike of the idea would be relative in
practice, the key question is would this actually motivate folks more to
get big projects finished faster? since there are only a handful of
folks who fall into that category they can decide for themselves, and if
it wouldn't motivate them, then the question can be asked again, what
would?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] capturing and storing query statement with rules
(moving to HACKERS) Mike Mascari wrote: Joe Conway wrote: I think this shows how to do what you want: http://archives.postgresql.org/pgsql-sql/2003-05/msg00301.php Maybe debug_query_string should be mapped into a variable like CURRENT_USER? Perhaps something like CURRENT_QUERY? I was thinking something similar. This exact question has come up at least three times in the last three months. I doubt we'd want a special keyword like CURRENT_QUERY, but maybe current_query()? Comments? Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] interval's and printing...
--On Tuesday, June 24, 2003 14:43:24 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: TODO updated: * Have SELECT '13 minutes'::interval display zero seconds in ISO datestyle I just posted a patch to -patches for this. (it's a quickie, even). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two weeks to feature freeze
Robert Treat wrote: the whole discussion is based on how do we get big projects done when no one is motivated to work on 'foo' until there faced with a deadline; this idea puts the pressure on 'foo' developers from the get go. i'm not saying this a guaranteed way to solve that problem but i think it is a possible solution. i'm sure there will be big projects most people don't care about (win32) and big projects most people would like (replication) so the amount of like or dislike of the idea would be relative in practice, the key question is would this actually motivate folks more to get big projects finished faster? since there are only a handful of folks who fall into that category they can decide for themselves, and if it wouldn't motivate them, then the question can be asked again, what would? I can confirm that there are several people working on Win32/PITR right now, maybe four, that wouldn't if we hadn't set the beta freeze at July 1 --- so such pressure is a real motivator --- though certainly this isn't the way we want to motivate developers. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [GENERAL] capturing and storing query statement with
--On Tuesday, June 24, 2003 14:07:23 -0700 Joe Conway [EMAIL PROTECTED] wrote: (moving to HACKERS) Mike Mascari wrote: Joe Conway wrote: I think this shows how to do what you want: http://archives.postgresql.org/pgsql-sql/2003-05/msg00301.php Maybe debug_query_string should be mapped into a variable like CURRENT_USER? Perhaps something like CURRENT_QUERY? I was thinking something similar. This exact question has come up at least three times in the last three months. I doubt we'd want a special keyword like CURRENT_QUERY, but maybe current_query()? Comments? I was thinking the same thing. Currently I use the contrib/dblink supplied function, but a firstclass, in the default install, version would be nice. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pg_get_triggerdef in pg_dump
Bruce Momjian wrote: I don't think an option to do such justification would be good unless we can do it consistenly in the code, and there is enough demand. It's no big additional effort to do this, and going back and forth is not a big problem. I wouldn't invent an option for that, just do it. Let's see what's happening. At least, there seems agreement on not using tabs but spaces. Still, I'd like to have somebody having a look at my algorithm. It's the key component, which should be proven right theoretically. Regards, Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two weeks to feature freeze
'K, and do you have any ETA on when you'll have this translated into some useful tests that we can incorporate? On Mon, 23 Jun 2003, Dann Corbit wrote: Here is a list of a small sample of the citations available from the ACM on software testing: http://portal.acm.org/citation.cfm?id=581358coll=portaldl=ACMCFID=657 0092CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=376180coll=portaldl=ACMCFID=657 0092CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=367020coll=portaldl=ACMCFID=657 0092CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=308790coll=portaldl=ACMCFID=657 0092CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=257668coll=portaldl=ACMCFID=657 0092CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=248262coll=portaldl=ACMCFID=657 0092CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=227759coll=portaldl=ACMCFID=657 0092CFTOKEN=81653602 These articles are careful, scientific studies that have been extensively peer reviewed. These articles indicate that testing is a good idea. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Two weeks to feature freeze
On Mon, 23 Jun 2003, Dann Corbit wrote: -Original Message- From: Jan Wieck [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 10:30 PM To: Dann Corbit Cc: scott.marlowe; Bruce Momjian; Tom Lane; Jason Earl; PostgreSQL-development Subject: Re: [HACKERS] Two weeks to feature freeze [snip] I personally think you don't actually ever did any software testing yourself. You are not really talking from experience, are you? So please, show me what you have now, or get one more plus on my minus-list. I have already posted enough information to show my qualitications. Whether I am qualified or not is irrelevant to whether the argument has merit or not. I have raised what I consider to be an important issue. You have raised a point that you are not prepared to do anything about though ... nobody disagrees with you about adding more testing, but if you aren't willing to do the work, why should anyone else be? Someone has to spearhead it ... you seem to be passionate about seeing it happen, but don't care enough to do anything about it ... ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
On Mon, 23 Jun 2003, Dann Corbit wrote: Would it be nice if we had more tests? Yes. In fact, one of the items on my personal todo list is to devise a more versatile performance test than pgbench for testing postgresql parameters, builds, and installations. But it's not getting done by me carping at people on the Hackers list. It'll get done when I spend a long weekend writing Perl. Put up or shut up time, Dann. It's shut up, then. I'm not willing to commit to this effort. Woo hoo ... now *that* was the longest, useless thread I think we've had here so far .. we almost need to start a 'hall of shameful threads' ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
On Tue, 24 Jun 2003, Robert Treat wrote: On Mon, 2003-06-23 at 21:36, The Hermit Hacker wrote: On Mon, 23 Jun 2003, Robert Treat wrote: The target-date-based approach we've taken in the last couple of releases seems much more productive. productive on a small scale; for sure. productive for large scale features... well, that's why it's being discussed. 'K, but if we extend the dev cycle in order to get 'foo' in, how is that better then having 'foo' continue to be developed thru the release and committed in the next cycle? I think it makes it easier to code 'foo' since you're not coding against (quite as much of) a moving target. I *soo* disagree with this one ... the only way that postgresql is going to stop being a moving target so that someone can code 'foo' is if everyone else goes to sleep until that happens ... It could also help people plan better since they would know that foo is coming in the next release. 'K, that helps the end users, but that doesn't do anything for the person developing 'foo' ... i'm sure everyone who doesn't want foo would agree with that position. The counter though is those folks who did want foo but now have to wait 4-6 months for the next release since foo took a month longer to develop than was initially planned. Ya, but, based on past experience (hell, this release has been a good example) ... you delay the release because developer of 'foo' figures oh, it will be ready in another month, and then something comes up that causes that commitment not to happen, so we delay it yet another month? And I'm not saying that the second delay was due to mis-estimating the time needed ... suddenly getting really busy on a contract, a day job, a death in the family, etc ... you cannot predict what could cause a delay, or how long such a delay would take ... the whole discussion is based on how do we get big projects done when no one is motivated to work on 'foo' until there faced with a deadline; this idea puts the pressure on 'foo' developers from the get go. i'm not saying this a guaranteed way to solve that problem but i think it is a possible solution. i'm sure there will be big projects most people don't care about (win32) and big projects most people would like (replication) so the amount of like or dislike of the idea would be relative in practice, the key question is would this actually motivate folks more to get big projects finished faster? since there are only a handful of folks who fall into that category they can decide for themselves, and if it wouldn't motivate them, then the question can be asked again, what would? First, we already seen that such a 'pressure' doesn't matter, especially if when push comes to shove, they know we'll postpone to accommodate them ... Second ... I don't believe the problem *is* the release cycles ... I think the problem that needs a solution is how to open up these large projects so that the deadline(s) don't fall on ones person's shoulders to get done .. how do we encourage/promote work groups for the large projects? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
On Tue, 24 Jun 2003, Dann Corbit wrote: I did something about it. I raised the issue. Is it really so that whoever it is that raises a question is also the one who must fix the issue raised? A strange model indeed. Its worked for us ... Wait, I know what should make you happy ... it won't get anytihng done, but ... Bruce, can you add * Improve Testing to the TODO list Someone has to spearhead it ... you seem to be passionate about seeing it happen, but don't care enough to do anything about it ... Don't care and won't do are not the same thing. Well, actually, they are ... if someone doesn't care, they aren't going to do, are they? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] RServ patch to support multiple slaves (sorta)
Patch applied. Thanks. --- Michael A Nachbaur wrote: Attached is a patch that provides *VERY* limited support for multiple slave servers. I haven't tested it very well, so use at your own risk (and I recommend against using it in production). Basically, I have a central database server that has 4 summary tables inside it replicated to a remote slave (these database tables are for my mail server authentication, so these are replicated to another server tuned for many connections, and so I don't have postgres connections opened straight to my back-end database server). Unfortunately, I also wanted to implement a replication database server for hot-backups. I realized, too late, that the replication process is pretty greedy and will try to replicate all tables marked as a MasterAddTable. To make a long story, I made a patch to RServ.pm and Replicate that allows you to specify, on the command line, a list of tables that you want to replicate...it'll ignore all others. I haven't finished, since this has to be integrated with CleanLog for instance, but this should (and does) suffice for the moment. I have yet to test it with two slaves, but at least my mail server replication database now works (it was failing every time it tried to replicate, for a variety of reasons). Anyone have any suggestions on how to improve on this? (or, if someone more familiar with this code wants to take the ball and run with it, you're welcome to). -- Michael A Nachbaur [EMAIL PROTECTED] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] compile failure on cvs tip --with-krb5
Patch applied. Thanks. --- Kurt Roeckx wrote: On Fri, Jun 20, 2003 at 07:48:02PM -0700, Joe Conway wrote: This change (I'm sure this will wrap poorly -- sorry): http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/libpq/pqcomm.h.diff?r1=1.85r2=1.86 modified SockAddr, but no corresponding change was made here (fe-auth.c:612): case AUTH_REQ_KRB5: #ifdef KRB5 if (pg_krb5_sendauth(PQerrormsg, conn-sock, conn-laddr.in, conn-raddr.in, hostname) != STATUS_OK) It's not obvious to me what the change ought to be though. This patch should hopefully fix both kerberos 4 and 5. Kurt [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Two weeks to feature freeze
The Hermit Hacker wrote: On Tue, 24 Jun 2003, Dann Corbit wrote: I did something about it. I raised the issue. Is it really so that whoever it is that raises a question is also the one who must fix the issue raised? A strange model indeed. Its worked for us ... Wait, I know what should make you happy ... it won't get anytihng done, but ... Bruce, can you add * Improve Testing to the TODO list That seems too vague for TODO. We might as well add Make PostgreSQL faster. :-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Two weeks to feature freeze
-Original Message- From: The Hermit Hacker [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 6:10 PM To: Dann Corbit Cc: The Hermit Hacker; Jan Wieck; scott.marlowe; Bruce Momjian; Tom Lane; Jason Earl; PostgreSQL-development Subject: RE: [HACKERS] Two weeks to feature freeze On Tue, 24 Jun 2003, Dann Corbit wrote: I did something about it. I raised the issue. Is it really so that whoever it is that raises a question is also the one who must fix the issue raised? A strange model indeed. Its worked for us ... Wait, I know what should make you happy ... it won't get anytihng done, but ... Bruce, can you add * Improve Testing to the TODO list It is surely a titanic mistake to bring up any issue on this list if you do not plan to fix it yourself. Someone has to spearhead it ... you seem to be passionate about seeing it happen, but don't care enough to do anything about it ... Don't care and won't do are not the same thing. Well, actually, they are ... if someone doesn't care, they aren't going to do, are they? You have had the time to do everything you ever cared about? It is really true that I have made a titanic waste of time in an effort to get someone else to do something about it or at least get them interested in it. I won't waste my time in that way again. I deeply rue the time I have wasted already. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
I think it was a useful discussion. I find it interesting to compare our clearly ad-hock testing methods to traditional commercial testing strategies. I think our results are very good, but it does look awful ad-hock and it is easy to see how someone would question its effectiveness. Of course, the whole open source development model seems ad-hock too, and on the surface seems inferior to a commercial software development model, but there again, the proof is in the result. --- Dann Corbit wrote: -Original Message- From: The Hermit Hacker [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 6:10 PM To: Dann Corbit Cc: The Hermit Hacker; Jan Wieck; scott.marlowe; Bruce Momjian; Tom Lane; Jason Earl; PostgreSQL-development Subject: RE: [HACKERS] Two weeks to feature freeze On Tue, 24 Jun 2003, Dann Corbit wrote: I did something about it. I raised the issue. Is it really so that whoever it is that raises a question is also the one who must fix the issue raised? A strange model indeed. Its worked for us ... Wait, I know what should make you happy ... it won't get anytihng done, but ... Bruce, can you add * Improve Testing to the TODO list It is surely a titanic mistake to bring up any issue on this list if you do not plan to fix it yourself. Someone has to spearhead it ... you seem to be passionate about seeing it happen, but don't care enough to do anything about it ... Don't care and won't do are not the same thing. Well, actually, they are ... if someone doesn't care, they aren't going to do, are they? You have had the time to do everything you ever cared about? It is really true that I have made a titanic waste of time in an effort to get someone else to do something about it or at least get them interested in it. I won't waste my time in that way again. I deeply rue the time I have wasted already. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: 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] Two weeks to feature freeze
On Tue, 24 Jun 2003, Bruce Momjian wrote: The Hermit Hacker wrote: On Tue, 24 Jun 2003, Dann Corbit wrote: I did something about it. I raised the issue. Is it really so that whoever it is that raises a question is also the one who must fix the issue raised? A strange model indeed. Its worked for us ... Wait, I know what should make you happy ... it won't get anytihng done, but ... Bruce, can you add * Improve Testing to the TODO list That seems too vague for TODO. We might as well add Make PostgreSQL faster. :-) 'K, can you add that one too? :) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Two weeks to feature freeze
On Tue, 24 Jun 2003, Dann Corbit wrote: Don't care and won't do are not the same thing. Well, actually, they are ... if someone doesn't care, they aren't going to do, are they? You have had the time to do everything you ever cared about? No no, that isn't what he is arguing (or I'm miss reading) ... he said that not caring about something *and* not doing it aren't the same thing ... which isnt' the same as caring but not having the time ... is it? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] compile warnings
Since we're getting close to a freeze, I thought I'd point out these warnings again: make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/pgtypeslib' [...] i386-redhat-linux-gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/include -I/usr/kerberos/include -g -c -o timestamp.o timestamp.c -MMD timestamp.c: In function `dttofmtasc_replace': timestamp.c:468: warning: `%g' yields only last 2 digits of year timestamp.c:606: warning: `%x' yields only last 2 digits of year in some locales -and- make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/preproc' [...] i386-redhat-linux-gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -Wno-error -I./../include -I. -I../../../../src/include -I/usr/kerberos/include -DMAJOR_VERSION=3 -DMINOR_VERSION=0 -DPATCHLEVEL=0 -DINCLUDE_PATH=\/usr/include\ -c -o preproc.o preproc.c -MMD In file included from preproc.y:6189: pgc.c: In function `yylex': pgc.c:1386: warning: label `find_rule' defined but not used /usr/include/ctype.h: At top level: pgc.c:3377: warning: `yy_flex_realloc' defined but not used Other than these 4 warnings, I get a clean compile on Red Hat 9 and 8.0 systems. Joe ---(end of broadcast)--- TIP 3: 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] compile warnings
Joe Conway wrote: Since we're getting close to a freeze, I thought I'd point out these warnings again: make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/pgtypeslib' [...] i386-redhat-linux-gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/include -I/usr/kerberos/include -g -c -o timestamp.o timestamp.c -MMD timestamp.c: In function `dttofmtasc_replace': timestamp.c:468: warning: `%g' yields only last 2 digits of year timestamp.c:606: warning: `%x' yields only last 2 digits of year in some locales Micheal Meskes has asked if anyone has an idea on how to fix this. -and- make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/preproc' [...] i386-redhat-linux-gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -Wno-error -I./../include -I. -I../../../../src/include -I/usr/kerberos/include -DMAJOR_VERSION=3 -DMINOR_VERSION=0 -DPATCHLEVEL=0 -DINCLUDE_PATH=\/usr/include\ -c -o preproc.o preproc.c -MMD In file included from preproc.y:6189: pgc.c: In function `yylex': pgc.c:1386: warning: label `find_rule' defined but not used /usr/include/ctype.h: At top level: pgc.c:3377: warning: `yy_flex_realloc' defined but not used Other than these 4 warnings, I get a clean compile on Red Hat 9 and 8.0 systems. I believe these are coming from bison and it is difficult to fix. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] PHP/PgSQL *and* libpq ...
Just a side bar to the whole thread about PHP/MySQL ... I realize that libpq is intwined with the backend right now, but if anyone could think of a way of at least adding a make target that would create a libpq.tar.gz distribution, I believe it would go a long way towards making it easier for ppl to add/compile in PgSQL support into PHP ... right now, to do so, you have to download an 8Meg file to get libpq ... if it could be reduced to a .5Meg tar.gz file: svr1# du -sk libpq 532 libpq it would be less onerous to download and add the support in ... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PHP/PgSQL *and* libpq ...
Added to TODO: * Allow creation of a libpq-only tarball --- The Hermit Hacker wrote: Just a side bar to the whole thread about PHP/MySQL ... I realize that libpq is intwined with the backend right now, but if anyone could think of a way of at least adding a make target that would create a libpq.tar.gz distribution, I believe it would go a long way towards making it easier for ppl to add/compile in PgSQL support into PHP ... right now, to do so, you have to download an 8Meg file to get libpq ... if it could be reduced to a .5Meg tar.gz file: svr1# du -sk libpq 532 libpq it would be less onerous to download and add the support in ... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Two weeks to feature freeze
The Hermit Hacker wrote: On Tue, 24 Jun 2003, Dann Corbit wrote: I did something about it. I raised the issue. Is it really so that whoever it is that raises a question is also the one who must fix the issue raised? A strange model indeed. Its worked for us ... Sorry Marc, but that ain't entirely true. There have been a good number of examples where the one who raised an issue isn't just of the format to implement it. So someone else jumped in and did it instead. I don't need to pick any particular samples, you know that it happened a few times. And don't get the wrong picture. Yes, Dann is just talking here on the testing methodology front. But as much as it looks like we two hate each other on this thread, we actually start working together on a totally different issue. And to say the least, I like his version better than Katie's ... 'nuff said. Jan Wait, I know what should make you happy ... it won't get anytihng done, but ... Bruce, can you add * Improve Testing to the TODO list Someone has to spearhead it ... you seem to be passionate about seeing it happen, but don't care enough to do anything about it ... Don't care and won't do are not the same thing. Well, actually, they are ... if someone doesn't care, they aren't going to do, are they? -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 3: 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] libpgtcl and pgtclsh
I'm looking to move both of these over to GBorg, like we did with the C++ interfaces and ODBC ... the problem is, unlike those, I can't find anyone that is actually working with it ... Is anyone using these? Anyone willing to step up and act as maintainer for it? Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
The Hermit Hacker wrote: On Tue, 24 Jun 2003, Bruce Momjian wrote: The Hermit Hacker wrote: On Tue, 24 Jun 2003, Dann Corbit wrote: I did something about it. I raised the issue. Is it really so that whoever it is that raises a question is also the one who must fix the issue raised? A strange model indeed. Its worked for us ... Wait, I know what should make you happy ... it won't get anytihng done, but ... Bruce, can you add * Improve Testing to the TODO list That seems too vague for TODO. We might as well add Make PostgreSQL faster. :-) 'K, can you add that one too? :) Make his life easier: Replace the entire TODO with Make PostgreSQL better That pretty much summs it up, no? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
On Tue, 24 Jun 2003, Jan Wieck wrote: The Hermit Hacker wrote: On Tue, 24 Jun 2003, Bruce Momjian wrote: The Hermit Hacker wrote: On Tue, 24 Jun 2003, Dann Corbit wrote: I did something about it. I raised the issue. Is it really so that whoever it is that raises a question is also the one who must fix the issue raised? A strange model indeed. Its worked for us ... Wait, I know what should make you happy ... it won't get anytihng done, but ... Bruce, can you add * Improve Testing to the TODO list That seems too vague for TODO. We might as well add Make PostgreSQL faster. :-) 'K, can you add that one too? :) Make his life easier: Replace the entire TODO with Make PostgreSQL better That pretty much summs it up, no? Oh, I like that ... definitely leaves it open to the interpretation of the reader as to what would make it better :) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] Many Pl/PgSQL parameters - AllocSetAlloc(128)?
Joe Conway [EMAIL PROTECTED] writes: Actually, adding a pfree(oneres); to the end of that for loop plugs the memory leak and allows me to see the error message: Good catch. Takes a while to check all 16777216 possibilities though, so I'm still not sure more isn't needed here. I wonder why it's doing anything at all --- the check for supertypes ought to trigger only for complex type (rowtype) arguments, and there are none here. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [GENERAL] Many Pl/PgSQL parameters - AllocSetAlloc(128)?
Joe Conway [EMAIL PROTECTED] writes: Actually, adding a pfree(oneres); to the end of that for loop plugs the memory leak and allows me to see the error message: On second look, you can't pfree oneres at the bottom of gen_cross_product() because it's part of the returned data structure --- note the assignment *iter++ = oneres; I think the bug here is that gen_cross_product should be ignoring argument positions that have nsupers == 0; those should always be assigned the same type as the input, since the regular type resolution algorithm is responsible for dealing with 'em. It might work to get rid of the wild card case (line 1115), which'd reduce the number of outputs to product(nsupers+1). I doubt we really want any wild cards in there anymore. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
