Re: [ADMIN] Problem with data migration from 9.1 to 9.2

/lib/pgsql/data_new -E UTF8 --lc-collate=C --lc-ctype=C --lc-monetary=C --lc-numeric=C -U postgres Try. -- Andrzej Zawadzki -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin

Re: [ADMIN] password administration

his merely encourages people to > use a cycle of six or so passwords, like something they can remember > with one digit tagged on. > Hi! Such a policy is in force in my country (Poland) but only if system contains personal data. (government law) 8 or more characters - 2 capital letters, 2 digit

Re: [ADMIN] upgrading, but learned about pg_dumpall too late

On 21.02.2010 00:22, Greg Stark wrote: > On Sat, Feb 20, 2010 at 10:42 PM, Andrzej Zawadzki wrote: > >> Downgrade to 7.4 >> Dump >> Upgrade >> Restore >> >> > Actually that's not the best way. > > True bat not easier for begin

Re: [ADMIN] upgrading, but learned about pg_dumpall too late

directory was initialized by PostgreSQL version > 7.4, which is not compatible with this version 8.1.1 > > Any suggestions will be appreciated. > Downgrade to 7.4 Dump Upgrade Restore -- Andrzej Zawadzki -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin

[ADMIN] Problem after upgrade to 8.4.1

970426] LOG:  execute :  UPDATE b.person SET last_person_hist_id = $1, history_generate_id = 0 WHERE id = $2 [32096][azawadzki][2009-10-04 17:00:46 CEST][970426] DETAIL:  parameters: $1 = '1374224', $2 = '658041' [32096][azawadzki][2009-10-04 17:00:46 CEST][970426] LOG:  execute :  SET CONSTRAINTS b.last_person_hist_id_fkey IMMEDIATE [32096][azawadzki][2009-10-04 17:00:46 CEST][970426] ERROR:  could not open relation with OID 10027008 [32096][azawadzki][2009-10-04 17:00:46 CEST][970426] STATEMENT:   SET CONSTRAINTS b.last_person_hist_id_fkey IMMEDIATE [32096][azawadzki][2009-10-04 17:00:46 CEST][970426] LOG:  execute S_2: ROLLBACK I can repeat this behavior on all my test and production servers. If I run this last transaction block separately everything works fine. What could be wrong? Some bad adjustments? On the 8.3 works well... ps. sorry for html but IMHO looks better. -- Andrzej Zawadzki

Re: [ADMIN] "like" and index

Daniel J. Summers wrote: > Andrzej Zawadzki wrote: >> Daniel J. Summers wrote: >> >>> Tony Liao wrote: >>> >>>> I try to explain analyze,but it doesn't work ,it use seq scan. >>>> >>> Generally sp

Re: [ADMIN] "like" and index

Daniel J. Summers wrote: > Tony Liao wrote: >> I try to explain analyze,but it doesn't work ,it use seq scan. > Generally speaking, LIKE doesn't use indexes. ?! That's not true at all!! -- Andrzej Zawadzki -- Sent via pgsql-admin mailing list (pgsql-admin@postgre

Re: [ADMIN] Moving database install to new SAN

n I think that is much faster to copy running database to new SAN. Then stop postgres and rsync what was changed - but this will be probably only a few files. > 3. start postgres with new data directory Minimal downtime I think. Best regards -- Andrzej Zawadzki ---(en

Re: [ADMIN] cpu usage on the linux machine

Jessica Richard wrote: > If the linux box has 8 CPU's, is there a way to configure for Postgres > to user 6 of them? how? Thanks! Try that: http://www.bullopensource.org/cpuset/ -- Andrzej Zawadzki PLD ---(end of broadcast)--- TIP