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
--
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 d
"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 r
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 ac
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
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 Postgre
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:
http://www.taygeta.com/ha-postgre
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 30G
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 PITR
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
> -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
>
> "Da
"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 archiv
> -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
>
> "Da
> -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
>
> "Da
"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
any
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
16 matches
Mail list logo
