Re: [BUGS] BUG #6353: If there is invalid line in pg_hba.conf, DB start fails without any nofice and no logs in pgstartup.
er...@eurotel.com.tr writes: > If I add this line to pg_hba.conf, it causes a silent startup failure: > localallbackup 127.0.0.1/32 trust > There is a linux user backup on this system. After adding this line and > issue "pg_ctl reload" it signals server successfully, no errors. But if I > stop db server, I can not start db anymore. Strangely no log exists in > pgstartup.log. Well, that line is obviously incorrect, because a "local" line doesn't need an IP address. For me, the postmaster gives very clear warnings about this, either in the pg_ctl reload case: LOG: received SIGHUP, reloading configuration files LOG: invalid authentication method "127.0.0.1/32" CONTEXT: line 95 of configuration file "/var/lib/pgsql/data/pg_hba.conf" WARNING: pg_hba.conf not reloaded or in the fresh-start case: LOG: invalid authentication method "127.0.0.1/32" CONTEXT: line 95 of configuration file "/var/lib/pgsql/data/pg_hba.conf" FATAL: could not load pg_hba.conf Your problem apparently is that the log messages are either not coming out at all, or you're looking in the wrong place for them. You have not said anything about your logging configuration so it's hard to give concrete advice, but in the default configuration set up by Red Hat's packages I'd expect those messages to appear in the current log file underneath /var/lib/pgsql/data/pg_log/. It's also conceivable that the messages aren't getting out at all because of a permissions-type problem --- I remember some very old versions of selinux policy would sometimes block postgres log messages, for example. If you've got selinux enabled it'd be worth checking for avc messages in the kernel logs. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6353: If there is invalid line in pg_hba.conf, DB start fails without any nofice and no logs in pgstartup.
On 22-12-2011 12:53, er...@eurotel.com.tr wrote: > If I add this line to pg_hba.conf, it causes a silent startup failure: > localallbackup 127.0.0.1/32 trust > There is a linux user backup on this system. After adding this line and > issue "pg_ctl reload" it signals server successfully, no errors. But if I > stop db server, I can not start db anymore. Strangely no log exists in > pgstartup.log. Even I start with -d 5 debug param, it exists after "logging > shutdown" message. Debugging with gdb didn't help. After removing the line > added above in pg_hba.conf, db starts. > This is not a bug. Did you check your server logs (pgstartup.log must be the pg_ctl output)? I got: LOG: invalid authentication method "127.0.0.1/32" CONTEXT: line 80 of configuration file "/home/euler/pg90/data/pg_hba.conf" FATAL: could not load pg_hba.conf If you don't have logging_collector enabled, you should get the above message in your terminal. Problem is: instead of local you should use host. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6351: ERROR: btree index keys must be ordered by attribute
christian_oede...@gmx.de writes: > our OR-Mapper accidently created an index that contained the same column > twice, with the result that some SELECTs could not be executed anymore and > gave the error message "btree index keys must be ordered by attribute". > The problem can be reproduced with a new table every time: > CREATE TABLE tab (id SERIAL, a INTEGER, b INTEGER); > CREATE INDEX tab123 ON tab (a, b, a); > SELECT a, b FROM tab WHERE a = 0 AND b = 0; > ERROR: XX000: btree index keys must be ordered by attribute Hmm. This didn't use to be allowed at all before 9.0; previous releases would reject the index definition: regression=# CREATE INDEX tab123 ON tab (a, b, a); ERROR: duplicate key value violates unique constraint "pg_attribute_relid_attnam_index" But now that we allow it it'd be nice if it actually worked :-(. Looking into the archives I see that we were mainly thinking about the possibility of exclusion constraints naming the same column more than once, which may explain why nobody tried using such an index for queries. I'll see about fixing this in HEAD, although my initial guess is that it will be too invasive to back-patch. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6353: If there is invalid line in pg_hba.conf, DB start fails without any nofice and no logs in pgstartup.
The following bug has been logged on the website: Bug reference: 6353 Logged by: Erkan Durmus Email address: er...@eurotel.com.tr PostgreSQL version: 9.0.6 Operating system: Centos 5.7 Description: Hi, Firstly, thanks for developing Pgsql! Problem: If I add this line to pg_hba.conf, it causes a silent startup failure: localallbackup 127.0.0.1/32 trust There is a linux user backup on this system. After adding this line and issue "pg_ctl reload" it signals server successfully, no errors. But if I stop db server, I can not start db anymore. Strangely no log exists in pgstartup.log. Even I start with -d 5 debug param, it exists after "logging shutdown" message. Debugging with gdb didn't help. After removing the line added above in pg_hba.conf, db starts. Regards, Erkan Durmus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Postgresql 9.1.2 - abnormal memory usage
Hi, On Friday, December 16, 2011 01:50:03 PM Havasvölgyi Ottó wrote: > A simple query "insert into mytable default values" on a single > serial-column table also leaks. It can also produced by pgbench. On > Windows and Linux too. Youve mentioned that in several threads now. If you really think that you have discovered a memory leak with a simple scenario as that could you please open a new bugreport on report your findings there instead of hiding it deep in other threads. Thanks, Andres -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6352: Getting signal 7: Bus error
wrote: > PostgreSQL version: 8.4.9 > Operating system: CentOS 5.7 on OpenVz (2.6.32-042stab044.11) > LOG: server process (PID 30683) was terminated by signal 7: Bus > error > LOG: terminating any other active server processes We've had a few reports like this lately, all on VMs. Here is one where a solution was found: http://archives.postgresql.org/pgsql-bugs/2011-12/msg00024.php This is most likely a bug in OpenVz, not PostgreSQL. -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6352: Getting signal 7: Bus error
The following bug has been logged on the website: Bug reference: 6352 Logged by: Sebastian Email address: se...@metasite.net PostgreSQL version: 8.4.9 Operating system: CentOS 5.7 on OpenVz (2.6.32-042stab044.11) Description: When trying to import dump getting this: LOG: server process (PID 30683) was terminated by signal 7: Bus error LOG: terminating any other active server processes postgresql.conf settings: max_connections = 20 shared_buffers = 13288MB temp_buffers = 128MB max_prepared_transactions = 25 work_mem = 2048MB maintenance_work_mem = 32MB max_stack_depth = 8MB max_files_per_process = 1000 fsync = on synchronous_commit = off wal_sync_method = fsync full_page_writes = off wal_buffers = 512MB wal_writer_delay = 2000ms checkpoint_segments = 50 Container has 16384MB RAM kernel values: kernel.shmmni = 655360 kernel.shmall = 20971520 kernel.shmmax = 175726755840 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
