Re: [HACKERS] Script binaries renaming
Marc G. Fournier napsal(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Tuesday, March 25, 2008 22:51:53 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Uh, I think it is hard to make a case that 'createuser' is an appropriate name for a Postgres utility. On the other hand, we haven't had many complaints about it, which is kind of odd. If nobody has ever complained, what is the reason for the change? How many ppl are going to complain because the commands they are used to suddenly stop existing? Minimal me :-) and Solaris Architect committee have complain. Question is also how many users really use these commands. For example vacuumdb is not too important now when we have autovacuum. You can specify tablespace in createdb command but you don't have createtablespace command and so on. I will send survey to general list today and I hope we get some useful information. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Magnus Hagander napsal(a): On Tue, 2008-03-25 at 21:59 -0400, Tom Lane wrote: snip Are we really prepared to break everyone's scripts for this? I wonder how many people actually use those commands :-) I know I always use psql with a commandline parameter, and the majority of other peoples scripts that I've come across also do that. So I'm not sure exactly how important it is. Another option then might be to simply deprecate their use, and eventually get rid of them, instead of renaming them? In one of my mail I also mentioned to replace all of these commands by one (e.g. pg_cmd) which will integrate all of them. Removing is not good solution for people who writes scripts, because process psql output is complicated and there is not easy way how to run vacuum on all databases for example. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Magnus Hagander napsal(a): On Wed, 2008-03-26 at 13:21 +0100, Zdeněk Kotala wrote: Magnus Hagander napsal(a): On Tue, 2008-03-25 at 21:59 -0400, Tom Lane wrote: snip Are we really prepared to break everyone's scripts for this? I wonder how many people actually use those commands :-) I know I always use psql with a commandline parameter, and the majority of other peoples scripts that I've come across also do that. So I'm not sure exactly how important it is. Another option then might be to simply deprecate their use, and eventually get rid of them, instead of renaming them? In one of my mail I also mentioned to replace all of these commands by one (e.g. pg_cmd) which will integrate all of them. Removing is not good solution for people who writes scripts, because process psql output is complicated and there is not easy way how to run vacuum on all databases for example. You can add lots of nice parameters to psql to make it quite easy to process the output. Running vacuum on all databases isn't particularly hard - but it does require a small bit of shell-fu. Yes, it needs extra lines in shell script and probably most of use cases are possible do by psql command. Maybe removing will be better solution. But I'll grant you that one for vacuumdb. I was specifically thinking about the create/drop user/db/lang scripts, which are the ones likely to conflict with other parts of the system. Didn't think of vacuumdb. I see. I think that autovacuum stops usage of vacuumdb command anyway. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Andrew Dunstan napsal(a): Zdeněk Kotala wrote: Question is also how many users really use these commands. For example vacuumdb is not too important now when we have autovacuum. This is not true. Plenty of apps will quite reasonably choose to follow large batch updates by a single vacuumdb rather than using autovacuum. Yes, up to 8.2, but I think situation for 8.3 could be different. We have more works, autovacuum is better and so on. Incidentally, I am less opposed than some to some sensible renaming here, eventually. Perhaps we could take the opportunity to fix the naming of initdb, which confuses the heck out of many people. Instead of renaming initdb extend pg_ctl (pg_ctl init) seems to me as a better idea. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] regress test problems
What locale do you use? It seems that problem is in collation. Try it with C. Zdenek Pavel Stehule napsal(a): Hello I tested head again from scratch with negative results: http://www.pgsql.cz/data/regression.diffs http://www.pgsql.cz/data/regression.out Regards Pavel Stehule [EMAIL PROTECTED] pgsql]$ uname -a Linux nemesis.nat.buk.cvut.cz 2.6.24.3-34.fc8 #1 SMP Wed Mar 12 18:17:20 EDT 2008 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] pgsql]$ cat /etc/redhat-release Fedora release 8 (Werewolf) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] Fix for large file support (nonsegment mode support)
Peter Eisentraut napsal(a): Zdenek Kotala wrote: But how it was mentioned in this thread maybe somethink like this CREATE TABLESPACE name LOCATION '/my/location' SEGMENTS 10GB should good solution. If segments is not mentioned then default value is used. I think you would need a tool to resegmentize a table or tablespace offline, usable for example when recovering a backup. Do you mean something like strip(1) command? I don't see any usecase for terrabytes data. You usually have a problem to find place where you can backup. Also, tablespace configuration information is of course also stored in a table. pg_tablespace probably won't become large, but it would probably still need to be special-cased, along with other system catalogs perhaps. It is true and unfortunately singularity. Same as database list which is in a table as well, but it is stored also as a text file for startup purpose. I more incline to use non table configuration file for tablespaces, because I don't see any advantage to have it under MVCC control and it allow also to define storage for pg_global and pg_default. An then, how to coordindate offline resegmenting and online tablespace operations in a crash-safe way? Another factor I just thought of is that tar, commonly used as part of a backup procedure, can on some systems only handle files up to 8 GB in size. There are supposed to be newer formats that can avoid that restriction, but it's not clear how widely available these are and what the incantation is to get at them. Of course we don't use tar directly, but if we ever make large segments the default, we ought to provide some clear advice for the user on how to make their backups. I think tar is OK - minimal on Solaris. See man largefile. Default segment size still should be 1GB. If DBA makes a decision to increase this to higher value, then it is his responsibility to find way how to process this big files. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
