On Fri, Mar 18, 2011 at 4:55 PM, Stephen Rees wrote:
> Robert,
>
> Thank you for reply. I had the wrong end of the stick regarding pg_dump and
> hot-standby.
> I will take a look at omnipitr, as you suggest.
>
> Per your comment
>>
>> You have to stop replay while you are doing the dumps like this
Robert,
Thank you for reply. I had the wrong end of the stick regarding
pg_dump and hot-standby.
I will take a look at omnipitr, as you suggest.
Per your comment
You have to stop replay while you are doing the dumps like this
how do I stop, then resume, replay with both the master and hot-
On Tue, Mar 15, 2011 at 5:50 PM, Stephen Rees wrote:
> Using PostgreSQL 9.0.x
>
> I cannot use pg_dump to generate a backup of a database on a hot-standby
> server, because it is, by definition, read-only.
That really makes no sense :-) You can use pg_dump on a read-only
slave, but I think the i
Stephen Rees wrote:
> I cannot use pg_dump to generate a backup of a database on a hot-
> standby server, because it is, by definition, read-only.
That seems like a non sequitur -- I didn't think pg_dump wrote
anything to the source database. Have you actually tried? If so,
please show your
Using PostgreSQL 9.0.x
I cannot use pg_dump to generate a backup of a database on a hot-
standby server, because it is, by definition, read-only. However, it
seems that I can use COPY TO within a serializable transaction to
create a consistent set of data file(s). For example,
BEGIN TRANSA
