Re: [HACKERS] Open items
Greg Sabino Mullane wrote: [ There is text before PGP section. ] [ PGP not available, raw data follows ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample file to not use all those commented-out values. Unfortunately, I have not had time to do this. If someone could take of this, it would be most appreciated. See Tom`s notes on some issues involved: http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php Another reason to make sure this makes it into 8.0 is so that the new group of users does not see the format of the file change from 8.0 to 8.1, but can start right away with the more intuitive format. This is too involved a change at this stage. I don't expect postgresql.conf to change any more from 7.4-8.0 than from 8.0-8.1 so I don't see why this is more critical for this release, and it has too many open issues. Tom's post linked above seems to indicate it might be accepted, but I will certainly yield to Core's decision. I'm still hoping someone else will step up to the plate and tackle this: I feel that it would be nice not to confuse a whole new group of users with commented-out defaults which may or may not have a relation to the actual setttings. :) Well, I haven't seen any of the research requested by Tom, and with beta a few days away, I don't see it happening in time. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Tom in Doom3?
On Thu, 5 Aug 2004, Mike Mascari wrote: Christopher Kings-Lynne wrote: Hey Tom, Did you rate a mention in the Doom 3 readme file? :) --- 4. COPYRIGHT INFORMATION DOOM 3 is linked with the JpegLib, copyright (c)1991-1998 Thomas G. Lane/Independent JPEG Group. All rights reserved. --- Cool :) I remember Lamar Owen had found some site which determined the major contributors to open source software and it read something like: 1. UC Berkeley 2. MIT 3. Tom Lane 4. Carnegie Mellon 5. IBM Not to mention his success as a college wrestler: http://www.prep.fairfield.edu/On_Campus/Athletics/Wrestling/12_17/tom_lane.jpg :-) Gavin ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Tom in Doom3?
Gavin Sherry [EMAIL PROTECTED] writes: Not to mention his success as a college wrestler: http://www.prep.fairfield.edu/On_Campus/Athletics/Wrestling/12_17/tom_lane.jpg That one is definitely somebody else ;-) regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Fwd: init scripts and su
Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: I was asked on IRC just why we can't have user=postgres and group=postgres in the postgresql.conf, and simply when we are run as root, switch to that user and group. I should think that running as root up until sometime after we have read postgresql.conf would open up more security issues. It's certainly not a way to close this one... postmaster could use postgres/postgres by default, overridable by command line. Regards, Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL as an application server
Jonathan M. Gardner wrote: Thoughts? Comments? Hasn't Oracle done something like this? Probably this is more suited to -general? I haven't done anything near this. I wonder how much more painful it is to debug the application, put it under version control, etc. Personally, I can't stand editing/debugging application if they are stored in something less flexible than a filesystem. Probably in the far future Postgres can provide an FTP interface like Zope... -- dave ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] More vacuum.c refactoring
[Sorry for the late reply. I'm still struggling to catch up after vacation ...] On Fri, 9 Jul 2004 21:29:52 -0400 (EDT), Bruce Momjian [EMAIL PROTECTED] wrote: Where are we on this, 2x. :-) Here: Tom Lane wrote: Will study these comments later, but it's too late at night here... Servus Manfred ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Quick question regarding tablespaces
On Thu, 1 Jul 2004 22:55:56 -0400, Mike Rylander [EMAIL PROTECTED] wrote: I was thinking of purely tablespace-based random_page_cost, as that variable is tied to the access time of a particular filesystem. Strictly speaking we'd also need tablespace-based sequential_page_cost. Servus Manfred ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] nntp server craziness
Seems the NNTP server went wonky again... TIA! -- Mike Rylander [EMAIL PROTECTED] Indentation is a wonderful form of commentary from programmer to programmer, but its symbology is largely wasted on the computer. We don't tell poets how to format their poetry. -- Larry Wall ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] More vacuum.c refactoring
Manfred Koizar [EMAIL PROTECTED] writes: On Fri, 9 Jul 2004 21:29:52 -0400 (EDT), Bruce Momjian [EMAIL PROTECTED] wrote: Where are we on this, 2x. :-) Here: Tom Lane wrote: Will study these comments later, but it's too late at night here... I haven't had time to review the original, already-applied refactoring, let alone the follow-up. Considering that there's been at least one bug report against the original (unused variable IIRC), I think it does need reviewing. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Open items
Added to TODO: * Remove comments on postgresql.conf variables --- Bruce Momjian wrote: Greg Sabino Mullane wrote: [ There is text before PGP section. ] [ PGP not available, raw data follows ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample file to not use all those commented-out values. Unfortunately, I have not had time to do this. If someone could take of this, it would be most appreciated. See Tom`s notes on some issues involved: http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php Another reason to make sure this makes it into 8.0 is so that the new group of users does not see the format of the file change from 8.0 to 8.1, but can start right away with the more intuitive format. This is too involved a change at this stage. I don't expect postgresql.conf to change any more from 7.4-8.0 than from 8.0-8.1 so I don't see why this is more critical for this release, and it has too many open issues. Tom's post linked above seems to indicate it might be accepted, but I will certainly yield to Core's decision. I'm still hoping someone else will step up to the plate and tackle this: I feel that it would be nice not to confuse a whole new group of users with commented-out defaults which may or may not have a relation to the actual setttings. :) Well, I haven't seen any of the research requested by Tom, and with beta a few days away, I don't see it happening in time. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] nntp server craziness
VM restarted ... On Fri, 6 Aug 2004, Mike Rylander wrote: Seems the NNTP server went wonky again... TIA! -- Mike Rylander [EMAIL PROTECTED] Indentation is a wonderful form of commentary from programmer to programmer, but its symbology is largely wasted on the computer. We don't tell poets how to format their poetry. -- Larry Wall ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Open items
Is this the proper item description? * Remove comments on postgresql.conf variables By removing comments we prevent the confusion that commenting a line returns a modified value to its default, which it does not. --- Bruce Momjian wrote: Added to TODO: * Remove comments on postgresql.conf variables --- Bruce Momjian wrote: Greg Sabino Mullane wrote: [ There is text before PGP section. ] [ PGP not available, raw data follows ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample file to not use all those commented-out values. Unfortunately, I have not had time to do this. If someone could take of this, it would be most appreciated. See Tom`s notes on some issues involved: http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php Another reason to make sure this makes it into 8.0 is so that the new group of users does not see the format of the file change from 8.0 to 8.1, but can start right away with the more intuitive format. This is too involved a change at this stage. I don't expect postgresql.conf to change any more from 7.4-8.0 than from 8.0-8.1 so I don't see why this is more critical for this release, and it has too many open issues. Tom's post linked above seems to indicate it might be accepted, but I will certainly yield to Core's decision. I'm still hoping someone else will step up to the plate and tackle this: I feel that it would be nice not to confuse a whole new group of users with commented-out defaults which may or may not have a relation to the actual setttings. :) Well, I haven't seen any of the research requested by Tom, and with beta a few days away, I don't see it happening in time. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Bug in ALTER COLUMN/TYPE
Rod Taylor wrote: On Tue, 2004-08-03 at 23:36, Christopher Kings-Lynne wrote: I think we need to deny changing column types if a function is using the table type as a return set. test=# create table test (a int4); CREATE TABLE test=# create function test () returns setof test as 'select 1' language sql; What we really need is dependencies within the function body and the ability to clear the function cache (recompile). I notice we didn't have this on the TODO --- added: * Track dependencies in function bodies and recompile/invalidate -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Open items
Hrmmm, stupid question here, but why not just change hte postgresql.conf to be those variables that *are* changed from the default, with a simple comment pointing to the documention for the rest? the benefit of that is that at lesat the documentation has fuller descriptions of what the variables are for ... *that* could be easily done after beta ... On Fri, 6 Aug 2004, Bruce Momjian wrote: Is this the proper item description? * Remove comments on postgresql.conf variables By removing comments we prevent the confusion that commenting a line returns a modified value to its default, which it does not. --- Bruce Momjian wrote: Added to TODO: * Remove comments on postgresql.conf variables --- Bruce Momjian wrote: Greg Sabino Mullane wrote: [ There is text before PGP section. ] [ PGP not available, raw data follows ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample file to not use all those commented-out values. Unfortunately, I have not had time to do this. If someone could take of this, it would be most appreciated. See Tom`s notes on some issues involved: http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php Another reason to make sure this makes it into 8.0 is so that the new group of users does not see the format of the file change from 8.0 to 8.1, but can start right away with the more intuitive format. This is too involved a change at this stage. I don't expect postgresql.conf to change any more from 7.4-8.0 than from 8.0-8.1 so I don't see why this is more critical for this release, and it has too many open issues. Tom's post linked above seems to indicate it might be accepted, but I will certainly yield to Core's decision. I'm still hoping someone else will step up to the plate and tackle this: I feel that it would be nice not to confuse a whole new group of users with commented-out defaults which may or may not have a relation to the actual setttings. :) Well, I haven't seen any of the research requested by Tom, and with beta a few days away, I don't see it happening in time. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Open items
Marc G. Fournier wrote: Hrmmm, stupid question here, but why not just change hte postgresql.conf to be those variables that *are* changed from the default, with a simple comment pointing to the documention for the rest? the benefit of that is that at lesat the documentation has fuller descriptions of what the variables are for ... *that* could be easily done after beta ... Not sure why removing the comments is seen as good myself, but I think the idea was that if you comment out something and change the default, you assume that commenting it out returns it to the default, though it does not. I am unclear on your suggestion above. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pgxs: build infrastructure for extensions v4
Oh, I see that modification now. Thanks. Sorry I missed it. --- Joe Conway wrote: Bruce Momjian wrote: FYI, I couldn't find anything in the shell pg_config with this path: strncat(otherpath, /pgxs/src/makefiles/pgxs.mk, MAXPGPATH-1); Did you find a mention of this? I looked in pg_config.sh and Makefile.global.in. I see it here: http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/bin/pg_config/Attic/pg_config.sh.diff?r1=1.9;r2=1.10 --pkglibdir)show=$show \$val_pkglibdir;; +--pgxs) show=$show \$val_pgxsdir/src/makefiles/pgxs.mk;; --configure)show=$show \$val_configure;; Joe ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Open items
On Fri, 6 Aug 2004, Bruce Momjian wrote: Marc G. Fournier wrote: Hrmmm, stupid question here, but why not just change hte postgresql.conf to be those variables that *are* changed from the default, with a simple comment pointing to the documention for the rest? the benefit of that is that at lesat the documentation has fuller descriptions of what the variables are for ... *that* could be easily done after beta ... Not sure why removing the comments is seen as good myself, but I think the idea was that if you comment out something and change the default, you assume that commenting it out returns it to the default, though it does not. 'k, now you've totally confused me ... if you comment something out, and it doesn't return to the default, where does it go to? my understanding was that the 'beef' was that the defaults that are displayed on each of the variables in postgresql.conf file don't necessarily match the defaults compiled into the backend ... which, I *think* is what you meant in the above? :) Right now, if you install postgresql, there are various variables added/set in the postgresql.conf file (notably the stuff that Tom did with the shared memory buffer) ... with the rest being what could be the default, but may not be for the commented out variables ... my suggestion is to remove the commented out variables altogether, and change the file to something like: # # for a complete list of GUC variables, see ... # put 'live/set' variables here Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] pg_dump: could not parse ACL list
Hi all,
I have a fresh installation of 8.0devel but I'm not able to
perform any backup using pg_dump:
$ pg_dump -p 5433 test
pg_dump: could not parse ACL list ([0:1]={postgres=UC/postgres,=UC/postgres}) for object
public (SCHEMA)
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
[HACKERS] cancel cetanj$47$1@floppy.pyrenet.fr
This message was cancelled from within Mozilla. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] No such file or directory during PITR
Tom Lane wrote: Gaetano Mendola [EMAIL PROTECTED] writes: I did a recovery strictly following the doc instructions, the recovery succeded but I'm wondering if the following line in the logs is normal or not. cp: cannot stat `/home/pitr/0001.history': No such file or directory Yes, see the point in the docs that the recovery_command *will* be asked for nonexistent files. Thanks, I got it. Regards Gaetano Mendola ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PITR - recovery to a particular transaction
G u i d o B a r o s i o wrote: 8.0 || 7.5?? 8.0 Regards Gaetano Mendola ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Open items
If you change shared_buffers to 2000, remove the comment and reload, the variable is now 2000. If you comment out the variable and reload again, it is still 2000, not the default. --- Marc G. Fournier wrote: On Fri, 6 Aug 2004, Bruce Momjian wrote: Marc G. Fournier wrote: Hrmmm, stupid question here, but why not just change hte postgresql.conf to be those variables that *are* changed from the default, with a simple comment pointing to the documention for the rest? the benefit of that is that at lesat the documentation has fuller descriptions of what the variables are for ... *that* could be easily done after beta ... Not sure why removing the comments is seen as good myself, but I think the idea was that if you comment out something and change the default, you assume that commenting it out returns it to the default, though it does not. 'k, now you've totally confused me ... if you comment something out, and it doesn't return to the default, where does it go to? my understanding was that the 'beef' was that the defaults that are displayed on each of the variables in postgresql.conf file don't necessarily match the defaults compiled into the backend ... which, I *think* is what you meant in the above? :) Right now, if you install postgresql, there are various variables added/set in the postgresql.conf file (notably the stuff that Tom did with the shared memory buffer) ... with the rest being what could be the default, but may not be for the commented out variables ... my suggestion is to remove the commented out variables altogether, and change the file to something like: # # for a complete list of GUC variables, see ... # put 'live/set' variables here Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Open items
Bruce Momjian [EMAIL PROTECTED] writes: Is this the proper item description? * Remove comments on postgresql.conf variables It could easily be taken to mean removing this: #authentication_timeout = 60# 1-600, in seconds ^^^ rather than the leading #. I'd suggest * Un-comment all variables in postgresql.conf By not showing commented-out variables, we will discourage people from thinking that re-commenting a variable returns it to its default. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Open items
On Fri, 6 Aug 2004, Bruce Momjian wrote: If you change shared_buffers to 2000, remove the comment and reload, the variable is now 2000. If you comment out the variable and reload again, it is still 2000, not the default. Oh, weird ... and that isn't considered a bug? Definitely wouldn't be the behaviour I would have expected of any other server/daemon process ... now I can see where the confusion is arising :( Marc G. Fournier wrote: On Fri, 6 Aug 2004, Bruce Momjian wrote: Marc G. Fournier wrote: Hrmmm, stupid question here, but why not just change hte postgresql.conf to be those variables that *are* changed from the default, with a simple comment pointing to the documention for the rest? the benefit of that is that at lesat the documentation has fuller descriptions of what the variables are for ... *that* could be easily done after beta ... Not sure why removing the comments is seen as good myself, but I think the idea was that if you comment out something and change the default, you assume that commenting it out returns it to the default, though it does not. 'k, now you've totally confused me ... if you comment something out, and it doesn't return to the default, where does it go to? my understanding was that the 'beef' was that the defaults that are displayed on each of the variables in postgresql.conf file don't necessarily match the defaults compiled into the backend ... which, I *think* is what you meant in the above? :) Right now, if you install postgresql, there are various variables added/set in the postgresql.conf file (notably the stuff that Tom did with the shared memory buffer) ... with the rest being what could be the default, but may not be for the commented out variables ... my suggestion is to remove the commented out variables altogether, and change the file to something like: # # for a complete list of GUC variables, see ... # put 'live/set' variables here Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Open items
On Fri, 6 Aug 2004, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Is this the proper item description? * Remove comments on postgresql.conf variables It could easily be taken to mean removing this: #authentication_timeout = 60# 1-600, in seconds ^^^ rather than the leading #. I'd suggest * Un-comment all variables in postgresql.conf By not showing commented-out variables, we will discourage people from thinking that re-commenting a variable returns it to its default. That works ... then it implies that there are just no defaults, which, IMHO, would definitely cause less confusion :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Uncommenting .conf WAS: Open items
Bruce, etc: If you change shared_buffers to 2000, remove the comment and reload, the variable is now 2000. If you comment out the variable and reload again, it is still 2000, not the default. And more than one person has been baffled and confused by this, including several major contributors to our project. And we discussed this about 2 months ago and everyone on this list agreed that it should be changed; I'm sorry it didn't make it into the TODO at that time. I see this as a really minor change that will greatly improve the comprehension of how to modify the .conf file. It's documentation, really, and we won't be touching any code. How about if I tackle this this weekend? I'd like to double-check the organization of the new variables in the file, anyway. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL as an application server
On Thu, 2004-08-05 at 22:27, Jonathan M. Gardner wrote: A few nights ago, I implemented some of my application logic in PostgreSQL via PL/PythonU. I was simply amazed at what I was able to do. My question becomes: Why not get rid of the middle layer and move it into the databse entirely? In the mid-90s, I was a lead on just such an app using Oracle PL/SQL. IIRC, it was about a half million lines of code. At that time, Oracle hadn't seen anything quite like it and was pretty interested in what we'd done. I'll add that if we knew what it would be like when we started, we probably would have done it somewhat differently than we did. The advantage is that you have very tight integration with the database and there are few or no external dependencies to worry about. For database heavy applications that require some level of portability, this isn't a bad way to do development. The major disadvantage is that the development environment and tools for in-database languages aren't nearly as rich as your typical standalone environment, which makes programming a pain in the ass for many types of codes. I might have missed something in the intervening years, but I don't think anyone has really bridged that gap. The database guys generally don't like running application code in their database, mostly because it creates new failure modes and problems that they have to manage. For example, at least in older versions of Oracle, if you accidentally programmed an infinite loop or some other busy non-functioning state, it took the DBA to kill it. In the course of application development, this could happen many, many times as code was being debugged, much to the annoyance of the DBAs. That said, I don't see any obvious reason why it couldn't be done well with a moderate amount of effort. j. andrew rogers ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Uncommenting .conf WAS: Open items
Josh Berkus [EMAIL PROTECTED] writes: I see this as a really minor change that will greatly improve the comprehension of how to modify the .conf file. It's documentation, really, and we won't be touching any code. Wrong on both counts: it's not really minor (if it were, it would have got done) and you will need to touch the code. See the earlier discussion. There are several defaults that are presently determined at compile time and are not correctly reflected into postgresql.conf.sample. We'd have to clean that up before we can do something like this. Marc's suggestion of just removing all the non-active entries could be done trivially ;-) ... but I don't think people would see it as an improvement. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Uncommenting .conf WAS: Open items
Tom,
Wrong on both counts: it's not really minor (if it were, it would have
got done) and you will need to touch the code. See the earlier
discussion. There are several defaults that are presently determined
at compile time and are not correctly reflected into
postgresql.conf.sample. We'd have to clean that up before we can do
something like this.
I think we can work around that. Putting those few parameters in as:
#SORT_LOCALE = {set at compile time, check SHOW}
... would still be an improvement for the *majority* of parameters, which are
not set at compile time.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] pg_dump: could not parse ACL list
Gaetano Mendola [EMAIL PROTECTED] writes:
$ pg_dump -p 5433 test
pg_dump: could not parse ACL list ([0:1]={postgres=UC/postgres,=UC/postgres}) for
object public (SCHEMA)
Ugh. This is an unforeseen side effect of Joe's recent changes to make
array_out emit dimension info.
I think the most reasonable answer is to tweak the ACL code so that it
creates ACL arrays with lower bound 1 instead of lower bound 0. The
only possible downside is that this would confuse any client code that
is manually manipulating ACL arrays and knows about the lower-bound-0
behavior ... but any such code is likely broken anyway by the other ACL
changes that have gone on lately ...
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Uncommenting .conf WAS: Open items
Josh Berkus [EMAIL PROTECTED] writes:
I think we can work around that. Putting those few parameters in as:
#SORT_LOCALE = {set at compile time, check SHOW}
... would still be an improvement for the *majority* of parameters, which are
not set at compile time.
Okay, if you can live with that grottiness. But it's still not a
zero-code-touch operation, as at least the sed substitutions in
initdb will need to change.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] UNICODE characters above 0x10000
Attached, as promised, small patch removing the limitation, adding correct utf8 validation. Regards, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hansen Sent: Friday, August 06, 2004 2:20 PM To: 'Hackers' Subject: [HACKERS] UNICODE characters above 0x1 I've started work on a patch for this problem. Doing regression tests at present. I'll get back when done. Regards, John ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html wchar.c.patch Description: wchar.c.patch ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Enter the #1 Hacker site on the entire internet!
ApocalypseKnight wrote: Learn how to Hack into computers,websites,Aol/Yahoo/Msn accounts,view webcams without permission,computer programming,and much,MUCH more at: http://stop.to/Hacker and: http://groups.msn.com/SecretsoftheCyberWarrior ApocalypseKnight I think ApocalypseKnight ment 'crackers'. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] listing triggers
Hi, When using psql I can list the tables and sequences by typing: \d futhermore: \dt lists tables \ds lists sequences \d tablename lists that table. etc. etc. But how can I get a listing of all used triggers on a certain table? Thanks for your time Regards, Erwin Moller ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL as an application server
The major disadvantage is that the development environment and tools for in-database languages aren't nearly as rich as your typical standalone environment, which makes programming a pain in the ass for many types of codes. I might have missed something in the intervening years, but I Although the gap still exists within the environment itself, one significant advantage with PostgreSQL is you can use a more native (to the programmer anyway) language to generate your logic. With PostgreSQL alone you can use plPerl, plPython and plPHP. The language itself hasn't change in it's implementation of the pL. You just have to remember to make all ' a '' :) (at least for the most part). Sincerely, Joshua D. Drake don't think anyone has really bridged that gap. The database guys generally don't like running application code in their database, mostly because it creates new failure modes and problems that they have to manage. For example, at least in older versions of Oracle, if you accidentally programmed an infinite loop or some other busy non-functioning state, it took the DBA to kill it. In the course of application development, this could happen many, many times as code was being debugged, much to the annoyance of the DBAs. That said, I don't see any obvious reason why it couldn't be done well with a moderate amount of effort. j. andrew rogers ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0034 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open items
Done. --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Is this the proper item description? * Remove comments on postgresql.conf variables It could easily be taken to mean removing this: #authentication_timeout = 60# 1-600, in seconds ^^^ rather than the leading #. I'd suggest * Un-comment all variables in postgresql.conf By not showing commented-out variables, we will discourage people from thinking that re-commenting a variable returns it to its default. regards, tom lane -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PostgreSQL as an application server
On Fri, 2004-08-06 at 10:53, Joshua D. Drake wrote: Although the gap still exists within the environment itself, one significant advantage with PostgreSQL is you can use a more native (to the programmer anyway) language to generate your logic. With PostgreSQL alone you can use plPerl, plPython and plPHP. The language itself hasn't change in it's implementation of the pL. You just have to remember to make all ' a '' :) (at least for the most part). One of the things I very much like about PostgreSQL is that it feels like more of a programmer's RDBMS than Oracle. As in the needs and preferences of programmers were obviously given a higher priority in the design of PostgreSQL. I find this to be a very attractive feature and a good thing. This is a case of where a focus on the needs and preferences of hackers in the development of the software by hackers has worked out pretty well, at least for me. People say that is a bad thing about a lot of OSS, but I actually think it was needed in RDBMS software. j. andrew rogers ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] UNICODE characters above 0x10000
John Hansen [EMAIL PROTECTED] writes: Attached, as promised, small patch removing the limitation, adding correct utf8 validation. Surely this is badly broken --- it will happily access data outside the bounds of the given string. Also, doesn't pg_mblen already know the length rules for UTF8? Why are you duplicating that knowledge? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] CVS comment
On Tue, Aug 03, 2004 at 06:42:03PM +0200, Gaetano Mendola wrote: I'm reading some comment on CVS and I seen this comment for tab-complete.c revision 1.109: Fix subtransaction behavior for large objects, temp namespace, files, password/group files. Also allow read-only subtransactions of a read-write parent, but not vice versa. These are the reasonably noncontroversial parts of Alvaro's recent mop-up patch, plus further work on large objects to minimize use of the TopTransactionResourceOwner. but the modification on that file have noting to see with this. Is it normal ? Yeah. I included your tab-complete patch in the patch I sent to pgsql-patches, which later Tom reworked and applied. His CVS comment didn't mention the tab completion change. This isn't surprising at all, as minor changes go uncommented sometimes when they are surrounded by bigger changes (like the large object work). -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Por suerte hoy explotó el califont porque si no me habrÃa muerto de aburrido (Papelucho) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_dump: could not parse ACL list
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
$ pg_dump -p 5433 test
pg_dump: could not parse ACL list ([0:1]={postgres=UC/postgres,=UC/postgres}) for object
public (SCHEMA)
Ugh. This is an unforeseen side effect of Joe's recent changes to make
array_out emit dimension info.
Sorry about that :(. I guess I haven't tried dumping any databases since
making the change.
I think the most reasonable answer is to tweak the ACL code so that it
creates ACL arrays with lower bound 1 instead of lower bound 0. The
only possible downside is that this would confuse any client code that
is manually manipulating ACL arrays and knows about the lower-bound-0
behavior ... but any such code is likely broken anyway by the other ACL
changes that have gone on lately ...
At least it looks like it was an easy fix :).
Thanks,
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Trapping QUERY_CANCELED: yes, no, maybe?
On Sat, 31 Jul 2004 21:24:33 -0400, Tom Lane [EMAIL PROTECTED] wrote:
Exactly. There's a proof-of-concept test at the bottom of
regress/sql/plpgsql.sql, wherein a function gets control back
from a query that would have run for an unreasonably long time.
referring to
| -- we assume this will take longer than 1 second:
| select count(*) into x from tenk1 a, tenk1 b, tenk1 c;
On Thu, 29 Aug 2002 13:27:36 -0400, Tom Lane [EMAIL PROTECTED] wrote:
You mean, that the test might fail on a system that takes more than
ten seconds to INSERT or UPDATE a single row? I don't think this is a
real problem.
I don't like depending on a timeout *at all* in a regression test;
the exact value of the timeout is not particularly relevant to my
concern about it.
Maybe
SELECT sleep('0:0:2'::interval);
as used in regress/sql/stats.sql is a better way to ensure that the
query takes longer than one second?
Servus
Manfred
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Trapping QUERY_CANCELED: yes, no, maybe?
Manfred Koizar [EMAIL PROTECTED] writes:
referring to
| -- we assume this will take longer than 1 second:
| select count(*) into x from tenk1 a, tenk1 b, tenk1 c;
Maybe
SELECT sleep('0:0:2'::interval);
as used in regress/sql/stats.sql is a better way to ensure that the
query takes longer than one second?
You think there's a serious risk of failure there ;-) ?
By my count the query will try to generate one trillion join rows.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Trapping QUERY_CANCELED: yes, no, maybe?
On Fri, 06 Aug 2004 18:55:49 -0400, Tom Lane [EMAIL PROTECTED] wrote: You think there's a serious risk of failure there ;-) ? Not on my hardware... Servus Manfred ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] CVS comment
Alvaro Herrera wrote: On Tue, Aug 03, 2004 at 06:42:03PM +0200, Gaetano Mendola wrote: I'm reading some comment on CVS and I seen this comment for tab-complete.c revision 1.109: Fix subtransaction behavior for large objects, temp namespace, files, password/group files. Also allow read-only subtransactions of a read-write parent, but not vice versa. These are the reasonably noncontroversial parts of Alvaro's recent mop-up patch, plus further work on large objects to minimize use of the TopTransactionResourceOwner. but the modification on that file have noting to see with this. Is it normal ? Yeah. I included your tab-complete patch in the patch I sent to pgsql-patches, which later Tom reworked and applied. His CVS comment didn't mention the tab completion change. This isn't surprising at all, as minor changes go uncommented sometimes when they are surrounded by bigger changes (like the large object work). Understood. Why not comment each file separately too much work with CVS? I do not have experience with CVS ( at work I user Clearcase ) and for my personal purpose I use subversion ( any plans to migrate the CVS repository to subversion or even bitkeeper ? ). Regards Gaetano Mendola ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Vacuum Cost Documentation?
Updated. Thanks. --- Matthew T. O'Connor wrote: Related to autovacuum work, I was looking into the new vacuum delay functionality. I might be missing something, but I can't find anything on it in the developer docs. Is that right? Also, in the default postgresql.conf there is: #vacuum_cost_naptime = 50 # 0-1000 milliseconds however psql reports this value as 0. I assume this is just postgresql.conf is just wrong. Can we fix this so it's consistent? Thanks, Matthew O'Connor ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] CVS comment
On Sat, Aug 07, 2004 at 01:34:20AM +0200, Gaetano Mendola wrote: Alvaro Herrera wrote: Yeah. I included your tab-complete patch in the patch I sent to pgsql-patches, which later Tom reworked and applied. His CVS comment didn't mention the tab completion change. This isn't surprising at all, as minor changes go uncommented sometimes when they are surrounded by bigger changes (like the large object work). Understood. Why not comment each file separately too much work with CVS? People just doesn't feel it's important ... other projects have strict guidelines regarding CVS commit message formatting, but what I have seen is in most cases useless noise. Anyone can see the real diffs when there's need. I do not have experience with CVS ( at work I user Clearcase ) and for my personal purpose I use subversion ( any plans to migrate the CVS repository to subversion or even bitkeeper ? ). Subversion and arch have been mentioned, but so far there is no compelling reason to change. It'd take convincing at least a couple of core hackers to get the ball rolling ... -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) If it wasn't for my companion, I believe I'd be having the time of my life (John Dunbar) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] parameter hints to the optimizer
Oliver Jowett wrote: Merlin Moncure wrote: Another way to deal with the problem is to defer plan generation until the first plan execution and use the parameters from that execution. When talking the V3 protocol, 7.5 defers plan generation for the unnamed statement until parameters are received in the Bind message (which is essentially the same as what you describe). There was some discussion at the time about making it more flexible so you could apply it to arbitary statements, but that needed a protocol change so it didn't happen. What do you mean about arbitrary statements? Non-prepared ones, or non-unnamed ones? I am trying to figure out what TODO item needs to be added. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] [BUGS] casting strings to multidimensional arrays yields
Tom Lane wrote:
I think that suppressing unquoted trailing whitespace is probably
reasonable. I'm much less enthusiastic about rejecting unquoted
embedded whitespace, though. I think that's significantly likely
to break apps, and it doesn't seem like it's really needed to have
sane behavior. The leading/trailing whitespace asymmetry is just
weird, but it doesn't follow that embedded whitespace is weird.
If we are going to make such changes, 8.0 is the right time to do it.
The attached patch suppresses trailing whitespace, but allows embedded
whitespace in unquoted elements as discussed above. It also rejects some
previously accepted cases that were just too strange to be correct:
-- Postgres 8.0, with the patch
-- none of these should be accepted
select '{{1,{2}},{2,3}}'::text[];
ERROR: malformed array literal: {{1,{2}},{2,3}}
select '{{},{}}'::text[];
ERROR: malformed array literal: {{},{}}
select '{{1,2},\\{2,3}}'::text[];
ERROR: malformed array literal: {{1,2},\{2,3}}
select '{{1 2 x},{3}}'::text[];
ERROR: malformed array literal: {{1 2 x},{3}}
The third case above actually does get an ERROR in 7.4 but it looks
suspicious itself:
-- in Postgres 7.4
select '{{1,2},\\{2,3}}'::text[];
ERROR: malformed array literal: {{1
More examples:
-- Postgres 8.0, with the patch
-- all of these should be accepted
select '{}'::text[];
text
--
{}
(1 row)
select '{0 second ,0 second}'::interval[];
interval
-
{00:00:00,00:00:00}
(1 row)
select '{ { , } , { 3 } }'::text[];
text
-
{{,},{3}}
(1 row)
select ' { {0 second , 0 second } }'::text[];
text
---
{{ 0 second ,0 second}}
(1 row)
If there are no objections, I'll update the docs and commit tomorrow
sometime.
Thanks,
Joe
Index: src/backend/utils/adt/arrayfuncs.c
===
RCS file: /cvsroot/pgsql-server/src/backend/utils/adt/arrayfuncs.c,v
retrieving revision 1.106
diff -c -r1.106 arrayfuncs.c
*** src/backend/utils/adt/arrayfuncs.c 5 Aug 2004 03:29:37 - 1.106
--- src/backend/utils/adt/arrayfuncs.c 7 Aug 2004 01:34:02 -
***
*** 351,368
* The syntax for array input is C-like nested curly braces
*-
*/
static int
ArrayCount(char *str, int *dim, char typdelim)
{
! int nest_level = 0,
! i;
! int ndim = 1,
! temp[MAXDIM],
! nelems[MAXDIM],
! nelems_last[MAXDIM];
! bool scanning_string = false;
! bool eoArray = false;
! char *ptr;
for (i = 0; i MAXDIM; ++i)
{
--- 351,382
* The syntax for array input is C-like nested curly braces
*-
*/
+ typedef enum
+ {
+ ARRAY_NO_LEVEL,
+ ARRAY_LEVEL_STARTED,
+ ARRAY_ELEM_STARTED,
+ ARRAY_ELEM_COMPLETED,
+ ARRAY_QUOTED_ELEM_STARTED,
+ ARRAY_QUOTED_ELEM_COMPLETED,
+ ARRAY_ELEM_DELIMITED,
+ ARRAY_LEVEL_COMPLETED,
+ ARRAY_LEVEL_DELIMITED
+ } ArrayParseState;
+
static int
ArrayCount(char *str, int *dim, char typdelim)
{
! intnest_level = 0,
! i;
! intndim = 1,
! temp[MAXDIM],
! nelems[MAXDIM],
! nelems_last[MAXDIM];
! bool scanning_string = false;
! bool eoArray = false;
! char *ptr;
! ArrayParseState parse_state = ARRAY_NO_LEVEL;
for (i = 0; i MAXDIM; ++i)
{
***
*** 370,375
--- 384,390
nelems_last[i] = nelems[i] = 1;
}
+ /* special case for an empty array */
if (strncmp(str, {}, 2) == 0)
return 0;
***
*** 389,394
--- 404,423
errmsg(malformed array literal: \%s\, str)));
break;
case '\\':
+ /*
+ * An escape must be after a level start, after an
+ * element start, or after an element delimiter. In any
+ * case we now must be past an element start.
+ */
+ if (parse_state != ARRAY_LEVEL_STARTED
+ parse_state != ARRAY_ELEM_STARTED
+ parse_state != ARRAY_QUOTED_ELEM_STARTED
+ parse_state != ARRAY_ELEM_DELIMITED)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+ errmsg(malformed array literal: \%s\, str)));
+ if (parse_state != ARRAY_QUOTED_ELEM_STARTED)
+ parse_state = ARRAY_ELEM_STARTED;
/* skip the escaped character */
if (*(ptr + 1))
ptr++;
***
*** 398,408
--- 427,464
errmsg(malformed array literal: \%s\, str)));
break;
case '\':
+ /*
+ * A quote must be after a level start, after a quoted
+ * element start, or after an element delimiter. In any
+ * case we now must be past an element start.
+ */
+ if (parse_state != ARRAY_LEVEL_STARTED
+ parse_state != ARRAY_QUOTED_ELEM_STARTED
+ parse_state != ARRAY_ELEM_DELIMITED)
+ ereport(ERROR,
+
[HACKERS] cvsweb down temporarily
due to a googlebot effect, I had to shut it down temporarily ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PATCHES] [BUGS] casting strings to multidimensional arrays yields strange
Joe Conway [EMAIL PROTECTED] writes:
The attached patch suppresses trailing whitespace, but allows embedded
whitespace in unquoted elements as discussed above. It also rejects some
previously accepted cases that were just too strange to be correct:
-- Postgres 8.0, with the patch
-- none of these should be accepted
select '{{1,{2}},{2,3}}'::text[];
ERROR: malformed array literal: {{1,{2}},{2,3}}
Okay, uneven nesting level of {} is clearly bogus.
select '{{},{}}'::text[];
ERROR: malformed array literal: {{},{}}
Hm. This seems like it would be a legitimate representation of a 2x0
array. Why would you allow '{}' and reject this?
select '{{1,2},\\{2,3}}'::text[];
ERROR: malformed array literal: {{1,2},\{2,3}}
Okay, junk outside the {} structure is bad.
select '{{1 2 x},{3}}'::text[];
ERROR: malformed array literal: {{1 2 x},{3}}
So here you're rejecting the first data value because it's partially
quoted and partially not? I guess this is arguably reasonable, but
I'm not sure that it's really necessary either. Historically array_in
has taken this sort of thing.
The third case above actually does get an ERROR in 7.4 but it looks
suspicious itself:
select '{{1,2},\\{2,3}}'::text[];
ERROR: malformed array literal: {{1
This is something I was planning to fix myself: ReadArrayStr is using
arrayStr as the string to complain about in its error messages, but that
is the same string that it is scribbling on by overwriting with \0 where
it wants to terminate an individual data value. So you get bogus
messages anytime a syntax error is detected after having absorbed at
least one item value.
The easiest way to fix it seems to be for array_in to pass an additional
parameter which is the original non-overwritable input string, and use
that in the ereport calls.
More examples:
These look okay. Didn't study the code though.
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] UNICODE characters above 0x10000
My apologies for not reading the code properly. Attached patch using pg_utf_mblen() instead of an indexed table. It now also do bounds checks. Regards, John Hansen -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Saturday, August 07, 2004 4:37 AM To: John Hansen Cc: Hackers; Patches Subject: Re: [HACKERS] UNICODE characters above 0x1 John Hansen [EMAIL PROTECTED] writes: Attached, as promised, small patch removing the limitation, adding correct utf8 validation. Surely this is badly broken --- it will happily access data outside the bounds of the given string. Also, doesn't pg_mblen already know the length rules for UTF8? Why are you duplicating that knowledge? regards, tom lane wchar.c.patch Description: wchar.c.patch ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Vacuum Cost Documentation?
On 8/6/2004 9:04 PM, Bruce Momjian wrote: Updated. Thanks. I thought we want to have the feature activated ... I reversed your change and brought guc.c in sync instead. Jan --- Matthew T. O'Connor wrote: Related to autovacuum work, I was looking into the new vacuum delay functionality. I might be missing something, but I can't find anything on it in the developer docs. Is that right? Also, in the default postgresql.conf there is: #vacuum_cost_naptime = 50 # 0-1000 milliseconds however psql reports this value as 0. I assume this is just postgresql.conf is just wrong. Can we fix this so it's consistent? Thanks, Matthew O'Connor ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] PITR - recovery to a particular transaction
When we do a PITR recovery based on xid, does it stop recovery based on the start of the xid or the commit of the xid? And if you say recovery_target_inclusive =true, does it recover that xid while not recoverying other xids that are higher but committed sooner than the target xid? --- Oliver Elphick wrote: On Wed, 2004-08-04 at 19:16, Tom Lane wrote: Oliver Elphick [EMAIL PROTECTED] writes: How about adding a logging option to put the transaction id on the log for every statement that modifies the database? Would that be a small enough change to be allowed into 8.0? I think we could get away with adding transaction ID as one of the available %-items in log_line_prefix. I'm not sure how useful this really is though --- timestamps are probably more useful overall to have in your log. Why not both? You seem to be suggesting that using the id is less useful than the time, but surely it's going to be easier to say this disaster happened in transaction 123 so lets do a PITR up to 122 than to say this happened at time x so do PITR up to x - 1 second; the latter might miss several tranactions. Have I got the concepts wrong here? The direction I was expecting we'd head in is to provide WAL logfile examination tools. But that's not going to happen for 8.0, so any means of getting the transaction id is better than none. -- Oliver Elphick [EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA And not only so, but we glory in tribulations also; knowing that tribulation worketh patience; And patience, experience; and experience, hope. Romans 5:3,4 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Vacuum Cost Documentation?
Jan Wieck wrote: On 8/6/2004 9:04 PM, Bruce Momjian wrote: Updated. Thanks. I thought we want to have the feature activated ... I reversed your change and brought guc.c in sync instead. OK. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Vacuum Cost Documentation?
Jan Wieck wrote: On 8/6/2004 9:04 PM, Bruce Momjian wrote: Updated. Thanks. I thought we want to have the feature activated ... I reversed your change and brought guc.c in sync instead. Uh, if the guy is doing a vacuum at night, does he want the delay? Seems someone should have to enable the delay by default, or does your setup recoginize when it is being run on a lightly loaded system? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] 8.0 beta status
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Yeah, those are all bug fixes and okay for post-beta I think. But which two tablespace failures are you thinking of exactly? The last couple weeks have been a bit of a blur for me... http://groups.google.com.au/groups?q=tablespaces+group:comp.databases.postgresql.hackershl=enlr=ie=UTF-8group=comp.databases.postgresql.hackersscoring=dselm=Pine.LNX.4.58.0407281411470.17889%40linuxworld.com.aurnum=4 Okay, this is a the-error-message-could-be-better gripe. Fair enough, but it's not top of my priority list ... http://groups.google.com.au/groups?q=tablespaces+group:comp.databases.postgresql.hackershl=enlr=ie=UTF-8group=comp.databases.postgresql.hackersscoring=dselm=4107211C.2050508%40familyhealth.com.aurnum=5 I think the problem here is that we don't have a syntax for saying my tablespace is the same as my database's default tablespace or my tablespace is the same as my schema's default tablespace, when there is an intermediate object (schema or table) that isn't using that tablespace. (Note that TABLESPACE pg_default does definitely not mean either of these.) This is fixable with some special syntax but is it worth the trouble? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PITR - recovery to a particular transaction
Bruce Momjian [EMAIL PROTECTED] writes: When we do a PITR recovery based on xid, does it stop recovery based on the start of the xid or the commit of the xid? You can stop either before or after that commit. See recovery.conf.sample (I don't think it's documented anywhere else yet :-(), regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] UNICODE characters above 0x10000
John Hansen [EMAIL PROTECTED] writes: My apologies for not reading the code properly. Attached patch using pg_utf_mblen() instead of an indexed table. It now also do bounds checks. I think you missed my point. If we don't need this limitation, the correct patch is simply to delete the whole check (ie, delete lines 827-836 of wchar.c, and for that matter we'd then not need the encoding local variable). What's really at stake here is whether anything else breaks if we do that. What else, if anything, assumes that UTF characters are not more than 2 bytes? Now it's entirely possible that the underlying support is a few bricks shy of a load --- for instance I see that pg_utf_mblen thinks there are no UTF8 codes longer than 3 bytes whereas your code goes to 4. I'm not an expert on this stuff, so I don't know what the UTF8 spec actually says. But I do think you are fixing the code at the wrong level. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
