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
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
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
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
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
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
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
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
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
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
> 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
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
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
13 matches
Mail list logo
