Re: [ADMIN] persistent 'psql: FATAL: listen_addresses cannot be changed after server start

2007-10-10 Thread David Rovner
David Rovner wrote: ... After some network configuration changes (IP changes and some editing to config files which may have been interrupted buy shutdowns), I cannot get past this error: That's a bit vague. What changed externally with your network? What files were you changing and what

Re: [ADMIN] persistent 'psql: FATAL: listen_addresses cannot be changed after server start

2007-10-10 Thread David Rovner
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 10, 2007 10:02 AM To: David Rovner Cc: Steve Crawford; pgsql-admin@postgresql.org Subject: Re: [ADMIN] persistent 'psql: FATAL: listen_addresses cannot be changed after server start David Rovner

Re: [ADMIN] persistent 'psql: FATAL: listen_addresses cannot be changed after server start

2007-10-10 Thread Tom Lane
David Rovner [EMAIL PROTECTED] writes: I see this error at the command prompt in root executing anything that starts with psql. The argument list does not matter. psql with no arguments returns this error as well. PGOPTIONS environment variable, perhaps? It's hard to imagine why anyone would

Re: [ADMIN] persistent 'psql: FATAL: listen_addresses cannot be changed after server start

2007-10-10 Thread David Rovner
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 10, 2007 10:02 AM To: David Rovner Cc: Steve Crawford; pgsql-admin@postgresql.org Subject: Re: [ADMIN] persistent 'psql: FATAL: listen_addresses cannot be changed after server start David Rovner

Re: [ADMIN] persistent 'psql: FATAL: listen_addresses cannot be changed after server start

2007-10-10 Thread Tom Lane
David Rovner [EMAIL PROTECTED] writes: PGOPTIONS is set to -i Well, that's equivalent to --listen_addresses=*, so that's your problem. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives?

Re: [ADMIN] persistent 'psql: FATAL: listen_addresses cannot be changed after server start

2007-10-10 Thread David Rovner
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 10, 2007 10:57 AM To: David Rovner Cc: Steve Crawford; pgsql-admin@postgresql.org Subject: Re: [ADMIN] persistent 'psql: FATAL: listen_addresses cannot be changed after server start David Rovner

Re: [ADMIN] warm/hot backup of Postgresql

2007-10-10 Thread Decibel!
On Oct 7, 2007, at 11:37 AM, Faber Fedor wrote: Is SLONY/replication my only choice? Remember, I can't/don't want to rebuild the existing servers. Slony is. As an added benefit, it will allow you to perform a migration with effectively zero downtime. -- Decibel!, aka Jim C. Nasby, Database

[ADMIN] Using rsync for base backups for PITR

2007-10-10 Thread Scott Whitney
I'm reading conflicting information on this. Is this a supported technique? start_backup rsync the initial base backup stop_backup Then, periodically, start_backup rsync again stop_backup It's my opinion that this wouuld significantly cut down the 30GB base backup I'll need to take for each

Re: [ADMIN] Using rsync for base backups for PITR

2007-10-10 Thread Bruce Momjian
Scott Whitney wrote: I'm reading conflicting information on this. Is this a supported technique? start_backup rsync the initial base backup stop_backup Then, periodically, start_backup rsync again stop_backup It's my opinion that this wouuld significantly cut down the 30GB base

Re: [ADMIN] Using rsync for base backups for PITR

2007-10-10 Thread Scott Whitney
In the same way that you don't have a valid archive while the tar is running, no? In either case, I have to archive the WAL segments used during the file system backup, right? Is rsync a supported method for a warm standby server? Specifically, I'm thinking about:

[ADMIN] PG 8.1.4 not clearing pg_clog

2007-10-10 Thread Scott Whitney
Sorry if this one is a repost, folks. I didn't see it come to my box or show up on the archive on the web. I've seen several posts on this issue in the past, but none seems to address my situation. In my pg_clog directory, I have 225 files dating back to August 8th, when I installed this

Re: [ADMIN] Using rsync for base backups for PITR

2007-10-10 Thread Bruce Momjian
Scott Whitney wrote: In the same way that you don't have a valid archive while the tar is running, no? In either case, I have to archive the WAL segments used during the file system backup, right? Well, with the tar I assume you still have the old tar around. This is not true with the rsync

[ADMIN] Timing problem wtih pg_stat_activity

2007-10-10 Thread Donald Fraser
Please ignore my previous question - I should have read the documents first! The answer is here: When using the statistics to monitor current activity, it is important to realize that the information does not update instantaneously. Each individual server process transmits new block and row

Re: [ADMIN] PG 8.1.4 not clearing pg_clog

2007-10-10 Thread Tom Lane
Scott Whitney [EMAIL PROTECTED] writes: Which I assume to be epoch dates and thusly converted. This assumption is incorrect, which likely accounts for your confusion. XID numbers have nothing to do with any external reality, and age() results even less. If today is Saturday, a cronjob runs

[ADMIN] Timing problem wtih pg_stat_activity

2007-10-10 Thread Donald Fraser
PostgreSQL 8.1.9, Linux Redhat ES 4 I am experiencing a timing issue with the following query: SELECT count(procpid) FROM pg_stat_activity WHERE usename='someuser' If I execute the above query by the client who is user someuser and it is executed immediately after connecting I am getting two

Re: [ADMIN] Using rsync for base backups for PITR

2007-10-10 Thread Simon Riggs
On Wed, 2007-10-10 at 11:46 -0500, Scott Whitney wrote: Is rsync a supported method for a warm standby server? Specifically, I'm thinking about: http://www.taygeta.com/ha-postgresql.html That's dated 2001... -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com