Re: [ADMIN] iconv -c ?
On 7/22/13 5:06 AM, Jan-Peter Seifert wrote: Gesendet: Sonntag, 21. Juli 2013 um 16:03 Uhr Von: Peter Eisentraut pete...@gmx.net On Mon, 2013-07-15 at 16:55 +0200, Jan-Peter Seifert wrote: it seems ( for quite some time now ) that PostgreSQL is using the -c option of iconv when exporting data to a different encoding: http://www.gnu.org/savannah-checkouts/gnu/libiconv/documentation/libiconv-1.13/iconv.1.html PostgreSQL doesn't use iconv at all. Hello Peter, sure? The Windows versions of PostgreSQL ( 8.4 - 9.2 ) have an iconv.dll in their bin folder. That might be because it's a dependency of gettext. -- 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] Starting psql without connection
On Sun, 2013-07-07 at 10:11 +0200, Thorsten Kampe wrote: is it possible to start psql in interactive mode without connecting to a database (similar to sqlplus /nolog for Oracle databases)? No, that's not possible. -- 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] Upgrading 9.0.5 to 9.0.13 on ubuntu 10.4
On 6/6/13 8:01 PM, Kasia Tuszynska wrote: dpkg: error processing /var/cache/apt/archives/postgresql-9.0_9.0.13-1.pgdg10.4+1_amd64.deb (--unpack): trying to overwrite '/usr/share/locale/zh_TW/LC_MESSAGES/plpython-9.0.mo', which is also in package postgresql-plpython-9.0 0:9.0.5-1~lucid dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/postgresql-9.0_9.0.13-1.pgdg10.4+1_amd64.deb This appears to be a packaging bug. You can probably work around the issue by temporarily uninstalling the postgresql-plpython-9.0 package. -- 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] UNIX vs Windows LC CTYPE and UPPER mu
On tor, 2012-04-19 at 10:02 +0200, Albe Laurenz wrote: After looking at the UNICODE character list I tend to agree that code point 0xB5 (MICRO SIGN) should not be converted to 0x39C (GREEK CAPITAL LETTER MU). There's 0x3BC for GREEK SMALL LETTER MU. http://www.unicode.org/Public/UNIDATA/UnicodeData.txt has: 00B5;MICRO SIGN;Ll;0;L;compat 03BCN;;;039C;;039C and 039C;GREEK CAPITAL LETTER MU;Lu;0;L;N03BC; So this mapping is correct. Case conversion is not necessarily round-trip. -- 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] re-create information_schema
On ons, 2012-02-29 at 16:25 -0500, Ray Stell wrote: On Wed, Feb 29, 2012 at 03:55:13PM -0500, Ray Stell wrote: http://www.postgresql.org/docs/9.1/static/release-9-1-2.html This must be repeated in each database to be fixed. including postgres, template0, and template1? Yes, if you want those databases to be fixed. -- 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] unix domain sockets on Windows.
On lör, 2011-12-31 at 17:06 -0800, Jeff Rule wrote: Does the postgres server support listening on unix domain sockets on windows? No. It seems to me that they do not, but this is not called out directly in the documentation. Listen_address in postgresql.conf listen_addresses = '' # what IP address(es) to listen on; # comma-separated list of addresses; # defaults to 'localhost', '*' = all # (change requires restart) It says right there that it controls what *IP addresses* to listen to. It does not have anything to do with Unix-domain sockets. There are other options that control whether and where those are created. -- 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] check_postgres monitor by Bucardo - any opinions?
On tor, 2011-10-20 at 14:16 -0400, Mark Steben wrote: Hi all, I'm evaluating the check_postgres program. We are running postgres 8.3. Does anybody have any experience with this monitoring software they would like to share? I'm specifically interested in the 'postgres_bloat' program but would welcome any comments about anything germaine to check_postgres. It's a nice tool, but it has lots of bugs, and a new release usually fixes 3 and introduces 2 new ones. So I'm a little careful about upgrading. -- 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] Problem of LD_LIBRARY_PATH
On sön, 2011-09-18 at 14:56 +0800, Rural Hunter wrote: This is my env: postgres@backup:~$ env MANPATH=:/opt/PostgreSQL/9.1/share/man SHELL=/bin/bash TERM=linux USER=postgres LD_LIBRARY_PATH=/opt/PostgreSQL/9.1/lib/ PGPORT=3500 LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*. x wd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36: PGUSER=postgres PGDATABASE=postgres MAIL=/var/mail/postgres PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/opt/PostgreSQL/9.1/bin PWD=/home/postgres LANG=zh_CN.UTF-8 SHLVL=1 HOME=/home/postgres LANGUAGE=zh_CN:zh LOGNAME=postgres PGDATA=/raid/PostgreSQL/data LESSOPEN=| /usr/bin/lesspipe %s LESSCLOSE=/usr/bin/lesspipe %s %s _=/usr/bin/env To make top/vi work, I just need to unset LD_LIBRARY_PATH. What else do you have installed in /opt/PostgreSQL/9.1/lib/? Can you show a directory listing? -- 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] Problem of LD_LIBRARY_PATH
On sön, 2011-09-18 at 22:41 +0800, Rural Hunter wrote: I didn't install anything else there: (for a very small value of anything else) It looks like you have some version of libncurses in there, which is prone to interfere with the operating system installation. I suppose you got this installation from some third-party installer. So you might want to check their precise installation instructions, or report a bug if they don't work. I think setting LD_LIBRARY_PATH should not actually be necessary. Alternatively, install the official Ubuntu package. postgres@backup:~$ ls -l /opt/PostgreSQL/9.1/lib/ Total 9804 -rwxr-xr-- 1 root daemon 1366272 2011-09-09 13:45 libcrypto.so.6 -rw-r--r-- 1 root daemon 149938 2011-09-09 13:44 libecpg.a -rw-r--r-- 1 root daemon 18852 2011-09-09 13:44 libecpg_compat.a -rwxr-xr-x 1 root daemon 23327 2011-09-09 14:03 libecpg_compat.so -rwxr-xr-x 1 root daemon 23327 2011-09-09 14:03 libecpg_compat.so.3 -rwxr-xr-x 1 root daemon 23327 2011-09-09 14:03 libecpg_compat.so.3.3 -rwxr-xr-x 1 root daemon 87003 2011-09-09 14:03 libecpg.so -rwxr-xr-x 1 root daemon 87003 2011-09-09 14:03 libecpg.so.6 -rwxr-xr-x 1 root daemon 87003 2011-09-09 14:03 libecpg.so.6.3 -rwxr-xr-- 1 root daemon 192738 2011-09-09 13:45 libedit.so lrwxrwxrwx 1 root root17 2011-09-13 13:47 libjpeg.so - libjpeg.so.62.0.0 lrwxrwxrwx 1 root root17 2011-09-13 13:47 libjpeg.so.62 - libjpeg.so.62.0.0 -rwxr-xr-- 1 root daemon 138936 2011-09-09 13:45 libjpeg.so.62.0.0 -rwxr-xr-- 1 root daemon 59040 2011-09-09 13:45 liblber-2.3.so.0 -rwxr-xr-- 1 root daemon 241360 2011-09-09 13:45 libldap-2.3.so.0 -rwxr-xr-- 1 root daemon 260568 2011-09-09 13:45 libldap_r-2.3.so.0 lrwxrwxrwx 1 root root15 2011-09-13 13:47 libncurses.so - libncurses.so.5 lrwxrwxrwx 1 root root17 2011-09-13 13:47 libncurses.so.5 - libncurses.so.5.5 -rwxr-xr-- 1 root daemon 380336 2011-09-09 13:45 libncurses.so.5.5 -rw-r--r-- 1 root daemon 60292 2011-09-09 13:43 libpgport.a -rw-r--r-- 1 root daemon 101184 2011-09-09 13:44 libpgtypes.a -rwxr-xr-x 1 root daemon 68966 2011-09-09 14:03 libpgtypes.so -rwxr-xr-x 1 root daemon 68966 2011-09-09 14:03 libpgtypes.so.3 -rwxr-xr-x 1 root daemon 68966 2011-09-09 14:03 libpgtypes.so.3.2 lrwxrwxrwx 1 root root18 2011-09-13 13:47 libpng12.so - libpng12.so.0.10.0 lrwxrwxrwx 1 root root18 2011-09-13 13:47 libpng12.so.0 - libpng12.so.0.10.0 -rwxr-xr-- 1 root daemon 149520 2011-09-09 13:45 libpng12.so.0.10.0 -rw-r--r-- 1 root daemon 286182 2011-09-09 13:44 libpq.a -rwxr-xr-x 1 root daemon 189815 2011-09-09 14:03 libpq.so -rwxr-xr-x 1 root daemon 189815 2011-09-09 14:03 libpq.so.5 -rwxr-xr-x 1 root daemon 189815 2011-09-09 14:03 libpq.so.5.4 -rwxr-xr-- 1 root daemon 105464 2011-09-09 13:45 libsasl2.so.2 -rwxr-xr-- 1 root daemon 315032 2011-09-09 13:45 libssl.so.6 lrwxrwxrwx 1 root root13 2011-09-13 13:47 libtermcap.so.2 - libncurses.so lrwxrwxrwx 1 root root18 2011-09-13 13:47 libuuid.so - libuuid.so.16.0.22 lrwxrwxrwx 1 root root14 2011-09-13 13:47 libuuid.so.1 - libuuid.so.1.2 -rwxr-xr-- 1 root daemon 17728 2011-09-09 13:45 libuuid.so.1.2 lrwxrwxrwx 1 root root18 2011-09-13 13:47 libuuid.so.16 - libuuid.so.16.0.22 -rw-r--r-- 1 root daemon 51937 2011-09-09 13:45 libuuid.so.16.0.22 -rwxr-xr-- 1 root daemon 4157970 2011-09-09 13:45 libxml2.so.2 -rwxr-xr-- 1 root daemon 822303 2011-09-09 14:03 libxslt.so.1 drwxr-xr-x 4 root daemon4096 2011-08-25 11:20 postgresql 于2011年9月18日 21:58:17,Peter Eisentraut写到: On sön, 2011-09-18 at 14:56 +0800, Rural Hunter wrote: This is my env: postgres@backup:~$ env MANPATH=:/opt/PostgreSQL/9.1/share/man SHELL=/bin/bash TERM=linux USER=postgres LD_LIBRARY_PATH=/opt/PostgreSQL/9.1/lib/ PGPORT=3500 LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35 : *.x wd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac
Re: [ADMIN] LC_COLLATE and pg_upgrade
On mån, 2011-02-14 at 14:18 +0100, Bernhard Schrader wrote: As far as I read right now, LC_COLLATE is a read_only variable which is used while initdb. But why does the pg_upgrade script doesn't see that utf8 and UTF-8 are the same? Is it just a string compare? Why don't you just reinitialize your new database cluster with the same locale spelling as the old one? Your points are valid, but unfortunately difficult to handle in the general case. -- 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] Logging questions
On fre, 2010-12-10 at 10:01 -0800, Wells Oliver wrote: Hello- a quick question about logging. I'm trying to set logging to the most minimal level possible. e.g. I really don't want to see the following kind of thing: 2010-12-10 09:59:40 PST FATAL: database woliver does not exist Because... so what? Some guy forgot to supply the DB name. I've looked over the logging options in the documentation and they are legion. What are my key options to reduce logging to the lowest, most vital sort of messages? The problem is, the distinction of severity is actually not so much about what is important to you the DBA, but what is important to the session process. The above is important to the session process because the session cannot continue after that error. Other, more severe problems will only show up as error because the session can continue. So unless you want to set log_min_messages to panic, which pretty much means that by the time you see the message your database system is dead, you probably want to log everything at least on level error or warning and then rely on a log analysis tool and/or other monitoring to work out what is important to you. -- 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] failing to compile v. 9.0.1 on debian squeeze with readline
On mån, 2010-12-06 at 00:29 +0200, Imre Oolberg wrote: 4. compile $ make ... gcc -O2 -Wall -Wmissing-prototypes ... ... postmaster/postmaster.o: In function `PostmasterMain': postmaster.c:(.text+0x420c): undefined reference to `optreset' tcop/postgres.o: In function `process_postgres_switches': postgres.c:(.text+0x122b): undefined reference to `optreset' utils/misc/ps_status.o: In function `set_ps_display': ps_status.c:(.text+0xd6): undefined reference to `setproctitle' collect2: ld returned 1 exit status make[2]: *** [postgres] Error 1 make[2]: Leaving directory `/opt/postgres/tmp/postgresql-9.0.1/src/backend' make[1]: *** [all] Error 2 make[1]: Leaving directory `/opt/postgres/tmp/postgresql-9.0.1/src' make: *** [all] Error 2 A workaround seems to ./configure with '--without-readline' (and the above mentioned parameter values get st to 'no') but I would like to ask I compile PostgreSQL on Debian squeeze about 10 times a day and I have never seen that. Could you show the output of dpkg -l \*readline\* -- 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] Syslog line wrapping
On tor, 2010-09-23 at 20:55 -0700, Evan Rempel wrote: I am running Postgresql 8.3 and would like to get postgres to NOT wrap the syslog lines. Is ther any configuration to do this. Perhaps I can wrap them at a very large line number? PostgreSQL 8.4 increased the line length. -- 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] Issues with LC_COLLATE, across 8.3/8.4 on various platforms
On tis, 2010-02-02 at 17:28 +0200, Achilleas Mantzios wrote: It seems that libc's behaviour regarding LC_COLLATE in Linux/FreeBSD are two different stories, hence the seen results. The UTF-8 locales on FreeBSD and Mac OS X are pretty much broken. This is becoming a FAQ ... -- 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] Issues with LC_COLLATE, across 8.3/8.4 on various platforms
On ons, 2010-02-03 at 17:05 +0200, Achilleas Mantzios wrote: Στις Wednesday 03 February 2010 16:53:20 ο/η Peter Eisentraut έγραψε: On tis, 2010-02-02 at 17:28 +0200, Achilleas Mantzios wrote: It seems that libc's behaviour regarding LC_COLLATE in Linux/FreeBSD are two different stories, hence the seen results. The UTF-8 locales on FreeBSD and Mac OS X are pretty much broken. This is becoming a FAQ ... This is a libc/locale combination issue. Care to elaborate? AFAICT for my case in FreeBSD, the greek UTF locale el_GR.UTF-8 behaves as expected without problems. Well, while in all of PostgreSQL 8.3.3 on i686-pc-linux-gnu (lc_collate=C) PostgreSQL 8.3.7 (lc_collate=el_GR.UTF-8) on i386-unknown-freebsd6.3 PostgreSQL 8.4.1 on x86_64-unknown-freebsd8.0 (lc_collate=en_US.UTF-8), gives fooname - Cylinder Liner No1 Cylinder head No1 Cylinder head cover No1 is not a correct sorting result in my book, unless your measure of correctness is ASCII byte value order. And then it's left as an exercise to determine what the results would be for texts involving non-ASCII letters. -- 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] recovery is stuck when children are not processing SIGQUIT from previous crash
On lör, 2009-09-26 at 12:19 -0400, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: strace on the backend processes all showed them waiting at futex(0x7f1ee5e21c90, FUTEX_WAIT_PRIVATE, 2, NULL Notably, the first argument was the same for all of them. Probably means they are blocked on semaphores. Stack traces would be much more informative ... Got one now: #0 0x7f65951eaf8e in ?? () from /lib/libc.so.6 #1 0x7f65951dc218 in ?? () from /lib/libc.so.6 #2 0x7f65951dbcdd in __vsyslog_chk () from /lib/libc.so.6 #3 0x7f65951dc1a0 in syslog () from /lib/libc.so.6 #4 0x006694bd in EmitErrorReport () at elog.c:1404 #5 0x00669935 in errfinish (dummy=-1790575472) at elog.c:415 #6 0x005c291e in quickdie (postgres_signal_arg=value optimized out) at postgres.c:2502 #7 signal handler called #8 0x7f65951e0513 in send () from /lib/libc.so.6 #9 0x7f65951dbeed in __vsyslog_chk () from /lib/libc.so.6 #10 0x7f65951dc1a0 in syslog () from /lib/libc.so.6 #11 0x006694bd in EmitErrorReport () at elog.c:1404 #12 0x00669935 in errfinish (dummy=3) at elog.c:415 #13 0x005c291e in quickdie (postgres_signal_arg=value optimized out) at postgres.c:2502 #14 signal handler called #15 0x7f65951e0303 in recv () from /lib/libc.so.6 #16 0x005486a8 in secure_read (port=0x24a76f0, ptr=0x9ac680, len=8192) at be-secure.c:319 #17 0x0054f3d0 in pq_recvbuf () at pqcomm.c:754 #18 0x0054f817 in pq_getbyte () at pqcomm.c:795 #19 0x005c4d10 in PostgresMain (argc=4, argv=value optimized out, username=0x2478728 xyz) at postgres.c:317 #20 0x0059938d in ServerLoop () at postmaster.c:3218 #21 0x0059a0cf in PostmasterMain (argc=5, argv=0x24731d0) at postmaster.c:1031 #22 0x00551245 in main (argc=5, argv=value optimized out) at main.c:188 Looks like a race condition or lockup in the syslog code. -- 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] recovery is stuck when children are not processing SIGQUIT from previous crash
On tor, 2009-11-12 at 10:45 -0500, Tom Lane wrote: In practice the code path isn't sufficiently used or critical enough to be worth trying to make that bulletproof. Well, the subject line is recovery is stuck. Not critical enough? -- 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] recovery is stuck when children are not processing SIGQUIT from previous crash
On Wed, 2009-09-23 at 10:04 -0400, Tom Lane wrote: I'd prefer not to go there, at least not without a demonstration that this will solve a bug that's unsolvable otherwise. If a child is really stuck in a state that doesn't accept SIGQUIT, it probably won't accept SIGKILL either (eg, uninterruptable disk wait). Or maybe we just have some errant code that is blocking SIGQUIT; but that's a garden variety bug IMO, not something that needs major new postmaster logic to work around. strace on the backend processes all showed them waiting at futex(0x7f1ee5e21c90, FUTEX_WAIT_PRIVATE, 2, NULL Notably, the first argument was the same for all of them. I gather that a futex is a Linux kernel thing, which is probably then used by glibc to implement some pthreads stuff. Anyone know more? But yes, using SIGKILL on these processes works without problem. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] recovery is stuck when children are not processing SIGQUIT from previous crash
I have observed the following situation a few times now (weeks or months apart), most recently with 8.3.7. Some postgres child process crashes. The postmaster notices and sends SIGQUIT to all other children. Once all other children have exited, it would enter recovery. But for some reason, some children are not processing the SIGQUIT signal and are basically just stuck. That means the whole database system is then stuck and won't continue without manual intervention. If I go in manually and SIGKILL the offending processes, everything proceeds normally, recovery finishes, and the system is up again. I haven't had the chance yet to analyze why the SIGQUIT signals are getting stuck. Be that as it may, it appears there are no provisions for this case. I couldn't find any documentation or previous reports on this sort of thing. One might imagine a feature where the postmaster resorts to throwing SIGKILLs around after a while, similar to how init scripts are sometimes set up. But perhaps manual intervention is the way to go. Comments? -- 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] General queries regarding backup
On Wednesday 22 July 2009 08:25:36 Deepak Bala wrote:
Hi everyone,
I have some queries regarding the PITR backup procedure on Postgres
8.3. Here are the steps I follow for backup
1. I set up WAL archiving and checked that this is working.
2. Execute SELECT pg_start_backup('label')
3. Zip the entire data directory excluding the pg_xlog directory.
4. At this point the WAL archive directory contains a .backup file
which looks something like this
0001000B.0020.backup. This recognizes that the WAL
file 0001000B (and all subsequent WAL files) must be
present when we restore the database.
5. The contents of the .backup file looks something like this
START WAL LOCATION: 0/B20 (file 0001000B)
STOP WAL LOCATION: 0/C00 (file 0001000C)
CHECKPOINT LOCATION: 0/B20
START TIME: 2009-07-22 04:02:25 UTC
LABEL: Something
STOP TIME: 2009-07-22 04:02:39 UTC
6. Execute the SELECT pg_stop_backup() command to stop the backup.
I have a few questions about this.
1. I was not able to find the file 0001000C in the WAL
archive location after taking the base backup. Is that normal ? The
file 0001000B exists and is the last WAL file. The
server was stopped after taking the base backup
This is normal, although arguably not desirable. In PostgreSQL 8.4, this was
changed so that pg_stop_backup() waits until the ...000C file in your case is
in the archive. So that is what you want.
2. When I do a restore, postgres will have a look at the
restore_command from my recover.conf to look for all WAL files from
0001000B right ? Is it ok if it does not find
0001000C ?
Yes. Recovery will stop when it runs out of files to restore.
3. Lets assume that after taking the base backup the WAL files with
the suffix 0C 0D 0E etc were generated. What happens if the entire
hard disk crashes but I still have the data directory archived along
with the WAL file 0001000B ? It means that all the
data that was in the DB till the base backup can be recovered but any
subsequent data that was updated / inserted will be lost. Am I right
when I say that ?
In this scenario you would have to restore your *previous* base backup,
because the current base backup wouldn't be usuable, as it requires that the
...000C file be present.
It's always a good idea to have two base backups around, if you can afford the
space, in case something goes wrong during or around the time you take the
next base backup.
--
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] Make the primary key a multilingual value
On Saturday 04 July 2009 20:44:11 Ransika de Silva wrote: I have a requirement of storing multilingual words and hence planing to utilize the Unicode support of the database tables. The question that I have is, will there be a problem if I make the primary key of a table multilingual, Not unless you create the problem yourself. :-) Shouldn't be a problem as far as PostgreSQL is concerned. -- 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] Postgres user with a shell of /bin/false
On Friday 22 May 2009 06:51:42 Cliff Pratt wrote: I've browsed my history of the list, and the Internet for information regarding giving the unix 'postgres' user a shell of /bin/false, so that it cannot be logged into directly. It seems from my research that if I set the user's shell to /bin/false it will not prevent the running of postgres itself. I think it could work, but I don't think it is to be recommended. Sometimes you want to log in as that user to be able to do certain types of special administration or fixes. For example, if you ever need to run pg_resetxlog, you probably want to be logged in as postgres, unless you are very confident that your su or sudo invocations are correct and don't mess up the permissions of the database directory in strange ways. Maybe disabling the password of the account and allowing login only via sudo is close to what you want, but ends up being more flexible. -- 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] Audit Log Destination
On Wednesday 20 May 2009 23:51:53 Arnold, Sandra wrote: One of my security controls is to audit events. I don't have a problem on how to do that. However, another control is for all functionality of the PostgreSQL database to cease or stall if the directory that contains the audit logs is full. What happens to PostgreSQL if any of the log directories are full and unable to have anything else written to it? I have looked and cannot find anything that will tell me what happens. PostgreSQL doesn't have the concept of an audit log. So perhaps you can explain exactly which functionality you are using for that purpose; then we might figure out what happens when the disk is full. In principle, however, you can try this out yourself, by creating a limited- size partition and pointing your log there. That might give you a better feeling for what exactly will happen. -- 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] pg_dump formatting
On Sunday 22 March 2009 06:26:02 Caleb Cushing wrote: COPY blarg (blah, bleh, blerg) FROM stdin; 1 random character data djfa;djjf;sdjl;afkjeoiuoiejk,cxjueiojiojeef98hkjdyf98y92hvniay8syfkdnf38932 hrhf9e83uifnskjj3h9r83hhjnnn2iyfhkjsndfi7y938hnksu879hf089h3n299ssdjfh92 3 the above in pg_dump is one line it'd be easier to diff if it were say on 3, or best yet with the exception of say, binary data or things that can't be wrapped, have the data (for like text records) wrapped at 79 characters or maybe 78 with \ at the end or something... Maybe wdiff will do what you want. -- 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] Postgressql backup/restore question
samana srikanth wrote: Can we do a point-in-time restore of a single database out of n databases??. In principle no. But you could invent workarounds such as recovering to the point where you are happy with your restored one database, and then restore the other n-1 databases from an SQL dump. -- 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] postgres block_size problem
Bhujbal, Santosh wrote: Hi All, We were getting the following error on executing a COPY command on postgres8.2.0. SQL execution failed, Internal error. SQL Statement: (COPY command failed with error: ERROR: row is too big: size 8200, maximum size 8136) So, in order to fix the error we tried increasing the block size to 16k and recompiled the postgres library. The problem at hand was resolved with the new postgres library and we were now able to populate data for the mentioned query successfully. However, this experiment fails when we tried to run the new postgres on data directory generated with 8k block size which is likely to occur during an upgrade with postgres log showing the following error: 2008-12-30 14:57:33 IST DETAIL: The database cluster was initialized with BLCKSZ 8192, but the server was compiled with BLCKSZ 16384. 2008-12-30 14:57:33 IST HINT: It looks like you need to recompile or initdb. What could be the possible solution to this? If you want to migrate data from an 8k block size data directory to a 16k block size data directory, you need to do a dump and restore, just like on a major version upgrade. -- 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] initdb locale discrepancy
Subbiah Stalin-XCGF84 wrote: The following is the message we had got while setting up postgres database. This message was overlooked when we setup but now we have found the discrepancies. For now the database are created with encode type as UTF8 but the locale settings are ISO8859-1 in postgresql.conf. The question i have is, what will be impact if we don't use any multibyte characters in the mix. If you only use ASCII characters, then there will be no effect. Else, you might experience incorrect results and possibly crashes when doing sort operations or other string manipulation operations on the affected strings. -- 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] 8.3.4 rpms for Opensuse10.3 64bit
Gerd König wrote: a few months ago we started using Postgres on Opensuse10.3-64bit. We installed Postgres 8.3.1 with the (at that time) latest available rpm's. But now Postgres' current version is 8.3.4 and I'm wondering why there are no new rpm's for Opensuse ?!?! The answer is quite simply that no one is volunteering to do the work. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [GENERAL] [ADMIN] 8.3.4 rpms for Opensuse10.3 64bit
Dave Page wrote: 2008/9/23 Peter Eisentraut [EMAIL PROTECTED]: Gerd König wrote: a few months ago we started using Postgres on Opensuse10.3-64bit. We installed Postgres 8.3.1 with the (at that time) latest available rpm's. But now Postgres' current version is 8.3.4 and I'm wondering why there are no new rpm's for Opensuse ?!?! The answer is quite simply that no one is volunteering to do the work. Oh, I thought you were looking after that build. If it's not being maintained, we'll need to remove it from the download pages unless someone else can volunteer? I am looking after it, but I cannot guarantee real-time releases with the resources available to me. Certainly, one or two more people joining the looking after would be welcome. I did some work recently to put all the pieces in place, so at this time we basically only need to replace the tarballs and release once in a while. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [GENERAL] [ADMIN] 8.3.4 rpms for Opensuse10.3 64bit
Devrim GÜNDÜZ wrote: On Tue, 2008-09-23 at 09:49 +0100, Simon Riggs wrote: I'll look at doing that. We need the SUSE builds also. I actually built 8.3.4 on SLES 10.2 on..err..Friday, while building Fedora/RH RPMs. 8.3.1 spec of SLES is broken IMHO, and it requires special attention from someone who is experienced in packaging (me :-) ) and who is familiar with pg code.. Yeah, as you can see here https://build.opensuse.org/project/show?project=server:database:postgresql SLES builds have been broken for a while. I have not analyzed that yet. Bugs and patches welcome. -- 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] server/db encoding (mix) issues
[EMAIL PROTECTED] wrote: Well - I did setup two instances of 8.3.3 on an Ubuntu 7.10 system last week - both under a different user account. I set the locale for each account in the .bashrcs (export LANG=de_DE and export LANG=de_DE.UTF-8 respectively). After that I ran initdb (initdb --encoding='LATIN1' -W -A md5 -D $PGDATA and initdb --encoding='UTF8' -W -A md5 -D $PGDATA(?)). I'm not sure whether I specified the server encoding for the UTF8-instance though. Did I make something wrong? Not really, but I suggest you forget about the environment settings and forget about the --encoding option and just use the --locale option of initdb to set the locale settings. However, when I try to create an UTF-8 db in the LATIN1 server or an LATIN1 db in the UTF-8 server I get the error that the db encoding does not match the server locale and that the LC_TYPE-Locale requires the encoding of the server. Before that I thought it just fails because there is no locale with the name LATIN1 in windows. Are those additional encoding checks in v8.3.3 or had they been put in place with v8.3.1 already? They have existed since 8.3.0. -- 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] pg_dump etc. versions
Jan-Peter Seifert wrote: I'm wondering if there's a compatibility list of the tools supplied with PostgreSQL - e.g. psql seems to be very server version specific (only major or also minor versions?). For pg_dump I'd say users should use the version of the target server if it's already installed, but is this also the case if the target server version is older? Am I completely wrong? Should I always use the pg_dump from the source server? When migrating from 8.1 to 8.2 I get several errors with commands regarding creating users and a lib that had been integrated into the core when restoring from the source server's pg_dump's dump. When using the target server's pg_dump for the dump I don't. But is then really everything okay? And pgAdmin comes with its own set of the PostgreSQL tools ... I think the only thing that we really check is that pg_dump of a newer version can dump databases from an older version server. All the other tools probably only work (completely) with a server from the same major release. -- 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] server/db encoding (mix) issues
Jan-Peter Seifert wrote: we have a mix of older software still using LATIN1 as db encoding and the psqlODBC-drivers (ANSI) and newer software using UTF8 as db encoding. As running two server instances would use up more resources(?) than just one we'd like to have all dbs in one cluster. Which cons against this solution are there? Which operating system locale should be used then? C locale is recommended in the docs - also because of better performance. However, the language of the software is not English but German - so shouldn't there be problems with sorting German Umlauts etc. correctly etc.? Which encoding should the server have - UTF8/Unicode or LATIN1? BTW which is the correct locale for LATIN1 and German (de_DE (my guess) or [EMAIL PROTECTED] (which seems to be for LATIN9)). Using SQL_ASCII doesn't seem to be a wise choice. Are there no problems when connecting with psqlODBC-ANSI drivers if the server encoding is UTF8/Unicode? I'd be happy if you could enlighten me a bit. Set your locale to de_DE.utf8 and use UTF8 as server encoding. I would be interested to know where the documentation recommends using the C locale. That would certainly not be reasonable for many uses. -- 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] Changing encoding
Am Dienstag, 15. Juli 2008 schrieb Carol Walter: I have some databases that use SQL ASCII or Latin1 encoding that need to be UTF8. When I have drop the database and recreated it with the correct encoding I get errors in restoring the data. How is this done? What is your PostgreSQL version? What is the exact command sequence? The sort of problem you describe is usually fixed by setting the client encoding correctly, but recent versions should do this automatically for dumps/restores. -- 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] What is the difference between Logical link and Foreign Key link in Postgresql
Am Montag, 16. Juni 2008 schrieb Suresh Gupta VG: Can any one explain me what is the difference between logical link and foreign key link between the tables in postgresql. PostgreSQL has no concept by the name of logical link. What are you refering to? -- 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] UUID generation functions
Am Dienstag, 3. Juni 2008 schrieb Hyatt, Gordon: http://www.postgresql.org/docs/8.3/static/uuid-ossp.html My bad - just realised the OP most probably needs a Windows-compatible solution and uuid-ossp is not. Actually, I'm developing on Windows, but deploying on Linux (both the web-server and the DB server), so a solution that is independent of platform is the most desirable. I was hoping that PG would have something to generate UUIDs internally. It does. Read the above link. -- 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] howto restore from pg_dumpall
Marc Fromm wrote: When I restore from a pg_dumpall file, I am required to peform the following steps or else all the records in the databses are duplicated. If I only empty the data/base folder I get al sorts of errors. You may find the pg_dumpall --clean option useful, so the dump file is set up in a way that cleans out its predecessor objects automatically. Otherwise you will have to find your own to way clean up before restoring. -- 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] Backup of live database
Am Mittwoch, 16. Januar 2008 schrieb Tom Lane: (Thinks for a bit...) Actually I guess there's one extra assumption in there, which is that tar must issue its reads in multiples of our page size. But that doesn't seem like much of a stretch. There is something about that here: http://www.gnu.org/software/tar/manual/html_node/tar_149.html#SEC149 -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] get PGDATA as non-postgres user
Am Donnerstag, 3. Januar 2008 schrieb Sofer, Yuval: I need to get PGDATA location when I logged in as non-postgres user. Consider writing a security-definer function that retrieves the information. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [ADMIN] reconfiguring diskspace while upgrading to 8.2.5
Am Freitag, 28. Dezember 2007 schrieb Mark Steben: As we go. I am investigating using the new tablespace facility to move our biggest and most accessed I didn't see anything in your description about having the WAL on a separate disk. You should include that in your plans. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [ADMIN] pg_hba.conf is driving me nuts
Julio Leyva wrote: also make sure you started postgesql with -i option, so you can connect from the lan He said he had set listen_addresses to '*', which is equivalent. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[ADMIN] pg_start_backup without WAL archiving
Why is it not allowed to call pg_start_backup when WAL archiving is off? Wouldn't this be useful as a discrete file system backup without PITR capability? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [ADMIN] pg_start_backup without WAL archiving
Jeff Larsen wrote: On Nov 25, 2007 8:24 AM, Peter Eisentraut [EMAIL PROTECTED] wrote: Why is it not allowed to call pg_start_backup when WAL archiving is off? Wouldn't this be useful as a discrete file system backup without PITR capability? Because a file system level backup is no good unless the database is stopped, or you are using PITR. You are begging the question. If I enable WAL archiving, make a base backup to a safe place, and my data center goes up in flame immediately afterwards without a WAL segment being archived, that base backup should still be usable. Or maybe not. That's the question. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] Error while compiling PostgreSQL with Java
Никоноров Григорий wrote: I have a problem. I try to install PostgreSQL from source with java. I Installed JDK, ANT properly but when i try to configure i have an error - Warning.Ignored options - --with-java. Please help me ! PostgreSQL has no such option. You may be looking for the JDBC driver. If so, see http://jdbc.postgresql.org/. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [ADMIN] configure using libxml
Am Freitag, 9. November 2007 schrieb König, Monika: I try to configure postgresql 8.3beta with libxml by the comand: LDFLAGS=-lstdc++ ./configure --with-tcl --without-zlib --with-libxml -prefix=/usr/local/postgresql-8.3beta It works fine, but after make and make install I can't use the xml-functions. the running configuration is: Note that the configuration doesn't mention the libxml switch, so you forgot something somewhere. Did you do a make distclean before rebuilding, and did you install the new build? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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: [ADMIN] tar, but not gnu tar
Am Freitag, 24. August 2007 03:58 schrieb Tom Lane: Tena Sakai [EMAIL PROTECTED] writes: This seems to contradict what we say about GNU tar? Is this GNU tar? What version? Yes, it is GNU tar v1.14 FWIW, I tried this on Fedora Core 6 while running pgbench: [EMAIL PROTECTED] ~]$ tar --version tar (GNU tar) 1.15.1 [EMAIL PROTECTED] ~]$ tar cf t.tar $PGDATA tar: Removing leading `/' from member names tar: /home/tgl/testversion/data/pg_xlog/00010003: file changed as we read it [EMAIL PROTECTED] ~]$ echo $? 0 [EMAIL PROTECTED] ~]$ ISTR that the original caution was against writing scripts that assume anything being emitted to stderr must indicate a problem. The relevant NEWS entry from GNU tar 1.16 is: * After creating an archive, tar exits with code 1 if some files were changed while being read. Previous versions exited with code 2 (fatal error), and only if some files were truncated while being archived. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] Yet Another Socket .s.PGSQL.5432 Problem
Am Donnerstag, 16. August 2007 23:41 schrieb Hilton Perantunes: Alvaro, it works like a charm =). Thank you all. Bad, bad Debian.. no cookies for you (and I'll read the error messages more carefully next time)! The problem is quite likely some variant on the following: You had your distribution-supplied PostgreSQL packages installed, which use /var/run/postgresql as the socket location. Then you built your own pieces of PostgreSQL, which use /tmp. When you call just psql or pgadmin3, they will use the system-supplied libpq, which uses the system-specific socket location, since they don't know about your hand-crafted installation. If you had called the psql binary from your own installation with an explicit path (and your used the rpath feature during compilation), then this would have worked. Or you could have used the environment variable LD_LIBRARY_PATH to point to the libpq of your choice. There are a few ways to get this wrong. On Debian the socket location is usually the first indicator, but you ought to be careful in general if you mix installations like that. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [ADMIN] Migration Between Releases
Am Mittwoch, 15. August 2007 16:20 schrieb George Wilk: I thought that the major release was the first number in the versioning schema, the second represented minor release, and the third would be the maintenance release or revision number (i.e. 8.2.4). You thought wrong then. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [ADMIN] Migration Between Releases
Am Mittwoch, 15. August 2007 16:52 schrieb George Wilk: Hi Peter, thanks for your helpful and kind reply. It certainly clears a lot of smoke... In the future you might consider including links to relevant information. You posted the relevant information yourself. You just need to believe it. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [ADMIN] postmaster.pid file
Tena Sakai wrote: ~/bin/pg_ctl -D ~/bin reload It's quite unlikely that your data directory is ~/bin. As I looked at the pid file, there were three lines. The first line seemed like the pid of the server process. The second line indicates where the database cluster resides. In my case it is /usr/local/pgsql/data. That should be your -D argument then. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [ADMIN] varchar vs text columns
Jessica Richard wrote: What is the difference between varchar and text for a string column? Nothing, if you don't use a limit for varchar. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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: [ADMIN] building from source requires postgres user account
Am Donnerstag, 12. Juli 2007 16:22 schrieb George Wilk: I'd like to use my own user account when building postgres from source. When I follow directions on Sun's page: http://docs.sun.com/app/docs/doc/819-5578/6n7lcpcl5?a=view I don't have a problem, but running build under my own account runs into file permission issues after the build is done. My build.log shows: Nothing in the build process requires a special user account or writes a file named build.log or writes messages of that kind. So please be more specific. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [ADMIN] Size of logfiles
Am Montag, 21. Mai 2007 15:38 schrieb Peter Elmers: I have searched the web and am sorry to say that i found nothing about the default behavior of the log files of postgres. That's easy: By default, postgres doesn't write a log file. There are about half a dozen ways to set this up, though. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] pg_dump not enough space to create a backup FreeBSD 6.1?
Joost Kraaijeveld wrote: Can I somehow use another partition to store the temporaray files without changing my /tmp mount? Set the environment variable TMPDIR. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [ADMIN] Moving data directory
Linux Geeks wrote: I'm very new to postgresql and would like to move my data directory to another partition in Ubuntu. The standard installation is in /usr/lib/postgresql. How do I move it into /var/lib/postgresql. The standard data directory on Ubuntu *is* /var/lib/postgresql. You must be confusing something. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [ADMIN] Adding a port to postgresql.conf
Am Freitag, 4. Mai 2007 15:11 schrieb Carol Walter: Can I add a port in postgresql.conf and still maintain 5432? No. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [ADMIN] Help me to decrypt password
sufian khan wrote: How I decrypt any password that is store in our database table app_users. That would seem to strongly depend on how you encrypted it in the first place. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [ADMIN] REINDEX using only 1 CPU (of 2)
[EMAIL PROTECTED] wrote: I've got PG 8.2.3 running on a dual-core P4, and I noticed that, at least during reindexing, postgreSQL REINDEX process is using only 1 of those 2 cores. One process, one CPU (core) -- you can't do anything about that. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] Where are aliases stored?
Am Donnerstag, 12. April 2007 16:46 schrieb Chris Hoover: Is there not a way to query the pg_ catalog views and get a listing of views with columns (by alias name)? The column names (what you call alias names) are in pg_attribute, the views are in pg_class. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [ADMIN] question on plpgsql block
Karthikeyan Sundaram wrote: I tried a plpgsql block from the php. plpgsql blocks only work in a plpgsql function. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [ADMIN] How to compile with different MAXALIGN?
Sean Murphy wrote: search of the Docs tells me that I can compile the server with a different MAXALIGN, but the install docs don't give any indication how this is achieved. Is there a configure or gmake option I can feed, or do I need to change a line in one (or more) of the source files? Alignment is a property dictated by the compiler, so the official way to change that is to argue with your compiler. On Linux i386, it seems that the option -malign-double will get you the 8 byte alignment that might be compatible with your Windows build. All of this, however, is totally unofficial and highly risky, because an alignment difference might indicate that there are other differences in the binary data layout that are not caught by the existing checks. You will get data corruption if you are wrong. Moreover, a build with a nonstandard alignment will be incompatible with everything else on your system in ways that are hard to define in brief, so interfacing with other libraries or modules will possibly be broken, as will your next PostgreSQL upgrade. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] host name?
Igor Neyman wrote: But besides having ip address (instead of machine name), it doesn't have clent program name connected to PG. That information is not available to the server. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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: [ADMIN] pg_hba.conf multiple auth_metods question
Gémes Géza wrote: I have successfully deployed krb5 or pam (with pam_krb5) authentication with my clients. My question is: Can I use both in a failover fashion? Not in PostgreSQL, but you could probably hook Kerberos into PAM. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] 8.2 Admin Pack broken?
Andy Shellam (Mailing Lists) wrote: Not particularly!! Don't know what it is but it doesn't _appear_ to be GNU. According to man make it is a FreeBSD General Command. I can tell you that ./configure make make install works and builds a working Postgres server just fine, it's just the contribs it doesn't build. There is extra code in the top-level makefile that detects if you don't run GNU make, tries to find it, and calls it instead. But you need to have it installed somewhere. That code, however, is not replicated in each directory of the source tree. In the past, we have usually refered to the GNU make program as gmake, but I see an increasing number of systems, including my own, that no longer installs GNU make as gmake but only as make. So basically you just need to be careful what you call. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [ADMIN] rename a cluster
Ray Stell wrote: Is there a method to rename a cluster? Clusters don't have names in the first place. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] rename a cluster
Ray Stell wrote: What I was trying to get at is, is mv of the dir ok or is there something else that needs to be considered? Thx. Renaming the directory is OK. Just make sure your init script or whatever finds it. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [ADMIN] Question to safe way for minor update
Thomas Papke wrote: 1. i am running a large postgres 8.1.4 database in production. What is a good and safe way for an minor update to 8.1.8 (less downdown and possible jump back option)? Using binary packages, install the new one over the old one, and if you don't like it, install the old one over the new one. How riskful is an minor update for the data files? Not riskful. 2. i am using two dualcore opterons with 8GB memory - if i am using the CFLAGS=-O2 option for compile optimization -- is there any real performance boost? I don't think anyone has ever seriously considered building with anything less than -O2 for anything but debugging purposes or coping with buggy compilers on rare architectures. In other words, there isn't any good reason not to do it. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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: [ADMIN] Question to safe way for minor update
Thomas Papke wrote: AN other question: Are the postgres datafiles (not the dump) platform independ? No. So is it possible to just copy the datafiles from linux to a windows machine if they are running the same postgres version? There is no guarantee or direct check against this, but anecdotal evidence suggests that this combination will not work. In general, the data file compatibility is determined by some combination of architecture and compiler settings. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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: [ADMIN] Question to safe way for minor update
Thomas Papke wrote: Right now our 8.1.4 is running without any compiler options. Any possible problem if i will compile the 8.1.8 with CLAGS -O2 -march=Opteron -- will the datafiles of the 8.1.4 non optimized postgres make any problems? No. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [ADMIN] Question on Fragmentations
Moiz Kothari wrote: What are the reasons of data getting fragmented in postgres? What do you mean by that? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [ADMIN] Install Tsearch2
Am Freitag, 2. Februar 2007 13:05 schrieb Alexander B.: I am getting the follow error: analise3:/postgres/share/contrib/tsearch2 # make Makefile:31: ../../src/Makefile.global: No such file or directory Makefile:32: /contrib/contrib-global.mk: No such file or directory make: *** No rule to make target `/contrib/contrib-global.mk'. Stop. analise3:/postgres/share/contrib/tsearch2 # Run configure first. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [ADMIN] pg_dumpall failure - could not access status of transaction
Robert Leftwich wrote: pg_dump: Error message from server: ERROR: could not access status of transaction 3183024 DETAIL: could not open file pg_clog/0003: No such file or directory If your database system has already experienced on the order of 3183024 transactions, then you should wonder where that file went. Otherwise you probably have garbage on disk, pointing to a transaction that hasn't happened yet. This is usually hardware trouble in any case, unless you have actually deleted the file manually. The alternative is that your database system has already seen more than 2^32 transactions and you have hit some bug in the transaction wraparound, but that would be much less likely than the above cases. I'm (obviously) lost here - what is the correct way to track down the appropriate file and record to point pg_filedump at to view any corruption? Look for something that contains 3183024 as a four-byte integer. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] Postgres encyrption export
Tom Dong wrote: We are wondering whether there has been US Commerce Department review of the Postgres application for export. The Debian project submits all software it distributes to said department, so one can be fairly assured that they have heard of PostgreSQL, but how that affects what you are distributing I'm not sure. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [ADMIN] Postgres encyrption export
Am Dienstag, 30. Januar 2007 23:03 schrieb Tom Dong: I did see an early email posted on POstgres mailing list about ECCN number of Postgres and saw the response debating if Postgres should be considered a US product. According to the lawyers I'm involved with, the contributions by US citizens or residents are certainly significant enought to make this true for the purpose of export or embargo control. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [ADMIN] Install XML on Postgres 8.1
Shoaib Mir wrote: Do we have XML docs indexing mechanism in the todo's for 8.3? as this is one of the problem I faced while moving the Oracle like XML functionality to PostgreSQL using xml2 contrib. Indexing of data types is done in terms of operator classes (or maybe operator families in 8.3, not sure), but so far no one has proposed to define any operators whatsoever on the XML type, so I don't see where any indexing mechanism would come from at the moment. What does Oracle offer? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [ADMIN] Postgresql Upgrade 7.4 to 8.2
Radhika Sambamurti wrote: 1. How is the backup and recovery using WAL logging in 8.2 It's great! -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [ADMIN] server process (PID xxx) was terminated by signal
Bruce Momjian wrote: Is there no API to return the name of signals? There is, but it's not portable. If someone wants to perform an exercise in writing configure code, look for strsignal() and sys_siglist[]. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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: [ADMIN] Install XML on Postgres 8.1
Shoaib Mir wrote: Can we compare the same powerful like Oracle has on Xml? I don't think so that current xml2 support is according to the SQL 2003 standards and for now it is I guess just the basic one. The functionality of the xml2 contrib module is almost completely orthogonal to what the SQL standard says in matters of XML. Whether either of these are equally powerful as what Oracle offers, I can't say, but since we're currently working on enhanced XML functionality in 8.3, I invite comments on that. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] Install XML on Postgres 8.1
Joshua D. Drake wrote: PeterE do you have a specific TODO I can line item for the pending 8.3 release? http://developer.postgresql.org/index.php/XML_Todo -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] Migration problems with encoding.
Manuel Trujillo wrote: The problem: Encoding incompatibilities between the postgresql version. In detail? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [ADMIN] Recovery plan for DRDB setup - recovery tool
Morten Andersen wrote: So are there any Postgresql tools for analyzing and repairing the offline database files (like e.g. the MySQL 'myisamchk'-tool). No. So, how do other DRDB Postgresql sites handles failovers. Do you do anything pro-active on the slave before starting Postgresql, or do you trust DRDB and Postgresql completely. If you don't trust PostgreSQL, why would you trust its offline recovery tools? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [ADMIN] dump from 8.x restore to 7.3.x
Shane Ambler wrote: I don't see that as being the case - there will be exceptions where you have new features in an 8.x database that won't work in a 7.x db but otherwise it shouldn't matter, the dumps can be used to import into other databases than postgres as long as you use dump with inserts instead of copy and use common datatypes. Restoring dumps from new versions into old versions doesn't work (without a lot of manual work). Example cases: 8.2 dump won't install into 8.1 because it sets standard_conforming_stings, which can't be set in 8.1 8.1 dump won't install into 8.0 because it dumps users as roles, but roles don't exist in 8.0. 8.0 dump won't install into 7.4 because it dumps tablespaces, which don't exist in 7.4. etc. etc. Obviously you can see that getting pretty bad if you want to go from 8.1 all the way to 7.3. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [ADMIN] Version 7.3.8 Upgrade
Craig W wrote: I am sure that there will be benefits of upgrading, but are there any known problems with upgrading ? Please also let me know if it is a painless transition. RTFM? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [ADMIN] Need to repair Database
Jurado, Hector R. wrote: We use a program that uses GPG file extension, now when the application try to call the database it responds that the database is corrupt. Which tool I could use to repair it? With this amount of detailed information, we can't even guess. Normally I need to get old backup and all my new data is lost, the problem begin when some user close the program improperly. Closing the program improperly would not cause database corruption. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [ADMIN] Missing Earth Distance Functions Under Debian
Duncan McDonald wrote: No I didn't run the earthdistance.sql script on the backup database, is this included with the standard PostgreSQL package? If not, would you mind letting me know how/where to obtain it? http://packages.debian.org/cgi-bin/search_contents.pl?word=earthdistance.sqlsearchmode=searchfilescase=insensitiveversion=stablearch=i386 -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [ADMIN] Logfile permission
Cassiano, Marco wrote: Is there a way to modify the UMASK used by postmaster to create the logfiles ? No. You should use syslog if you have extraordinary log file management requirements. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] Inserting bit-type value into integer-type column
Am Dienstag, 29. August 2006 10:32 schrieb Riho Maisa: The anomaly for me: in 7.2 it works, but in 7.4 it doesn't. 7.2 was wrong to accept such things; 7.4 fixed it. I cannot rewrite SQL INSERT because it's in compiled application. Either fix your application or patch the PostgreSQL server or stick with 7.2 (not recommended, because 7.2 is not maintained anymore). -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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: [ADMIN] Problem with PostgreSQL 8.1.4 Install (using RPMs)
Lane Van Ingen wrote: Does anyone know what the initial user/password should be? Thanks. Probably postgres without a password but with ident authentication, which means you must log in as the postgres user on your OS. (That one probably doesn't have a password either, so go through root.) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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: [ADMIN] 7.4 - data recovery
Bartosz Belter wrote: 3. I've recovered some files and it looks to me they're from $PGDATA/base/data/xxx (it looks this is the complete folder) 4. No other files! (no pg_clog, pg_xlog etc) If you don't have a clog, then all your transactions will appear as didn't happen yet, so your table data appears to be in the future. You can just commit dummy transactions until it appears again. This is obvious not an official and approved way, but it's at least a shot before you're forced to get out your hex editor. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [ADMIN] [GENERAL] How to detect Postgres deadlocks?
andre wrote: 1) Which sql queries should I use to detect deadlocks while they are happening? I see the deadlock info on the log file, but I'd like to query the database to see them as they happen... Since deadlocks are broken up within one second, it will be hard to actually see them. You could crank up the deadlock timeout and then query pg_locks and infer cycles from there. From there you can also move over to the statistics tables to see what the processes are currently doing. But the system won't actually tell you that there is a deadlock until the timeout is over. If you have special requirements like that, you need to patch the source. The other option is to decorate your server log lines with pids and such that you can link from the deadlock error message to the logged statements. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] Migration from 7.4.2 to 8.1.4
Am Montag, 21. August 2006 11:43 schrieb Gallai János: I'm an administrator of a big company who has a PgSQL-database version 7.4.2. We would like to upgrade it to 8.1.4 but the dump we made cannot be restored. We got a lot of error messages while restoring database related on something's being restored before other objects would exists. You should have more success if you use the pg_dump(all) program from 8.1.4 to create the dump. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [ADMIN] Issue on Varchar Ordering
Erika Terahata Torres Prada e Silva - MPS wrote: I'm having the following issue: create table aluno (id serial, nome varchar(60)); rodrigo=# select * from aluno order by nome offset 35 limit 5; id | nome +--- 36 | GABRIELA HELEDA DE SOUZA 37 | GABRIELA JACOBY NOS 38 | GABRIEL ALCIDES KLIM PERONDI 39 | GABRIELA LETICIA BATISTA NUNES 40 | GABRIEL ALEXANDRE DA SILVA MANICA (5 registros) The problem is that records with id 38 and 40 might come before the others. It seems that the spacing isn't considered on ordering. That is, for practical purposes, correct. May I suggest that you properly normalize your tables, by putting given name and family name into separate columns. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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: RES: [ADMIN] Issue on Varchar Ordering
Erika Terahata Torres Prada e Silva - MPS wrote: But it's not correct to my language pt_BR and it worked correctly with PostgreSQL at Windows and FreeBSD. I have this problem only with Debian and now I'm looking for some Debian related issue. String ordering is determined by national and international standards. In your case, glibc seems to think that ISO 14651 applies. If you think differently, complain to glibc, or work on changing the standard, or define your own locale. I wouldn't know why Windows and FreeBSD operate differently (I have some idea, but I won't spread rumours). But unless they have a more substantial reason than We thought this looks reasonable, I'd rather go with the public standard. For that matter, you have not told what you consider the correct ordering in your example, nor have you proposed a computation rule to get there. But in the overall scheme of things, first normal form will cooperate better with established sorting rules (for any data type), and vice versa. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] Monitoring error messages
[EMAIL PROTECTED] wrote: These are both logged as ERROR: which is easy to check for with automatic monitoring. However I wouldn't want to be called out to fix a non-existent error where someone has typed in some nonsense. Is it easy to suppress the syntax errors so that the real database errors are obvious? I think the short answer is No, unless you do your own post-processing. But note that syntax errors may also point to mistakes in your application code. If you want to filter out randomness that occurs during interactive sessions, I'd rather attack the problem there. You could, for example, alter the logging settings in your .psqlrc file. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: RES: RES: [ADMIN] Issue on Varchar Ordering
Alvaro Herrera wrote: LC_COLLATE=pt_PT sort EOF GABRIEL ALEXANDRE DA SILVA MANICA GABRIELA JACOBY NOS GABRIELA HELEDA DE SOUZA GABRIELA LETICIA BATISTA NUNES GABRIEL ALCIDES KLIM PERONDI EOF On my system it outputs the order you show above, which shows that my locale is correctly defined per your expectations. That is absolutely wild. This will indeed return a space-sensitive sort under pt_BR, but not under, say, de_DE. So there is order in this world! (heh) This is on Debian, so the original poster has some configuration or version difference. Please tell OS version, and the output of SHOW lc_collate. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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: [ADMIN] localization problem
j n wrote: can any1 point me to some tutorial what is needed to run localization support ... There isn't much to tutor about. You pretty much have everything figured out. than creating data directory initdb --locale=sk_SK.utf8 /usr/local/pgsql/dataSK creating database : createdb doctorko -U doctorko -E UTF8 This looks correct. SHOW LC_COLLATE give output sk_SK If you initialized with locale sk_SK.utf8 but lc_collate shows sk_SK, then something went wrong. so everythink look ok but order still not working ... Check if the order is consistent with what you get with the sort command from the shell. If that doesn't help, show us the data. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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
[ADMIN] Background writer memory bloat?
I'm seeing a background writer process in an 8.0.8 installation that uses 1.6 GB of main memory, and ps shows that it has used an unreasonable amount of CPU time so far. It seems that the machine was under heavy load just before I got to it; maybe that is cause? Has anyone seen this sort of memory bloat on the background writer process? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [ADMIN] Background writer memory bloat?
Am Freitag, 4. August 2006 17:00 schrieb Tom Lane: Are you sure it's bloat, and not just a reflection of the fact that it's touched every page of the shared buffers over its lifespan? That seems to be the explanation. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [ADMIN] installing on user account
Am Freitag, 4. August 2006 17:57 schrieb Rodolfo Borges: $psql -U jabberd2 jabberd2 psql: FATAL: IDENT authentication failed for user jabberd2 You need to read up on configuring the client authentication. If you don't have root access, ident is probably not a good choice. In particular ... I also tried appending a -W argument to that command. It asked for the password, I gave the password from the createuser command, and the same error ocurred. ... if you expect to use password authentication, you need to change the client authentication mechanism away from ident and toward passwords. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] Circular Dependency in Tables and Deletion of Data
Am Montag, 24. Juli 2006 14:53 schrieb Mans: Isnt it a crazy thing?? Yes, but with deferrable constraints and transactions blocks, it should be no problem to manage the data. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
