Re: [GENERAL] Voting: pg_ctl init versus initdb
Tom Lane píše v so 14. 11. 2009 v 11:22 -0500: Zdenek Kotala zdenek.kot...@sun.com writes: Because there is doubt if someone else want this I would like to ask here for your opinion. There are following options: 1) Yeah I like pg_ctl init pg_ctl init will be preferred method and initdb will disappear from usr/bin in the future. 2) Good, but keep initdb as well pg_ctl init and initdb stays forever 3) Do not touch my lovely initdb pg_ctl init is nonsense, initdb is only correct way. You have listed them in reverse preference order ;-) Maybe because I'm sitting on opposite hemisphere :-) The only people who would actually care about this are packagers who think they can get away with taking initdb out of $PATH. If you believe that you can get away with that, you can do it today without any help from pg_ctl. (Your theory presumably is that only one place in the initscript needs to know about it, and that one place could just as easily invoke initdb with an explicit path to wherever.) If you don't believe that you can get away with hiding initdb out of sight, then this patch is useless to you. init script is not only one place when you need initdb. init script can do it for you but often you need to setup correct locale. And admins need to init database manually. And after that they want to have command for it in default path. Another advantage of pg_ctl is that it is easy to extend it to cope with more postgres versions and calls appropriate version of postgres or initdb. (BTW, have you actually tried moving initdb? I wonder how well the relative-path logic for finding SHAREDIR etc is going to cope.) libexecdir is not used. find_other_exec() is little bit stupid. It finds only binaries in the same directory. I guess It should look into bindir and libexecdir as well. when I'm thinking about it postgres and initdb should be installed into libexecdir instead of bindir. For example sshd is in /usr/lib/sshd/ on solaris. So I find the patch pretty useless. But it's also pretty harmless, so long as it doesn't extend to the idea that we'd actually hide initdb in a default installation; at that point you're going to start hitting stiff resistance. I supposed to use libexecdir for installation. If packager wants to hide it than he can set libexecdir to another place. If not initdb will stay in bindir. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Voting: pg_ctl init versus initdb
Greg Smith píše v ne 15. 11. 2009 v 22:16 -0500: Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: If we did add an extra option then the option would be initdb not init. It would take us all years to remove all evidence of the phrase initdb from the mailing lists and our minds. init is already embedded in various packagers' initscripts. And I thought the entire point of this proposal was that we could expunge knowledge of initdb from users' minds. Exactly. I think the best transition design would be to make initdb and init both work. initdb sounds me now better then init, but to have both is technically not problem. But question is if it is less confusing than have only one of them. Just a note that we already have WAL/XLOG or postgres/postmaster/frontend/backend. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Voting: pg_ctl init versus initdb
Hi all, I prepared patch which extend pg_ctl functionality and add init command which do same thing like initdb (it calls initdb on the background). The idea behind this is to have only one command which control database. pg_ctl already has start, stop, restart, reload and so on. To have init is logical. There is also second reason for that. Initdb does not fit pg binaries naming convection which could lead to name conflict in the /usr/bin. Because there is doubt if someone else want this I would like to ask here for your opinion. There are following options: 1) Yeah I like pg_ctl init pg_ctl init will be preferred method and initdb will disappear from usr/bin in the future. 2) Good, but keep initdb as well pg_ctl init and initdb stays forever 3) Do not touch my lovely initdb pg_ctl init is nonsense, initdb is only correct way. Thanks for your response Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Solaris 9 upgrade to Solaris 10
VANOLE, MICHAEL J (ATTSI) píše v pá 11. 09. 2009 v 11:58 -0500: Hi, We are running Pg 8.2.6 on sparc-sun-solaris2.9 compiled by gcc 3.4.6. We are planning a server software upgrade to Solaris 10 (binaries and kernel, etc). Has anyone done this, and were there problems when trying to start up postmaster after the upgrade? I did not try it, but I don't expect any problems. Solaris 10 U4 and newer ship PostgreSQL 8.2. Only what you need to know is that S10 uses SMF instead of init scripts. You need to run: svcadm enable postgresql:version_82 more man postgres_82. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Solaris Postgres
John R Pierce píše v út 15. 09. 2009 v 19:53 -0700: anyone on the PG team privvy to Sun Solaris patches for postgres? like patch 138826-04 is Postgres 8.3.7 for Solaris10 Sparc... 138827-04 is the same for Sol10 x86... What is wrong on this? It is standard Solaris way how to deliver fixes. I'm curious if anyone has a clue how long before Sun releases PG 8.4.x in Solaris 'patch' format ... Currently S10 is shipped with three version (8.1, 8.2, 8.3) of PostgreSQL. There is no plan to integrate PG8.4 into S10 at this moment. However I'm finalizing integration into Nevada and 8.4 will appear in the next OpenSolaris release. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Solaris Postgres
John R Pierce píše v so 26. 09. 2009 v 09:44 -0700: I'm curious if anyone has a clue how long before Sun releases PG 8.4.x in Solaris 'patch' format ... Currently S10 is shipped with three version (8.1, 8.2, 8.3) of PostgreSQL. There is no plan to integrate PG8.4 into S10 at this moment. However I'm finalizing integration into Nevada and 8.4 will appear in the next OpenSolaris release. ok, I asked because I'm pretty sure Sol10 originally only came with 8.1, and 8.2 then later 8.3 were added as part of incremental updates (don't know offhand which update added what) so, in mainstream solaris as opposed to opensolaris, 8.4 isn't likely to be released any time soon? No. If somebody will approve to integrate it into S10 (some people does not like idea to have four version of PostgreSQL inside :-). PG8.4 could appear in S10 update 9 which will be released in first half of next year. But, S10U9 new feature deadline window is coming... I asked because we're working on an inhouse app using postgres, the team wants to use 8.4... I had previously packaged 8.3.7 in solaris package format only to have it come out as a patch a month or two later, so I was hoping to save myself the redundant effort. You can use community build [1] which is compiled similar way as official Solaris packages. Or you have to wait to Solaris next release. Zdenek [1] http://www.postgresql.org/download/solaris -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Solaris Postgres
John R Pierce píše v so 26. 09. 2009 v 10:57 -0700: Zdenek Kotala wrote: I asked because we're working on an inhouse app using postgres, the team wants to use 8.4... I had previously packaged 8.3.7 in solaris package format only to have it come out as a patch a month or two later, so I was hoping to save myself the redundant effort. You can use community build [1] which is compiled similar way as official Solaris packages. Or you have to wait to Solaris next release. thats what we're using now, and in fact, my packages for 8.3 were built from the community build prior to it being included in U7 or whatever. the main thing I miss from the community builds is having the SMF manifest [1], and I've figured out how to hack my own by using Sun's 8.x release manifest and methods files as a template.. Hmm, it is good point. I'm thinking to add SMF manifest into Pg repository for next release. However I will discus it with Bjorn we could add it into next minor release update. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 8.3.4 Solaris x86 compilation issues
Hi, It is really strange. Is there any reason why you don't use integrated SSL? 64bit version is located in /usr/sfw/lib/64 Try ./configure --prefix=/opt/usr/local --with-libs=/usr/sfw/lib/64:/opt/usr/local/lib --without-readline --with-openssl CFLAGS= -m64 -xmodel=medium Or you canuse precompiled binaries from PostgreSQL web site. Zdenek Dot Yet napsal(a): Hi everyone, i am facing some problem while compiling postgresql 8.3.4 on Solaris 10 x86 10u5. the compiler is SunStudio 12. The compilation happens without errors, but make check fails: OpenSSL 0.9.8i compiled as: ./Configure --prefix=/opt/usr/local -m64 -xmodel=medium PostgreSQL 8.3.4 compiled as: ./configure --prefix=/opt/usr/local --with-libs=/opt/usr/local/lib --without-readline --with-openssl CFLAGS= -m64 -xmodel=medium The error happens while running make check: ./pg_regress --temp-install=./tmp_check --top-builddir=../../.. --srcdir=/export/home/dotyet/pginst/postgresql-8.3.4/src/test/regress --temp-port=55432 --schedule=./parallel_schedule --multibyte=SQL_ASCII --load-language=plpgsql == removing existing temp installation== == creating temporary installation== == initializing database system == == starting postmaster== Killed Killed Killed Killed Killed Killed if I remove the --with-openssl, everything works as expected. any thoughts? thanks in advance. dotyet -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 8.3.4 Solaris x86 compilation issues
I know solaris FAQ well. There is mention OpenSSL problem with Solaris 8. Solaris 9 and newer are OK. They ship OpenSSL version which really work. Zdenek postgres Emanuel CALVO FRANCO napsal(a): do you just read FAQ_Solaris in the docs. I don't remember at all, but is explain some steps to run with SSL. 2008/11/1, Zdenek Kotala [EMAIL PROTECTED]: Hi, It is really strange. Is there any reason why you don't use integrated SSL? 64bit version is located in /usr/sfw/lib/64 Try ./configure --prefix=/opt/usr/local --with-libs=/usr/sfw/lib/64:/opt/usr/local/lib --without-readline --with-openssl CFLAGS= -m64 -xmodel=medium Or you canuse precompiled binaries from PostgreSQL web site. Zdenek Dot Yet napsal(a): Hi everyone, i am facing some problem while compiling postgresql 8.3.4 on Solaris 10 x86 10u5. the compiler is SunStudio 12. The compilation happens without errors, but make check fails: OpenSSL 0.9.8i compiled as: ./Configure --prefix=/opt/usr/local -m64 -xmodel=medium PostgreSQL 8.3.4 compiled as: ./configure --prefix=/opt/usr/local --with-libs=/opt/usr/local/lib --without-readline --with-openssl CFLAGS= -m64 -xmodel=medium The error happens while running make check: ./pg_regress --temp-install=./tmp_check --top-builddir=../../.. --srcdir=/export/home/dotyet/pginst/postgresql-8.3.4/src/test/regress --temp-port=55432 --schedule=./parallel_schedule --multibyte=SQL_ASCII --load-language=plpgsql == removing existing temp installation== == creating temporary installation== == initializing database system == == starting postmaster== Killed Killed Killed Killed Killed Killed if I remove the --with-openssl, everything works as expected. any thoughts? thanks in advance. dotyet -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
Randal T. Rioux napsal(a): On Tue, September 9, 2008 5:25 am, Zdenek Kotala wrote: Randal T. Rioux napsal(a): I've battled this for a while. I'm finally breaking down and asking for help. If you're answer to this is why 64-bit then don't answer. You wouldn't understand. Same if you say why don't you use packages. Here is my scenerio: - Sun 420R x450Mhz UltraSPARC-II / 4GB RAM - Solaris 10 05/08 - OpenSSL 0.9.8h - PostgreSQL 8.3.3 - GCC 3.4.6 - GNU Make 3.81 Three questions (yeah, you forbided ask, but ...) grumble grumble grumble... 1) Why 64 64bit code on SPARC is slower, because SPARC uses 4byte instructions and processing 64bit data needs more instructions. It is good only if you need more then 4GB share memory. When you use sunstudio compiler with best optimization 64bit application has 1%-5% performance degradation. A. Many databases use more than 4GB share memory. Of course but you mention that you have only 4GB RAM. B. Re: SunStudio - that's why I'm using GCC. I don't understand you there. Sunstudio generates better code on SPARC and it is faster than code produced with GCC. 2) Why you don't use package You can use Solaris'es packages, which are integrated and optimized for Solaris. Which are bloated with stuff I don't need and missing stuff I do. Not to mention terribly outdated. Could you be more specific? If is there something what you missing or what is wrong in Solaris'es packages let me know. Maybe I can improve it. 3) Why you don't use build-in libssl? Integrated libssl is not only copy of original open ssl. It has lot of improvements and it uses crypto hardware accelerator if you have it (for example Niagara 2). But it is 32-bit. No, You have 64bit version in /usr/sfw/lib/64. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
Randal T. Rioux napsal(a): On Wed, September 10, 2008 10:54 am, Zdenek Kotala wrote: I just don't like the Solaris package system in general. It is, dare I say, worse than RPM. But this is a PostgreSQL list, so I'll save the rant! Community solaris package on postgresql download website is only tarbal. Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
Randal T. Rioux napsal(a): On Mon, September 8, 2008 9:38 am, Randal T. Rioux wrote: Found a kludgy fix! cp /usr/local/lib/sparcv9/libgcc_s.so.1 /usr/sfw/lib/sparcv9/ Now, both OpenSSL and PostgreSQL work great. In 64-bit mode. If anyone has a less hack-ish solution, please share. try to look on original Makefile for solaris fro inspiration: http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/postgres/postgresql-8.3/ http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/postgres/postgresql-8.3/Makefile.sfw Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
Tom Lane napsal(a): I'm not a Solaris user I can sent you a installation media ;-), if you want. , but I'd be kinda surprised if Solaris' own libraries were built with gcc --- Sun has their own compiler no? Yes, sun studio. It is not installed by default, but it is possible to download it from http://developers.sun.com/sunstudio/downloads/. It is highly recommended to use sun studio compiler on SPARC. GCC is slower (~30%) and generates slower and sometimes buggy code on SPARC. Solaris 10 is compiled with Sun Studio 10, however integrated PostgreSQL is compiled with Sun Studio 11. Only gcc is compiled with gcc :-). Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Postgres in a solaris zone - patch 125077-02 needed
Markova, Nina napsal(a): Hi, I am working on installing postgres ina zone - zoneadm install command finished with errors : Error: /usr/lib/libkrb5.so.1 not found. Please install the patch for 6381288 (we should expose the krb5 api). The patch needed is 125077-02 for SPARC and 125078-02 for x86 systems. pkgadd: ERROR: checkinstall script did not complete successfully I wasn't able to find 125077-02 patch for SPARC, and contacted SUN last week - they are very slow. Had anybody encountered the same problem? How have you solved it? Do you by chance have patch in question handy, so you can email it to me. What version of postgreSQL and Solaris (include update version) do you use? Do you use official solaris'es packages? Kerberos 5 has been integrated in Solaris 10 update 4. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
Randal T. Rioux napsal(a): I've battled this for a while. I'm finally breaking down and asking for help. If you're answer to this is why 64-bit then don't answer. You wouldn't understand. Same if you say why don't you use packages. Here is my scenerio: - Sun 420R x450Mhz UltraSPARC-II / 4GB RAM - Solaris 10 05/08 - OpenSSL 0.9.8h - PostgreSQL 8.3.3 - GCC 3.4.6 - GNU Make 3.81 Three questions (yeah, you forbided ask, but ...) 1) Why 64 64bit code on SPARC is slower, because SPARC uses 4byte instructions and processing 64bit data needs more instructions. It is good only if you need more then 4GB share memory. When you use sunstudio compiler with best optimization 64bit application has 1%-5% performance degradation. 2) Why you don't use package You can use Solaris'es packages, which are integrated and optimized for Solaris. 3) Why you don't use build-in libssl? Integrated libssl is not only copy of original open ssl. It has lot of improvements and it uses crypto hardware accelerator if you have it (for example Niagara 2). See more: http://blogs.sun.com/janp/ http://blogs.sun.com/janp/entry/on_openssl_versions_in_solaris Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Connection problem
Do you have any core dump? Stack trace should help. Zdenek A B napsal(a): I get a lot of Error server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. and I think I need some help finding out what is the problem. Any suggestions on where to start? I think I have maximum logging on (debug5) but prior to the crash I get no log. I connect to the server with php/apache and I use pg_pconnect to get persistent connections. The first log message for a working request to the server says: LOG: 0: connection received: host=[local] LOCATION: BackendInitialize, postmaster.c:2755 DEBUG: 0: forked new backend, pid=6961 socket=8 LOCATION: BackendStartup, postmaster.c:2581 DEBUG: 0: received password packet LOCATION: recv_password_packet, auth.c:940 LOG: 0: connection authorized: user=myuser database=mydb LOCATION: BackendInitialize, postmaster.c:2825 DEBUG: 0: postmaster child[6961]: starting with ( LOCATION: BackendRun, postmaster.c:2925 DEBUG: 0: postgres LOCATION: BackendRun, postmaster.c:2928 DEBUG: 0: -v196608 LOCATION: BackendRun, postmaster.c:2928 DEBUG: 0: -y LOCATION: BackendRun, postmaster.c:2928 DEBUG: 0: mydb LOCATION: BackendRun, postmaster.c:2928 DEBUG: 0: ) LOCATION: BackendRun, postmaster.c:2930 DEBUG: 0: InitPostgres LOCATION: PostgresMain, postgres.c:3142 DEBUG: 0: StartTransaction LOCATION: ShowTransactionState, xact.c:4001 DEBUG: 0: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 8513010/1/0, nestlvl: 1, children: LOCATION: ShowTransactionStateRec, xact.c:4026 DEBUG: 0: CommitTransaction LOCATION: ShowTransactionState, xact.c:4001 DEBUG: 0: name: unnamed; blockState: STARTED; state: INPROGR, xid/subid/cid: 8513010/1/0, nestlvl: 1, children: LOCATION: ShowTransactionStateRec, xact.c:4026 DEBUG: 0: StartTransactionCommand LOCATION: start_xact_command, postgres.c:2200 STATEMENT: SELECT count(*) FROM Users DEBUG: 0: StartTransaction LOCATION: ShowTransactionState, xact.c:4001 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Collate problem when using ORDER BY
David Harel napsal(a): Hi, I'm new here. I work on a site that uses postgres version 8.1.5 and database encoding ISO_8859_8. When I sort select requests using order by the weight of the characters seem to be really funny (but consistent). It seems to me that if I create a phantom converted field such as: SELECT field convert(field, ISO_8859_8 ,UTF8) as field_utf8 ORDER BY field_utf8; Then the sort will be OK however, I get the error: Query failed: ERROR: character 0xd7 of encoding ISO_8859_8 has no equivalent in UTF8. Is it due to a bad character in the content? Can I get rid of it like find/replace? Can I change collate for a given table/database? You can use only one encoding per database. It means you convert data from UTF8 to ISO_8859_8, but you store it back into UTF8 encoded field. Probably strcoll function is confused with illegal UTF8 character which has been created by your conversion. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] ERROR: could not open relation
Q Master napsal(a): I get this strange error Caused by: org.postgresql.util.PSQLException: ERROR: could not open relation 1663/53544/58374: No such file or directory How do I recover from it ? Version 8.2 on windows. I think I had an hardware issue in the past where my box rebooted few times I assume this is due to that thing. I tried to re index them but is not working. Any ideas ? You lost file related to table 58374 and database 53544. Check presence file with name 58374 in directory base/53544. You can determine which table is it: 1) get database name select * from pg_database where oid=53544 2) get table name (connect to affected database) select * from pg_class where oid=58374 Probably there is no much what you can do. Only restore from backup. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] ERROR: could not open relation
Gurjeet Singh napsal(a): The query should be select * from pg_class where relfienode = 58374 Yeah, of course. Thanks Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb in 8.3
Richard Huxton napsal(a): I think someone is looking at per-database locales for 8.4 - the issue is more tricky than you might think because you need to worry about system catalogue sort-order. There is Google Soc project for implementing collation per database level. I hope it will appear in 8.4 version. Catalog sort-order is not affected by locale, because name data type uses different operator then varchar. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pl/java on Solaris
Roberts, Jon napsal(a): I don't see a pljava file in my share directory like I do on Windows. Is pl/java not included when compiling from source? pl/java is not part of core like pl/pgPerl... You need to download it separately from http://pgfoundry.org/projects/pljava/ Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] too many trigger records found for relation xyz
Mikko Partio napsal(a): Hello all Postgres version 8.3.1 I just created a bunch of tables (~10) with identical structure; all tables have 6 foreign key references to other tables and a primary key. To my surprise, some of the tables were created ok, some missed primary key and some didn't get created at all. Can you provide self contained reproduction scenario? Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] too many trigger records found for relation xyz
Mikko Partio napsal(a): I little investigation showed that there is duplicate row in pg_class: # select oid from pg_class group by oid having count(*) 1 ; oid 294397 (1 row) Could you check if pg_attribute is doubled for this relation? Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] too many trigger records found for relation xyz
Mikko Partio napsal(a): Should I try remove one of the duplicate rows from pg_class? Try it with caution. You should use ctid column to refer to exact row. Try before: select oid, ctid, xmin, xmax, cmin, cmax, relname from pg_class where oid = 294397; If both row are identical or not. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] too many trigger records found for relation xyz
Mikko Partio napsal(a): On Tue, Apr 8, 2008 at 1:45 PM, Zdenek Kotala [EMAIL PROTECTED] wrote: Mikko Partio napsal(a): Should I try remove one of the duplicate rows from pg_class? Try it with caution. You should use ctid column to refer to exact row. Try before: select oid, ctid, xmin, xmax, cmin, cmax, relname from pg_class where oid = 294397; If both row are identical or not. # select oid, ctid, xmin, xmax, cmin, cmax, relname from pg_class where oid = 294397; oid | ctid|xmin|xmax| cmin | cmax | relname +---+++--+--+-- 294397 | (1125,36) | 3944654557 | 0 | 35 | 35 | abc 294397 | (1124,55) | 3943984380 | 3943984642 |3 |3 | abc (2 rows) Which one should I remove? What is the worst case scenario for the delete? The database is 1,5TB so I would rather not restore it from backups :-) (1124,55) is deleted one. This row should not be visible. But it seems a problem with visibility - transaction wraparound. Do you have any warning message in the log about vacuuming? Or clog corruption when transaction 3943984642 is marked as rollbacked. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] too many trigger records found for relation xyz
Mikko Partio napsal(a): How can I tell if there is clog corruption? Unfortunatelly, I'm afraid that there is not way how to check it. CLOG file is only array of bits and it does not contains any CRC or backup copy. Try to check filesystem integrity. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] too many trigger records found for relation xyz
Mikko Partio napsal(a): On Tue, Apr 8, 2008 at 5:26 PM, Mikko Partio [EMAIL PROTECTED] wrote: Ok I removed the faulty tuple and nothing catastrophical happened. I can do a pg_dump now, but I still can't remove the one remaining table: # drop table xyz ; ERROR: too many trigger records found for relation xyz Any insight for this problem? I managed to solve the situation with the help of this thread: http://archives.postgresql.org/pgsql-bugs/2007-02/msg00167.php Everything seems to be ok for now, but I'm still curious what caused to whole mess to begin with. It is really strange. It would be nice to have reproduce scenario. Can you run same DDL command which invoke a catalog corruption on test database cluster? Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Can Postgres 8.x start if some disks containing tablespaces are not mounted?
Morris Goldstein napsal(a): But that makes me wonder: what about this sequence of events: - Postgres running normally on /dev/sda and /dev/sdb. - Update to table in /dev/sdb tablespace is committed but still exists in WAL. - Postgres crashes (e.g. power failure). - Postgres starts with /dev/sda only. - Recovery needs to update table in /dev/sdb tablespace. I assume bad things will happen in this case. yes, Probably best solution in this case is to implemented tablespace availability into postgreSQL and PostgreSQL shouldn't start when tablespace is missing. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Can Postgres 8.x start if some disks containing tablespaces are not mounted?
Morris Goldstein napsal(a): Suppose I have a database with $PGDATA on /dev/sda, and a tablespace directory on /dev/sdb. Will Postgres start successfully if /dev/sda is mounted and /dev/sdb is not? If not, why not? It is not good idea to run PostgreSQL in your scenario. However PostgeSQL needs only catalog tables to start. Until you don't touch data stored on unmounted disk you should not get any error. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Locale / Encoding mismatch
PG 8.3 has strict rule what CTYPE and LOCALLE is allowed. It is protection before possible problems with data processing. You probably need set en_AU.uft8 locale when you initialize server. Zdenek Naz Gassiep napsal(a): I have just attempted to upgrade to 8.3.1 and I now get this error when trying to create a UTF8 DB: [EMAIL PROTECTED]:~$ createdb twerl -E utf8 createdb: database creation failed: ERROR: encoding UTF8 does not match server's locale en_AU DETAIL: The server's LC_CTYPE setting requires encoding LATIN1. I have never bothered with the server's locale, all the locale handling in the app gets handled within the DB itself. I guess I now have to dig into the murky world of system locales and how they affect my app ecosystem. I don't suppose there is an easy solution to this and a short explanation of why it now occurs is there? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Survey: renaming/removing script binaries (createdb, createuser...)
Greg Sabino Mullane napsal(a): snip Nobody want to rename psql. Personaly, I dislike current command names for long long time. Many times I tried create unix user by createuser command. And these names could be potential names of system commands. Yours is the first time I've heard of anyone with this problem. The useradd and adduser commands don't even start with the same letter. If it's that confusing, you can always use an alias or a symlink to make things more inline with what you want. It is not about letters but about memory :-). Currently it is not problem for me, but it was when I was starting play with Linux. For the record, I think any renaming is a terrible idea, and a solution in search of a problem. Any change, no matter how long it takes, will break untold number of scripts, make us look bad, and frustrate people, similar to the way that implicit cast removal did in 8.3, but without the Very Good Reason to show people why we made the change. I understand this point of view. And it is reason also why I asked if people use these commands or they prefer psql. For example nobody had complained that createtablespace command is missing. Does it mean that nobody uses tablespaces? It means everybody must use psql for tablespace creation. I personally use psql for everything. Only sometimes I use vacumdb or createuser command. Unfortunately, I not good survey maker and some tools usage statistic could be nice to have in survey as well. :( I have lived with current names and I can live with them in the future as well. Additionally, once we make the change, to which version do we refer to in the docs or when answering questions? You can't safely refer to the new commands until they've had time to percolate through as people update their database. And considering that I still work with some 7.3 system, and plenty of 7.4 ones, that could be a long time. Doc is related to version. And if you look on postmaster command in latest documentation that it says obsolete use postgres. *If* we're going to do this, at the very least it needs to be rolled out as a point revision update across all versions, so we minimize the confusion for people on older versions. We also need to keep symlinks or some other backwards-compatibilty around for a long time, *and* make a clean break at some future major version with lots of prior warning. I don't think so, that backport is necessary, but backward compatibility is obvious for new severals releases. By the way does postgreSQL has some EOL strategy? There are lot of OBSOLETE thinks mentioned in documentation, but I have never seen a list/roadmap when they will be removed. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Survey: renaming/removing script binaries (createdb, createuser...)
Alvaro Herrera napsal(a): Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Greg Smith wrote: And if anybody suggests putting a _ in something I have to type all the time, I will stick my fingers in my ears and start yelling until they stop. Bad enough I have to type pg_ctl a few times every day now. alias pgctl=pg_ctl Still, if we can't have pg then the whole idea loses a lot of its appeal. I'm not excited about having to type pgcmd createdb ..., much less anything longer. What about pgc? And what about two commands one for create and one for drop? It save 6 or 4 chars. pgc db (as create db) pgc user pgd db (as drop db) pgd user Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Survey: renaming/removing script binaries (createdb, createuser...)
Alvaro Herrera napsal(a): Zdenek Kotala wrote: And what about two commands one for create and one for drop? It save 6 or 4 chars. pgc db (as create db) pgc user pgd db (as drop db) pgd user Well, there are things besides create and drop -- for example vacuum. Yeah, good point I forgot vacuum and reindex. OK pgc looks good. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Survey: renaming/removing script binaries (createdb, createuser...)
Tom Lane napsal(a): Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: I like this too. It'd be considerably more work than the currently proposed patch, though, since we'd have to meld the currently separate programs into one executable. I note that we can continue to have the current executables stashed in PREFIX/share/libexec and let the pg executable exec them. Not share/ surely, since these are executables, but yeah. This brings me to the idea that pg is a very small stupid program that just tries to match its first argument against a filename in PREFIX/libexec/postgresql. If it finds a match it execs that program with the remaining args, else it fails. If we do it that way then the problem of a client-only installation is solved: it merely has a smaller population of files in PREFIX/libexec, and pg doesn't know the difference. Also the problem of optionally providing the old names just reduces to providing links in bin/, whereas with a melded executable we'd need still more smarts to look at how it'd been invoked. So +2 or so for this one. It sounds good. Only one comments libexec is not on Solaris, but PREFIX/lib is allowed to use for this purpose. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Survey: renaming/removing script binaries (createdb, createuser...)
Naz Gassiep napsal(a): We're not seriously thinking of changing these are we? Once a command set has been in use for as long a time as the PG command set has, any benefit that may be derived by new users with an aversion to documentation reading is vastly offset by the confusion that would result among long time users whos scripts, tools and mental mental processes all have the old names hardcoded in. Yes, I understand your point of view, but on other side there are arguments in discussion, that for newbies old name are terrible to use and frankly, who reads manual before he start to use a product? I can't imagine how there would be a nomenclature clash, if there is, then just take one of the tools out of the path, use symlinks or put calling scripts in the path instead. These are suboptimal solutions, granted, but *any* naming scheme we change to will be subject to the possibility of naming clashes with another package with a similar name, unless we make the binaries have long, verbose names. I don't know about you, but I don't fancy having to type postgresqlclient dbname to start a DB. I like psql dbname. Nobody want to rename psql. Personaly, I dislike current command names for long long time. Many times I tried create unix user by createuser command. And these names could be potential names of system commands. So I ask again, we're not seriously thinking about this are we? Yes, we are. And this is a reason why I prepare this survey, because we could not reach a decision on the -hackers. However, it seems that we choose third variant with new wrapper command pgc. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Survey: renaming/removing script binaries (createdb, createuser...)
Ron Mayer napsal(a): Tom Lane wrote: Leif B. Kristensen [EMAIL PROTECTED] writes: On Wednesday 26. March 2008, Ron Mayer wrote: ...a pg program that took as arguments the command. So you'd have pg createdb instead of pg_createdb. I'll second that. ... I like this too. Though I guess we might need to find a different name if we want to go down that path. man pg tells me browse pagewise through text files. IMHO postgres createdb is still better than the whole bunch of separate commands. Or even pgSQL createdb just so people know it's not a pre-SQL postgres database :-) My personal preference is pg_cmd :-). Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Survey: renaming/removing script binaries (createdb, createuser...)
Tom Lane napsal(a): Leif B. Kristensen [EMAIL PROTECTED] writes: On Wednesday 26. March 2008, Ron Mayer wrote: I'd prefer a pg program that took as arguments the command. So you'd have pg createdb instead of pg_createdb. I'll second that. It would be much easier on the brain, as you might issue a pg --help if you don't remember the exact syntax or even the name of each command. I like this too. It'd be considerably more work than the currently proposed patch, though, since we'd have to meld the currently separate programs into one executable. One fairly serious objection is that doing so would eliminate the current distinction between client-side and server-side applications, at least if we wanted to fold both sets into one pg executable. So a client-only install would be carrying some baggage in the form of code that's useless if the server isn't local. If we are OK with restricting the scope of the pg program to client-side functionality, then there's no problem. I think we can use pg (or pg_cmd) for client side and integrate initdb and other tools into pg_ctl, as a pg_ctl init and so on. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Survey: renaming/removing script binaries (createdb, createuser...)
Ron Mayer napsal(a): Zdeněk Kotala wrote: 1) What type of names do you prefer? I'd prefer a pg program that took as arguments the command. So you'd have pg createdb instead of pg_createdb. There are many precedents. cvs update, git pull apt-get install. Anyone else like this approach? One of my original idea was to create pg_cmd command which will integrate all create/drop command in one. For example pg_cmd create database pg_cmd list user and so on. It is also possible solution. But we need split client commands and server commands (initdb, pg_ctl, pg_controldata...). Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Survey: renaming/removing script binaries (createdb, createuser...)
Alvaro Herrera napsal(a): Tom Lane wrote: Leif B. Kristensen [EMAIL PROTECTED] writes: On Wednesday 26. March 2008, Ron Mayer wrote: I'd prefer a pg program that took as arguments the command. So you'd have pg createdb instead of pg_createdb. I'll second that. It would be much easier on the brain, as you might issue a pg --help if you don't remember the exact syntax or even the name of each command. I like this too. It'd be considerably more work than the currently proposed patch, though, since we'd have to meld the currently separate programs into one executable. I note that we can continue to have the current executables stashed in PREFIX/share/libexec and let the pg executable exec them. If we are OK with restricting the scope of the pg program to client-side functionality, then there's no problem. Perhaps we can put the server-side functionality on pg_ctl. +1 Yes, pg(.*) for client side and pg_ctl for server side. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_ctrl stop problems (psql 8.2.5)
LARC/J.L.Shipman/jshipman napsal(a): Hello, I am running postgresql 8.2.5 on Solaris 10. When I try to shut down postgres using pg_ctrl -D datafile stop it does not shutdown.Does anyone know why this is, or what files pg_ctrl access to determine the shutdown process. We have tried deleting a pgsql semaphore file located in tmp. This did not help. Any help is appreciated. Solaris uses SMF for starting and stopping postgreSQL. If postgres was started by SMF then it tries to restart when it fails (or stopeed another way). try svcs postgresql it shows you status. svcs disable postgresql:version_82 stop postgresql. See man postgres_82 for detail. Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
