Re: [HACKERS] Copyright
Mark, After all - you wouldn't want somebody to say that PostgreSQL copied them, because the date was later, would you? :-) I think it won't be hard to understand what Copyright (c) 1996-2006 means ;) Best regards -- Matteo Beccati http://phpadsnew.com http://phppgads.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] problem with large maintenance_work_mem settings and
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: forgot to mention that this is 8.1.3 compiled from source. See the discussion starting here: http://archives.postgresql.org/pgsql-hackers/2006-02/msg00590.php I was following this thread - and it was partly a reason why I'm playing with that(the CREATE INDEX on that table finished after about 12 hours with a bit less 2GB for maintenance_work_mem(for comparision it took me only about 2,5hours to create this table) . It would be interesting to try the same test with CVS tip to see if the sorting improvements Simon and I made over the past few weeks help much. playing with CVS tip right now, it is a bit faster for both the initial bulkloading (about 5%) and for the CREATE INDEX itself (11h30min vs 11h54min) though not a dramatic improvement. 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] Copyright
On Sun, Mar 05, 2006 at 12:02:19PM +0100, Matteo Beccati wrote: After all - you wouldn't want somebody to say that PostgreSQL copied them, because the date was later, would you? :-) I think it won't be hard to understand what Copyright (c) 1996-2006 means ;) Maybe... but if it hasn't changed... Of course, that whole line has no legal value in North America anyways... Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Deleting loid from the database
contrib/vacuumlo perhaps? Michael Fuhr wrote: On Sat, Mar 04, 2006 at 12:08:52PM +0530, Md.Abdul Aziz wrote: I am a presently working on a module which enhances postgre to store audio files,while storing the aduido file in the databese i used liod,now the problem is i am able to unlink but still the data is present in the postgre database.can some one suggest me how to delete (not unlink) large objects from the postgre databse. VACUUM FULL pg_largeobject might be what you're looking for, but if you're going to reload the data then an ordinary VACUUM (without FULL) will free the space for re-use by PostgreSQL without shrinking the file (unless the table has no live tuples, in which case the file size will be zeroed). ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Copyright
[EMAIL PROTECTED] wrote: On Sun, Mar 05, 2006 at 12:02:19PM +0100, Matteo Beccati wrote: After all - you wouldn't want somebody to say that PostgreSQL copied them, because the date was later, would you? :-) I think it won't be hard to understand what Copyright (c) 1996-2006 means ;) Maybe... but if it hasn't changed... Of course, that whole line has no legal value in North America anyways... The file is /src/tools/copyright. We don't re-run it for minor releases because there are almost no changes in minor releases. If we did run it, it would change a lot of code for little purpose. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Copyright updated
I have updated the copyrights on all the files in CVS HEAD, and updated the script that does the work. The commit message was too long to be automatically accepted. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.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
[HACKERS] Status of TODO item remove postmaster -o options
Hi, what's the status of this todo item? The relevant thread from 2001 is here: http://archives.postgresql.org/pgsql-hackers/2001-10/thrd6.php#00011 I think we should leave the code alone, and instead document in 7.2 that -o is deprecated (and explain what to do instead), with the intention of removing it in 7.3. I didn't find such a notice in the 7.2 release notes. Markus Bertheau ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Deleting loid from the database
On Sun, Mar 05, 2006 at 09:54:02PM +0800, Christopher Kings-Lynne wrote: contrib/vacuumlo perhaps? vacuumlo only calls lo_unlink(); the data still exists in pg_largeobject due to MVCC. -- Michael Fuhr ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Defining my own operator's precedence
On Sun, Mar 05, 2006 at 05:13:11PM +, Pierre Racine wrote: Hi, I have develop my own data type and my own operators on this data type. I could not find how to tell PostgreSQL which precedence I want to assign to my operator. For example, I want my unary operator ~ to have a higher precedence than my + operator. For now I have to use parenthesis to avoid ambiguity. I would prefer being able to define implicit precedence. Sorry, not possible. :( You pretty much have to choose operators whose precedence matches what you want. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. signature.asc Description: Digital signature
Re: [HACKERS] Copyright
Bruce Momjian pgman@candle.pha.pa.us writes: The file is /src/tools/copyright. We don't re-run it for minor releases because there are almost no changes in minor releases. If we did run it, it would change a lot of code for little purpose. It might make sense to run it once a year in early January, rather than tying the update to releases. In any case we'd only run it on CVS HEAD --- I agree that updating the notices in the back branches would just cause code churn. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Copyright
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: The file is /src/tools/copyright. We don't re-run it for minor releases because there are almost no changes in minor releases. If we did run it, it would change a lot of code for little purpose. It might make sense to run it once a year in early January, rather than tying the update to releases. In any case we'd only run it on CVS HEAD --- I agree that updating the notices in the back branches would just cause code churn. Right. I usually do run it earlier in the year, but was delayed this time. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Status of TODO: postgresql.conf: reset to default when commented
Hi, What's the status of the TODO item Allow commenting of variables in postgresql.conf to restore them to defaults Currently, if a variable is commented out, it keeps the previous uncommented value until a server restarted. I take that to apply to the configuration re-read at SIGHUP? Markus Bertheau ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Status of TODO: postgresql.conf: reset to default when
Markus Bertheau wrote: Hi, What's the status of the TODO item Allow commenting of variables in postgresql.conf to restore them to defaults Currently, if a variable is commented out, it keeps the previous uncommented value until a server restarted. I take that to apply to the configuration re-read at SIGHUP? Right, and it is something we have needed to fix for a while. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Remove vestigial UNION JOIN support?
SQL92 contains a construct table1 UNION JOIN table2, which is defined essentially the same as table1 FULL JOIN table2 ON false --- you get all the rows of table1 null-extended into the table2 columns, and all the rows of table2 null-extended into the table1 columns, and no actual join rows. SQL99, however, deprecates this construct, and it's gone entirely in SQL2003. (They don't say *why* they got rid of it --- is it just because it's redundant, or was there some error in the definition? Date and Darwen obviously don't like it either, but don't say why.) We've got some vestigial support for this thing, but given the subsequent evolution of the standard it seems quite unlikely that we'll ever finish up the implementation. It'd make more sense to spend the work on allowing FULL JOIN ON FALSE, something that we don't accept today but I think wouldn't be much work to fix. So I'm proposing that we remove what's there. In particular we could get rid of the intermediate yylex() function in parser.c, which should save at least a few microseconds during every SQL command. I didn't have a problem with that function when it was put in, because I figured we'd find other cases where we needed extra lookahead, but so far we've not found any so I'm thinking we could save the overhead. Any objections? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] pg.conf re-reading in signal handler or at next return to main loop?
Hi, src/backend/utils/misc/README says If SIGHUP is received, the GUC code rereads the postgresql.conf configuration file (this does not happen in the signal handler, but at next return to main loop; note that it can be executed while within a transaction). SIGHUP_handler() calls ProcessConfigFile() which calls ParseConfigFile() which reads postgresql.conf. For me that means that postgresql.conf in read in the signal handler, which contradicts the claim in the README. Where's my error? Markus Bertheau ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] problem with large maintenance_work_mem settings and
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: samples %symbol name 24915704 96.2170 ltsReleaseBlock 3872651.4955 LogicalTapeRead 1687250.6516 inlineApplySortFunction Hmm ... the comment in ltsReleaseBlock sez /* * Insert blocknum into array, preserving decreasing order (so that * ltsGetFreeBlock returns the lowest available block number). This could * get fairly slow if there were many free blocks, but we don't expect * there to be very many at one time. */ We probably need to tweak things so this doesn't get called during the final merge pass. Looking at it now. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] LDAP auth
Magnus Hagander [EMAIL PROTECTED] writes: Was there ever a decision in the libcurl thread? No, not yet. Personally I'm unconvinced that we should depend on libcurl: if it's going to use openldap to do LDAP work, then the only good reason to use libcurl rather than openldap directly is if there's some clear use-case for libcurl's other features. Which no one had presented AFAIR. I'm still willing to be convinced though. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg.conf re-reading in signal handler or at next return to main loop?
Markus Bertheau [EMAIL PROTECTED] writes: SIGHUP_handler() calls ProcessConfigFile() which calls ParseConfigFile() which reads postgresql.conf. For me that means that postgresql.conf in read in the signal handler, which contradicts the claim in the README. Where's my error? The comment is referring to the control flow in a backend; you're looking at the postmaster's sighup handler, which is different. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Remove vestigial UNION JOIN support?
Tom Lane wrote: SQL92 contains a construct table1 UNION JOIN table2, which is defined essentially the same as table1 FULL JOIN table2 ON false --- you get all the rows of table1 null-extended into the table2 columns, and all the rows of table2 null-extended into the table1 columns, and no actual join rows. SQL99, however, deprecates this construct, and it's gone entirely in SQL2003. (They don't say *why* they got rid of it --- is it just because it's redundant, or was there some error in the definition? Date and Darwen obviously don't like it either, but don't say why.) We've got some vestigial support for this thing, but given the subsequent evolution of the standard it seems quite unlikely that we'll ever finish up the implementation. It'd make more sense to spend the work on allowing FULL JOIN ON FALSE, something that we don't accept today but I think wouldn't be much work to fix. So I'm proposing that we remove what's there. In particular we could get rid of the intermediate yylex() function in parser.c, which should save at least a few microseconds during every SQL command. I didn't have a problem with that function when it was put in, because I figured we'd find other cases where we needed extra lookahead, but so far we've not found any so I'm thinking we could save the overhead. Any objections? Agreed. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.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] ACCESS EXCLUSIVE LOCK
On Thu, Mar 02, 2006 at 06:16:00AM -0800, [EMAIL PROTECTED] wrote: TRUNCATE is another command that takes an access exclusive lock. The whole SP takes about 10 seconds to run total. The TRUNCATE command only takes less than a second. However, the access exclusive lock is held throughout the entire SP, not just during the execution of the TRUNCATE command. Shouldn't TRUNCATE be releasing the lock as soon as it finishes? Nope. Locks stick around until the transaction finishes. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Not so happy with psql's new multiline behavior
On Sat, Mar 04, 2006 at 01:07:15PM -0500, [EMAIL PROTECTED] wrote:
For me, I prefer the interactive behaviour of ZSH. Multiline
statements remain as multiline statements, as they were typed.
One can navigate up and down through the multiline statement
to make alterations. The real beauty of this approach comes up
when doing something such as defining a function. Would you
LOVE the ability to edit the function, in the original form,
as originally typed, allowing you to insert text, and even
newlines into the middle? Effectively you have have a full
text editor, for the last complete series of lines.
snip
Oh no. We typed the wrong command in. It isn't 'a' we want. We want 'ls'.
Hit up-arrow twice, and we get (_ = cursor)
$ f()
{
a
}_
ISTM this is much more useful than the way psql used to work. Don't know
about what's happening in -tip...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Uninstall script errors
Is there any progress on this cleanup? --- Michael Fuhr wrote: On Thu, Mar 02, 2006 at 02:49:13PM -0500, Tom Lane wrote: Michael Fuhr [EMAIL PROTECTED] writes: Would it make sense for DROP TYPE to have some kind of limited cascade so you could drop a type and its I/O functions at the same time, but still get an error if other objects depend on the type? Seems pretty ugly. Maybe the thing to do is have a command that somehow reverts a type to the shell state, whereupon the deletion sequence can be the exact logical inverse of the creation sequence: I thought the same thing after the recent commits involving shell types and got similarly stuck. Do people at least agree that a DROP TYPE that works without CASCADE would be desirable? The rationale is the same as for other DROP commands: drop the object if nothing depends on it, else raise an error. That's impossible now because of the circular dependency between a type and its I/O functions, which requires the use of CASCADE. -- Michael Fuhr ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.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] problem with large maintenance_work_mem settings and
On Sun, 2006-03-05 at 15:15 -0500, Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: samples %symbol name 24915704 96.2170 ltsReleaseBlock 3872651.4955 LogicalTapeRead 1687250.6516 inlineApplySortFunction Hmm ... the comment in ltsReleaseBlock sez /* * Insert blocknum into array, preserving decreasing order (so that * ltsGetFreeBlock returns the lowest available block number). This could * get fairly slow if there were many free blocks, but we don't expect * there to be very many at one time. */ We probably need to tweak things so this doesn't get called during the final merge pass. Looking at it now. OK. I also had a report of poor performance, just isolated to the final merge pass and sucked quite badly; sounds like you've located the cause. Best Regards, Simon Riggs ---(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] Uninstall script errors
On Mon, Mar 06, 2006 at 12:06:28AM -0500, Bruce Momjian wrote: Is there any progress on this cleanup? I'm still planning to work on it unless somebody else wants to, but I was hoping for more feedback on the use of DROP TYPE CASCADE. That seems to be the only way to remove a type due to the circular dependency between the type and its I/O functions, but I'm wary of CASCADE due to its destructive power. Hence my question about whether the uninstall scripts are intended to do forced drops or whether they should fail if dependent objects still exist. Here are some options I'm thinking about: 1. Use DROP TYPE CASCADE and eliminate the drops for operators, functions, etc., because the cascade will drop them anyway. This would make the uninstall scripts simpler than they currently are. 2. Use DROP TYPE CASCADE and keep the drops for support objects. This would result in the fewest number of changes to the current scripts. 3. Use DROP TYPE CASCADE, keep the drops for support objects, and wrap all the drops in a transaction. Certain kinds of dependencies (e.g., an index dependency on an operator class) will cause one of those drops to fail, aborting the transaction before it reaches DROP TYPE CASCADE. This would provide some protection against dropping a type when dependent objects still exist, but it's not foolproof. An unindexed column might depend only on the type itself, so none of the drops would fail and that column would be dropped by the DROP TYPE CASCADE. 4. Wait for a decision about whether DROP TYPE should be modified to have the ability to revert the type to a shell so the I/O functions and finally the type itself can be dropped without using CASCADE. Another possibility, which Tom has already said is pretty ugly, would be a limited cascade whereby DROP TYPE would cascade to the I/O functions but would raise an error if other dependent objects still exist. Comments? Other possibilities? -- Michael Fuhr ---(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
