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:
nanswers = 1;
for (i = 0; i < nargs; i++)
{
nanswers *= (arginh[i].nsupers + 2);
cur[i] = 0;
}
iter = result = (Oid **) palloc(sizeof(Oid *) * nanswers);
I get nanswers = 16777216, so right off the bat 67MB or so is allocated.
Then there's this:
/* compute the cross product from right to left */
for (;;)
{
oneres = (Oid *) palloc0(FUNC_MAX_ARGS * sizeof(Oid));
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,", ' ' , "\n'en_US'::varchar,", ' '
, "\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 broadcast)---
TIP 4: Don't 'kill -
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] Two weeks to feature freeze
> -Original Message- > From: Josh Berkus [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2003 10:50 PM > To: Dann Corbit; Jan Wieck > Cc: scott.marlowe; Bruce Momjian; Tom Lane; Jason Earl; > PostgreSQL-development > Subject: Re: [HACKERS] Two weeks to feature freeze > > > Dann, > > > 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. > > It is not irrelevant. This is an Open Source project, not > some Dot-Com where > you can float good ideas until you go bankrupt. If there's > no possibility > of us getting a major 3rd-party certified battery of QA tests > donated, why > bother putting it on the TODO list? > > 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. ---(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
Dann, > 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. It is not irrelevant. This is an Open Source project, not some Dot-Com where you can float good ideas until you go bankrupt. If there's no possibility of us getting a major 3rd-party certified battery of QA tests donated, why bother putting it on the TODO list? 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. -- Josh Berkus Aglio Database Solutions San Francisco ---(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
> -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. ---(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
Dann Corbit wrote: -Original Message- From: Jan Wieck [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 10:10 PM To: scott.marlowe Cc: Dann Corbit; Bruce Momjian; Tom Lane; Jason Earl; PostgreSQL-development Subject: Re: [HACKERS] Two weeks to feature freeze scott.marlowe wrote: > On Mon, 23 Jun 2003, Dann Corbit wrote: > [Dann Corbit wrote a lot] > [...] > It may be reassuring to think your product is very well tested before > it > goes out the door, but it's a false security, proven over and over by > commercial products that simply don't work in the field because of > problems that the original designers never envisioned, and now that they > have a thorough and long drawn out testing cycle, it simply takes longer > and longer to get fixes, while providing little, if any, improvement in > quality. Scott, it's worse. It's been back in the early 90's, when we had WfW-3.11 systems with some MS-Word dinosaur, and we just lost 14 days of work because it simply crashed on loading the document. The Microsoft support solution was something that lost all the formatting, indexing and cross references of a structured 250 page concept. I don't remember the exact procedure as my brain cells did overcharge, but the dummy on the hotline really believed that their thoroughly tested software wasn't the problem and that the error lies within our document. That that was a file, written by their thoroughly tested software was a point she really didn't catch. This dumb hotline girl is the type of people, Dann Corbit's test strategy will reassure. Plus maybe a few (unfortunately important but otherwise useless) managers. Other than that, it'll not make the life of the average DBA any better. Big amounts of useless tests just give otherwise clueless people the false impression, the error must be somewhere else. MySQL's crash-me is a perfect example for that. Do you really believe that such disasters were the result of careful testing before release? Everyone who thinks a careful test plan and implementation is a bad idea is very, very wrong. IMO-YMMV. No, I do not. But again, where is your "careful test plan" please? All I have seen from you so far is asking us to provide you with a careful test plan while dancing carefully around every single attempt to get a look at what you got so far. I have written PostgreSQL regression tests. I have done consistency checks of entire ERP systems prior to data conversion attempts. I know the value of tests, whether they are against software or data. May I ask what you've done so far? 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. 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Two weeks to feature freeze
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=581358&coll=portal&dl=ACM&CFID=657 0092&CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=376180&coll=portal&dl=ACM&CFID=657 0092&CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=367020&coll=portal&dl=ACM&CFID=657 0092&CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=308790&coll=portal&dl=ACM&CFID=657 0092&CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=257668&coll=portal&dl=ACM&CFID=657 0092&CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=248262&coll=portal&dl=ACM&CFID=657 0092&CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=227759&coll=portal&dl=ACM&CFID=657 0092&CFTOKEN=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
Re: [HACKERS] Two weeks to feature freeze
> -Original Message- > From: Jan Wieck [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2003 10:10 PM > To: scott.marlowe > Cc: Dann Corbit; Bruce Momjian; Tom Lane; Jason Earl; > PostgreSQL-development > Subject: Re: [HACKERS] Two weeks to feature freeze > > > scott.marlowe wrote: > > On Mon, 23 Jun 2003, Dann Corbit wrote: > > [Dann Corbit wrote a lot] > > [...] > > It may be reassuring to think your product is very well > tested before > > it > > goes out the door, but it's a false security, proven over > and over by > > commercial products that simply don't work in the field because of > > problems that the original designers never envisioned, and > now that they > > have a thorough and long drawn out testing cycle, it simply > takes longer > > and longer to get fixes, while providing little, if any, > improvement in > > quality. > > Scott, it's worse. > > It's been back in the early 90's, when we had WfW-3.11 > systems with some > MS-Word dinosaur, and we just lost 14 days of work because it simply > crashed on loading the document. The Microsoft support solution was > something that lost all the formatting, indexing and cross > references of > a structured 250 page concept. I don't remember the exact > procedure as > my brain cells did overcharge, but the dummy on the hotline really > believed that their thoroughly tested software wasn't the problem and > that the error lies within our document. That that was a > file, written > by their thoroughly tested software was a point she really > didn't catch. > > This dumb hotline girl is the type of people, Dann Corbit's test > strategy will reassure. Plus maybe a few (unfortunately important but > otherwise useless) managers. Other than that, it'll not make > the life of > the average DBA any better. Big amounts of useless tests just give > otherwise clueless people the false impression, the error must be > somewhere else. MySQL's crash-me is a perfect example for that. Do you really believe that such disasters were the result of careful testing before release? Everyone who thinks a careful test plan and implementation is a bad idea is very, very wrong. IMO-YMMV. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] a problem with index and user define type
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. Thank you! Regards Laser Tom Lane wrote: Weiping He <[EMAIL PROTECTED]> writes: the situation trun worse: now the explain shows the query using the index, the we can't select out the match row! Any hint about what's wrong with us? My bet: either your operators are broken or your operator class definition is wrong. regards, tom lane ---(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
scott.marlowe wrote: On Mon, 23 Jun 2003, Dann Corbit wrote: > [Dann Corbit wrote a lot] > [...] It may be reassuring to think your product is very well tested before it goes out the door, but it's a false security, proven over and over by commercial products that simply don't work in the field because of problems that the original designers never envisioned, and now that they have a thorough and long drawn out testing cycle, it simply takes longer and longer to get fixes, while providing little, if any, improvement in quality. Scott, it's worse. It's been back in the early 90's, when we had WfW-3.11 systems with some MS-Word dinosaur, and we just lost 14 days of work because it simply crashed on loading the document. The Microsoft support solution was something that lost all the formatting, indexing and cross references of a structured 250 page concept. I don't remember the exact procedure as my brain cells did overcharge, but the dummy on the hotline really believed that their thoroughly tested software wasn't the problem and that the error lies within our document. That that was a file, written by their thoroughly tested software was a point she really didn't catch. This dumb hotline girl is the type of people, Dann Corbit's test strategy will reassure. Plus maybe a few (unfortunately important but otherwise useless) managers. Other than that, it'll not make the life of the average DBA any better. Big amounts of useless tests just give otherwise clueless people the false impression, the error must be somewhere else. MySQL's crash-me is a perfect example for that. 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] dblink_ora - a first shot on Oracle ...
Bruce Momjian wrote: Well, we have a patch, so we need someone to babysit it until it is applied, or put it somewhere and reference it via TODO. OK -- either way is fine by me. Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] dblink_ora - a first shot on Oracle ...
Well, we have a patch, so we need someone to babysit it until it is applied, or put it somewhere and reference it via TODO. --- Joe Conway wrote: > Bruce Momjian wrote: > > OK, can you take ownership of it? > > > > You mean a TODO entry? Sure, as long as Hans is OK with it. > > Joe > > > -- 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] dblink_ora - a first shot on Oracle ...
Bruce Momjian wrote: OK, can you take ownership of it? You mean a TODO entry? Sure, as long as Hans is OK with it. 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] dblink_ora - a first shot on Oracle ...
OK, can you take ownership of it? --- Joe Conway wrote: > Bruce Momjian wrote: > > This seems like a natural addition to our existing dblink in /contrib. > > > > 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. > > Joe > > -- 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 ...
Bruce Momjian wrote: This seems like a natural addition to our existing dblink in /contrib. 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. Joe ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] How to disconnect a user
Someone's asking this in the PHPBuilder forums: http://www.phpbuilder.com/board/showthread.php?s=e35a83518b040c2b4db0c7ef3867ab40&threadid=10244626 --- Hi all Is there a way to disconnect users from a D.B in postgresql rather than kill -9 the pid user? thanks in advance --- Doesn't seem to me that there's any way to do it... Chris ---(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] Subtraction carry bug in xlog.c in 7.3 and 7.4
Bruce Momjian <[EMAIL PROTECTED]> writes: > Should we add an Assert() to make it clear the current code is OK? A comment maybe, but not an assert. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 2Q implementaion for PostgreSQL buffer replacement.
Looks good to me --- we will include it in 7.4. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- 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 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
Dann Corbit wrote: -Original Message- From: Jan Wieck [mailto:[EMAIL PROTECTED] What do you think is the way to become an insider? Join the CVS tree and make a large and valuable contribution to the project. Go ahead, let's see it. I have contributed a lot of crap over the years. After some other knowingly good and professional programmers layed hand on it, it turned out to be usefull. This isn't meant 100% ironically. I really don't think the original version of the parallel regression test, just to stay with the topic for this example, was worth the bit's needed for storage. But it was a starting point, others built on. And crappy as it was, it caught a bug - funny, isn't it? So don't be afraid, let's see what you got so far. 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 8: explain analyze is your friend
Re: [HACKERS] interval's and printing...
Add to TODO: * Have SELECT '13 minutes'::interval display zero seconds --- Larry Rosenman wrote: > Why does the interval type not print seconds when they are zero? > > This leads to inconsistent reading of the information. > > 7.3.3: > > ler=# select '13 minutes'::interval; > interval > -- > 00:13 > (1 row) > > ler=# select '13 minutes 1 second'::interval; > interval > -- > 00:13:01 > (1 row) > > ler=# > > I noticed this when I loaded the data from my long distance company into > a PG database. > > > -- > 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 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] Regression tests fails to start on system without unix
Added to TODO: Allow the regression tests to start postmaster with -i so the tests can be run on systems that don't support unix-domain sockets --- Tom Lane wrote: > Kurt Roeckx <[EMAIL PROTECTED]> writes: > > The regression tests will fail to start on a system that doesn't > > have, or wasn't compiled for, unix domain sockets. > > I see some options to fix this: > > - Always start with -i > > - Make the "unix_sockets" variable depend on > > HAVE_UNIX_SOCKETS intead of listen the OSs. > > The second way is the way it should have been done all along. > > Probably the best fix is to add a command-line switch to pg_regress > to instruct it to use -i, and then have the makefile test > HAVE_UNIX_SOCKETS to decide whether to pass that switch. This way, > hand invocation of the script could easily run the test both ways, > on machines where that's possible. > > regards, tom lane > > ---(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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] compile failure on cvs tip --with-krb5
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- 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.85&r2=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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Subtraction carry bug in xlog.c in 7.3 and 7.4
Should we add an Assert() to make it clear the current code is OK? --- Tom Lane wrote: > "J.R. Nield" <[EMAIL PROTECTED]> writes: > > The attached patches against 7.3 and 7.4 fix a subtraction carry bug in > > xlog.c. > > This is simply a waste of cycles, because xrecoff can never be zero > (if it were, it'd be pointing at a page header, which is not a valid > record location). If you look around in the code, you'll note that > xrecoff==0 is actually used as an invalid-value flag in a couple of > contexts. > > Can you point to anyplace where the behavior would change? If so > I think there's a deeper bug to fix. > > regards, tom lane > > ---(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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two weeks to feature freeze
Thank's Robert, that was probably what Bruce needs to call me every other hour now ... Jan Robert Treat wrote: On Sat, 2003-06-21 at 22:55, Bruce Momjian wrote: Andrew Dunstan wrote: > > Maybe a better strategy would be to get a release out soon but not wait 6 > months for another release which would contain the Win32 port and the PITR > stuff (assuming those aren't done in time for this release). What concerns me is that we thought that after 7.3, and didn't do much work on either until we got near 7.4 release. I wonder if this is just going to be a pattern, where these items are so large, we can't get any motivation to focus on them until we get near the final release. I guess if each final release gets us a little closer, eventually we will get there, but this process is not ideal. The big puzzle is how do you get people (including myself) motivated to work on a feature that takes a _huge_ amount of work to see any payoff? I would like to know. Anyone? Here's a sure to be wildly unpopular suggestion: Make the deciding factor for the next release support of "foo" (foo can be win32, pitr, replication, 2PC, whatever...). This would put ample pressure on the developers of "foo" to get it done since the whole release rides on their shoulders. It also might encourage others to help out more since they can't get something new until "foo" is completed. This would also prioritize said developers time on the large project rather than other non-prioritized tasks, and it also helps to ensure a "killer feature" for those who want such things, Robert Treat -- #==# # 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
Re: [HACKERS] PostgreSQL Core Welcomes New Member
On Tue, 24 Jun 2003, Marc G. Fournier wrote: > > The PostgreSQL Core would like to publicly welcome welcome Josh Berkus as > our newest member. > > Josh is being included especially as a "liason" between the > source-programmer and non-source-programmer contributors to PostgreSQL, in > an effort to expand PostgreSQL volunteer documentation, advocacy, and > vendor relations efforts. > > In addition to being actively involved in the project for the last 4 > years, he previously helped create the Marketing Project of > OpenOffice.org, and launched the pgsql-performance list and PostgreSQL's > first local user group (SFPUG). Whut? Please drop www.us as a postgresql mirror. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] PostgreSQL Core Welcomes New Member
The PostgreSQL Core would like to publicly welcome welcome Josh Berkus as our newest member. Josh is being included especially as a "liason" between the source-programmer and non-source-programmer contributors to PostgreSQL, in an effort to expand PostgreSQL volunteer documentation, advocacy, and vendor relations efforts. In addition to being actively involved in the project for the last 4 years, he previously helped create the Marketing Project of OpenOffice.org, and launched the pgsql-performance list and PostgreSQL's first local user group (SFPUG). ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] RServ patch to support multiple slaves (sorta)
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] src/bin/scripts seems a bit of a misnomer now
Added to TODO: * Rename /scripts directory because they are all C programs now --- Tom Lane wrote: > Rod Taylor <[EMAIL PROTECTED]> writes: > > How about just pulling them up a directory into src/bin? > > Nah, I don't like that. All the programs are at the same level in the > src/bin tree, and I think it should stay that way. > > Bruce's idea of calling it "tools" seems reasonable ... although there > might be some confusion because we also have a src/tools directory. > "admintools" seems a bit long to me, although I'd go along if other > people like it. Maybe just "admin"? > > regards, tom lane > -- 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 7: don't forget to increase your free space map settings
Re: [HACKERS] pg_get_triggerdef in pg_dump
Add to TODO: o Allow ALTER TABLE to modify column lengths and change to binary compatible types --- Tom Lane wrote: > "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > >> There might be other cases of legal direct change of system catalog > >> entries, e,g. varchar to text, if they all are only names for internally > >> identical data structures. Can you tell which datatypes may be legally > >> interchanged? > > > Yes, you can check if they're binary compatible from the pg_cast table > > But nearly all of the interesting cases require you to understand the > type's interpretation of typmod, and you can't learn that from a table. > How many cases are there where blindly looking for a binary-compatible > cast in pg_cast will really do you much good? AFAICS you'd have to set > atttypmod to -1 if you change atttypid without knowing very specifically > what you are changing from and to. > > regards, tom lane > > ---(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 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
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. --- Andreas Pflug wrote: > Tom Lane wrote: > > > > >I recall objecting to someone who wanted to remove "unnecessary" > >parentheses, but I can't see any risk in inserting unnecessary > >whitespace. > > > That "someone" was me indeed, and as I mentioned the code is completely > separated from the code that pg_dump uses. Thus, there's *no way* that > this could break backup integrity. I consider these original functions > as pg_dump helper functions, not meant to be human readable. > > There are *many* parentheses that are not necessary, and the code trying > to figure out is quite conservative. All is decided in one single > routine, depending on two parameters only, and thus failing to locate > several cases when parentheses would be avoidable (not even */ over +- > will be noticed!). > > I've been trying hard to make pgsql as maintainable as mssql, and > there's only this point left. Any attempts to contribute this so far > just have been answered with "dunno but there might eventually perhaps > maybe some problem" without having a look at that function. I feel that > I am asked to prove the validity of my code, which is as impossible as > it is for software in general, but I haven't seen any case where my > solution failed to reproduce correctly. If you know one, tell me. If you > know a case where my core routine decides falsely, tell me. > > What I *really* want is having the original source stored, including > comments, version info, ... Currently, it's argued that underlying table > and column might change, braking the view/rule. This could be > restricted, or source could be dropped (alter table ... cascaded). Is it > really only me who tries to put complicated views into pgsql and wants > to understand them 10 days later? We do have an enterprise grade RDBMS, > don't we? > > Regards, > Andreas > > > ---(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 7: don't forget to increase your free space map settings
Re: [HACKERS] Two Phase Commit WAS: Re: Two weeks to feature freeze
Josh Berkus wrote: Anyway, I would vote for a first implemenation for 2PC which addressed the commit-then-crash issue in some expedient-but-not-reliable way, and putting 2PC in /contrib with a "not for production use" warning. Some people will use it in production anyway, and hopefully one or more of them will put in the dozens of hours required to make it reliable. Josh, you cannot put something that requires an FE/BE protocol change, ON COMMIT extra work plus ON RESTART extra work into contrib. The interim solution to Tom's concern is "ask the operator". His entire point is based on the fact that there is no way to let the systems figure out what's right in the case they lost communication and don't know why. And for a system that just misses IP packets, there is no way to figure out if it's just that someone tripped over the cable or if the other building got nuked. To figure out what happened was never the goal for the ARPA project. Their goal was to continue communication as long as there is a possible path. If that's gone, you're on your own ... sorry! I think 2PC is of no use for things like replication with takeover on failure in mind. At least it'd cause a major hickup in the system, and since failurs tend to oscillate, I don't want to be anywhere close when that collaborative throwup starts. But I do think that there is value in distributed transactions. Well ... I *know* that there is. 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 6: Have you searched our list archives? http://archives.postgresql.org
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??? Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] sa_family_t in cygwin compile of cvs + regression failure
OK, patch applied to typedef sa_family_t for cygwin. If other platforms
need it, I will have to do something more generic.
Thanks for the testing. Block removed, though I did have that ISP
marked as cronic, so there must have been a bunch of spam from there,
not just a few.
---
deststar wrote:
> I still seem to get a compile problem (included below).
> Will double check tomorrow when not so tired (02:15 here).
> Cheers,
> - Stuart
> P.S. My server seems to be blacklisted as a spam server by you. Please
> could you white list me.
>
> gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations
> -I../../../../src/i
> nclude -DBUILDING_DLL -c -o printtup.o printtup.c -MMD
> 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"
> ../../../../src/include/libpq/pqcomm.h:54: warning: no semicolon at end
> of struc
> t or union
> ../../../../src/include/libpq/pqcomm.h:56: `sa_family_t' undeclared here
> (not in
> a function)
> ../../../../src/include/libpq/pqcomm.h:63: `sa_family_t' undeclared here
> (not in
> a function)
> ../../../../src/include/libpq/pqcomm.h:63: `sa_family_t' undeclared here
> (not in
> a function)
> ../../../../src/include/libpq/pqcomm.h:67: parse error before '}' token
> ../../../../src/include/libpq/pqcomm.h:77: field `addr' has incomplete type
> ../../../../src/include/libpq/pqcomm.h:79: confused by earlier errors,
> bailing o
> ut
> make[4]: *** [printtup.o] Error 1
>
>
>
> ---(end of broadcast)---
> TIP 8: explain analyze is your friend
>
--
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
Index: src/include/libpq/pqcomm.h
===
RCS file: /cvsroot/pgsql-server/src/include/libpq/pqcomm.h,v
retrieving revision 1.87
diff -c -c -r1.87 pqcomm.h
*** src/include/libpq/pqcomm.h 23 Jun 2003 23:51:59 - 1.87
--- src/include/libpq/pqcomm.h 24 Jun 2003 01:48:40 -
***
*** 47,52
--- 47,56
#define _SS_PAD2SIZE(_SS_MAXSIZE - (sizeof (sa_family_t) + \
_SS_PAD1SIZE + _SS_ALIGNSIZE))
+ #ifdef __CYGWIN__
+ typedef unsigned short sa_family_t;
+ #endif
+
struct sockaddr_storage {
#ifdef SALEN
uint8_t __ss_len;/* address length */
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] sa_family_t in cygwin compile of cvs + regression failure
deststar wrote:
> I still seem to get a compile problem (included below).
> Will double check tomorrow when not so tired (02:15 here).
> Cheers,
> - Stuart
> P.S. My server seems to be blacklisted as a spam server by you. Please
> could you white list me.
>
> gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations
> -I../../../../src/i
> nclude -DBUILDING_DLL -c -o printtup.o printtup.c -MMD
> 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"
> ../../../../src/include/libpq/pqcomm.h:54: warning: no semicolon at end
> of struc
> t or union
> ../../../../src/include/libpq/pqcomm.h:56: `sa_family_t' undeclared here
> (not in
> a function)
> ../../../../src/include/libpq/pqcomm.h:63: `sa_family_t' undeclared here
> (not in
> a function)
> ../../../../src/include/libpq/pqcomm.h:63: `sa_family_t' undeclared here
> (not in
> a function)
> ../../../../src/include/libpq/pqcomm.h:67: parse error before '}' token
> ../../../../src/include/libpq/pqcomm.h:77: field `addr' has incomplete type
> ../../../../src/include/libpq/pqcomm.h:79: confused by earlier errors,
> bailing o
> ut
> make[4]: *** [printtup.o] Error 1
>
>
>
> ---(end of broadcast)---
> TIP 8: explain analyze is your friend
>
--
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
Index: src/include/libpq/pqcomm.h
===
RCS file: /cvsroot/pgsql-server/src/include/libpq/pqcomm.h,v
retrieving revision 1.87
diff -c -c -r1.87 pqcomm.h
*** src/include/libpq/pqcomm.h 23 Jun 2003 23:51:59 - 1.87
--- src/include/libpq/pqcomm.h 24 Jun 2003 01:48:40 -
***
*** 47,52
--- 47,56
#define _SS_PAD2SIZE(_SS_MAXSIZE - (sizeof (sa_family_t) + \
_SS_PAD1SIZE + _SS_ALIGNSIZE))
+ #ifdef __CYGWIN__
+ typedef unsigned short sa_family_t;
+ #endif
+
struct sockaddr_storage {
#ifdef SALEN
uint8_t __ss_len;/* address length */
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
On Mon, 23 Jun 2003, Dann Corbit wrote: > The resistance to testing is typical of programmers. The PostgreSQL > group is a group of programmers. I don't think I can change anyone's > mind, since the most significant people on the list don't think it is > worth the bother. > > Therefore, I am going to stop harping on it. *rofl* I believe several of us have suggested that we would welcome submissions for improved testing ... so, what, we feel that the test that is done is sufficient, but are willing to accept submissions to improve it, but you aren't willing to spend the time/effort to do so? We might be a bunch of 'typical programmers', but you definitely sound like a typical "I want you to do something to make life easier for me, but am not willing to expend the time or effort to do anyting 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, 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? 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 ... 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 ... ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: Auto Building / Testing (was: Re: [HACKERS] Two weeks to feat..)
Yes, it does some of that, but I don't think it is safe to do a cvs update in an automated fashion, as least on my machine. --- The Hermit Hacker wrote: > > On Mon, 23 Jun 2003, Peter Eisentraut wrote: > > > Bruce Momjian writes: > > > > > Well, it is a nice test template for people who aren't shell script > > > experts, and I have been in the habit of pushing stuff I use into /tools > > > so it is available for others. > > > > I know and I'm not happy about it. The PostgreSQL source tree isn't a > > repository of everyone's favorite shell scripts. There's an official > > method to build and test a PostgreSQL installation. If that is flawed or > > incomplete, then let's talk about it. But everyone pushing out their own > > little test methodology without further consideration is not going to help > > this discussion. > > 'K, its flawed and incomplete, let's talk about it :) > > What I was looking for here was something I could add to cron on a machine > that would update the source, do a base configure (or give me the ability > to give extra options, as the case may be), build, install and test, and > report errors to me via email where applicable ... > > The idea is that it could be something that ppl could have run nightly, in > the wee hours, and only when a problem occurs would they be informed so > taht they coudl either fix teh error (ie. out of space), or report it to > the list(s) ... > > > > > ---(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 7: don't forget to increase your free space map settings
Auto Building / Testing (was: Re: [HACKERS] Two weeks to feat..)
On Mon, 23 Jun 2003, Peter Eisentraut wrote: > Bruce Momjian writes: > > > Well, it is a nice test template for people who aren't shell script > > experts, and I have been in the habit of pushing stuff I use into /tools > > so it is available for others. > > I know and I'm not happy about it. The PostgreSQL source tree isn't a > repository of everyone's favorite shell scripts. There's an official > method to build and test a PostgreSQL installation. If that is flawed or > incomplete, then let's talk about it. But everyone pushing out their own > little test methodology without further consideration is not going to help > this discussion. 'K, its flawed and incomplete, let's talk about it :) What I was looking for here was something I could add to cron on a machine that would update the source, do a base configure (or give me the ability to give extra options, as the case may be), build, install and test, and report errors to me via email where applicable ... The idea is that it could be something that ppl could have run nightly, in the wee hours, and only when a problem occurs would they be informed so taht they coudl either fix teh error (ie. out of space), or report it to the list(s) ... ---(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] sa_family_t in cygwin compile of cvs + regression failure
I still seem to get a compile problem (included below). Will double check tomorrow when not so tired (02:15 here). Cheers, - Stuart P.S. My server seems to be blacklisted as a spam server by you. Please could you white list me. gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/i nclude -DBUILDING_DLL -c -o printtup.o printtup.c -MMD 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" ../../../../src/include/libpq/pqcomm.h:54: warning: no semicolon at end of struc t or union ../../../../src/include/libpq/pqcomm.h:56: `sa_family_t' undeclared here (not in a function) ../../../../src/include/libpq/pqcomm.h:63: `sa_family_t' undeclared here (not in a function) ../../../../src/include/libpq/pqcomm.h:63: `sa_family_t' undeclared here (not in a function) ../../../../src/include/libpq/pqcomm.h:67: parse error before '}' token ../../../../src/include/libpq/pqcomm.h:77: field `addr' has incomplete type ../../../../src/include/libpq/pqcomm.h:79: confused by earlier errors, bailing o ut make[4]: *** [printtup.o] Error 1 ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] TO_CHAR SO SLOW???
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?? P.S Postgres 7.3 ---(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] sa_family_t in cygwin compile of cvs + regression failure
You might still have a problem with compiling getaddrinfo.c. Please let me know and I can correct it. --- deststar wrote: > On cygwin sa_family_t was undeclared, adding the following line: > typedef unsigned short sa_family_t; > to both: > src/port/getaddrinfo.c > src/include/libpq/pqcomm.h > seemed to compile ok but with make check there was one regression > failure in test privileges (doesn't look realted, but I'm not sure). > Also included for ease of testing is a patch sepratly sent to patches > for ecpg. > System: Athalon + Win 2k + cygwin 1.3.22 + gcc 3.2 > *** ./expected/privileges.out Wed May 14 04:26:04 2003 > --- ./results/privileges.out Sun Jun 15 16:12:34 2003 > *** > *** 10,18 > --- 10,22 > CREATE GROUP regressgroup1; > CREATE GROUP regressgroup2 WITH USER regressuser1, regressuser2; > ALTER GROUP regressgroup1 ADD USER regressuser4; > + WARNING: AbortTransaction and not in in-progress state > + ERROR: rename > /home/Administrator/pgcvs/pgsql/src/test/regress/./tmp_check/data/global/pg_group.2284 > to > /home/Administrator/pgcvs/pgsql/src/test/regress/./tmp_check/data/global/pg_group: > Permission denied > ALTER GROUP regressgroup2 ADD USER regressuser2;-- duplicate > WARNING: ALTER GROUP: user "regressuser2" is already in group "regressgroup2" > ALTER GROUP regressgroup2 DROP USER regressuser2; > + WARNING: AbortTransaction and not in in-progress state > + ERROR: rename > /home/Administrator/pgcvs/pgsql/src/test/regress/./tmp_check/data/global/pg_group.2284 > to > /home/Administrator/pgcvs/pgsql/src/test/regress/./tmp_check/data/global/pg_group: > Permission denied > ALTER GROUP regressgroup2 ADD USER regressuser4; > -- test owner privileges > SET SESSION AUTHORIZATION regressuser1; > > == > > *** src/interfaces/ecpg/compatlib/Makefile.orig Thu May 22 18:20:44 2003 > --- src/interfaces/ecpg/compatlib/MakefileSun Jun 15 15:45:34 2003 > *** > *** 17,23 > SO_MINOR_VERSION= 0.0 > > override CPPFLAGS := -I$(top_srcdir)/src/interfaces/ecpg/include > -I$(top_srcdir)/src/include/utils $(CPPFLAGS) > ! SHLIB_LINK = -L../pgtypeslib -lpgtypes > > OBJS= informix.o > > --- 17,23 > SO_MINOR_VERSION= 0.0 > > override CPPFLAGS := -I$(top_srcdir)/src/interfaces/ecpg/include > -I$(top_srcdir)/src/include/utils $(CPPFLAGS) > ! SHLIB_LINK = -L../pgtypeslib -lpgtypes -L../ecpglib -lecpg > > OBJS= informix.o > > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] sa_family_t in cygwin compile of cvs
OK, I just applied a patch which should fix cygwin too. Please give it
a try. Thanks.
---
deststar wrote:
> Yes there's:
> struct sockaddr {
>unsigned short sa_family; /* address family, AF_xxx */
>char sa_data[14];/* 14 bytes of protocol address */
> };
> in socket.h
>
> struct sockaddr {
> u_short sa_family;
> charsa_data[14];
> };
> in winsock.h & winsock2.h
>
> typedef struct sockaddr_ipx {
> short sa_family;
> char sa_netnum[4];
> char sa_nodenum[6];
> unsigned short sa_socket;
> } SOCKADDR_IPX, *PSOCKADDR_IPX, *LPSOCKADDR_IPX;
> in wsipx.h
>
> and for ss_family:
> struct sockaddr_storage {
> short ss_family;
> char __ss_pad1[6];/* pad to 8 */
> __int64 __ss_align; /* force alignment */
> char __ss_pad2[112]; /* pad to 128 */
> };
> in winsock2.h
>
> To be honest I'm not at all sure about the correctness of my patch as I
> don't know what sa_family is for, I just did a search on google and
> unsigned short seemd to be the answer & it seemed to pass the regression
> test.
> regards,
> - Stuart
>
> Bruce Momjian wrote:
>
> > deststar, is there any sa_family or ss_family in the cygwin include
> > directory, perhap with double leading underscores?
> >
> > ---
> >
> > deststar wrote:
> >
> >>Jason Tishler wrote:
> >>
> >>>On Sun, Jun 15, 2003 at 04:54:21PM +0100, deststar wrote:
> >>>
> >>>
> On cygwin sa_family_t was undeclared, adding the following line:
> typedef unsigned short sa_family_t;
> to both:
> src/port/getaddrinfo.c
> src/include/libpq/pqcomm.h
> >>>
> >>>
> >>>Isn't the attached or fixing Cygwin itself a better approach?
> >>>
> >>>
> >>
> >>Yes it does seem better, attached is a proposed patch to cygwin.h &
> >>configure.in (incase cygwin gets it in future)
> >>Have tested with make installcheck & it works fine.
> >>If you see no problems I will sumit to patches
> >>thanks,
> >>- Stuart
> >
> >
> >>*** src/include/port/cygwin.h.orig Thu May 22 18:20:28 2003
> >>--- src/include/port/cygwin.h Tue Jun 17 22:31:04 2003
> >>***
> >>*** 21,23
> >>--- 21,28
> >> #else
> >> #define DLLIMPORT __declspec (dllimport)
> >> #endif
> >>+
> >>+ #ifndef HAVE_SA_FAMILY_T
> >>+ typedef unsigned short sa_family_t;
> >>+ #endif
> >>+
> >
> >
> >>*** configure.in.orig Sun Jun 15 05:07:58 2003
> >>--- configure.inTue Jun 17 22:22:24 2003
> >>***
> >>*** 855,860
> >>--- 855,866
> >> [$ac_includes_default
> >> #include ])
> >>
> >>+ AC_CHECK_TYPE(sa_family_t,
> >>+ [AC_DEFINE(HAVE_SA_FAMILY_T,1,[Cygwin does not have sa_family_t
> >>defined so test])],
> >>+ [],
> >>+ [$ac_includes_default
> >>+ #include ])
> >>+
> >> AC_CACHE_CHECK([for PS_STRINGS], [pgac_cv_var_PS_STRINGS],
> >> [AC_TRY_LINK(
> >> [#include
> >
>
>
>
> ---(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 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] ss_family in hba.c
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. --- Kurt Roeckx wrote: > On Tue, Jun 17, 2003 at 11:01:27PM -0500, Bruno Wolff III wrote: > > > > My system does have its own sockaddr_storage definition. I think > > it uses __ss_ as the prefix. Also, after looking at the fallback > > definition in pqcomm.h, I don't see where that defines ss_family > > and hence don't see how that could work. > > I am going to see if adding __ works as suggested by someone else > > who replied. > > See if this patch helps. > > Don't forget to run autoconf after applying the patch. > > > > Kurt > [ Attachment, skipping... ] > > ---(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 -- 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] sa_family_t in cygwin compile of cvs
Yes there's:
struct sockaddr {
unsigned shortsa_family; /* address family, AF_xxx */
char sa_data[14];/* 14 bytes of protocol address */
};
in socket.h
struct sockaddr {
u_short sa_family;
charsa_data[14];
};
in winsock.h & winsock2.h
typedef struct sockaddr_ipx {
short sa_family;
char sa_netnum[4];
char sa_nodenum[6];
unsigned short sa_socket;
} SOCKADDR_IPX, *PSOCKADDR_IPX, *LPSOCKADDR_IPX;
in wsipx.h
and for ss_family:
struct sockaddr_storage {
short ss_family;
char __ss_pad1[6];/* pad to 8 */
__int64 __ss_align; /* force alignment */
char __ss_pad2[112]; /* pad to 128 */
};
in winsock2.h
To be honest I'm not at all sure about the correctness of my patch as I
don't know what sa_family is for, I just did a search on google and
unsigned short seemd to be the answer & it seemed to pass the regression
test.
regards,
- Stuart
Bruce Momjian wrote:
deststar, is there any sa_family or ss_family in the cygwin include
directory, perhap with double leading underscores?
---
deststar wrote:
Jason Tishler wrote:
On Sun, Jun 15, 2003 at 04:54:21PM +0100, deststar wrote:
On cygwin sa_family_t was undeclared, adding the following line:
typedef unsigned short sa_family_t;
to both:
src/port/getaddrinfo.c
src/include/libpq/pqcomm.h
Isn't the attached or fixing Cygwin itself a better approach?
Yes it does seem better, attached is a proposed patch to cygwin.h &
configure.in (incase cygwin gets it in future)
Have tested with make installcheck & it works fine.
If you see no problems I will sumit to patches
thanks,
- Stuart
*** src/include/port/cygwin.h.orig Thu May 22 18:20:28 2003
--- src/include/port/cygwin.h Tue Jun 17 22:31:04 2003
***
*** 21,23
--- 21,28
#else
#define DLLIMPORT __declspec (dllimport)
#endif
+
+ #ifndef HAVE_SA_FAMILY_T
+ typedef unsigned short sa_family_t;
+ #endif
+
*** configure.in.orig Sun Jun 15 05:07:58 2003
--- configure.in Tue Jun 17 22:22:24 2003
***
*** 855,860
--- 855,866
[$ac_includes_default
#include ])
+ AC_CHECK_TYPE(sa_family_t,
+ [AC_DEFINE(HAVE_SA_FAMILY_T,1,[Cygwin does not have sa_family_t defined so test])],
+ [],
+ [$ac_includes_default
+ #include ])
+
AC_CACHE_CHECK([for PS_STRINGS], [pgac_cv_var_PS_STRINGS],
[AC_TRY_LINK(
[#include
---(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
deststar, is there any sa_family or ss_family in the cygwin include directory, perhap with double leading underscores? --- deststar wrote: > Jason Tishler wrote: > > On Sun, Jun 15, 2003 at 04:54:21PM +0100, deststar wrote: > > > >>On cygwin sa_family_t was undeclared, adding the following line: > >>typedef unsigned short sa_family_t; > >>to both: > >>src/port/getaddrinfo.c > >>src/include/libpq/pqcomm.h > > > > > > Isn't the attached or fixing Cygwin itself a better approach? > > > > > Yes it does seem better, attached is a proposed patch to cygwin.h & > configure.in (incase cygwin gets it in future) > Have tested with make installcheck & it works fine. > If you see no problems I will sumit to patches > thanks, > - Stuart > *** src/include/port/cygwin.h.origThu May 22 18:20:28 2003 > --- src/include/port/cygwin.h Tue Jun 17 22:31:04 2003 > *** > *** 21,23 > --- 21,28 > #else > #define DLLIMPORT __declspec (dllimport) > #endif > + > + #ifndef HAVE_SA_FAMILY_T > + typedef unsigned short sa_family_t; > + #endif > + > *** configure.in.orig Sun Jun 15 05:07:58 2003 > --- configure.in Tue Jun 17 22:22:24 2003 > *** > *** 855,860 > --- 855,866 > [$ac_includes_default > #include ]) > > + AC_CHECK_TYPE(sa_family_t, > + [AC_DEFINE(HAVE_SA_FAMILY_T,1,[Cygwin does not have sa_family_t > defined so test])], > + [], > + [$ac_includes_default > + #include ]) > + > AC_CACHE_CHECK([for PS_STRINGS], [pgac_cv_var_PS_STRINGS], > [AC_TRY_LINK( > [#include > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ftp mirror
Sorry about that, I had long ago fixed the build, but failed to add it to cron ... new build created and cron entry added ... :( On Mon, 23 Jun 2003, Tom Lane wrote: > [EMAIL PROTECTED] writes: > > Is it me or is there a problem with ftp mirrors? > > The latest shapshots I have here are from June 2; seems rather old.. > > It's not the mirrors' fault --- the nightly snapshots aren't getting > updated on the master site either. I think this is still on Marc's > "to fix" list. With beta getting closer, I hope he fixes it soon... > > 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]) > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Two Phase Commit WAS: Re: Two weeks to feature freeze
> I don't think it could have been said any better. There are a host of > improvements on the standard 2PC protocol, including 3PC, multi-cast > 2PC, and other variants both synchronous and asynchronous. But if > PostgreSQL is going to work with XA, then it doesn't get to choose the > TM or the protocol. The only relevance of this thread, as I see it, is I'm no expert in this area, but XA seems to be the choice for Java based Transaction Servers, so at very least the JDBC guys will want to have the ability to fake XA. > whether or not core will stomach an XA-compatible 2PC implementation > in the backend. If not, then is Satoshi Nagayasu in vain? That was No, it's not in vain to add 2PC (XA-compatible was his interest at the time) into the backend. What is debatable is whether the PostgreSQL folks will implement a replication system based on it. > what I "sensed" in the original thread 6 months ago, that the 2PC work > being done by Satoshi Nagayasu was going to be allowed to die on the vine. It is difficult work, but is no less useful than nested transactions will be. A certain segment of the user-base will be jumping up and down when they get them, myself included. -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Two Phase Commit WAS: Re: Two weeks to feature freeze
I second the agreement ... a 'reference implementation', of sorts, at least gives someone to build on then starting right from scratch ... On Mon, 23 Jun 2003, Bruce Momjian wrote: > > Agreed. > > --- > > Josh Berkus wrote: > > Tom, > > > > > No. I want to know what the subordinate does when it's promised to > > > commit and the co-ordinator never responds. AFAICS the subordinate > > > is screwed --- it can't commit, and it can't abort, and it can't expect > > > to make progress indefinitely on other work while it's holding locks > > > for the not-quite-committed transaction. > > > > AFAIK, MS SQL Server's two-phase commit works like this ... if both servers > > prepare, and one crashes, the transaction is screwed up. Somewhat unreliable > > considering the frequence with which MSSQL crashes, yet it seems to be good > > enough for several companies to sell "solutions" based on it. (performance is > > also appalling, but that's a different issue) > > > > Anybody have a grasp of Oracle internals for 2PC? > > > > Anyway, I would vote for a first implemenation for 2PC which addressed the > > commit-then-crash issue in some expedient-but-not-reliable way, and putting > > 2PC in /contrib with a "not for production use" warning. Some people will > > use it in production anyway, and hopefully one or more of them will put in > > the dozens of hours required to make it reliable. > > > > -- > > Josh Berkus > > Aglio Database Solutions > > San Francisco > > > > ---(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 5: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faqs/FAQ.html > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Two Phase Commit WAS: Re: Two weeks to feature freeze
Rod Taylor wrote: -- Start of PGP signed section. > > Perhaps the people on this list who are pushing 2PC could do the ground work? > > > - 2PC is better than a standard transaction when dealing with multiple > servers as it can recover in some circumstances (but not all). > > - 2PC (XA support as described by the X/Open group) is the only > implementation of distributed transactions supported by many third party > components -- that I'm aware of -- to the point where it is a part of > the Java Spec on dealing with distributed transactions. > > - 2PC isn't very good in a number of circumstances, as such PostgreSQL > should avoid its use when PostgreSQL has a choice in the matter -- like > communication with other PostgreSQL servers. > > This is a case of learning to speak Japanese because all of the people > you want to talk with only speak Japanese. It simply doesn't matter how > good Esperanto is. Agreed --- other db's have it, and people ask for it, so we should just do our best and document the limitations. -- 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
[HACKERS] Bug in japanese charset mappings?
I've run into what seems like an old bug in the character set mapping for japanese encoding while trying to extract data from my database using the Java JDBC driver. The problem has to do with the japanese full-width wave dash. This problem was brought up by Tom O'Dowd way back in February but doesn't seem to have been fixed yet. His original post can be seen at: http://archives.postgresql.org/pgsql-hackers/2003-02/msg00328.php Can someone tell me what the status of this 'bug' is? Is it really a bug in postgres. If it is a bug it doesn't seem to have been fixed since I am experiencing the same problem using 7.3.3. Is there an easy work around? Thanks, Jean-Christian Imbeault ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two Phase Commit WAS: Re: Two weeks to feature freeze
Rod Taylor wrote: >>Perhaps the people on this list who are pushing 2PC could do the ground work? > > - 2PC is better than a standard transaction when dealing with multiple > servers as it can recover in some circumstances (but not all). > > - 2PC (XA support as described by the X/Open group) is the only > implementation of distributed transactions supported by many third party > components -- that I'm aware of -- to the point where it is a part of > the Java Spec on dealing with distributed transactions. > > - 2PC isn't very good in a number of circumstances, as such PostgreSQL > should avoid its use when PostgreSQL has a choice in the matter -- like > communication with other PostgreSQL servers. > > This is a case of learning to speak Japanese because all of the people > you want to talk with only speak Japanese. It simply doesn't matter how > good Esperanto is. I don't think it could have been said any better. There are a host of improvements on the standard 2PC protocol, including 3PC, multi-cast 2PC, and other variants both synchronous and asynchronous. But if PostgreSQL is going to work with XA, then it doesn't get to choose the TM or the protocol. The only relevance of this thread, as I see it, is whether or not core will stomach an XA-compatible 2PC implementation in the backend. If not, then is Satoshi Nagayasu in vain? That was what I "sensed" in the original thread 6 months ago, that the 2PC work being done by Satoshi Nagayasu was going to be allowed to die on the vine. Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [GENERAL] PlPython
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> The behavior that I think would be most useful would be to automatically > >> transpose CREATE FUNCTION ... LANGUAGE "plpython" into CREATE FUNCTION > >> ... LANGUAGE "plpythonu". Which we could do with an ugly hack in CREATE > >> FUNCTION (ugly, but no worse than things we've done to index opclass > >> names, for example). But it could be too confusing. > > > You mean in gram.y? Yes, I think that is our only choice. > > Actually I think it should be in functioncmds.c. I moved the special > kluges for opclass names out of gram.y and into indexcmds.c awhile ago. > But that's just an implementation detail --- we really need to still be > thinking about whether this is the behavior we want or not. Someone > else made a fair point that such a kluge might not actually make life > any easier for reloading dump files. If we do it that way, then if a > non-superuser tries to CREATE FUNCTION ... LANGUAGE "plpython" it will > fail (not being trusted) and so he's got no hope of loading the dump > without editing anyway. If that's true, there's not much point in > introducing a hidden kluge. Well, it does fix the super-user case, so we have to tell non-super users to get their administrator to install it, which actually is the right solution anyway for non-super-user installs of plpython language modules anyway. -- 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] Two Phase Commit WAS: Re: Two weeks to feature freeze
> Perhaps the people on this list who are pushing 2PC could do the ground work? - 2PC is better than a standard transaction when dealing with multiple servers as it can recover in some circumstances (but not all). - 2PC (XA support as described by the X/Open group) is the only implementation of distributed transactions supported by many third party components -- that I'm aware of -- to the point where it is a part of the Java Spec on dealing with distributed transactions. - 2PC isn't very good in a number of circumstances, as such PostgreSQL should avoid its use when PostgreSQL has a choice in the matter -- like communication with other PostgreSQL servers. This is a case of learning to speak Japanese because all of the people you want to talk with only speak Japanese. It simply doesn't matter how good Esperanto is. -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Two weeks to feature freeze
On Monday 23 June 2003 15:42, Dann Corbit wrote: > Let me rephrase it: > "Only a cohesive, organized testing effort can result in a product that > is proven reliable." One can never 100% prove reliability without time in the field with real-world data, testing or no testing. I would dare say that there are numerous reliable software packages out there in OSS-land that have never had that sort of testing. But it really hinges on ones definition of proof, no? Furthermore, the beta testers here in hackers are not 'end-users' per se. The people in hackers who test the betas are very valuable as our QA team. PostgreSQL is already proven reliable, to various degrees of reliability, enough to where a PostgreSQL backend was approved as the new .ORG registry. The track record continues, without mathematically rigorous and cohesive testing. Such testing would be useful, of course, by it is not required for our purposes. Those who want rigorous testing can do the rigorous testing. You yourself said that your company has a separate QA team from the development team; OK, organize a rigorous QA team. While you won't stop releases (unless you find showstopper bugs, like those that have been found by our wonderful hackers testers), your input into actually testing PostgreSQL (as opposed to trying to convince someone else to test for you) would be valuable. But you're not going to get me to do it; I do enough testing of a varied nature already. I do this for fun. If you find testing fun, more power to you. :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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 Phase Commit WAS: Re: Two weeks to feature freeze
Tom, "Putting in "dozens of hours" is not the issue here --- the problem is that there isn't any solution in sight, and I'm not eager to go down a path that has an obvious dead end." Well, I doubt we're breaking any new ground with this discussion. If I really cared about this feature, I would get in touch with CJ Date and see what he has to say about it; but I don't care that much, except from a "Postgres marketability" perspective. Perhaps the people on this list who are pushing 2PC could do the ground work? I'd suggest starting with the collected works of CJ Date and Hugh Darwin, and contacting them if it's not already in a book. -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [GENERAL] PlPython
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> The behavior that I think would be most useful would be to automatically >> transpose CREATE FUNCTION ... LANGUAGE "plpython" into CREATE FUNCTION >> ... LANGUAGE "plpythonu". Which we could do with an ugly hack in CREATE >> FUNCTION (ugly, but no worse than things we've done to index opclass >> names, for example). But it could be too confusing. > You mean in gram.y? Yes, I think that is our only choice. Actually I think it should be in functioncmds.c. I moved the special kluges for opclass names out of gram.y and into indexcmds.c awhile ago. But that's just an implementation detail --- we really need to still be thinking about whether this is the behavior we want or not. Someone else made a fair point that such a kluge might not actually make life any easier for reloading dump files. If we do it that way, then if a non-superuser tries to CREATE FUNCTION ... LANGUAGE "plpython" it will fail (not being trusted) and so he's got no hope of loading the dump without editing anyway. If that's true, there's not much point in introducing a hidden kluge. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PlPython
Tom Lane wrote: > elein <[EMAIL PROTECTED]> writes: > > For 7.4 (which I expect is the patch's target) it might be > > best to make both names point to the same thing with a > > clear release note that says that they are the same thing > > and that plpython[u] is now untrusted. > > I don't know any way to actually do that, though. If we put two entries > in pg_language then functions created in plpython will stay associated > with that entry. That'd probably be the worst of all possible worlds, > since a person looking at pg_language would quite reasonably assume that > plpython was still trusted and the untrusted plpythonu was just an > addition. (Especially if he happened to know that such an addition was > planned long ago.) You could shoot yourself in the foot pretty badly > with such a misunderstanding :-( > > The behavior that I think would be most useful would be to automatically > transpose CREATE FUNCTION ... LANGUAGE "plpython" into CREATE FUNCTION > ... LANGUAGE "plpythonu". Which we could do with an ugly hack in CREATE > FUNCTION (ugly, but no worse than things we've done to index opclass > names, for example). But it could be too confusing. You mean in gram.y? Yes, I think that is our only choice. -- 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] [GENERAL] PlPython
elein <[EMAIL PROTECTED]> writes: > For 7.4 (which I expect is the patch's target) it might be > best to make both names point to the same thing with a > clear release note that says that they are the same thing > and that plpython[u] is now untrusted. I don't know any way to actually do that, though. If we put two entries in pg_language then functions created in plpython will stay associated with that entry. That'd probably be the worst of all possible worlds, since a person looking at pg_language would quite reasonably assume that plpython was still trusted and the untrusted plpythonu was just an addition. (Especially if he happened to know that such an addition was planned long ago.) You could shoot yourself in the foot pretty badly with such a misunderstanding :-( The behavior that I think would be most useful would be to automatically transpose CREATE FUNCTION ... LANGUAGE "plpython" into CREATE FUNCTION ... LANGUAGE "plpythonu". Which we could do with an ugly hack in CREATE FUNCTION (ugly, but no worse than things we've done to index opclass names, for example). But it could be too confusing. 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] Two weeks to feature freeze
> -Original Message- > From: Nigel J. Andrews [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2003 1: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] > So you've never worked on a project where the data is of high > value, since in those circumstances the customer is always > going to apply their own acceptance testing anyway. If you > think that doesn't happen you try sitting through 2 solid > days of Y2k testing on _one_ system and tell me customers > never do their own testing. Here's an old copy of my resume. You be the judge: ftp://cap.connx.com/C.A.P.%20Biographies/DannCorbit.htm#_Toc441048186 The burden of reliablity testing must not rest solely on the end user. That constitutes negligence on the part of the software vendor (IMO-YMMV). > > Therefore, I am going to stop harping on it. > > But there is no need to, as has been mentioned before, if the > testing is not upto your level of testing submit something > that makes it so. Having said that I do believe you mentioned > that you didn't have the time to create something but you > would be happy to test it, i.e. test the test. I may or may not have time to work on a software test system for PostgreSQL. I do a lot of PostgreSQL work here, and at some point I think I will have valuable contributions to the project. ---(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: > > -Original Message- > > From: scott.marlowe [mailto:[EMAIL PROTECTED] > > Sent: Monday, June 23, 2003 12:25 PM > > To: Dann Corbit > > Cc: Bruce Momjian; Tom Lane; Jason Earl; PostgreSQL-development > > Subject: Re: [HACKERS] Two weeks to feature freeze > > > > > > On Mon, 23 Jun 2003, Dann Corbit wrote: > > > > > Vendor A: "We think our tool is pretty solid and our end > > users hardly > > > ever turn up any bugs." > > > > > > Vendor B:" We think our tool is pretty solid and our 8500 tests > > > currently show only 3 defects with the released version, > > and these are > > > low impact issues. To view our current database of issues, > > log onto > > > web form ." > > > > > > Which tool would you prefer to install? > > > > The one I've tested and found to meet my needs, both now and > > by providing > > fixes when I needed it. How about the one that doesn't run tests in order to show how much better it is than the competition but to actually test operation? In other words Vendor B has an interest in having the tests pass, what gives you the confidence it just hasn't listed the ones that fail and that the tests that do pass are not just testing something vendor B wants to show it can do? > > Real world example: We run Crystal Reports Enterprise > > edition where I > > work. It's tested thouroughly (supposedly) and has all kinds of QA. > > However, getting it to work right and stay up is a nightmare. > > It's taken > > them almost a year to get around to testing against the OpenLDAP LDAP > > server we use. The box said "LDAP V3 compliant" and they > > assured us that > > it was. Well, it doesn't work with our LDAP V3 compliant > > LDAP server at > > all, and the problem is something they can't fix for months > > because it > > doesn't fit into their test cycle. > > > > > > Real world example: Postgresql aggregates in subselects. > > Someone found a bug in subselects in Postgresql with inner > > references to > > outter aggregates. The postgresql team delivered a patch in > > less than a > > week. User tested it and it works. > > > > I'm not against testing and all, but as one of the many beta > > testers for > > Postgresql, I do feel a bit insulted by your attitude that only a > > cohesive, organized testing effort can result in a reliable product. > > Let me rephrase it: > "Only a cohesive, organized testing effort can result in a product that > is proven reliable." > > Without such an effort, it is only an educated guess as to whether the > product is reliable or not. The data is the most valuable software > component in an organization. It is worth more than the hardware and it > is worth more than the software. If you are going to trust one billion > dollars worth of corporate data on a software system, you ought to > ensure that the system has been carefully tested. I don't think that is > just an opinion. It's simply common sense. So you've never worked on a project where the data is of high value, since in those circumstances the customer is always going to apply their own acceptance testing anyway. If you think that doesn't happen you try sitting through 2 solid days of Y2k testing on _one_ system and tell me customers never do their own testing. > Therefore, I am going to stop harping on it. But there is no need to, as has been mentioned before, if the testing is not upto your level of testing submit something that makes it so. Having said that I do believe you mentioned that you didn't have the time to create something but you would be happy to test it, i.e. test the test. -- Nigel J. Andrews ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Two weeks to feature freeze
On Mon, 23 Jun 2003, Dann Corbit wrote: > > -Original Message- > > From: scott.marlowe [mailto:[EMAIL PROTECTED] > > Sent: Monday, June 23, 2003 12:25 PM > > To: Dann Corbit > > Cc: Bruce Momjian; Tom Lane; Jason Earl; PostgreSQL-development > > Subject: Re: [HACKERS] Two weeks to feature freeze > > > > > > On Mon, 23 Jun 2003, Dann Corbit wrote: > > > > > Vendor A: "We think our tool is pretty solid and our end > > users hardly > > > ever turn up any bugs." > > > > > > Vendor B:" We think our tool is pretty solid and our 8500 tests > > > currently show only 3 defects with the released version, > > and these are > > > low impact issues. To view our current database of issues, > > log onto > > > web form ." > > > > > > Which tool would you prefer to install? > > > > The one I've tested and found to meet my needs, both now and > > by providing > > fixes when I needed it. > > > > Real world example: We run Crystal Reports Enterprise > > edition where I > > work. It's tested thouroughly (supposedly) and has all kinds of QA. > > However, getting it to work right and stay up is a nightmare. > > It's taken > > them almost a year to get around to testing against the OpenLDAP LDAP > > server we use. The box said "LDAP V3 compliant" and they > > assured us that > > it was. Well, it doesn't work with our LDAP V3 compliant > > LDAP server at > > all, and the problem is something they can't fix for months > > because it > > doesn't fit into their test cycle. > > > > > > Real world example: Postgresql aggregates in subselects. > > Someone found a bug in subselects in Postgresql with inner > > references to > > outter aggregates. The postgresql team delivered a patch in > > less than a > > week. User tested it and it works. > > > > I'm not against testing and all, but as one of the many beta > > testers for > > Postgresql, I do feel a bit insulted by your attitude that only a > > cohesive, organized testing effort can result in a reliable product. > > Let me rephrase it: > "Only a cohesive, organized testing effort can result in a product that > is proven reliable." No, it isn't proven reliable PERIOD, it's proven reliable under the exact conditions of the testing procedure you've implemented. And no matter how idiot proof we try to make Postgresql and its testing, someone else will always make a better idiot. :-) Actually, what I'm saying is that the corner cases are the ones that are hard to predict, and no amount of effort up front is going to find a corner case you haven't thought of yet. > Without such an effort, it is only an educated guess as to whether the > product is reliable or not. The data is the most valuable software > component in an organization. It is worth more than the hardware and it > is worth more than the software. If you are going to trust one billion > dollars worth of corporate data on a software system, you ought to > ensure that the system has been carefully tested. I don't think that is > just an opinion. It's simply common sense. But if that is true, then Postgresql should cause me no end of problems as it crashes down around my feet every other week. Oddly, the dbas for the other systems here at work (Oracle and MSSQL server) have a much higher workload keeping their factory tested databases up and running. In over four years of use, we have had exactly ZERO downtime of postgresql. Carefully testing the system is what I, the DBA of our postgresql servers, do. Only I know how we use the system, so no matter how you or Bruce or Tom might test it, I'll always be able to do something you wouldn't think of, because you're simply not in my shoes. It's not an educated guess that postgresql works for us, it's proven over and over again every single day by the throrough testing and use of every Postgresql user. > > I take my support of Postgresql seriously, and answer many > > questions every > > week in the general, sql, and performance mailing lists. I'm > > not paid to > > do it, I stay at work an extra hour or so each day to "pay > > for it." I > > test every beta and RC release on our dataset at work, and > > with a test > > load to make sure it works for us, and it does. > > > > I offered to beta test for Crystal Reports and was told they weren't > > interested, they can do it in house. Their support, like many big > > commercial houses, is designed more to make my boss's boss > > happy, not me, > > and it shows every day in how they fail to provide timely support for > > their product while playing CYA to the higherups. > > A long test cycle does result in a slower patch. But when you get the > patch, it is going to work and not introduce new problems. Nice theory, but it isn't provable by my experience. While I've put .0 releases of postgresql into production many a times, usually with no issues at all, I never have and never will put a .0 release of Crystal Reports online. Th
Re: [HACKERS] Two weeks to feature freeze
Dann Corbit wrote: > Let me rephrase it: > "Only a cohesive, organized testing effort can result in a product that > is proven reliable." > > Without such an effort, it is only an educated guess as to whether the > product is reliable or not. The data is the most valuable software > component in an organization. It is worth more than the hardware and it > is worth more than the software. If you are going to trust one billion > dollars worth of corporate data on a software system, you ought to > ensure that the system has been carefully tested. I don't think that is > just an opinion. It's simply common sense. True, it is an "educated guess", but it turns out our educated guess method produces more reliable code than the exhaustive testing method, so though there isn't as much of a _feeling_ of confidence, there is a _result_ of more reliability. -- 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
scott.marlowe wrote: > Peter is coming off awfully paternalistic here. I'd rather have a few > extra scripts to look through to find what I need when I'm trying to > figure out something than to have a tool that only the hackers know exists > and I can only get by asking nicely to see the pretty code. > > While no one wants to see a contrib or tool directory of a hundred megs, > lots of little example files and testing scripts can be nice for nothing > else other than the examples they provide. I learned a lot when I first > started using pgsql from the things in the contrib directory. Having something that just runs and I don't have to fiddle with it is a big help --- of course, it took me a few years to realize that this is the best way to test patches --- kind of embarassing that I didn't think of it in 1997. I think the patch came out of complaints that my patch application was letting in broken code --- since I have been using it, I am mostly down to weird bugs or platform problem, but the obvious patch problems are pretty much gone, which some people might have noticed. -- 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] Two weeks to feature freeze
> -Original Message- > From: scott.marlowe [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2003 12:25 PM > To: Dann Corbit > Cc: Bruce Momjian; Tom Lane; Jason Earl; PostgreSQL-development > Subject: Re: [HACKERS] Two weeks to feature freeze > > > On Mon, 23 Jun 2003, Dann Corbit wrote: > > > Vendor A: "We think our tool is pretty solid and our end > users hardly > > ever turn up any bugs." > > > > Vendor B:" We think our tool is pretty solid and our 8500 tests > > currently show only 3 defects with the released version, > and these are > > low impact issues. To view our current database of issues, > log onto > > web form ." > > > > Which tool would you prefer to install? > > The one I've tested and found to meet my needs, both now and > by providing > fixes when I needed it. > > Real world example: We run Crystal Reports Enterprise > edition where I > work. It's tested thouroughly (supposedly) and has all kinds of QA. > However, getting it to work right and stay up is a nightmare. > It's taken > them almost a year to get around to testing against the OpenLDAP LDAP > server we use. The box said "LDAP V3 compliant" and they > assured us that > it was. Well, it doesn't work with our LDAP V3 compliant > LDAP server at > all, and the problem is something they can't fix for months > because it > doesn't fit into their test cycle. > > > Real world example: Postgresql aggregates in subselects. > Someone found a bug in subselects in Postgresql with inner > references to > outter aggregates. The postgresql team delivered a patch in > less than a > week. User tested it and it works. > > I'm not against testing and all, but as one of the many beta > testers for > Postgresql, I do feel a bit insulted by your attitude that only a > cohesive, organized testing effort can result in a reliable product. Let me rephrase it: "Only a cohesive, organized testing effort can result in a product that is proven reliable." Without such an effort, it is only an educated guess as to whether the product is reliable or not. The data is the most valuable software component in an organization. It is worth more than the hardware and it is worth more than the software. If you are going to trust one billion dollars worth of corporate data on a software system, you ought to ensure that the system has been carefully tested. I don't think that is just an opinion. It's simply common sense. > I take my support of Postgresql seriously, and answer many > questions every > week in the general, sql, and performance mailing lists. I'm > not paid to > do it, I stay at work an extra hour or so each day to "pay > for it." I > test every beta and RC release on our dataset at work, and > with a test > load to make sure it works for us, and it does. > > I offered to beta test for Crystal Reports and was told they weren't > interested, they can do it in house. Their support, like many big > commercial houses, is designed more to make my boss's boss > happy, not me, > and it shows every day in how they fail to provide timely support for > their product while playing CYA to the higherups. A long test cycle does result in a slower patch. But when you get the patch, it is going to work and not introduce new problems. The resistance to testing is typical of programmers. The PostgreSQL group is a group of programmers. I don't think I can change anyone's mind, since the most significant people on the list don't think it is worth the bother. Therefore, I am going to stop harping on it. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
Peter Eisentraut wrote: > Bruce Momjian writes: > > > I put stuff in /tools so if something happens to me, you guys can keep > > going. > > Yes, we keep going with make clean; make check, like everyone else. Why > don't you consider using that? Actually, I used to manually do all those tests to test patches, but I found a single script was less error prone, and allowed me to more reliably test patches --- in the old days, I would forget the initdb or regression runs, only to find out later the patch broke something. There is a value to that script for me, and if someone else does patch application, I suggest they use it too. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two weeks to feature freeze
Peter Eisentraut wrote: > Bruce Momjian writes: > > > I put stuff in /tools so if something happens to me, you guys can keep > > going. > > Yes, we keep going with make clean; make check, like everyone else. Why > don't you consider using that? The script is automated to run at night, it captures gmake output while returning the proper error return code, and exits if it finds any problems. There was talk others want to automate nightly builds, so this a start for them. Amazing you find 688 bytes worth discussing. I know you said "what happens if everyone adds their scripts", but something that would be a mess if everyone did it isn't always a proper way to judge if something is appropriate. If someone wants to submit a better test build script, I will merge it into the existing one or replace mine. -- 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] Two weeks to feature freeze
On Mon, 23 Jun 2003, Bruce Momjian wrote: > Peter Eisentraut wrote: > > Bruce Momjian writes: > > > > > Well, it is a nice test template for people who aren't shell script > > > experts, and I have been in the habit of pushing stuff I use into /tools > > > so it is available for others. > > > > I know and I'm not happy about it. The PostgreSQL source tree isn't a > > repository of everyone's favorite shell scripts. There's an official > > method to build and test a PostgreSQL installation. If that is flawed or > > incomplete, then let's talk about it. But everyone pushing out their own > > little test methodology without further consideration is not going to help > > this discussion. > > I put stuff in /tools so if something happens to me, you guys can keep > going. Do I have to be clearer that that? I have RELEASE_CHANGES, > which Tom used for 7.3.X releases, pgindent, stuff for finding > missing/extraneous includes, static requirements, stuff like that. > > Unless you can find someone else who agrees with you, it stays. Peter is coming off awfully paternalistic here. I'd rather have a few extra scripts to look through to find what I need when I'm trying to figure out something than to have a tool that only the hackers know exists and I can only get by asking nicely to see the pretty code. While no one wants to see a contrib or tool directory of a hundred megs, lots of little example files and testing scripts can be nice for nothing else other than the examples they provide. I learned a lot when I first started using pgsql from the things in the contrib directory. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Two weeks to feature freeze
On Mon, 23 Jun 2003, Dann Corbit wrote: > Vendor A: "We think our tool is pretty solid and our end users hardly > ever turn up any bugs." > > Vendor B:" We think our tool is pretty solid and our 8500 tests > currently show only 3 defects with the released version, and these are > low impact issues. To view our current database of issues, log onto web > form ." > > Which tool would you prefer to install? The one I've tested and found to meet my needs, both now and by providing fixes when I needed it. Real world example: We run Crystal Reports Enterprise edition where I work. It's tested thouroughly (supposedly) and has all kinds of QA. However, getting it to work right and stay up is a nightmare. It's taken them almost a year to get around to testing against the OpenLDAP LDAP server we use. The box said "LDAP V3 compliant" and they assured us that it was. Well, it doesn't work with our LDAP V3 compliant LDAP server at all, and the problem is something they can't fix for months because it doesn't fit into their test cycle. Real world example: Postgresql aggregates in subselects. Someone found a bug in subselects in Postgresql with inner references to outter aggregates. The postgresql team delivered a patch in less than a week. User tested it and it works. I'm not against testing and all, but as one of the many beta testers for Postgresql, I do feel a bit insulted by your attitude that only a cohesive, organized testing effort can result in a reliable product. I take my support of Postgresql seriously, and answer many questions every week in the general, sql, and performance mailing lists. I'm not paid to do it, I stay at work an extra hour or so each day to "pay for it." I test every beta and RC release on our dataset at work, and with a test load to make sure it works for us, and it does. I offered to beta test for Crystal Reports and was told they weren't interested, they can do it in house. Their support, like many big commercial houses, is designed more to make my boss's boss happy, not me, and it shows every day in how they fail to provide timely support for their product while playing CYA to the higherups. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two weeks to feature freeze
Bruce Momjian writes: > I put stuff in /tools so if something happens to me, you guys can keep > going. Yes, we keep going with make clean; make check, like everyone else. Why don't you consider using that? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
Dann Corbit wrote: > PostgreSQL is a fairly mature product, having been in existence in one > form or another for many years now. > > I expect that most of the bugs that surface will be in areas of new > functionality. > > Great Bridge had the right idea though. Let's suppose that they ran > 10,000 tests and turned up only one bug. That would be just as valuable > (if not more so) than turning up 100 bugs. A large, carefully designed > test system is *proof* of software quality, or at least of the effort to > determine the quality level. It is also proof of the responsibility of > the software's originators. Look at the cost/benefit ratio to that. If you think we don't have to care about cost/benefit, well, it would be pretty amazing if we didn't. > Scenario: > You are going to install a tool that your organization will invest its > future in. > > Vendor A: "We think our tool is pretty solid and our end users hardly > ever turn up any bugs." > > Vendor B:" We think our tool is pretty solid and our 8500 tests > currently show only 3 defects with the released version, and these are > low impact issues. To view our current database of issues, log onto web > form ." > > Which tool would you prefer to install? I don't think commerical vendors, with those 8500 test, are are doing any better in reliability than PostgreSQL, and in fact, I think they are doing worse, and have to expend much more effort than we do. -- 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
Peter Eisentraut wrote: > Bruce Momjian writes: > > > Well, it is a nice test template for people who aren't shell script > > experts, and I have been in the habit of pushing stuff I use into /tools > > so it is available for others. > > I know and I'm not happy about it. The PostgreSQL source tree isn't a > repository of everyone's favorite shell scripts. There's an official > method to build and test a PostgreSQL installation. If that is flawed or > incomplete, then let's talk about it. But everyone pushing out their own > little test methodology without further consideration is not going to help > this discussion. I put stuff in /tools so if something happens to me, you guys can keep going. Do I have to be clearer that that? I have RELEASE_CHANGES, which Tom used for 7.3.X releases, pgindent, stuff for finding missing/extraneous includes, static requirements, stuff like that. Unless you can find someone else who agrees with you, it stays. -- 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] Two weeks to feature freeze
> -Original Message- > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 21, 2003 8:50 PM > To: Dann Corbit > Cc: Tom Lane; Jason Earl; PostgreSQL-development > Subject: Re: [HACKERS] Two weeks to feature freeze > > > Dann Corbit wrote: > > That is the worst possible test plan. It totally lacks > organization > > and there is no hint to define when the feature set has > been covered. > > Ad hoc testing is a useful addition, but it cannot replace all the > > standard tests that have been used by the industry for decades. > > > > If you run literally hundreds of tests designed to ensure that your > > product conforms to ANSI/ISO standards then the bugs that > are missed > > will be few and far between. Unless you are bad at designing tests. > > > > Designing tests is busywork. Desiging tests is boring. > Nobody wants > > to design tests, let alone interpret the results and define correct > > baselines. But testing is very, very important. > > I remember when I was with Great Bridge they said, "Oh, we > are going to have a test setup and do all sorts of testing to > improve PostgreSQL." I told them I doubted their testing was > going to shake out many more bugs than our existing testing > setup, and you know what, I was pretty much right. Sure, > they found a few, but it wasn't much. PostgreSQL is a fairly mature product, having been in existence in one form or another for many years now. I expect that most of the bugs that surface will be in areas of new functionality. Great Bridge had the right idea though. Let's suppose that they ran 10,000 tests and turned up only one bug. That would be just as valuable (if not more so) than turning up 100 bugs. A large, carefully designed test system is *proof* of software quality, or at least of the effort to determine the quality level. It is also proof of the responsibility of the software's originators. Scenario: You are going to install a tool that your organization will invest its future in. Vendor A: "We think our tool is pretty solid and our end users hardly ever turn up any bugs." Vendor B:" We think our tool is pretty solid and our 8500 tests currently show only 3 defects with the released version, and these are low impact issues. To view our current database of issues, log onto web form ." Which tool would you prefer to install? ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
"Dann Corbit" <[EMAIL PROTECTED]> writes: >> What do you think is the way to become an insider? > Join the CVS tree and make a large and valuable contribution to the > project. For instance, developing an industrial-strength test suite? If you've got an itch there, scratch it. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Two weeks to feature freeze
Bruce Momjian writes: > Well, it is a nice test template for people who aren't shell script > experts, and I have been in the habit of pushing stuff I use into /tools > so it is available for others. I know and I'm not happy about it. The PostgreSQL source tree isn't a repository of everyone's favorite shell scripts. There's an official method to build and test a PostgreSQL installation. If that is flawed or incomplete, then let's talk about it. But everyone pushing out their own little test methodology without further consideration is not going to help this discussion. -- Peter Eisentraut [EMAIL PROTECTED] ---(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
> -Original Message- > From: Jan Wieck [mailto:[EMAIL PROTECTED] > Sent: Sunday, June 22, 2003 5:45 AM > To: Dann Corbit > Cc: Tom Lane; Jason Earl; PostgreSQL-development > Subject: Re: [HACKERS] Two weeks to feature freeze > > > Dann Corbit wrote: > >> -Original Message- > >> From: Tom Lane [mailto:[EMAIL PROTECTED] > >> > >> Are you volunteering to create it? Step right up. > > > > No. And as an outsider, I rather doubt if any procedures I > developed > > would be taken very seriously. If such procedures are to be > > developed, I suspect that they will have to be developed > from within > > if they are to be successful. > > What do you think is the way to become an insider? Join the CVS tree and make a large and valuable contribution to the project. ---(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
> -Original Message- > From: The Hermit Hacker [mailto:[EMAIL PROTECTED] > Sent: Sunday, June 22, 2003 12:30 PM > To: Jan Wieck > Cc: The Hermit Hacker; Dann Corbit; Tom Lane; Jason Earl; > PostgreSQL-development > Subject: Re: [HACKERS] Two weeks to feature freeze > > > On Sun, 22 Jun 2003, Jan Wieck wrote: > > > The Hermit Hacker wrote: > > > On Fri, 20 Jun 2003, Dann Corbit wrote: > > > > > >> Designing tests is busywork. Desiging tests is boring. Nobody > > >> wants to design tests, let alone interpret the results > and define > > >> correct baselines. But testing is very, very important. > > > > > > But we do do testing ... we even design testing (in the > form of the > > > regression tests) ... we just don't do testing that you > personally > > > approve of ... and, from what I've seen so far, you > aren't willing > > > to actually put > > > *your* time where your mouth is ... design some tests and > submit them to > > > us ... if they are valid, they will get used ... > > > > > > If you feel that crash-me is a valid starting point, > start there and > > > see where it takes you ... > > > > Not that fast! I didn't take the time to check but it wouldn't > > surprise me if MySQL's crash-me is GPL'd and copyright MySQL AB. > > That's not an optimal point to start PostgreSQL test code > from, is it? > > I didn't say to copy it, but if the format is what Dann feels > is required to be taken seriously, it does give a starting > point to work from ... > > the thing is, as I think it was Tom that pointed out, the > crash-me is more a feature tester then anything ... but Dann > appears to be stuck on it as the 'be all, end all of testing > suites' ... No. I think it covers a broad spectrum of functionality. It is clear that there are warts in it, and also that it is slanted in a few instances to turn "bugs into features." But I think that a large and thorough test suite that covers all major areas of functionality will prove useful. A test suite that covers just as many features and yet is aimed at honest evaluation would be a big benefit. The larger and more complete a functionality test suite is, the better. If a test suite covers ten times the functionality, it will uncover ten times as many defects. I think it is part of the responsibility of a software vendor to ensure that any released product is as free of defects as possible (even an open source tool set). All real software products larger than a few hundred lines of code have some defects in them. If you are going to trust your companies data to a software tool, you would want it to be as free from defects as is possible to achieve, without rasing the cost prohibitively. I think that performance testing is also a good idea. One of the big benefits of creating a large performance suite is that you can profile your code and find out where the effort is needed to get a big speed increase. I think that the NIST validation suite will be very valuable. The coverage of NIST is pretty good, but that test has warts on it too. You will find (for instance) that there is not one single index built by that test suite. So the joins are all brute force. Yetch. If PostgreSQL can pass all three areas of NIST (SQL, ecpg (the pc directory), and the mc directory) that would be pretty impressive. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [SQL] TR: Like and =
Randall Lucas <[EMAIL PROTECTED]> writes: > The LIKE operator takes a pattern, and since your pattern did not > specify a wildcard at the end, it didn't exactly match the padded > string. > This behavior does seem kind of confusing; Yeah. As of CVS tip, the system is actually going out of its way to cause this to happen: if we deleted the separate ~~ operator for bpchar, then the automatic rtrim() that now happens when converting bpchar to text would cause the extra spaces to go away, and the LIKE would work as Nicolas is expecting. On the other hand, this would probably create some backwards-compatibility issues, since existing uses of LIKE with bpchar operands are no doubt using patterns that expect the spaces to be there. Any opinions whether we should change it or not? 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] dblink_ora - a first shot on Oracle ...
This seems like a natural addition to our existing dblink in /contrib.
---
Hans-Jürgen Schönig wrote:
> Hi there ...
>
> I have spent some time working on an Oracle version of dblink. It works
> quite nicely for me and I hope it does for others.
>
> It already supports some basic features such as persistent connection
> and fetching data. This is not a perfect piece of software and there is
> lot of room for enhancing this stuff.
> If there is somebody out there who is interesting in this kind of stuff
> I would be glad.
> Maybe I will have some time in the next few days so that I can provide
> an interface for flat files and some other database such as Berkley DB
> as well. Maybe there will also be a version for MySQL but this one will
> be used for MIGRATION purposes only. In other words: I won't touch MySQL
> - just for migration and to get rid of it.
>
> Personal thanks to Joe Conway, most of the code has been stolen from him.
>
> Here is what you can do with the Oracle version:
>
>
> SELECT dblink_oraconnect('scott/[EMAIL PROTECTED]');
> SELECT * FROM dblink_ora('SELECT ename, sal FROM emp')
> AS (ename text, sal text);
> SELECT 'BEGIN', dblink_oraexec('BEGIN');
> SELECT 'UPDATE emp SET sal = sal - 1',
> dblink_oraexec('UPDATE emp SET sal = sal - 1');
> SELECT 'ROLLBACK', dblink_oraexec('ROLLBACK');
> SELECT * FROM dblink_ora('SELECT ename, sal FROM emp')
> AS (ename text, sal text);
> SELECT 'BEGIN', dblink_oraexec('BEGIN');
> SELECT 'UPDATE emp SET sal = sal + 1',
> dblink_oraexec('UPDATE emp SET sal = sal + 1');
> SELECT * FROM dblink_ora('SELECT ename, sal FROM emp')
> AS (ename text, sal text);
> SELECT 'UPDATE emp SET sal = sal - 1',
> dblink_oraexec('UPDATE emp SET sal = sal - 1');
> SELECT 'COMMIT', dblink_oraexec('COMMIT');
> SELECT dblink_oradisconnect();
>
>
>
> [EMAIL PROTECTED] dblink_ora]$ psql test < func.sql
> DROP FUNCTION
> CREATE FUNCTION
> DROP FUNCTION
> CREATE FUNCTION
> DROP FUNCTION
> CREATE FUNCTION
> DROP FUNCTION
> CREATE FUNCTION
> DROP FUNCTION
> CREATE FUNCTION
> dblink_oraconnect
> ---
> OK
> (1 row)
>
> NOTICE: SQL statement successful
> NOTICE: Found 2 columns
> ename | sal
> +--
> SMITH | 798
> ALLEN | 1598
> WARD | 1248
> JONES | 2973
> MARTIN | 1248
> BLAKE | 2848
> CLARK | 2448
> SCOTT | 2998
> KING | 4998
> TURNER | 1498
> ADAMS | 1098
> JAMES | 948
> FORD | 2998
> MILLER | 1298
> (14 rows)
>
> NOTICE: Affected: -1
> ERROR: Cannot execute SQL statement
> NOTICE: Affected: 14
> ?column? | dblink_oraexec
> --+
> UPDATE emp SET sal = sal - 1 | 14
> (1 row)
>
> NOTICE: Affected: 0
> ?column? | dblink_oraexec
> --+
> ROLLBACK | 0
> (1 row)
>
> NOTICE: SQL statement successful
> NOTICE: Found 2 columns
> ename | sal
> +--
> SMITH | 798
> ALLEN | 1598
> WARD | 1248
> JONES | 2973
> MARTIN | 1248
> BLAKE | 2848
> CLARK | 2448
> SCOTT | 2998
> KING | 4998
> TURNER | 1498
> ADAMS | 1098
> JAMES | 948
> FORD | 2998
> MILLER | 1298
> (14 rows)
>
> NOTICE: Affected: -1
> ERROR: Cannot execute SQL statement
> NOTICE: Affected: 14
> ?column? | dblink_oraexec
> --+
> UPDATE emp SET sal = sal + 1 | 14
> (1 row)
>
> NOTICE: SQL statement successful
> NOTICE: Found 2 columns
> ename | sal
> +--
> SMITH | 799
> ALLEN | 1599
> WARD | 1249
> JONES | 2974
> MARTIN | 1249
> BLAKE | 2849
> CLARK | 2449
> SCOTT | 2999
> KING | 4999
> TURNER | 1499
> ADAMS | 1099
> JAMES | 949
> FORD | 2999
> MILLER | 1299
> (14 rows)
>
> NOTICE: Affected: 14
> ?column? | dblink_oraexec
> --+
> UPDATE emp SET sal = sal - 1 | 14
> (1 row)
>
> NOTICE: Affected: 0
> ?column? | dblink_oraexec
> --+
> COMMIT | 0
> (1 row)
>
> dblink_oradisconnect
> --
> OK
> (1 row)
>
>
> Regards,
>
> Hans
>
>
> --
> Cybertec Geschwinde u Schoenig
> Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
> Tel: +43/2952/30706; +43/664/233 90 75
> www.cybertec.at, www.postgresql.at, kernel.cybertec.at
>
[ application/x-gzip is not supported, 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
--
Re: [HACKERS] Two Phase Commit WAS: Re: Two weeks to feature freeze
Josh Berkus <[EMAIL PROTECTED]> writes: >> No. I want to know what the subordinate does when it's promised to >> commit and the co-ordinator never responds. AFAICS the subordinate >> is screwed --- it can't commit, and it can't abort, and it can't expect >> to make progress indefinitely on other work while it's holding locks >> for the not-quite-committed transaction. > Anyway, I would vote for a first implemenation for 2PC which addressed the > commit-then-crash issue in some expedient-but-not-reliable way, and putting > 2PC in /contrib with a "not for production use" warning. Some people will > use it in production anyway, and hopefully one or more of them will put in > the dozens of hours required to make it reliable. Putting in "dozens of hours" is not the issue here --- the problem is that there isn't any solution in sight, and I'm not eager to go down a path that has an obvious dead end. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two weeks to feature freeze
Scott MArlowe wrote:
> On Sat, 21 Jun 2003, Bruce Momjian wrote:
>
>> The big puzzle is how do you get people (including myself) motivated
>> to work on a feature that takes a _huge_ amount of work to see any
>> payoff? I would like to know. Anyone?
>
> Pizza? :-)
Unfortunately it's off my diet :-(
Seriously, I think an increased willingness to share the work around a bit
would be beneficial. I know that I volunteered to work on the w32 port at a
time when I was, as they say, "between jobs". The response was not
encouraging. Now I am working again and don't have much time available.
I know you can't simply divide tasks with infinite granularity ("nine women
can't make a bay in a month"). Some tasks require one or a few people to get
done and that's all that can be done. But if she/he/they can't get it done,
it's time to send out a call for help, IMNSHO.
Not meaning to criticize - the core team does a great job. I, too, have a
tendency to overcommit and under-delegate. It's very understandable.
andrew
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Two weeks to feature freeze
On Mon, 23 Jun 2003, Bruce Momjian wrote: > Peter Eisentraut wrote: > > The Hermit Hacker writes: > > > > > Ya, the script looked like it did a bit more then just a 'make clean; make > > > check' ... doesn't it? > > > > No. > > Well, it is a nice test template for people who aren't shell script > experts, and I have been in the habit of pushing stuff I use into /tools > so it is available for others. Please keep pushing such scripts out. They're a valuable learning tool for many beginners and a cost little in size to be included. ---(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 <[EMAIL PROTECTED]> writes: > Here's a sure to be wildly unpopular suggestion: > Make the deciding factor for the next release support of "foo" (foo can > be win32, pitr, replication, 2PC, whatever...). We've done that before (see WAL in 7.1), with unhappy results. The fundamental problem with it is that towards the end of the cycle, other developers don't know how to schedule their time, because they don't know when feature freeze is really going to be. People end up twiddling their thumbs while the schedule slips a few days at a time. The target-date-based approach we've taken in the last couple of releases seems much more productive. 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] ftp mirror
[EMAIL PROTECTED] writes: > Is it me or is there a problem with ftp mirrors? > The latest shapshots I have here are from June 2; seems rather old.. It's not the mirrors' fault --- the nightly snapshots aren't getting updated on the master site either. I think this is still on Marc's "to fix" list. With beta getting closer, I hope he fixes it soon... 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] Two weeks to feature freeze
On Monday 23 June 2003 10:43 am, Tom Lane wrote: > Robert Treat <[EMAIL PROTECTED]> writes: > > Here's a sure to be wildly unpopular suggestion: > > > > Make the deciding factor for the next release support of "foo" (foo can > > be win32, pitr, replication, 2PC, whatever...). > > We've done that before (see WAL in 7.1), with unhappy results. well, I did say it would be wildly unpopular ;-) > The > fundamental problem with it is that towards the end of the cycle, > other developers don't know how to schedule their time, because they > don't know when feature freeze is really going to be. People end up > twiddling their thumbs while the schedule slips a few days at a time. > Ok, what if feature freeze comes 1 month after completion of "foo" feature. This way the release is still feature dependent, but people arn't sitting around day by day waiting for foo, and they also don't have to worry about getting caught in the middle of something when foo gets done. (i'm kind of picking 1 month arbitraily, this could be two weeks if that works better). > 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. Robert Treat ---(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
On Sat, 2003-06-21 at 22:55, Bruce Momjian wrote:
> Andrew Dunstan wrote:
> >
> > Maybe a better strategy would be to get a release out soon but not wait 6
> > months for another release which would contain the Win32 port and the PITR
> > stuff (assuming those aren't done in time for this release).
>
> What concerns me is that we thought that after 7.3, and didn't do much
> work on either until we got near 7.4 release. I wonder if this is just
> going to be a pattern, where these items are so large, we can't get any
> motivation to focus on them until we get near the final release. I
> guess if each final release gets us a little closer, eventually we will
> get there, but this process is not ideal.
>
> The big puzzle is how do you get people (including myself) motivated to
> work on a feature that takes a _huge_ amount of work to see any payoff?
> I would like to know. Anyone?
>
Here's a sure to be wildly unpopular suggestion:
Make the deciding factor for the next release support of "foo" (foo can
be win32, pitr, replication, 2PC, whatever...). This would put ample
pressure on the developers of "foo" to get it done since the whole
release rides on their shoulders. It also might encourage others to help
out more since they can't get something new until "foo" is completed.
This would also prioritize said developers time on the large project
rather than other non-prioritized tasks, and it also helps to ensure a
"killer feature" for those who want such things,
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Two weeks to feature freeze
Peter Eisentraut wrote: > The Hermit Hacker writes: > > > Ya, the script looked like it did a bit more then just a 'make clean; make > > check' ... doesn't it? > > No. Well, it is a nice test template for people who aren't shell script experts, and I have been in the habit of pushing stuff I use into /tools so it is available for others. -- 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] Two Phase Commit WAS: Re: Two weeks to feature freeze
Agreed. --- Josh Berkus wrote: > Tom, > > > No. I want to know what the subordinate does when it's promised to > > commit and the co-ordinator never responds. AFAICS the subordinate > > is screwed --- it can't commit, and it can't abort, and it can't expect > > to make progress indefinitely on other work while it's holding locks > > for the not-quite-committed transaction. > > AFAIK, MS SQL Server's two-phase commit works like this ... if both servers > prepare, and one crashes, the transaction is screwed up. Somewhat unreliable > considering the frequence with which MSSQL crashes, yet it seems to be good > enough for several companies to sell "solutions" based on it. (performance is > also appalling, but that's a different issue) > > Anybody have a grasp of Oracle internals for 2PC? > > Anyway, I would vote for a first implemenation for 2PC which addressed the > commit-then-crash issue in some expedient-but-not-reliable way, and putting > 2PC in /contrib with a "not for production use" warning. Some people will > use it in production anyway, and hopefully one or more of them will put in > the dozens of hours required to make it reliable. > > -- > Josh Berkus > Aglio Database Solutions > San Francisco > > ---(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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two weeks to feature freeze
The Hermit Hacker writes: > Ya, the script looked like it did a bit more then just a 'make clean; make > check' ... doesn't it? No. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] SHM_QUEUE
just have a quick question. What i need to do is to create a shared memory structure (which i can do) and maintain in it a linked list which should be in shared memory too. I found the shmemqueue in postgres, but am having some problems using it. I just need to have the linked list store relation OID's. I see there is an Insert before and after which takes in an element and adds it to the queue. But the thing is - they are both SHM_QUEUE types. How can i convert an Oid to this type? Also, am i right in assuming that i can use this? I was looking for some examples of its use too. thanks nailah On Fri, 20 Jun 2003, Neil Conway wrote: > Hi Nailah, > > I hope your summer is going well. I saw your post on -hackers regarding some > problems with hash_search. The dynahash API can be a little bit picky -- IIRC, > it requires you to NULL pad hash keys out to the appropriate length, rather > than just using a regular NULL-terminated C-string. You weren't specific on > the exact problem you were having, but perhaps taking a look at > src/backend/commands/prepare.c (in PostgreSQL 7.3 or later) would be helpful: > it is a simple example of manipulating a hash table of prepared statements > that I wrote last summer. Since last I heard you guys were still working with > 7.1, you can find the code in question here: > > http://developer.postgresql.org/cvsweb.cgi/~checkout~/pgsql-server/src/backend/commands/prepare.c?rev=1.18&content-type=text/plain > > If that doesn't help, the usual fallback of breaking of gdb and stepping > through the troublesome code might help track down the problem. > > BTW, I'm not subscribed to the -hackers list temporarily (just for the summer, > as I'm busy w/ MS work), so my response to questions posted there will > probably be erratic (I just browse the archives on the web occaisonally). > > -Neil > ---(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 Phase Commit WAS: Re: Two weeks to feature freeze
Tom, > No. I want to know what the subordinate does when it's promised to > commit and the co-ordinator never responds. AFAICS the subordinate > is screwed --- it can't commit, and it can't abort, and it can't expect > to make progress indefinitely on other work while it's holding locks > for the not-quite-committed transaction. AFAIK, MS SQL Server's two-phase commit works like this ... if both servers prepare, and one crashes, the transaction is screwed up. Somewhat unreliable considering the frequence with which MSSQL crashes, yet it seems to be good enough for several companies to sell "solutions" based on it. (performance is also appalling, but that's a different issue) Anybody have a grasp of Oracle internals for 2PC? Anyway, I would vote for a first implemenation for 2PC which addressed the commit-then-crash issue in some expedient-but-not-reliable way, and putting 2PC in /contrib with a "not for production use" warning. Some people will use it in production anyway, and hopefully one or more of them will put in the dozens of hours required to make it reliable. -- Josh Berkus Aglio Database Solutions San Francisco ---(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] ftp mirror
Hi Mark Is it me or is there a problem with ftp mirrors? The latest shapshots I have here are from June 2; seems rather old.. Regards -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
On Sat, 21 Jun 2003, Bruce Momjian wrote: > Andrew Dunstan wrote: > > > > Maybe a better strategy would be to get a release out soon but not wait 6 > > months for another release which would contain the Win32 port and the PITR > > stuff (assuming those aren't done in time for this release). > > What concerns me is that we thought that after 7.3, and didn't do much > work on either until we got near 7.4 release. I wonder if this is just > going to be a pattern, where these items are so large, we can't get any > motivation to focus on them until we get near the final release. I > guess if each final release gets us a little closer, eventually we will > get there, but this process is not ideal. > > The big puzzle is how do you get people (including myself) motivated to > work on a feature that takes a _huge_ amount of work to see any payoff? > I would like to know. Anyone? Pizza? :-) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
On Sat, 21 Jun 2003, Christopher Kings-Lynne wrote: > Crash-me has nothing to do with testing, it jsut checks to see what > features a db supports: An interesting point is that until recently, crashme said that the postgresql backend crashed on very large queries. The actual problem was that postgresql has NO LIMIT to query size, and the crashme script would keep feeding the postgresql backend larger and larger amounts of query until the internal buffer of the crashme script overran. This failure was attributed to postgresql when it was, in fact a bug in the crashme script. This is not an isolated behaviour of crashme. It's a quick dirty hack job designed to show the differences between MySQL and all the other databases. If it was truly comprehensive (i.e. SQL92 spec testing) there would be hundreds of failure points for MySQL. but it isn't. It tests only those things that are good in MySQL against other databases (for the most part, there is some token effort at including a few things MySQL doesn't do). ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] informatoin reagarding the last date of submission
On Mon, 23 Jun 2003, Srikanth M wrote: > Hi! > Can anyone give me the informatoin reagarding the last date of > submission of the code to be added in next version of pgsql. June 30th ... ---(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] informatoin reagarding the last date of submission
Hi! Can anyone give me the informatoin reagarding the last date of submission of the code to be added in next version of pgsql. bye Srikanth ---(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] what is the meaning of "schema"?
On Saturday 21 Jun 2003 11:04 pm, _ wrote: > Hi > > Thanks for the reply especially since I have resigned > myself not to use schema anymore and > unsubscribed from the list. (I subscribed just to post) I've CCd this back to the hackers list, since others may have something to contribute here. > I think that when a schema is created as > > # create schema test authorization httpd > > pg_dump should do exactly that. > > Notice that it works perfectly since super user > is creating schema until it comes > to restoring the dump. I'm guessing (and that's all it is - I've not looked at the source) that PG doesn't know that the schema was created that way. So - basically I think we have two choices: 1. All schemas owned by "foo" should be built using: \connect - foo CREATE SCHEMA AUTHORIZATION foo; 2. All schemas owned by foo should use: \connect - postgres CREATE SCHEMA foo AUTHORIZATION foo; Both produce the same result, but the one requires superuser permissions. I think this certainly needs thinking about - it's only going to occur when you have a schema owned by neither the superuser or the database owner. > httpd does not have any specail privilege except > schema usage (either granted as "authorization" at > schema creation time by super user or > explicitly granted by postgres) and table level > permissions. I take it the explicit grant works OK? If so, that's the workaround I'd use for the moment. Must admit, I'd never considered having schemas owned by a user without other access to a database I don't suppose you've got the time to put together a small demo script for this - creates two users, creates a database for user1, creates schemas, one table then dumps the db? That would make for a quick test against 7.4 CVS - I don't think a fix would take long to produce then. -- Richard Huxton ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] [HACKERS] again: Bug #943: Server-Encoding from EUC_TW
> > > > 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. > > > > Sorry, I do not know anything about conversion maps and CNS 11643-1993 planes. > > I only got a file in BIG5 encoding from Taiwan and found that it is not possible > > to load all text to postgresql 7.3.3. > > But it is possible to convert to UTF-8 with iconv tool from glibc (Linux). > > It would be good if next release supports todays BIG5. > > I'm not looking forward to add any conversion entries confirmed by > standards. Can some one explain me the current status of the Oops. above should be: I'm not looking forward to add any conversion entries NOT confirmed by standards. > conversion maps between BIG5 and Unicode? The only info I could found > so far is in www.unicode.org. > -- > Tatsuo Ishii > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] again: Bug #943: Server-Encoding from EUC_TW toUTF-8
> > > 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. > > Sorry, I do not know anything about conversion maps and CNS 11643-1993 planes. > I only got a file in BIG5 encoding from Taiwan and found that it is not possible > to load all text to postgresql 7.3.3. > But it is possible to convert to UTF-8 with iconv tool from glibc (Linux). > It would be good if next release supports todays BIG5. I'm not looking forward to add any conversion entries confirmed by standards. Can some one explain me the current status of the conversion maps between BIG5 and Unicode? The only info I could found so far is in www.unicode.org. -- 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
