don't you try using Barman? It allows you to take snapshots and do PITR.
Not to mention you can use it as it's intended purpose as a backup engine.
-Joseph
On Thu, Aug 14, 2014 at 1:53 PM, Bill Mitchell
mailto:b...@publicrelay.com>> wrote:
We are running our own Postgres server
We are running our own Postgres server on AWS as well (since amazon RDS doesn't
support read replicas yet)
In out case, simply having a streaming replication standby works - and we do
our pg_dump from that -- or simply snapshot the machine and then promote the
replica to master to use full data
I wanted to share an experience that we had this morning, after the
upgrade from postgres 9.2.7 to postgres 9.3.4 on our production system.
(The data set was upgraded in QA without issues,but I rather suspect
that I had done a full 'vacuum' on that data set more recently). NOTE:
this was within a
; Jov
> blog: http:amutu.com/blog <http://amutu.com/blog>
>
>
> 2013/7/8 Bill Mitchell <mailto:b...@publicrelay.com>>
>
> You can do select pg_cancel_backend(8243);
>
> and that should terminate that process that is sending, but still
> leave you
You can do select pg_cancel_backend(8243);
and that should terminate that process that is sending, but still leave
your postgres server healthy.
regards,
Bill
On 7/8/13 5:31 AM, Jov wrote:
> one of our pg user send a select * from 10 million table without limit
> from psql,before get the return
Thanks to everybody's input -- as a first-time poster to this listserv,
I wasn't sure how long it would take to get a response. ;)
I was frankly astonished to see that the composite index on (a,b) was
used when I searched for (a), but Chris' response makes total sense.
In this case, I don't want
I am searching for some logic behind the selection of an index in
postgres -- it seems that if I have a composite index based on both
columns in a join table, it's only referenced if I query on the first
term in the composite index. I've read
http://www.postgresql.org/docs/9.1/static/indexes-multi
