Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"
Heikki Linnakangas schrieb: Lossing data is very bad, the solution provided by Robert is really simple. I support Roberts approach. you support changing localhost to be something other than 127.0.0.1 to hack around a poorly designed application?!? seriously? No, i support that PG should be able to not lossing data because of an easily catchable missconfiguration of the underlying system. You won't lose data. There are safeguards in place to print warnings in the log when you approach transaction wrap-around, and after a certain point the system will stop accepting new transactions, to prevent data loss. The manual says that autovacuum protects againt loss of very old data: http://www.postgresql.org/docs/9.1/static/routine-vacuuming.html So either your statement is wrong or the manual. ;) If there is the possibility to lose data just because of this kind of missconfiguration, we should accept Roberts patch. Greetings, Torsten -- http://www.dddbl.de - ein Datenbank-Layer, der die Arbeit mit 8 verschiedenen Datenbanksystemen abstrahiert, Queries von Applikationen trennt und automatisch die Query-Ergebnisse auswerten kann. -- 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] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"
On 11/11/11 20:51, Torsten Zuehlsdorff wrote: So either your statement is wrong or the manual. ;) If there is the possibility to lose data just because of this kind of missconfiguration, we should accept Roberts patch. Greetings, Torsten Robert's patch is based on a complete mis-assessment risk and misunderstanding of sane network configuration. No-one can sensibly support a position to redefine 'localhost' to mean what it should never mean. regards Mark -- 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] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"
Excerpts from Torsten Zuehlsdorff's message of vie nov 11 04:51:48 -0300 2011: > Heikki Linnakangas schrieb: > > You won't lose data. There are safeguards in place to print warnings in > > the log when you approach transaction wrap-around, and after a certain > > point the system will stop accepting new transactions, to prevent data > > loss. > > The manual says that autovacuum protects againt loss of very old data: > http://www.postgresql.org/docs/9.1/static/routine-vacuuming.html > > So either your statement is wrong or the manual. ;) Heikki is correct. The docs state, in the section that expands on the single phrase talking about very old data being lost: If for some reason autovacuum fails to clear old XIDs from a table, the system will begin to emit warning messages like this when the database's oldest XIDs reach ten million transactions from the wraparound point: WARNING: database "mydb" must be vacuumed within 177009986 transactions HINT: To avoid a database shutdown, execute a database-wide VACUUM in "mydb". (A manual VACUUM should fix the problem, as suggested by the hint; but note that the VACUUM must be performed by a superuser, else it will fail to process system catalogs and thus not be able to advance the database's datfrozenxid.) If these warnings are ignored, the system will shut down and refuse to start any new transactions once there are fewer than 1 million transactions left until wraparound: ERROR: database is not accepting commands to avoid wraparound data loss in database "mydb" HINT: Stop the postmaster and use a standalone backend to VACUUM in "mydb". The 1-million-transaction safety margin exists to let the administrator recover without data loss, by manually executing the required VACUUM commands. However, since the system will not execute commands once it has gone into the safety shutdown mode, the only way to do this is to stop the server and use a single-user backend to execute VACUUM. The shutdown mode is not enforced by a single-user backend. See the postgres reference page for details about using a single-user backend. So you don't actually lose data, but it's better not to get into that situation in the first place. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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 #6288: Is ALTER ROLE set client_encoding broken in 9.1?
On tor, 2011-11-10 at 19:30 -0500, Tom Lane wrote: > I think psql only pays attention to its locale when stdout is a tty. > Now *why* it acts like that, I'll leave for Peter to defend. We would have to review the original discussion about that. I can see arguments for doing it that way and for not doing it that way. This, however, still doesn't explain why a ALTER ROLE ... SET client_encoding is not taking effect. After all, a plain SET client_encoding still works. -- 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 #6288: Is ALTER ROLE set client_encoding broken in 9.1?
Peter Eisentraut writes: > On tor, 2011-11-10 at 19:30 -0500, Tom Lane wrote: >> I think psql only pays attention to its locale when stdout is a tty. >> Now *why* it acts like that, I'll leave for Peter to defend. > We would have to review the original discussion about that. I can see > arguments for doing it that way and for not doing it that way. > This, however, still doesn't explain why a ALTER ROLE ... SET > client_encoding is not taking effect. After all, a plain SET > client_encoding still works. The ALTER ROLE *does* take effect ... and then psql overrides it from the environment. Not sure why you expected differently --- psql doesn't especially care why the server sent the initial client_encoding that it did. BTW, I noticed while experimenting with this that if I have an environment of LANG="C", psql overrides the client_encoding to be SQL_ASCII, regardless of what the database encoding is. This seems like a bad idea, since it removes knowledge rather than adding any. 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
