On Sun, Jul 17, 2016 at 12:47 AM, Jan Wieck wrote:
>
> The only thing I can imagine would be that there is another slony cluster
> (or
> remnants of it) hanging around in the 9.4 installation, possibly in
> another database.
>
>
That does reproduce the problem. I ran the new doc/pgbench-tutorial
I turned on archive_command and have wal archiving going.
I did a pg_basebackup and copied the resulting file from source machine
to target, yet when I restore I am getting
requested WAL segment 000508AE009B has already been removed
The earliest WAL archives I have are
000500
On Mon, Jul 18, 2016 at 7:35 AM, Francisco Reyes wrote:
> I turned on archive_command and have wal archiving going.
>
> I did a pg_basebackup and copied the resulting file from source machine to
> target, yet when I restore I am getting
>
> requested WAL segment 000508AE009B has alread
On 07/17/2016 06:35 PM, Francisco Reyes wrote:
Why is the pg_basebackup restore looking for a WAL file that is even
older than the ones I have, when I turned on WAL archiving before I
started the pg_basebackup?
Figured it out.. the error is from a secondary slave trying to sync from
the mac
On 07/17/2016 04:03 PM, Francisco Reyes wrote:
On 07/17/2016 06:35 PM, Francisco Reyes wrote:
Why is the pg_basebackup restore looking for a WAL file that is even
older than the ones I have, when I turned on WAL archiving before I
started the pg_basebackup?
Figured it out.. the error is from
Hi all,
>
>
> select stats_reset from pg_stat_database;
It says the statistics were reseted back in 2014.
I want to reset it now (production database), to get more clear data.
select pg_stat_reset();
Should be ok? Those stats aren't used for Query plan, right?
Thanks
Patrick
On 07/17/2016 08:08 PM, Patrick B wrote:
Hi all,
select stats_reset from pg_stat_database;
It says the statistics were reseted back in 2014.
I want to reset it now (production database), to get more clear data.
select pg_stat_reset();
Should be ok? Those stats aren't used for Quer
