[HACKERS] Vacuum only a Schema ?
Hi, What about only vacuum a schema ? Is it a stupid idea or is it plannified in futur release ... ? What about also give the ability to vacuum all tables except some big one ? Regards, -- Hervé Piedvache ---(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] pg_autovacuum and v8.0
OK thanks ! Le Jeudi 9 Septembre 2004 18:14, Thomas F.O'Connell a écrit : > pg_autovacuum will still be in contrib as of 8.0. It did not make > integration with the core distribution. > > -tfo > > On Sep 9, 2004, at 11:09 AM, Hervé Piedvache wrote: > > Hi, > > > > I was thinking that new things will appear in v8.0 about pg_autovacuum > > ?? > > > > But I find nothing new in README and/or Version History > > > > Any help ? > > > > Regards, > > -- > > Hervé Piedvache > > > > Elma Ingénierie Informatique > > 6 rue du Faubourg Saint-Honoré > > F-75008 - Paris - France > > Pho. 33-144949901 > > Fax. 33-144949902 -- Hervé Piedvache Elma Ingénierie Informatique 6 rue du Faubourg Saint-Honoré F-75008 - Paris - France Pho. 33-144949901 Fax. 33-144949902 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] pg_autovacuum and v8.0
Hi, I was thinking that new things will appear in v8.0 about pg_autovacuum ?? But I find nothing new in README and/or Version History Any help ? Regards, -- Hervé Piedvache Elma Ingénierie Informatique 6 rue du Faubourg Saint-Honoré F-75008 - Paris - France Pho. 33-144949901 Fax. 33-144949902 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] vacuum log are difficult to read ...
Hi, I know that we have more and more details to show, during vacuum analyze ... but since v7.4.x it's not really easy to read quicly a vacuum analyze to see important points ... like elapsed time or number of tupples deleted... I would like to know first if you could make an effort about this ... only for human use ... ;o) And also if it's possible to have a report of the abnormal situations ... may be something like the point I had once, with the number of pages for the table really cheaper than the pages of my index for the same table ... Is it possible in a vacuum also to get informations about the quality of the parameters of the database .. for example the size of some parameters that are not in adequation with the data (pages, size of index etc.) we have in reality ... I don't know if my request is possible, but if so it could be a good opportunity for some tuning points, isn't it ? I hope I'm clear with my demand ;o) Regards, -- Hervé Piedvache Elma Ingénierie Informatique 6 rue du Faubourg Saint-Honoré F-75008 - Paris - France Pho. 33-144949901 Fax. 33-144949902 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Failed to initialize lc_messages 7.3b5
Hi, I don't know if it's important or not ... but on my linux Debian woody, with fr_FR@euro parameter when I do the initdb I've got a creating template1 database in /usr/local/pgsql/data/base/1... Failed to initialize lc_messages to '' I just would like to know what that's mean exactly ... Exact message of initdb : /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale fr_FR@euro. This locale setting will prevent the use of indexes for pattern matching operations. If that is a concern, rerun initdb with the collation order set to "C". For more information see the Administrator's Guide. Fixing permissions on existing directory /usr/local/pgsql/data... ok creating directory /usr/local/pgsql/data/base... ok creating directory /usr/local/pgsql/data/global... ok creating directory /usr/local/pgsql/data/pg_xlog... ok creating directory /usr/local/pgsql/data/pg_clog... ok creating template1 database in /usr/local/pgsql/data/base/1... Failed to initialize lc_messages to '' ok creating configuration files... ok initializing pg_shadow... ok enabling unlimited row size for system tables... ok initializing pg_depend... ok creating system views... ok loading pg_description... ok creating conversions... ok setting privileges on built-in objects... ok vacuuming database template1... ok copying template1 to template0... ok Success. You can now start the database server using: /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data or /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start regards, -- Hervé Piedvache Elma Ingénierie Informatique 6 rue du Faubourg Saint-Honoré F-75008 - Paris - France Tel. 33-144949901 fax. 33-144949902 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Impossible to import pg_dumpall from 7.2.2 to 7.3b1
Dear Tom, >> <[EMAIL PROTECTED]> writes: >> But when I try to import it inside 7.3b1 I get this : >> (seems that the copy command is not fully compatible with the 7.2.2 >> pg_dumpall ?) >> >> Many thinks like this : (I have only copied some parts ...) >> Size of the dump about 1.5 Gb ... >> >> Query buffer reset (cleared). >> psql:/tmp/dump_mybase.txt:1015274: invalid command \nPour >> Query buffer reset (cleared). > >It seems pretty clear that the COPY command itself failed, leaving psql >trying to interpret the following data as SQL commands. But you have >not shown us either the COPY command or the error message it generated, >so there's not a lot we can say about it... > >regards, tom lane OK I have (hope) find the trouble ... may be a mistake from my part but which was running with v7.2.2 ... (I think I have to alter my table with default current_date ...) I have this error message : psql:dump.7.2.2.txt:304: ERROR: Column "datecrea" is of type date but default expression is of type timestamp with time zone You will need to rewrite or cast the expression for the field : "datecrea" date DEFAULT now(), So after, the importation of the data are making errors messages because the previus table has not been created ... I'm right ? I have also a strange error : psql:dump.7.2.2.txt:1087: ERROR: function plpgsql_call_handler() does not return type language_handler psql:dump.7.2.2.txt:1126: ERROR: language "plpgsql" does not exist for those lines : -- -- TOC Entry ID 292 (OID 2083293) -- -- Name: "plpgsql_call_handler" () Type: FUNCTION Owner: postgres -- CREATE FUNCTION "plpgsql_call_handler" () RETURNS opaque AS '/usr/local/pgsql/lib/plpgsql.so', 'plpgsql_call_handler' LANGUAGE 'C'; -- -- TOC Entry ID 293 (OID 2083294) -- -- Name: plpgsql Type: PROCEDURAL LANGUAGE Owner: -- CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' HANDLER "plpgsql_call_handler" LANCOMPILER 'PL/pgSQL'; Hope this help ... Regards, -- Hervé ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Importing data from 7.2.2 into 7.3b1 !?
Hi, Sorry to insist, may be my previus subject was miss understood ... refering to this message : http://archives.postgresql.org/pgsql-hackers/2002-09/msg00461.php But I can't import my data from 7.2.2 into 7.3b1 ... 1- Many errors during importation of the data 2- Seems to use all the memory (and swap) during the import of the data made with a classical pg_dumpall from the 7.2.2 to the 7.3b1 ... I'm used to make the same import on the same computer from the same data from 7.2.2 (other server) to 7.2.2 (this computer)... so the 7.3b1 use more memory and seems to not understand the pg_dumpall data of the 7.3b1 ? Any idea ? I'm the only one with this kind of trouble ? The beta page tell us to make dump/initdb/reload ... it's what I've done but without any result ;) Regards, -- Hervé ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] PSQL completion !? v7.2.1
Hi, It's a stupid thing ... but really useful ... When we use, like me, psql all the time with the function VACUUM, psql make the completion of tables names, and of the word ANALYZE ... Why not the same for VERBOSE ? and for the new function FULL, and FREEZE ?? May be in the TODO for next release ;) regards, -- Hervé Piedvache Elma Ingenierie Informatique 6, rue du Faubourg Saint-Honoré F-75008 - Paris - France http://www.elma.fr Tel: +33-1-44949901 Fax: +33-1-44949902 Email: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
