On Wed, 2009-03-04 at 17:19 -0500, Tom Lane wrote:
> This behavior might be all right for an emergency recovery kind of tool,
> but I can't see us considering it a supported feature.
I agree post-recovery cleanup would be required to bring up a fully safe
read-write database. That's one of the r
On Wed, Mar 04, 2009 at 05:05:19PM -0500, Yauheni Labko wrote:
> No. %f is the WAL filename which is needed by the server to start recovery.
my recovery command is:
restore_command='/usr/local/pgsql/bin/pg_standby /data/pgsql/wals/alerts_oamp
%f %p %r >> /home/postgresql/log/alerts_oamp/recove
> my recovery command is:
> restore_command='/usr/local/pgsql/bin/pg_standby
> /data/pgsql/wals/alerts_oamp %f %p %r >>
> /home/postgresql/log/alerts_oamp/recovery.log'
You gave the recovery command, not the archive command. And give a piece of
log file where primary server performs archiving W
Hello raf,
> > > Easier is just
> > > select oid::regprocedure from pg_proc where
> note that this method doesn't produce a complete function
> signature. the precision and scale of numerics are not
> included in the output. hopefully, that won't matter for
> your needs.
Oh. So functions expe
Hello Tom,
> > I combined your suggestions into this query I'll be using for now:
>
> > SELECT DISTINCT n.nspname || '.' || p.oid::regprocedure::text FROM
>
> This is flat *wrong*, as you'll soon find if you are working with
> functions in more than one schema. regprocedure already puts a
> sch
jan-peter.seif...@gmx.de writes:
> Hello raf,
>>> Easier is just
>>> select oid::regprocedure from pg_proc where
>> note that this method doesn't produce a complete function
>> signature. the precision and scale of numerics are not
>> included in the output. hopefully, that won't matter for
>> yo
On Thu, Mar 05, 2009 at 10:04:44AM -0500, Yauheni Labko wrote:
> You gave the recovery command, not the archive command.
I'm curious why you are focused on the archive on the primary?
Is there some logic in the archive process that could cause the recovery to
be looking for
/data/pgsql/wals/al
Greetings,
This is on a Solaris 10 box. Did I shoot myself in the foot by trying
to do a completely clean install?
I'm installing version PostgreSQL 8.3.6 as a test. I want to take it
live in two weeks. I installed it configured and ran gmake once and
it seemed to work fine, but I didn
Hello, again,
I solved my own problem. The LD_LIBRARY_PATH was not set.
Carol
On Mar 5, 2009, at 3:27 PM, Carol Walter wrote:
Greetings,
This is on a Solaris 10 box. Did I shoot myself in the foot by
trying to do a completely clean install?
I'm installing version PostgreSQL 8.3.6 as a
Carol Walter writes:
> I'm installing version PostgreSQL 8.3.6 as a test. I want to take it
> live in two weeks. I installed it configured and ran gmake once and
> it seemed to work fine, but I didn't have the data directory name that
> I thought I should have had, so I ran gmake distclean
Carol Walter wrote:
> When I looked at the config.log file, the end looks like this ...
>
> #define HAVE_WCTYPE_H 1
> #define PACKAGE_BUGREPORT "pgsql-b...@postgresql.org"
> #define PACKAGE_NAME "PostgreSQL"
> #define PACKAGE_STRING "PostgreSQL 8.3.6"
> #define PACKAGE_TARNAME "postgresql"
> #defi
I'm running postgres 8.2.5 and I'm running a PITR restore on a
remote machine.
The archived logs are being restored at a rate of about 5 every 3 minutes
I was reading in compressed logs and uncompressing them as they are being
restored. I am now reading in uncompressed logs straight into the rest
May be helpful to add on some memory information to my question:
shared_buffers - 250MB
work_mem - 75 MB
maintenance_work_mem - 100MB
max_fsm_pages- 150
wal_buffers - 96
checkpoint_segments - 32
And some information on the machine (VMWARE)
ipcs -l
-- Shared Me
13 matches
Mail list logo
