Re: [HACKERS] pg_comparator table diff/sync
Erik Aronesty wrote: Is pg_comparator the only project out there that does what it does? http://www.sqlmanager.net/en/products/postgresql/dbcomparer http://www.sqlmanager.net/en/products/postgresql/dbcomparer http://pgdiff.sourceforge.net/ http://pgdiff.sourceforge.net/ http://apgdiff.sourceforge.net/ http://apgdiff.sourceforge.net/ -- View this message in context: http://www.nabble.com/pg_comparator-table-diff-sync-tf3730954.html#a10636792 Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Not ready for 8.3
Jim C. Nasby wrote: On Tue, May 15, 2007 at 10:32:14PM +0200, Magnus Hagander wrote: Stefan Kaltenbrunner wrote: They are not stable. The items should point to the archives, which are supposedly more stable. (I had already fixed one item in PatchStatus this morning). Really it would be much nicer to have links using the Message-Id but I doubt that's at all doable. hrm - I see so is there a particular reason for that behaviour ? They're stable until Bruce removes something from the queue. When something is removed, it's renumbered. It's how mhonarc works. It's the same with the archives - if we delete a mail, they get renumbered. So we never should delete, we should just blank out, but it has happened a couple of times. Isn't there any other archiver we could use? The lack of URL stability in mhonarc is bad enough, but the cross-month issue is just horrible. Nothing useful last time I looked (a year or two back admittedley). I have a design for one in mind that I was looking to prototype - there are some php classes that would make it quite simple to get messages into a database either via procmail, or from an mbox. the stumbling block I was running into was rewriting the old archives URLs to the new ones. Regards, Dave ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Not ready for 8.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, May 16, 2007 at 10:16:43AM +0900, Tatsuo Ishii wrote: Stefan Kaltenbrunner wrote: They are not stable. [...] As I proposed for many times, why don't we add message number to each subject line in mail? For example like this: [HACKERS: 12345] Re: Not ready for 8.3 What I don't understand is why mailing list software doesn't use message ID as primary index. Granted, it's ugly, but it is globally stable (and hopefully unique) _across all mailboxes_ Sorry for the random rant - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGSrYGBcgs9XrR2kYRAlY2AJ9Vq5JZZEqX/y/DkN/HJ4Wg47RMyQCfbdgh Z6KnR4eJHh/oDHr7GI/OiPU= =Nxev -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Windows Vista support (Buildfarm Vaquita)
Michael Meskes wrote: On Wed, May 09, 2007 at 12:46:52PM +0100, Dave Page wrote: Unfortunately I do not have access to a Vista system I could use to test and track this one down. I'm happy to run any tests you like. Dave, could you please apply this small patch to pgtypeslib/datetime.c. I still have no clue where the error code is comming from and I'm trying to narrow it down a bit. Hi Michael, The results are attached. Please let me know if I can do anything more. Regards, Dave [NO_PID]: ECPGdebug: set to 1 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGconnect: opening database regress1 on DEFAULT port DEFAULT [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 29: QUERY: create table date_test ( d date, ts timestamp) on connection regress1 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 29 Ok: CREATE TABLE [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 30: QUERY: set datestyle to iso on connection regress1 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 30 Ok: SET [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 35: QUERY: insert into date_test ( d , ts ) values ( date '1966-01-17' , timestamp '2000-07-12 17:34:29' ) on connection regress1 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 35 Ok: INSERT 0 1 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 37: QUERY: select * from date_test where d = date '1966-01-17' on connection regress1 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 37: Correctly got 1 tuples with 2 fields [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 37: RESULT: 1966-01-17 offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 37: RESULT: 1966-01-17 errno 22 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: raising sqlcode -209 in line 37, 'SQL error #-209 in line 37.'. [NO_PID]: sqlca: code: -209, state: 42804 sql error SQL error #-209 in line 37. [NO_PID]: ECPGtrans line 350 action = rollback connection = regress1 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ecpg_finish: Connection regress1 closed. [NO_PID]: sqlca: code: 0, state: 0 1: errno = 0 2: errno = 22 3: errno = 22 4: errno = 22 1: errno = 0 2: errno = 22 3: errno = 22 4: errno = 22 Date: 1966-01-17 timestamp: 2000-07-12 17:34:29 interval: @ 13556 days 12 hours 34 mins 14 secs m: 4, d: 19, y: 1998 date seems to get encoded to julian -622 m: 4, d: 19, y: 1998 date_day of 2003-12-04 17:34:29 is 4 Above date in format (ddd), mmm. dd, , repeat: (ddd), mmm. dd, . end is (Thu), Dec. 04, 2003, repeat: (Thu), Dec. 04, 2003. end date_defmt_asc1: 1995-12-25 date_defmt_asc2: 0095-12-25 date_defmt_asc3: 0095-12-25 date_defmt_asc4: 1995-12-25 date_defmt_asc5: 1995-12-25 date_defmt_asc6: 1995-12-25 date_defmt_asc7: 1995-12-25 date_defmt_asc8: 1995-12-25 date_defmt_asc9: 1995-12-25 date_defmt_asc10: 1995-12-25 date_defmt_asc12: 0095-12-25 timestamp_to_asc1: 1996-02-29 00:00:00 timestamp_to_asc2: 1994-02-11 03:10:35 timestamp_to_asc3: 2000-01-01 00:00:00 timestamp_fmt_asc: 0: abc-00:00:00-def-01/01/00-ghi% timestamp_defmt_asc(This is a 4/12/80 3-39l12test, This is a %m/%d/%y %H-%Ml%Stest) = 1980-04-12 03:39:12, error: 0 timestamp_defmt_asc(Tue Jul 22 17:28:44 +0200 2003, %a %b %d %H:%M:%S %z %Y) = 2003-07-22 15:28:44, error: 0 timestamp_defmt_asc(Tue Feb 29 17:28:44 +0200 2000, %a %b %d %H:%M:%S %z %Y) = 2000-02-29 15:28:44, error: 0 timestamp_defmt_asc(Tue Feb 29 17:28:44 +0200 1900, %a %b %d %H:%M:%S %z %Y) = 1900-02-28 15:28:44, error (should be error!): 1 timestamp_defmt_asc(Tue Feb 29 17:28:44 +0200 1996, %a %b %d %H:%M:%S %z %Y) = 1996-02-29 15:28:44, error: 0 timestamp_defmt_asc( Jul 31 17:28:44 +0200 1996, %b %d %H:%M:%S %z %Y) = 1996-07-31 15:28:44, error: 0 timestamp_defmt_asc( Jul 32 17:28:44 +0200 1996, %b %d %H:%M:%S %z %Y) = 1996-07-31 15:28:44, error (should be error!): 1 timestamp_defmt_asc(Tue Feb 29 17:28:44 +0200 1997, %a %b %d %H:%M:%S %z %Y) = 1997-02-28 15:28:44, error (should be error!): 1 timestamp_defmt_asc(Tue Jul 22 17:28:44 +0200 2003, %) = 1997-02-28 15:28:44, error (should be error!): 1 timestamp_defmt_asc(Tue Jul 22 17:28:44 +0200 2003, a %) = 1997-02-28 15:28:44, error (should be error!): 1 timestamp_defmt_asc(Jul, 22 17_28 `44 +0200 2003 , %b, %d %H_%M`%S %z %Y) = 2003-07-22 15:28:44, error: 0 timestamp_defmt_asc(Tue Jul %22 17:28:44 CEST 2003, %a %b %%%d %H:%M:%S %Z %Y) = 2003-07-22 15:28:44, error: 0 timestamp_defmt_asc(Tue Jul %22 17:28:44 CEST 2003, %a %b %%%d %H:%M:%S %Z %Y) = 2003-07-22 15:28:44, error: 0 timestamp_defmt_asc(abc 19 October %22 17:28:44 CEST 2003, abc%n %C %B %%%d %H:%M:%S %Z %Y) = 2003-10-22 15:28:44, error: 0 timestamp_defmt_asc(abc 18 October %34 17:28:44 CEST 80, abc%n %C %B %%%d %H:%M:%S %Z %y) = 1880-10-31 15:28:44, error (should be error!): 1 timestamp_defmt_asc(abc 18 October %34
Re: [HACKERS] Seq scans roadmap
32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2 cache effect. I'd say in a scenario where 32k pages are indicated you will also want larger than average L2 caches. How about using 256/blocksize? The reading ahead uses 1/4 ring size. To the best of our knowledge, this 1/4 needs to be 128k for reading. So I'd say we need 512/blocksize. Andreas ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] plperl vs. bytea
Ühel kenal päeval, E, 2007-05-07 kell 13:57, kirjutas Andrew Dunstan: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tino Wildenhain wrote: Andrew Dunstan schrieb: This does not need to be over-engineered, IMNSHO. Well could you explain where it would appear over-engineered? Anything that imposes extra requirements on type creators seems undesirable. I'm not sure either that the UUID example is a very good one. This whole problem arose because of performance problems handling large gobs of data, not just anything that happens to be binary. Well, we realize that bytea has got a performance problem, but are we so sure that nothing else does? I don't want to stick in a one-purpose wart only to find later that we need a few more warts of the same kind. An example of something else we ought to be considering is binary transmission of float values. The argument in favor of that is not so much performance (although text-and-back conversion is hardly cheap) as it is that the conversion is potentially lossy, since float8out doesn't by default generate enough digits to ensure a unique back-conversion. ISTM there are three reasons for considering non-text-based transmission: 1. Performance, as in the bytea case 2. Avoidance of information loss, as for float 3. Providing a natural/convenient mapping to the PL's internal data types, as we already do --- but incompletely --- for arrays and records It's clear that the details of #3 have to vary across PLs, but I'd like it not to vary capriciously. For instance plperl currently has special treatment for returning perl arrays as SQL arrays, but AFAICS from the manual not for going in the other direction; plpython and pltcl overlook arrays entirely, even though there are natural mappings they could and should be using. plpy (from http://python.projects.postgresql.org/project/be.html ) goes to another extreme and exposes the whole postgresql type system to embedded python interpreter. I don't know to what extent we should apply point #3 to situations other than arrays and records, but now is the time to think about it. If we can avoid copying/converting large(ish) values between postgresql and embedded language, we should try to do it. The main problems seem to be in differences alloc/free, palloc, refcounting/CG between pg and embedded languages. An example: working with the geometric types in a PL function is probably going to be pretty painful for lack of simple access to the constituent float values (not to mention the lossiness problem). of course we should provide access to subparts of pg types, either by writing some wrapper class/accessor functios or providing access through postgresql's existing functions. We should also be considering some non-core PLs such as PL/Ruby and PL/R; they might provide additional examples to influence our thinking. OK, we have a lot of work to do here, then. I can really only speak with any significant knowledge on the perl front. Fundamentally, it has 3 types of scalars: IV, NV and PV (integer, float, string). IV can accomodate at least the largest integer or pointer type on the platform, NV a double, and PV an arbitrary string of bytes. OTOH python has an extensible type system from the start (i.e. anything is an object), and thus could be painlessly (just SMOP) extended to use postgresql's native types when there is no 1:1 match with existing types. As for structured types, as I noted elsewhere we have some of the work done for plperl. My suggestion would be to complete it for plperl and get it fully orthogonal and then retrofit that to plpython/pltcl. I've actually been worried for some time that the conversion glue was probably imposing significant penalties on the non-native PLs, so I'm glad to see this getting some attention. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Not ready for 8.3
* Tatsuo Ishii [EMAIL PROTECTED] [070515 21:19]: As I proposed for many times, why don't we add message number to each subject line in mail? For example like this: [HACKERS: 12345] Re: Not ready for 8.3 This way, we could always obtain stable (logical) pointer, without reling on particular archival infrastructure. Isn't that what the Message-Id field is for? http://news.gmane.org/[EMAIL PROTECTED] a. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Not ready for 8.3
* Tatsuo Ishii [EMAIL PROTECTED] [070515 21:19]: As I proposed for many times, why don't we add message number to each subject line in mail? For example like this: [HACKERS: 12345] Re: Not ready for 8.3 This way, we could always obtain stable (logical) pointer, without reling on particular archival infrastructure. Isn't that what the Message-Id field is for? http://news.gmane.org/[EMAIL PROTECTED] a. Maybe. However I think subject-sequence has some advantages over Message-Id: - Easy to identify. Message-Id may not appear on some MUA with default setting - More handy than lengthy message Id - Easy to detect messages not delivered, by knowing that the sequence number was skipped -- Tatsuo Ishii SRA OSS, Inc. Japan ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Not ready for 8.3
I'm going to echo Bruce on this; I've mentioned that TSearch was going into Core at conferences and the reaction from existing users has been very enthusiastic, ranging from yippee! to about time!. Our users hate the fact that FTS is a separate module. Here here. And with respect to the debate about syntax, who cares? I think I prefer introducing real SQL-ish syntax over a bunch of pg_* functions, but doing it either way is IMHO better than doing nothing. ...Robert ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Not ready for 8.3
Am Mittwoch, 16. Mai 2007 05:37 schrieb Josh Berkus: In that case, we may need to talk about branching earlier so that developers can work on the new version who are frozen out of the in-process one. Well, we could branch right now, but who is going to commit anything into that new head branch? The committers are already claimed to be falling behind. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Not ready for 8.3
Am Mittwoch, 16. Mai 2007 05:37 schrieb Josh Berkus: I'm going to echo Bruce on this; I've mentioned that TSearch was going into Core at conferences and the reaction from existing users has been very enthusiastic, ranging from yippee! to about time!. Our users hate the fact that FTS is a separate module. At the same time they are subconsciously counting on us to make decisions based on rationality, not on enthusiasm. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Not ready for 8.3
Robert Haas wrote: Our users hate the fact that FTS is a separate module. Here here. Where? Where? Oh, you mean Hear Hear. (sorry - one of my pet peeves) And with respect to the debate about syntax, who cares? I think I prefer introducing real SQL-ish syntax over a bunch of pg_* functions, but doing it either way is IMHO better than doing nothing. We do have a responsibility, I think, to keep the grammar fairly clean, so the answer to your question who cares? is we do. That said, last time I looked most of the warts seemed to have been knocked off, IIRC, and the functional syntax would have been sufficiently ugly and cumbersome to weigh against it. So, like most others, I'm in favor of going with this unless there is some overwhelming reason I haven't heard of yet not to. cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] Testing concurrent psql
I'm looking for corner cases where the concurrent psql patch doesn't handle things properly. I'm wondering about multiple result sets but I can't think of any cases where I can test them. If you submit multiple commands at the psql prompt then psql seems to stop at the first semicolon and send the query separately. The only way to send multiple queries together seems to be with -c and I don't think we have any intention to support asynchronous queries via that route. Regular queries still work fine via this route. I seem to recall there was a way to construct scenarios that returned multiple result sets via rules but I don't know how to arrange that. Anyone remember? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Managing the community information stream
Bruce Momjian wrote: Alvaro Herrera wrote: Bruce Momjian wrote: Alvaro Herrera wrote: In Debian's bug tracking system, when the bug is created (which is done by sending an email to a certain address) it gets a number, and the email is distributed to certain lists. People can then reply to that mail, and send messages to [EMAIL PROTECTED] and it gets tracked in the bug, and you can see all those messages in the bug report. I ass-ume that BZ 3.0 does something similar. But often a TODO item has multiple threads containing details (often months apart), and it isn't obvious at the time the thread is started that this will happen. Note the number of TODO items that now have multiple URLs. How is that handled? Just add the bug address to CC and reply to it, just like when you reply to say added to TODO, only that you don't need to manually go and modify the TODO file by hand. The bug tracking system puts that mail into the bug report. Subsequent followups keep the bug address in CC and thus the whole discussion is saved in the bug report. Right, but you are adding the bug addresss at the end of the email thread. How do you point to the email you want to reference? I am not sure. We will have to investigate more the capabilities of the bug tracking system we intend to use. In the worst case one could add the URL for the archived message copy; second worst would be bouncing (hopefully not forward) the interesting messages to the bug address. If we had our own method for fetching a message by Message-Id, we could add Message-Ids to bugs reports. In the meantime we could use Gmane's. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Managing the community information stream
Alvaro Herrera wrote: Bruce Momjian wrote: Alvaro Herrera wrote: Bruce Momjian wrote: Alvaro Herrera wrote: In Debian's bug tracking system, when the bug is created (which is done by sending an email to a certain address) it gets a number, and the email is distributed to certain lists. People can then reply to that mail, and send messages to [EMAIL PROTECTED] and it gets tracked in the bug, and you can see all those messages in the bug report. I ass-ume that BZ 3.0 does something similar. But often a TODO item has multiple threads containing details (often months apart), and it isn't obvious at the time the thread is started that this will happen. Note the number of TODO items that now have multiple URLs. How is that handled? Just add the bug address to CC and reply to it, just like when you reply to say added to TODO, only that you don't need to manually go and modify the TODO file by hand. The bug tracking system puts that mail into the bug report. Subsequent followups keep the bug address in CC and thus the whole discussion is saved in the bug report. Right, but you are adding the bug addresss at the end of the email thread. How do you point to the email you want to reference? I am not sure. We will have to investigate more the capabilities of the bug tracking system we intend to use. In the worst case one could add the URL for the archived message copy; second worst would be bouncing (hopefully not forward) the interesting messages to the bug address. Sounds like what I do with the TODO list now. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Not ready for 8.3
[EMAIL PROTECTED] wrote: On Wed, May 16, 2007 at 10:16:43AM +0900, Tatsuo Ishii wrote: Stefan Kaltenbrunner wrote: They are not stable. [...] As I proposed for many times, why don't we add message number to each subject line in mail? For example like this: [HACKERS: 12345] Re: Not ready for 8.3 What I don't understand is why mailing list software doesn't use message ID as primary index. Granted, it's ugly, but it is globally stable (and hopefully unique) _across all mailboxes_ It does. The problem is that it only considers messages posted in the last calendar month. So on the 1st of each month, all threads start again as far as the archive goes. There is just one remaining problem: Outlook and derivatives don't set the In-Reply-To: nor References: headers. This breaks the threads (the best the software can do is group the messages by subject, but it works only partially). I've tried a coupld of times to decode how the Thread-Id stuff works, which is what Outlook seems to use, but I haven't been able to detect a pattern. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Not ready for 8.3
Tatsuo Ishii wrote: * Tatsuo Ishii [EMAIL PROTECTED] [070515 21:19]: As I proposed for many times, why don't we add message number to each subject line in mail? For example like this: [HACKERS: 12345] Re: Not ready for 8.3 This way, we could always obtain stable (logical) pointer, without reling on particular archival infrastructure. Isn't that what the Message-Id field is for? http://news.gmane.org/[EMAIL PROTECTED] a. Maybe. However I think subject-sequence has some advantages over Message-Id: - Easy to identify. Message-Id may not appear on some MUA with default setting Message-Ids are present in all messages. When the MUA doesn't set it, the MTA does. The problem starts when the MUA doesn't set the In-Reply-To header. - More handy than lengthy message Id True. - Easy to detect messages not delivered, by knowing that the sequence number was skipped The problem is that the number would be possibly set at a later stage of email delivery by the list software, so it doesn't help if the message is skipped in an earlier stage (spam filter, etc). -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Not ready for 8.3
* Tatsuo Ishii [EMAIL PROTECTED] [070516 07:23]: Maybe. However I think subject-sequence has some advantages over Message-Id: - Easy to identify. Message-Id may not appear on some MUA with default setting - More handy than lengthy message Id - Easy to detect messages not delivered, by knowing that the sequence number was skipped IMNSHO, we should be encouraging lists to move *away* from subject munging. Adding more characters into a subject line which can already be quite long is just making the situation worse. And of course, once you realize that subject munging is wrong, putting the list-sequence into a header of no real value, unless you believe your MTA/MUA filtering to be somehow dropping list messages, and your sequence numbers will prove to you if that's true or not. Oh - but wait, don't we all, as PostgreSQL users realize that sequences aren't generally guaranteed to be gapless anyways (sure, there are work solutions, but I'm not about to audit any MTA/list software for that...) ;-) -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Not ready for 8.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, May 16, 2007 at 10:03:47AM -0400, Alvaro Herrera wrote: [EMAIL PROTECTED] wrote: [...] There is just one remaining problem: Outlook and derivatives don't set the In-Reply-To: nor References: headers. This breaks the threads (the best the software can do is group the messages by subject, but it works only partially). I've tried a coupld of times to decode how the Thread-Id stuff works, which is what Outlook seems to use, but I haven't been able to detect a pattern. Heh. Seems to be a well-known problem: http://osdir.com/ml/discuss/2003-10/threads.html#00194 Ackthpttp. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGSxVVBcgs9XrR2kYRAsRrAJ9GC7fHJgaS424yoylnzB/9YPtE/wCbBCRE C62mzkj1BVXKlIau0TKlOS4= =GVAM -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Managing the community information stream
Bruce Momjian wrote: Alvaro Herrera wrote: Bruce Momjian wrote: Alvaro Herrera wrote: Bruce Momjian wrote: Alvaro Herrera wrote: In Debian's bug tracking system, when the bug is created (which is done by sending an email to a certain address) it gets a number, and the email is distributed to certain lists. People can then reply to that mail, and send messages to [EMAIL PROTECTED] and it gets tracked in the bug, and you can see all those messages in the bug report. I ass-ume that BZ 3.0 does something similar. But often a TODO item has multiple threads containing details (often months apart), and it isn't obvious at the time the thread is started that this will happen. Note the number of TODO items that now have multiple URLs. How is that handled? Just add the bug address to CC and reply to it, just like when you reply to say added to TODO, only that you don't need to manually go and modify the TODO file by hand. The bug tracking system puts that mail into the bug report. Subsequent followups keep the bug address in CC and thus the whole discussion is saved in the bug report. Right, but you are adding the bug addresss at the end of the email thread. How do you point to the email you want to reference? I am not sure. We will have to investigate more the capabilities of the bug tracking system we intend to use. In the worst case one could add the URL for the archived message copy; second worst would be bouncing (hopefully not forward) the interesting messages to the bug address. Sounds like what I do with the TODO list now. Except that this is the *worst case* with the bug tracker, whereas for the TODO list it is not only the worst case, it is also the best case and the only case at all. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Managing the community information stream
Alvaro Herrera wrote: I am not sure. We will have to investigate more the capabilities of the bug tracking system we intend to use. In the worst case one could add the URL for the archived message copy; second worst would be bouncing (hopefully not forward) the interesting messages to the bug address. Sounds like what I do with the TODO list now. Except that this is the *worst case* with the bug tracker, whereas for the TODO list it is not only the worst case, it is also the best case and the only case at all. And it requires no additional work to ignore threads. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Patch for pg_dump
This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Dany DeBontridder wrote: I often need in command line to get the code of function, so I make a patch for pg_dump, thanks this patch pg_dump is able to dump only one functions or all the functions. The argument is --object or -B Example: ./pg_dump -Bfunction:test_it -Bfunction:dblink_open To dump the functions test_it, dblink_open ./pgdump --object=function or pg_dump -Bfunction to dump only the functions It is possible to add other objects, (see getObject functions) I hope you'll find it interesting. Regards, .D. (patch under BSD licence) [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Not ready for 8.3
Here here. Where? Where? Oh, you mean Hear Hear. (sorry - one of my pet peeves) Oops. Of course since it's in written form perhaps I should be writing Read! Read! instead. We do have a responsibility, I think, to keep the grammar fairly clean, so the answer to your question who cares? is we do. Sure. I'm asking that rhetorical question under the assumption that none of the options on the table are so bad as to constitute an abrogation of that responsibility. If that's not the case, then it's an issue; otherwise, we shouldn't let differences of opinion over a question that may not have only one right answer prevent us from doing anything at all. ...Robert ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [DOCS] row-level stats and last analyze time
Has this been done yet? I don't think so. --- Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: On Thu, 2007-26-04 at 18:07 -0400, Neil Conway wrote: (1) I believe the reasoning for Tom's earlier change was not to reduce the I/O between the backend and the pgstat process [...] Tom, any comments on this? Your change introduced an undocumented regression into 8.2. I think you're on the hook for a documentation update at the very least, if not a revert. The documentation update seems the most prudent thing to me. The problem with the prior behavior is that it guarantees that every table in the database will eventually have a pg_stat entry, even if stats_row_level and stats_block_level are both off. In a DB with lots of tables that creates a significant overhead *for a feature the DBA probably thinks is turned off*. This is not how it worked before 8.2, and so 8.2.0's behavior is arguably a performance regression compared to 8.1 and before. Now this patch went in before we realized that 8.2.x had a bug in computing the stats-file-update delay, and it could be that after fixing that the problem is not so pressing. But I don't particularly care for new features that impose a performance penalty on those who aren't using them, and that's exactly what last_vacuum/last_analyze tracking does if we allow it to bloat the stats file in the default configuration. The long-term answer of course is to devise a more efficient stats reporting scheme, but I'm not sure offhand what that would look like. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Testing concurrent psql
On Wed, May 16, 2007 at 09:43:36AM -0400, Gregory Stark wrote: I'm looking for corner cases where the concurrent psql patch doesn't handle things properly. I'm wondering about multiple result sets but I can't think of any cases where I can test them. If you submit multiple commands at the psql prompt then psql seems to stop at the first semicolon and send the query separately. The only way to send multiple queries together seems to be with -c and I don't think we have any intention to support asynchronous queries via that route. Regular queries still work fine via this route. I seem to recall there was a way to construct scenarios that returned multiple result sets via rules but I don't know how to arrange that. Anyone remember? I don't know about rules, but you can have a SRF return SETOF REFCURSOR. Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Managing the community information stream
On Wed, May 16, 2007 at 10:46:50AM -0400, Alvaro Herrera wrote: I am not sure. We will have to investigate more the capabilities of the bug tracking system we intend to use. In the worst case one could add the URL for the archived message copy; second worst would be bouncing (hopefully not forward) the interesting messages to the bug address. Sounds like what I do with the TODO list now. Except that this is the *worst case* with the bug tracker, whereas for the TODO list it is not only the worst case, it is also the best case and the only case at all. And any number of people can manage it (just like the wiki). -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Integer datetimes
Are we agreed to wait for 8.4 for this? --- Neil Conway wrote: What is the reasoning behind having two different implementations of the datetime types, with slightly different behavior? Do we intend to keep supporting both FP- and integer-based datetimes indefinitely? Clearly, there are some costs associated with maintaining two different implementations: (1) It means we need to maintain two sets of code, with a corresponding increase in the maintenance burden, the probability of introducing bugs, etc., and making datetime behavior more difficult to test. (2) In general, I think it is a fundamentally *bad* idea to have the semantics of a builtin data type differ subtly depending on the value of a configure parameter. It makes writing portable applications more difficult, and can introduce hard-to-fix bugs. So, are there any corresponding benefits to providing both FP and integer datetimes? AFAIK the following differences in user-visible behavior exist: * integer timestamps have the same precision over their entire range (microsecond precision), whereas FP timestamps do not. This is clearly an advantage for integer timestamps. * integer timestamps have a smaller range than FP timestamps (294276 AD vs. 5874897 AD). Are there actually applications that use timestamps larger than 300,000 AD? Unless there are lots of applications that need timestamps over such a large range, ISTM integer datetimes are the better long-term approach, and I don't see how the FP-based datetime code justifies the maintenance burden. Notably, the FP datetime code doesn't depend on having a functional int64 type, but in 2007, are there really any platforms we care about that don't have such a type? Therefore, I propose that we make integer datetimes the default (perhaps for 8.4), and then eventually remove the floating-point datetime code. Comments? -Neil P.S. One thing to verify is that the performance of integer datetimes is no worse than the perf. of FP datetimes. I'd intuitively expect this to be true, but it would be worth investigating. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Not ready for 8.3
On Wed, May 16, 2007 at 08:58:44AM +0100, Dave Page wrote: Jim C. Nasby wrote: On Tue, May 15, 2007 at 10:32:14PM +0200, Magnus Hagander wrote: Stefan Kaltenbrunner wrote: They are not stable. The items should point to the archives, which are supposedly more stable. (I had already fixed one item in PatchStatus this morning). Really it would be much nicer to have links using the Message-Id but I doubt that's at all doable. hrm - I see so is there a particular reason for that behaviour ? They're stable until Bruce removes something from the queue. When something is removed, it's renumbered. It's how mhonarc works. It's the same with the archives - if we delete a mail, they get renumbered. So we never should delete, we should just blank out, but it has happened a couple of times. Isn't there any other archiver we could use? The lack of URL stability in mhonarc is bad enough, but the cross-month issue is just horrible. Nothing useful last time I looked (a year or two back admittedley). I have a design for one in mind that I was looking to prototype - there are some php classes that would make it quite simple to get messages into a database either via procmail, or from an mbox. the stumbling block I was running into was rewriting the old archives URLs to the new ones. How much visibility do we have into the mhonarc database? We should be able to come up with a simple redirector that would point the old mhonarc URLs to URLs for the new system... -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Not ready for 8.3
Jim C. Nasby wrote: How much visibility do we have into the mhonarc database? We should be able to come up with a simple redirector that would point the old mhonarc URLs to URLs for the new system... coughdatabase?/cough It's a file system. It simply generates HTML (or in our case) PHP files from each message in an mbox. That's one of the reasons for the monthly break - without it, the directories would be unusably full of files. I the current URLs represent the month, and the ID of the message as it comes out of the mbox I believe. We could probably write a script to dump a list of message IDs, directories and mbox positions I imagine, and then import that into a new database. It's been on my list to rewrite the whole archive system for a while for various reasons. There is quite a bit of crossover with the patch tracker I proposed so I was hoping to look at both together. Regards, Dave ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.3 pending patch queue
On Wed, May 16, 2007 at 12:33:38AM -0300, Marc G. Fournier wrote: Someone (you, I think) advocated a '3 weeks and then dump the rest of the patches' (not quote as strong of wording, but similar) ... why not split the patches list up: submitted patches, not reviewed reviewed patches, needs work, waiting on author reviewed patches, ready for commit. Once feature freeze started, the first list should only get small patches to it, easily reviewed and committed ... then, focus on reviewing list A and move the patch to list B or commit it ... once list A is cleared off, we go into Beta ... if a patch on list B gets re-submitted before Beta, it gets reviewed and either committed, or punt'd to the next release ... I don't think we want to be adding anything new in beta. But if we went into 'alpha' when list A is cleared that might work. (BTW, it's not really clear which list A is...) That leaves Freeze - Beta being as long as it takes to get thorugh List A ... and the only thing punt'd to the next release being that which really isn't ready ... -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Testing concurrent psql
On Wed, May 16, 2007 at 09:43:36AM -0400, Gregory Stark wrote: I'm looking for corner cases where the concurrent psql patch doesn't handle things properly. I'm wondering about multiple result sets but I can't think of any cases where I can test them. If you submit multiple commands at the psql prompt then psql seems to stop at the first semicolon and send the query separately. The only way to send multiple queries together seems to be with -c and I don't think we have any intention to support asynchronous queries via that route. Regular queries still work fine via this route. I seem to recall there was a way to construct scenarios that returned multiple result sets via rules but I don't know how to arrange that. Anyone remember? An ALSO SELECT rule? -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Integer datetimes
On Wed, 2007-16-05 at 11:25 -0400, Bruce Momjian wrote: Are we agreed to wait for 8.4 for this? Yes. -Neil ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Not ready for 8.3
On Wed, May 16, 2007 at 04:34:56PM +0100, Dave Page wrote: How much visibility do we have into the mhonarc database? We should be able to come up with a simple redirector that would point the old mhonarc URLs to URLs for the new system... coughdatabase?/cough And here I thought the reason we used tho POS was because it was the only archiver that used PostgreSQL as it's backend... It's a file system. It simply generates HTML (or in our case) PHP files from each message in an mbox. That's one of the reasons for the monthly break - without it, the directories would be unusably full of files. I the current URLs represent the month, and the ID of the message as it comes out of the mbox I believe. We could probably write a script to dump a list of message IDs, directories and mbox positions I imagine, and then import that into a new database. Yeah, if the files still resemble real emails then we can probably come up with a way to pull the data in. It's been on my list to rewrite the whole archive system for a while for various reasons. There is quite a bit of crossover with the patch tracker I proposed so I was hoping to look at both together. Let me know when you start on that... -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Not ready for 8.3
Aidan Van Dyk wrote: * Tatsuo Ishii [EMAIL PROTECTED] [070516 07:23]: Maybe. However I think subject-sequence has some advantages over Message-Id: - Easy to identify. Message-Id may not appear on some MUA with default setting - More handy than lengthy message Id - Easy to detect messages not delivered, by knowing that the sequence number was skipped IMNSHO, we should be encouraging lists to move *away* from subject munging. Adding more characters into a subject line which can already be quite long is just making the situation worse. +1 on that. It gets worse when messages are crossposted to multiple lists and so multiple [FOO] strings are put into the subject. On the other hand I know there is people who remove the [FOO] strings in their local machines! (I don't do it just because I have been too lazy to write a procmail rule about it). -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Integer datetimes
This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Neil Conway wrote: What is the reasoning behind having two different implementations of the datetime types, with slightly different behavior? Do we intend to keep supporting both FP- and integer-based datetimes indefinitely? Clearly, there are some costs associated with maintaining two different implementations: (1) It means we need to maintain two sets of code, with a corresponding increase in the maintenance burden, the probability of introducing bugs, etc., and making datetime behavior more difficult to test. (2) In general, I think it is a fundamentally *bad* idea to have the semantics of a builtin data type differ subtly depending on the value of a configure parameter. It makes writing portable applications more difficult, and can introduce hard-to-fix bugs. So, are there any corresponding benefits to providing both FP and integer datetimes? AFAIK the following differences in user-visible behavior exist: * integer timestamps have the same precision over their entire range (microsecond precision), whereas FP timestamps do not. This is clearly an advantage for integer timestamps. * integer timestamps have a smaller range than FP timestamps (294276 AD vs. 5874897 AD). Are there actually applications that use timestamps larger than 300,000 AD? Unless there are lots of applications that need timestamps over such a large range, ISTM integer datetimes are the better long-term approach, and I don't see how the FP-based datetime code justifies the maintenance burden. Notably, the FP datetime code doesn't depend on having a functional int64 type, but in 2007, are there really any platforms we care about that don't have such a type? Therefore, I propose that we make integer datetimes the default (perhaps for 8.4), and then eventually remove the floating-point datetime code. Comments? -Neil P.S. One thing to verify is that the performance of integer datetimes is no worse than the perf. of FP datetimes. I'd intuitively expect this to be true, but it would be worth investigating. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.3 pending patch queue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Wednesday, May 16, 2007 10:36:42 -0500 Jim C. Nasby [EMAIL PROTECTED] wrote: On Wed, May 16, 2007 at 12:33:38AM -0300, Marc G. Fournier wrote: Someone (you, I think) advocated a '3 weeks and then dump the rest of the patches' (not quote as strong of wording, but similar) ... why not split the patches list up: submitted patches, not reviewed reviewed patches, needs work, waiting on author reviewed patches, ready for commit. Once feature freeze started, the first list should only get small patches to it, easily reviewed and committed ... then, focus on reviewing list A and move the patch to list B or commit it ... once list A is cleared off, we go into Beta ... if a patch on list B gets re-submitted before Beta, it gets reviewed and either committed, or punt'd to the next release ... I don't think we want to be adding anything new in beta. But if we went into 'alpha' when list A is cleared that might work. (BTW, it's not really clear which list A is...) List A is the 'unreviewed patches list', which, on Feature Freeze, would be 'closed' ... Feature Freeze would last until all Patches in List A are processed, whether that means going back to the Author for fixes/work, or gets committed to the source tree ... Once List A is cleared off, then we dive into Beta, at which point in time only bug fixes would be applied ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGSyp14QvfyHIvDvMRAjIHAJ9MKdROk7Mh0EvcpJoJJJ4uY6iKSQCgldFS ZAYrJ08nKewt1fZbXnXUeN8= =Huf8 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Not ready for 8.3
[EMAIL PROTECTED] (Aidan Van Dyk) writes: * Tatsuo Ishii [EMAIL PROTECTED] [070516 07:23]: Maybe. However I think subject-sequence has some advantages over Message-Id: - Easy to identify. Message-Id may not appear on some MUA with default setting - More handy than lengthy message Id - Easy to detect messages not delivered, by knowing that the sequence number was skipped IMNSHO, we should be encouraging lists to move *away* from subject munging. Adding more characters into a subject line which can already be quite long is just making the situation worse. And of course, once you realize that subject munging is wrong, putting the list-sequence into a header of no real value, unless you believe your MTA/MUA filtering to be somehow dropping list messages, and your sequence numbers will prove to you if that's true or not. Oh - but wait, don't we all, as PostgreSQL users realize that sequences aren't generally guaranteed to be gapless anyways (sure, there are work solutions, but I'm not about to audit any MTA/list software for that...) ;-) The message ID *ought* to be usable for at least some of the desired purposes; having a web client that uses message IDs as a query mechanism, and where switching months doesn't ludicrously break things, would seem to be one part of the solution. Adding some sort of (I don't know...) database that associates bug tracking system items with message IDs would seem like an along-side way of linking in relevant information. Adding x-???: tags might be a way of adding bug tracking information into messages; it wouldn't help with original copies, but could be a reasonable change to make in a given message repository. -- output = (cbbrowne @ acm.org) http://cbbrowne.com/info/rdbms.html If nothing ever sticks to Teflon, how do they make Teflon stick to the pan? ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.3 pending patch queue
Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Tuesday, May 15, 2007 16:33:32 -0700 Joshua D. Drake [EMAIL PROTECTED] wrote: If the developers were to actually take a step back and say, Hey... instead of working on these dozen different features, I should work on three and help someone review another three... We wouldn't have this problem. Isn't that the point of the feature freeze period? To put 'development' off to the side and spend the time reviewing what is pending? Except at least from the patch status page, few are actually reviewing. It seems we have dumped all our problems on a hand full of hackers. If ppl find it so inconviencing to not be able to submit patches becaus we're in a feature freeze, then won't that motivate them to do some review, get the patches cleared so that they *can* move on? In theory yes, but see my comment above. Someone (you, I think) advocated a '3 weeks and then dump the rest of the patches' (not quote as strong of wording, but similar) ... why not split the patches list up: submitted patches, not reviewed reviewed patches, needs work, waiting on author reviewed patches, ready for commit. I did that, read the whole thread. Bruce did it too ;) and Stefan (all in slightly different ways). Joshua D. Drake Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGSnuT4QvfyHIvDvMRAmelAJ90HOW3iOYMABmA41XCjJnKV2urtwCfaFTt nquLm5G2tVKMCH3Ld7znGQM= =Vl54 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Not ready for 8.3
Robert Haas wrote: hate the fact that FTS is a separate module. Here here. And with respect to the debate about syntax, who cares? I think I prefer introducing real SQL-ish syntax over a bunch of pg_* functions, but doing it either way is IMHO better than doing nothing. I care. I want a professional easy to understand and easy to maintain that doesn't cause potential conflict with future and past development syntax. Or should we be writing SQL in assembly? Joshua D. Drake ...Robert ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Not ready for 8.3
I care. I want a professional easy to understand and easy to maintain that doesn't cause potential conflict with future and past development syntax. I agree with this. The point of my comment was that ISTM that an arbitrary amount of time can be consumed determining the optimal syntax, during which Oleg is obligated to continually update his patch without any guarantee that it will be accepted in anything like its current form, or at all. If people have strong opinions about the syntax, why were they not ALL expressed when the proposal was originally laid on the table? Sure, some people offered opinions, but it doesn't appear that there was any real consensus, and there certainly wasn't any clear guidance of the form this is what you need to do to get your patch accepted, which leaves everything in limbo and Oleg doing a lot of extra work to keep updating his patch. I haven't studied the proposed syntaxes in detail, but ISTM that if there is no consensus then probably all of the alternatives being advocated are reasonable. Again, if that's not the case, then let's eliminate the unreasonable ones and pick one of the remaining choices. But if committer A thinks that X is the only reasonable options and committer B thinks that Y is the only reasonable option, does that mean that the patch just sits there forever, or do we find a way to move forward? ...Robert ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Lack of urgency in 8.3 reviewing
In talking to people who are assigned to review patches or could review patches, I often get the reply, Oh, yea, I need to do that. Folks, we are six weeks into feature freeze and have made slim progress on getting patches reviewed and applied. As I stated earlier, we are now looking at August/September for beta, but that might be pushed back even later if we don't get more progress. It seems there is a lot of reliance on Tom to get the patches applied, but I don't think that is fair or reasonable. I think we need more urgency on the part of everyone to make faster progress. Patch reviewers and committers need to take more initiative to get things done rather than wait for some external force to prompt them. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Lack of urgency in 8.3 reviewing
Bruce Momjian wrote: In talking to people who are assigned to review patches or could review patches, I often get the reply, Oh, yea, I need to do that. It seems there is a lot of reliance on Tom to get the patches applied, but I don't think that is fair or reasonable. I think we need more urgency on the part of everyone to make faster progress. Patch reviewers and committers need to take more initiative to get things done rather than wait for some external force to prompt them. We have *alot* of people (comparatively) who can assist in reviewing code that are not committers. Even if they can not commit, they can help insure that patches are in a state that can be more easily reviewed for committers to actually test and apply. Joshua D. Drake ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Lack of urgency in 8.3 reviewing
Bruce, where can I take a look at the patch list in order to find out if I can be of some help? Regards, g.- On 5/16/07, Bruce Momjian [EMAIL PROTECTED] wrote: In talking to people who are assigned to review patches or could review patches, I often get the reply, Oh, yea, I need to do that. Folks, we are six weeks into feature freeze and have made slim progress on getting patches reviewed and applied. As I stated earlier, we are now looking at August/September for beta, but that might be pushed back even later if we don't get more progress. It seems there is a lot of reliance on Tom to get the patches applied, but I don't think that is fair or reasonable. I think we need more urgency on the part of everyone to make faster progress. Patch reviewers and committers need to take more initiative to get things done rather than wait for some external force to prompt them. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Guido Barosio --- http://www.globant.com [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Lack of urgency in 8.3 reviewing
It is all on the developer roadmap page: http://momjian.us/cgi-bin/pgpatches --- Guido Barosio wrote: Bruce, where can I take a look at the patch list in order to find out if I can be of some help? Regards, g.- On 5/16/07, Bruce Momjian [EMAIL PROTECTED] wrote: In talking to people who are assigned to review patches or could review patches, I often get the reply, Oh, yea, I need to do that. Folks, we are six weeks into feature freeze and have made slim progress on getting patches reviewed and applied. As I stated earlier, we are now looking at August/September for beta, but that might be pushed back even later if we don't get more progress. It seems there is a lot of reliance on Tom to get the patches applied, but I don't think that is fair or reasonable. I think we need more urgency on the part of everyone to make faster progress. Patch reviewers and committers need to take more initiative to get things done rather than wait for some external force to prompt them. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Guido Barosio --- http://www.globant.com [EMAIL PROTECTED] -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Seq scans roadmap
I think the analysis on syncscan needs to take the external I/O cache into account. I believe it is not necessary or desirable to keep the scans in lock step within the PG bufcache. The main benefit of a sync scan will be the ability to start the scan where other scans have already filled the I/O cache with useful blocks. This will require some knowledge of the size of the I/O cache by the syncscan logic, but that's where the largest amount of I/O cache memory (by far) is located. - Luke On 5/15/07 3:34 PM, Jim C. Nasby [EMAIL PROTECTED] wrote: On Tue, May 15, 2007 at 10:25:35AM -0700, Jeff Davis wrote: On Tue, 2007-05-15 at 10:42 +0100, Heikki Linnakangas wrote: Luke Lonergan wrote: 32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2 cache effect. How about using 256/blocksize? Sounds reasonable. We need to check the effect on the synchronized scans, though. I am a little worried that there will be greater differences in position as the number of scans increase. If we have only 8 buffers and several scans progressing, will they all be able to stay within a few buffers of eachother at any given time? Also, with 8 buffers, that means each scan must report every 4 pages at most (and maybe every page), which increases lock contention (the new design Heikki and I discussed requires a lock every time a backend reports its position). Given that spoiling the L2 cache is a trivial cost compared to extra physical IO, ISTM we should go with a largish ring for sync scans. What do you think would be the ideal size? 32 buffers? ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Lack of urgency in 8.3 reviewing
Bruce Momjian wrote: It is all on the developer roadmap page: http://momjian.us/cgi-bin/pgpatches There is also a slightly more readable one here: http://developer.postgresql.org/index.php/Todo:PatchStatus Joshua D. Drake --- Guido Barosio wrote: Bruce, where can I take a look at the patch list in order to find out if I can be of some help? Regards, g.- On 5/16/07, Bruce Momjian [EMAIL PROTECTED] wrote: In talking to people who are assigned to review patches or could review patches, I often get the reply, Oh, yea, I need to do that. Folks, we are six weeks into feature freeze and have made slim progress on getting patches reviewed and applied. As I stated earlier, we are now looking at August/September for beta, but that might be pushed back even later if we don't get more progress. It seems there is a lot of reliance on Tom to get the patches applied, but I don't think that is fair or reasonable. I think we need more urgency on the part of everyone to make faster progress. Patch reviewers and committers need to take more initiative to get things done rather than wait for some external force to prompt them. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Guido Barosio --- http://www.globant.com [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Not ready for 8.3
Jim C. Nasby wrote: On Wed, May 16, 2007 at 04:34:56PM +0100, Dave Page wrote: How much visibility do we have into the mhonarc database? We should be able to come up with a simple redirector that would point the old mhonarc URLs to URLs for the new system... coughdatabase?/cough And here I thought the reason we used tho POS was because it was the only archiver that used PostgreSQL as it's backend... You're thinking of the old search engine. It's a file system. It simply generates HTML (or in our case) PHP files from each message in an mbox. That's one of the reasons for the monthly break - without it, the directories would be unusably full of files. I the current URLs represent the month, and the ID of the message as it comes out of the mbox I believe. We could probably write a script to dump a list of message IDs, directories and mbox positions I imagine, and then import that into a new database. Yeah, if the files still resemble real emails then we can probably come up with a way to pull the data in. We have all the mbox files, so we can import them from there as raw messages. It's been on my list to rewrite the whole archive system for a while for various reasons. There is quite a bit of crossover with the patch tracker I proposed so I was hoping to look at both together. Let me know when you start on that... Roger. /D ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Lack of urgency in 8.3 reviewing
Bruce Momjian wrote: In talking to people who are assigned to review patches or could review patches, I often get the reply, Oh, yea, I need to do that. Folks, we are six weeks into feature freeze and have made slim progress on getting patches reviewed and applied. As I stated earlier, we are now looking at August/September for beta, but that might be pushed back even later if we don't get more progress. It seems there is a lot of reliance on Tom to get the patches applied, but I don't think that is fair or reasonable. I think we need more urgency on the part of everyone to make faster progress. Patch reviewers and committers need to take more initiative to get things done rather than wait for some external force to prompt them. I at least feel uncomfortable about reviewing code that deals with areas I have not touched much, and where I feel the author probably knows a lot more than me. The chance of my catching errors/problems in such a case is much lower. Looking at the list on the wiki, that rules out most of the things that don't have a reviewer already listed. I can look at the following items: . UTF8 text matching performance improvements . concurrent psql . PL/PSM If Tom gets around to per-function search paths I'll look at that too, but I don't actually recall seeing a patch for that. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Not ready for 8.3
Dave Page wrote: I the current URLs represent the month, and the ID of the message as it comes out of the mbox I believe. We could probably write a script to dump a list of message IDs, directories and mbox positions I imagine, and then import that into a new database. Yeah, if the files still resemble real emails then we can probably come up with a way to pull the data in. We have all the mbox files, so we can import them from there as raw messages. yeah, that's clearly the best source to work from. It's *possible* work from the mhonarc files (I've done it before), but it's more work. It's been on my list to rewrite the whole archive system for a while for various reasons. There is quite a bit of crossover with the patch tracker I proposed so I was hoping to look at both together. Let me know when you start on that... Roger. Same here - I've done something similar (off mhonarc files and in much smaller scale) before, and I'm definitely interested in helping out. //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Invalid magic number in log file?
Alvaro Herrera [EMAIL PROTECTED] writes: Maybe the thing to do here is to disallow running a postmaster when the data dir is using a different WAL magic (forcing you to pg_resetxlog or initdb). Which, curiously enough, is exactly what it does ... I'm not particularly concerned with the user-friendliness of the error message, since this case would never arise for normal users (the PG_VERSION check would fire first in any cross-version compatibility situation). It only matters for hackers tracking CVS HEAD. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Lack of urgency in 8.3 reviewing
Joshua D. Drake wrote: Bruce Momjian wrote: It is all on the developer roadmap page: http://momjian.us/cgi-bin/pgpatches There is also a slightly more readable one here: http://developer.postgresql.org/index.php/Todo:PatchStatus note that http://momjian.us/cgi-bin/pgpatches contains a link to the wiki site at the very top ;-) Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Lack of urgency in 8.3 reviewing
Andrew Dunstan wrote: Bruce Momjian wrote: In talking to people who are assigned to review patches or could review patches, I often get the reply, Oh, yea, I need to do that. Folks, we are six weeks into feature freeze and have made slim progress on getting patches reviewed and applied. As I stated earlier, we are now looking at August/September for beta, but that might be pushed back even later if we don't get more progress. It seems there is a lot of reliance on Tom to get the patches applied, but I don't think that is fair or reasonable. I think we need more urgency on the part of everyone to make faster progress. Patch reviewers and committers need to take more initiative to get things done rather than wait for some external force to prompt them. I at least feel uncomfortable about reviewing code that deals with areas I have not touched much, and where I feel the author probably knows a lot more than me. The chance of my catching errors/problems in such a case is much lower. Yep, that is part of our problem, but even items people have already said they _can_ review have shown little progress. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Lack of urgency in 8.3 reviewing
Andrew Dunstan wrote: Bruce Momjian wrote: In talking to people who are assigned to review patches or could review patches, I often get the reply, Oh, yea, I need to do that. Folks, we are six weeks into feature freeze and have made slim progress on getting patches reviewed and applied. As I stated earlier, we are now looking at August/September for beta, but that might be pushed back even later if we don't get more progress. It seems there is a lot of reliance on Tom to get the patches applied, but I don't think that is fair or reasonable. I think we need more urgency on the part of everyone to make faster progress. Patch reviewers and committers need to take more initiative to get things done rather than wait for some external force to prompt them. I at least feel uncomfortable about reviewing code that deals with areas I have not touched much, and where I feel the author probably knows a lot more than me. The chance of my catching errors/problems in such a case is much lower. Looking at the list on the wiki, that rules out most of the things that don't have a reviewer already listed. I can look at the following items: . UTF8 text matching performance improvements . concurrent psql . PL/PSM added your name to the list in the wiki If Tom gets around to per-function search paths I'll look at that too, but I don't actually recall seeing a patch for that. no - tom said in is patch triage mail that this code is not even written yet but he still wants to see it in 8.3 ... Stefan ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Lack of urgency in 8.3 reviewing
What about a mentoring schema in order to push up the gap that represents catching up with cases like the one Andrew posted? By the way, being a patch reviewer doesn't represents also to be able to find out potential problems in the code, which may have nothing to do with the patch functionality? g.- On 5/16/07, Bruce Momjian [EMAIL PROTECTED] wrote: Andrew Dunstan wrote: Bruce Momjian wrote: In talking to people who are assigned to review patches or could review patches, I often get the reply, Oh, yea, I need to do that. Folks, we are six weeks into feature freeze and have made slim progress on getting patches reviewed and applied. As I stated earlier, we are now looking at August/September for beta, but that might be pushed back even later if we don't get more progress. It seems there is a lot of reliance on Tom to get the patches applied, but I don't think that is fair or reasonable. I think we need more urgency on the part of everyone to make faster progress. Patch reviewers and committers need to take more initiative to get things done rather than wait for some external force to prompt them. I at least feel uncomfortable about reviewing code that deals with areas I have not touched much, and where I feel the author probably knows a lot more than me. The chance of my catching errors/problems in such a case is much lower. Yep, that is part of our problem, but even items people have already said they _can_ review have shown little progress. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- Guido Barosio --- http://www.globant.com [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Not ready for 8.3
Andrew Dunstan wrote: Josh Berkus wrote: I think that may be where we're heading. In that case, we may need to talk about branching earlier so that developers can work on the new version who are frozen out of the in-process one. I've argued this in the past. But be aware that it will make more work for committers. It is very far from cost-free. I hate to bring up the CMS flamewar again, but IMHO the one advantage the distributed systems (Git, Monotone, Darcs, etc) have over CVS subversion is that they push this branch management cost down to the developer who wants a branch - rather from the guys maintaining the official CMS. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Managing the community information stream
Bruce Momjian [EMAIL PROTECTED] writes: Alvaro Herrera wrote: This is even better than our archives due to the problem that the archives don't have links to messages crossing month boundaries. Have you noticed that if you go to the archives, some discussions appear truncated at a point, but you can go to the archive for the next month and it continues there? I find that artifact somewhat annoying. The bug report would continue receiving the CC'ed mails, so it would record them all in a single place. Not crossing month boundaries is super-annoying. Indeed, but that should be fixed. I can't imagine that one presumably-fixable deficiency is grounds for changing our entire discussion infrastructure. Or do you think we will find something else that has no deficiencies of its own? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Managing the community information stream
Bruce Momjian [EMAIL PROTECTED] writes: Alvaro Herrera wrote: This is even better than our archives due to the problem that the archives don't have links to messages crossing month boundaries. Have you noticed that if you go to the archives, some discussions appear truncated at a point, but you can go to the archive for the next month and it continues there? I find that artifact somewhat annoying. The bug report would continue receiving the CC'ed mails, so it would record them all in a single place. Not crossing month boundaries is super-annoying. Indeed, but that should be fixed. I can't imagine that one presumably-fixable deficiency is grounds for changing our entire discussion infrastructure. Or do you think we will find something else that has no deficiencies of its own? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Managing the community information stream
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Alvaro Herrera wrote: This is even better than our archives due to the problem that the archives don't have links to messages crossing month boundaries. Have you noticed that if you go to the archives, some discussions appear truncated at a point, but you can go to the archive for the next month and it continues there? I find that artifact somewhat annoying. The bug report would continue receiving the CC'ed mails, so it would record them all in a single place. Not crossing month boundaries is super-annoying. Indeed, but that should be fixed. I can't imagine that one presumably-fixable deficiency is grounds for changing our entire discussion infrastructure. Or do you think we will find something else that has no deficiencies of its own? Very much agreed, however, changing how it's done might open up ways to change other things for the better - things we can't do now. But getting rid of that annoying thing alone does not change anything else, or require changing of anything else. //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Not ready for 8.3
On 5/16/07, Joshua D. Drake [EMAIL PROTECTED] wrote: I care. I want a professional easy to understand and easy to maintain that doesn't cause potential conflict with future and past development syntax. You've just tempted me to create embedded SQL in assembly :) -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 3rd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Not ready for 8.3
Magnus Hagander wrote: It's been on my list to rewrite the whole archive system for a while for various reasons. There is quite a bit of crossover with the patch tracker I proposed so I was hoping to look at both together. Let me know when you start on that... Roger. Same here - I've done something similar (off mhonarc files and in much smaller scale) before, and I'm definitely interested in helping out. Is everyone aware of this system that runs on a well-known open-source database? http://www.archiveopteryx.org/ I've used it in a small way, and while I don't claim to have looked at it in detail it seems to pretty much do what it claims to. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Not ready for 8.3
Richard Huxton wrote: Magnus Hagander wrote: It's been on my list to rewrite the whole archive system for a while for various reasons. There is quite a bit of crossover with the patch tracker I proposed so I was hoping to look at both together. Let me know when you start on that... Roger. Same here - I've done something similar (off mhonarc files and in much smaller scale) before, and I'm definitely interested in helping out. Is everyone aware of this system that runs on a well-known open-source database? http://www.archiveopteryx.org/ I've used it in a small way, and while I don't claim to have looked at it in detail it seems to pretty much do what it claims to. Yeah, I looked at it in the past. The database storage part is actually pretty simple - it's the web front end that's going to take more effort, and thats what that product doesn't do (or if it does, it's a secondary function they don't shout about). Regards, Dave. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Not ready for 8.3
Dave Page wrote: Richard Huxton wrote: Magnus Hagander wrote: It's been on my list to rewrite the whole archive system for a while for various reasons. There is quite a bit of crossover with the patch tracker I proposed so I was hoping to look at both together. Let me know when you start on that... Roger. Same here - I've done something similar (off mhonarc files and in much smaller scale) before, and I'm definitely interested in helping out. Is everyone aware of this system that runs on a well-known open-source database? http://www.archiveopteryx.org/ I've used it in a small way, and while I don't claim to have looked at it in detail it seems to pretty much do what it claims to. Yeah, I looked at it in the past. The database storage part is actually pretty simple - it's the web front end that's going to take more effort, and thats what that product doesn't do (or if it does, it's a secondary function they don't shout about). It's supposed to have something in the latest version, I think. I used it as backing store for a small workflow app, so I've got some simple views/functions I added and PHP code (cake-php framework) for displaying messages if it'll be of any use. My one concern with the schema was that there didn't seem to be a way to partition archives (e.g. by year) to make maintenance a little simpler for large databases. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Testing concurrent psql
Jim C. Nasby [EMAIL PROTECTED] writes: On Wed, May 16, 2007 at 09:43:36AM -0400, Gregory Stark wrote: I seem to recall there was a way to construct scenarios that returned multiple result sets via rules but I don't know how to arrange that. Anyone remember? An ALSO SELECT rule? It gives you an error. Perhaps it once was allowed and found to cause problems? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Seq scans roadmap
On Wed, 2007-05-16 at 10:31 -0700, Luke Lonergan wrote: I think the analysis on syncscan needs to take the external I/O cache into account. I believe it is not necessary or desirable to keep the scans in lock step within the PG bufcache. I partially agree. I don't think we need any huge amount of shared buffers for the scans to use, and the scans should be able to catch up by using the OS buffer cache (which is still faster than fetching from disk). However, as I said before, I'm worried that, if the ring is too small, it might not work to my expectations. I will try to test this to eliminate my doubts. The main benefit of a sync scan will be the ability to start the scan where other scans have already filled the I/O cache with useful blocks. This will require some knowledge of the size of the I/O cache by the syncscan logic, but that's where the largest amount of I/O cache memory (by far) is located. I don't think it's necessarily the largest by far. However, it may be the largest. If you mean that the main benefit of sync scans is to make use of blocks that happen to be in cache before the scan began, I disagree. I think that's a possible benefit, but I was unable to show any huge benefit in my tests (someone may be able to on different hardware with different test cases). The main benefits that I see are: (1) reduce total number of blocks read from disk by making use of blocks as they are read by another concurrent seqscan. (2) eliminate the need for random I/O on concurrent sequential scans. I like the idea of using already-in-cache blocks. The code is there and it works, but I just didn't see the benefits yet. After I get any issues with this patch resolved and the reviewers are satisfied, I'd like to work on it. Regards, Jeff Davis ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Lack of urgency in 8.3 reviewing
I think one of the things that is preventing urgency is that everyone knows we have large patches unapplied, so they know that their lack of activity is not holding up the release. Any way around that? --- bruce wrote: In talking to people who are assigned to review patches or could review patches, I often get the reply, Oh, yea, I need to do that. Folks, we are six weeks into feature freeze and have made slim progress on getting patches reviewed and applied. As I stated earlier, we are now looking at August/September for beta, but that might be pushed back even later if we don't get more progress. It seems there is a lot of reliance on Tom to get the patches applied, but I don't think that is fair or reasonable. I think we need more urgency on the part of everyone to make faster progress. Patch reviewers and committers need to take more initiative to get things done rather than wait for some external force to prompt them. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Testing concurrent psql
Greg Stark [EMAIL PROTECTED] writes: Jim C. Nasby [EMAIL PROTECTED] writes: On Wed, May 16, 2007 at 09:43:36AM -0400, Gregory Stark wrote: I seem to recall there was a way to construct scenarios that returned multiple result sets via rules but I don't know how to arrange that. Anyone remember? An ALSO SELECT rule? It gives you an error. Not if you do it correctly. regression=# create table foo(f1 int); CREATE TABLE regression=# create rule r1 as on insert to foo do also regression-# ( select 1; select 2; select 3 ); CREATE RULE regression=# insert into foo values(42); ?column? -- 3 (1 row) INSERT 0 1 regression=# This shows BTW that PQexec throws away all but the last select-result; but they are all delivered to the client. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] Full page writes improvement, code update
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Koichi Suzuki wrote:
Hi,
As replied to Patch queue triage by Tom, here's simplified patch to
mark WAL record as compressable, with no increase in WAL itself.
Compression/decompression commands will be posted separately to PG
Foundary for further review.
---
As suggested by Tom, I agree that WAL should not include both full
page write and incremental (logical) log. I began to examine WAL
record format to see if incremental log can be made from full page
writes. It will be okay even before 8.4, if simplified patch to the
core is accepted. I will post simplified patch to the core as follows:
1. Mark the flag to indicate that the WAL record is compressable from
full page writes to incremental log. This flag will be set if
a) It is not written during the hot backup, and
b) Archive command is active, and
c) WAL contains full page writes, and
d) full_page_writes=on.
No logical log will be written to WAL in this case, and
2. During recovery, xl_tot_len check will be skipped for compressed WAL
records.
Please note that new GUC is not needed in this patch.
With this patch, compress/decompress can be developped outside the core.
I'd be very grateful if this patch can be considered again.
Best Regards;
--
-
Koichi Suzuki
diff -cr pgsql_org/src/backend/access/transam/xlog.c
pgsql/src/backend/access/transam/xlog.c
*** pgsql_org/src/backend/access/transam/xlog.c 2007-05-02
15:56:38.0 +0900
--- pgsql/src/backend/access/transam/xlog.c 2007-05-07 16:30:38.0
+0900
***
*** 837,842
--- 837,854
return RecPtr;
}
+ /*
+ * If online backup is not in progress and WAL archiving is active, mark
+ * backup blocks removable if any.
+ * This mark will be referenced during archiving to remove needless
backup
+ * blocks in the record and compress WAL segment files.
+ */
+ if (XLogArchivingActive() fullPageWrites
+ (info XLR_BKP_BLOCK_MASK) !Insert-forcePageWrites)
+ {
+ info |= XLR_BKP_REMOVABLE;
+ }
+
/* Insert record header */
record = (XLogRecord *) Insert-currpos;
***
*** 2738,2750
blk += blen;
}
! /* Check that xl_tot_len agrees with our calculation */
! if (blk != (char *) record + record-xl_tot_len)
{
! ereport(emode,
! (errmsg(incorrect total length in record at
%X/%X,
! recptr.xlogid,
recptr.xrecoff)));
! return false;
}
/* Finally include the record header */
--- 2750,2778
blk += blen;
}
! /*
! * If physical log has not been removed, check the length to see
! * the following.
! * - No physical log existed originally,
! * - WAL record was not removable because it is generated during
! * the online backup,
! * - Cannot be removed because the physical log spanned in
! * two segments.
! * The reason why we skip the length check on the physical log removal
is
! * that the flag XLR_SET_BKB_BLOCK(0..2) is reset to zero and it
prevents
! * the above loop to proceed blk to the end of the record.
! */
! if (!(record-xl_info XLR_BKP_REMOVABLE) ||
! record-xl_info XLR_BKP_BLOCK_MASK)
{
! /* Check that xl_tot_len agrees with our calculation */
! if (blk != (char *) record + record-xl_tot_len)
! {
! ereport(emode,
! (errmsg(incorrect total length in
record at %X/%X,
! recptr.xlogid,
recptr.xrecoff)));
! return false;
! }
}
/* Finally include the record header */
pgsql/src/backend/access/transam???: xlog.c.orig
diff -cr pgsql_org/src/include/access/xlog.h pgsql/src/include/access/xlog.h
*** pgsql_org/src/include/access/xlog.h 2007-01-06 07:19:51.0
+0900
--- pgsql/src/include/access/xlog.h 2007-05-07 16:30:38.0 +0900
***
*** 66,73
/*
* If we backed up any disk blocks with the XLOG record, we use flag bits in
* xl_info to signal it. We support backup of up to 3 disk blocks per XLOG
! * record. (Could support 4 if we cared to dedicate all the xl_info bits
for
! * this purpose; currently bit 0 of xl_info is unused and available.)
*/
#define XLR_BKP_BLOCK_MASK
Re: [HACKERS] Lack of urgency in 8.3 reviewing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Wednesday, May 16, 2007 20:09:44 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: I think one of the things that is preventing urgency is that everyone knows we have large patches unapplied, so they know that their lack of activity is not holding up the release. Any way around that? Set a fixed date (ie. 3 weeks) and whatever isn't in gets punted to 8.4 ... if that means those 'large patches' don't get applied, so be it ... --- bruce wrote: In talking to people who are assigned to review patches or could review patches, I often get the reply, Oh, yea, I need to do that. Folks, we are six weeks into feature freeze and have made slim progress on getting patches reviewed and applied. As I stated earlier, we are now looking at August/September for beta, but that might be pushed back even later if we don't get more progress. It seems there is a lot of reliance on Tom to get the patches applied, but I don't think that is fair or reasonable. I think we need more urgency on the part of everyone to make faster progress. Patch reviewers and committers need to take more initiative to get things done rather than wait for some external force to prompt them. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGS6Oa4QvfyHIvDvMRAtwrAJwLasoe+jiuAqvT4Dny/dndYvKxUgCcDxiX x+vMZlGMy06D9NOfzltG/ks= =PL+8 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Lack of urgency in 8.3 reviewing
On 5/16/07, Marc G. Fournier [EMAIL PROTECTED] wrote: Set a fixed date (ie. 3 weeks) and whatever isn't in gets punted to 8.4 ... if that means those 'large patches' don't get applied, so be it ... I disagree with that approach. Larger more complex patches required much more work and effort than small, simple ones. Not only do I think it's unfair to the authors who spent considerably more time on their work, but I think it also sets a bad precedent for future work; saying, in short, that if you want to make large strides to improve PostgreSQL, and you followed the community development process, you're still potentially last in line for review. -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 3rd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Not ready for 8.3
On Wed, May 16, 2007 at 07:48:10PM +0200, Magnus Hagander wrote: Dave Page wrote: I the current URLs represent the month, and the ID of the message as it comes out of the mbox I believe. We could probably write a script to dump a list of message IDs, directories and mbox positions I imagine, and then import that into a new database. Yeah, if the files still resemble real emails then we can probably come up with a way to pull the data in. We have all the mbox files, so we can import them from there as raw messages. yeah, that's clearly the best source to work from. It's *possible* work from the mhonarc files (I've done it before), but it's more work. We'd want the old URLs to be redirected too, so at some point we'll have to deal with mhonarc. -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Lack of urgency in 8.3 reviewing
Jonah H. Harris wrote: On 5/16/07, Marc G. Fournier [EMAIL PROTECTED] wrote: Set a fixed date (ie. 3 weeks) and whatever isn't in gets punted to 8.4 ... if that means those 'large patches' don't get applied, so be it ... I disagree with that approach. Larger more complex patches required much more work and effort than small, simple ones. Not only do I think it's unfair to the authors who spent considerably more time on their work, but I think it also sets a bad precedent for future work; saying, in short, that if you want to make large strides to improve PostgreSQL, and you followed the community development process, you're still potentially last in line for review. Yep. We lose a lot of credibility if we did that. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Not ready for 8.3
On Wed, May 16, 2007 at 09:32:44PM +0100, Richard Huxton wrote: Dave Page wrote: Richard Huxton wrote: Magnus Hagander wrote: It's been on my list to rewrite the whole archive system for a while for various reasons. There is quite a bit of crossover with the patch tracker I proposed so I was hoping to look at both together. Let me know when you start on that... Roger. Same here - I've done something similar (off mhonarc files and in much smaller scale) before, and I'm definitely interested in helping out. Is everyone aware of this system that runs on a well-known open-source database? http://www.archiveopteryx.org/ I've used it in a small way, and while I don't claim to have looked at it in detail it seems to pretty much do what it claims to. Yeah, I looked at it in the past. The database storage part is actually pretty simple - it's the web front end that's going to take more effort, and thats what that product doesn't do (or if it does, it's a secondary function they don't shout about). It's supposed to have something in the latest version, I think. I used it as backing store for a small workflow app, so I've got some simple views/functions I added and PHP code (cake-php framework) for displaying messages if it'll be of any use. My one concern with the schema was that there didn't seem to be a way to partition archives (e.g. by year) to make maintenance a little simpler for large databases. Luckily I happen to know of a database that would make that transparent to the app... But I tend to agree with Dave; the storage part is pretty easy. If we've still got to write our own front-end ISTM it'd be better to just make it exactly what we want... -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Stats not updated after rollback -- autovacuum confused.
This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Dawid Kuroczko wrote: Hello, I have a system where there are mostly COPYs, which insert data into a table. Ocasionally a COPY will fail (and thus, dead rows appear), but as far as I can tell ROLLBACK is not reflected anywhere in the pg_stats_user_tables. And since there are no rows n_tup_upd or n_tup_del, therefore autovacuum will not fire for that table. I see two possible solutions: 1) let rollback increment both n_tup_ins and n_tup_del (or maybe n_tup_upd, at least)? This would be a good safeguard, I guess. 2) ANALYZE is able to see wether table is accumulating dead rows. It might be a good idea to make ANALYZE able hint autovacuum that some tables need VACUUM (that they exceed limits set for autovacuum). The 2nd point could be a TODO item, perhaps? Something like: When ANALYZE runs, make it note removable dead rows and non-removable dead rows. If removable dead rows exceed some threshold, hint autovacuum at that table. Regards, Dawid ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] temporal variants of generate_series()
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Jim Nasby wrote:
On May 6, 2007, at 8:07 PM, Tom Lane wrote:
Jim Nasby [EMAIL PROTECTED] writes:
Also, what would be the appropriate way to put this into initdb?
You seem to have missed a step here, which is to convince people that
these belong in core at all. So far I've not even seen an argument
that
would justify putting them in contrib.
These are all examples of using generate series plus additional math
to generate a series of dates/timestamps:
http://archives.postgresql.org/pgsql-general/2007-01/msg01292.php
http://archives.postgresql.org/pgsql-sql/2006-02/msg00249.php
http://archives.postgresql.org/pgsql-general/2005-06/msg01254.php
http://archives.postgresql.org/pgsql-sql/2007-03/msg00093.php
http://archives.postgresql.org/pgsql-novice/2007-01/msg2.php
http://archives.postgresql.org/pgsql-sql/2006-03/msg00391.php
http://archives.postgresql.org/pgsql-hackers/2006-09/msg00330.php
That's from the first page of search results for 'generate_series
timestamp'.
FWIW, I could also make use of this in some of my code.
If they *were* of sufficiently
wide use to justify putting them into core, a more efficient
implementation would probably be expected.
Ok, I'll look into a C version, but why do SQL functions have such a
high overhead? I'm seeing an SQL function taking ~2.6x longer than
the equivalent code run directly in a query. With 100 days, the
difference drops a bit to ~2.4x. (this is on HEAD from a few months ago)
This is on my MacBook Pro with the Jean-Pierre's version of
generate_series:
decibel=# select count(*) from generate_series(now(),now()+'10
days'::interval,'1'::interval);
Time: 1851.407 ms
decibel=# select count(*) from generate_series(1,86400*10);
Time: 657.894 ms
decibel=# select count(*) from (select now() + (generate_series
(1,86400*10) * '1 second'::interval)) a;
Time: 733.592 ms
decibel=# select count(*) from (select 'epoch'::timestamptz + s.i *
'1 second'::interval AS generate_series from generate_series(extract
('epoch' from now())::bigint, extract('epoch' from now()+'10
days'::interval)::bigint, extract('epoch' from
'1'::interval)::bigint) s(i)) a;
Time: 699.606 ms
--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] BufFileWrite across MAX_PHYSICAL_FILESIZE boundary
This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Tom Lane wrote: Kurt Harriman [EMAIL PROTECTED] writes: Just noticed buffile.c:292 doesn't look quite right where BufFileDumpBuffer calls FileWrite: bytestowrite = FileWrite(thisfile, file-buffer, bytestowrite); It looks as though it would write the same data each time the loop is iterated. Would this be better? bytestowrite = FileWrite(thisfile, file-buffer + wpos, bytestowrite); Yeah, I think you're right. We've probably not seen this because in most usages the buffer is always block-aligned, but it looks possible for tuplestore.c to get out of alignment if its concurrent write/read feature is exercised just so. Do you want to try demonstrating the bug with a smaller-than-normal setting of MAX_PHYSICAL_FILESIZE? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Lack of urgency in 8.3 reviewing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Wednesday, May 16, 2007 21:04:27 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Jonah H. Harris wrote: On 5/16/07, Marc G. Fournier [EMAIL PROTECTED] wrote: Set a fixed date (ie. 3 weeks) and whatever isn't in gets punted to 8.4 ... if that means those 'large patches' don't get applied, so be it ... I disagree with that approach. Larger more complex patches required much more work and effort than small, simple ones. Not only do I think it's unfair to the authors who spent considerably more time on their work, but I think it also sets a bad precedent for future work; saying, in short, that if you want to make large strides to improve PostgreSQL, and you followed the community development process, you're still potentially last in line for review. Yep. We lose a lot of credibility if we did that. So, we lose no credibility if we sit in feature freeze indefinitely, with no direction, while we wait for reviewers to finish reviewing? - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGS7E64QvfyHIvDvMRAmW9AJ0Q75300Atm6nFOFT+1YfMRCtrcdQCffW2l htlQKO5dZRC2k2lWPGkjGvk= =BhsF -END PGP SIGNATURE- ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Lack of urgency in 8.3 reviewing
Marc G. Fournier wrote: Jonah H. Harris wrote: On 5/16/07, Marc G. Fournier [EMAIL PROTECTED] wrote: Set a fixed date (ie. 3 weeks) and whatever isn't in gets punted to 8.4 ... if that means those 'large patches' don't get applied, so be it ... I disagree with that approach. Larger more complex patches required much more work and effort than small, simple ones. Not only do I think it's unfair to the authors who spent considerably more time on their work, but I think it also sets a bad precedent for future work; saying, in short, that if you want to make large strides to improve PostgreSQL, and you followed the community development process, you're still potentially last in line for review. Yep. We lose a lot of credibility if we did that. So, we lose no credibility if we sit in feature freeze indefinitely, with no direction, while we wait for reviewers to finish reviewing? Well, if we stay indefinitely, then we have no release and we close up the project. I think eventually we will release. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Lack of urgency in 8.3 reviewing
Marc G. Fournier wrote: I disagree with that approach. Larger more complex patches required much more work and effort than small, simple ones. Not only do I think it's unfair to the authors who spent considerably more time on their work, but I think it also sets a bad precedent for future work; saying, in short, that if you want to make large strides to improve PostgreSQL, and you followed the community development process, you're still potentially last in line for review. Yep. We lose a lot of credibility if we did that. So, we lose no credibility if we sit in feature freeze indefinitely, with no direction, while we wait for reviewers to finish reviewing? *cough* that is hardly what is happening. Just today we had two people step up and commit to help reviewing. One of them is a committer (AndrewD). I believe under no uncertain terms, that if we continual proactive communication over the next several weeks that we will see a marked and steady improvement to our existing status. Let's keep this on earth shall we. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Testing concurrent psql
Tom Lane [EMAIL PROTECTED] writes: Greg Stark [EMAIL PROTECTED] writes: Jim C. Nasby [EMAIL PROTECTED] writes: On Wed, May 16, 2007 at 09:43:36AM -0400, Gregory Stark wrote: I seem to recall there was a way to construct scenarios that returned multiple result sets via rules but I don't know how to arrange that. Anyone remember? An ALSO SELECT rule? It gives you an error. Not if you do it correctly. Ah, I was trying to do a ON SELECT DO ALSO SELECT I now get this using the patched version, I can't see this divergence as a bad thing though: postgres=# insert into foo values(42); ?column? -- 1 (1 row) ?column? -- 2 (1 row) ?column? -- 3 (1 row) INSERT 0 1 It seems to work fine asynchronously too as libpq doesn't report the response as having been received until all three result sets are there anyways, so it doesn't require any special handling. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Lack of urgency in 8.3 reviewing
On 5/16/07, Bruce Momjian [EMAIL PROTECTED] wrote: Yep, that is part of our problem, but even items people have already said they _can_ review have shown little progress. For complex patches, it might help to identify and associate a core/senior community member in the early stages of design and development. This member will then have enough insight into the work as it progresses and can him/herself act as a committer and/or help the committer later. We developed HOT in a phased manner. Had each of the incremental patches been reviewed, I think the review process would have been much easier and less painful. Also that would have helped us to identify any obvious bugs/show stoppers early in the cycle and might have even generated better ideas to do things differently. Having said that, I fully understand the difficulties of the committers who need to put substantial efforts in understanding the patch and guage its overall impact. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] Not ready for 8.3
On Tue, 15 May 2007, Jim C. Nasby wrote: Speaking of reviewers... should we put some thought into how we can increase the number of people who can review code? It seems that's one of our biggest bottlenecks... Having recently dragged myself from never seeing the code before to being able to provide an early review to help the committers out, I can tell you a few things that would have sped up that process and therefore improve the odds more people will navigate the trail. My main difficulty was figuring out a workable way to build a local mirror of the code (so I could get off-line diffs), keep it in sync with the development tree, while branching out working areas to evaluate patches or do new development in. A good example walkthrough of how to do that using standard tools would be a big help. Hint: if you suggest CVsup I'll smack you. Overall, though, I don't think there would have been any substitute for what I learned by putting together my own small patches, so in some respects thinking about how to lower the bar for doing that would also ultimately expand the review pool. The main issues I had as a newcomer to the codebase was getting data in/out of the new code I added that was buried inside the system. Here are some examples of what I kept hoping to find documentation on: -Examples and usage guidelines for eLog and eReport (the stuff in the FAQ needs some more meat) -How to add a GUC variable. Once I've got that, now I can adjust the code in real-time just by updating it. -How to add to the statistics for some part of the system that track a new variable and follow how that moves through the collector process. If you put people into a position where they easily can poke data in at one end, see how it rattles around inside the engine by logging, and get some statistics on the result, now you've got someone who can build their own simple patches without being so frustrated. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] BufFileWrite across MAX_PHYSICAL_FILESIZE boundary
Bruce Momjian wrote: This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold Huh, no, this is a bug and should be fixed right away. --- Tom Lane wrote: Kurt Harriman [EMAIL PROTECTED] writes: Just noticed buffile.c:292 doesn't look quite right where BufFileDumpBuffer calls FileWrite: bytestowrite = FileWrite(thisfile, file-buffer, bytestowrite); It looks as though it would write the same data each time the loop is iterated. Would this be better? bytestowrite = FileWrite(thisfile, file-buffer + wpos, bytestowrite); Yeah, I think you're right. We've probably not seen this because in most usages the buffer is always block-aligned, but it looks possible for tuplestore.c to get out of alignment if its concurrent write/read feature is exercised just so. Do you want to try demonstrating the bug with a smaller-than-normal setting of MAX_PHYSICAL_FILESIZE? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
