Yes, it does indeed interleave and it seems to archive the backlog just
before the files are about to be deleted. That explains it.
Thanks for your help,
Neil
2013/1/31 Jeff Janes
> On Thu, Jan 31, 2013 at 12:50 AM, Neil Worden
> wrote:
> >
> > The situation is as follows:
> >
> > All conc
Sorry, this one should have been sent to the group.
-- Forwarded message --
Hi,
Master M -> streaming via pg_receivexlog -> TEST R (same location,
currently for testing and experimenting)
-> streaming to hot standby via dsl -> HOT1 (other location,
hot-standby a
On Thu, Jan 31, 2013 at 12:50 AM, Neil Worden wrote:
>
> The situation is as follows:
>
> All concerned machines are running 9.2.2 64-bit on Ubuntu Linux Server
> 12.10, installed from source, all following exactly the same procedure. We
> have a hot-standby running to a different location over a
On 01/31/2013 01:48 AM, Neil Worden wrote:
Btw, ps shows:
The archiver process says "last was 0001006E0034" and when i
look into my wal-archive-directory i see:
-rw--- 1 postgres postgres 16777216 Jan 31 10:24
0001006E0033
-rw--- 1 postgres postgres 1677
And a few minutes later the archiver-process with the same process-id has
written a file from ..8.. line:
postgres 11502 0.0 0.0 161096724 3112 ? Ss Jan29 0:12 postgres:
autovacuum launcher process
postgres 11503 0.0 0.0 20136 884 ?Ss Jan29 0:10 postgres:
archiver proce
Btw, ps shows:
postgres@darkblue:/data/pgdata/pg_xlog$ ps aux | grep post
postgres 11496 0.1 0.9 161018232 3696076 ? SJan29 2:49 postmaster
-i -D /data/pgdata
postgres 11499 0.0 1.6 161097088 6450616 ? Ss Jan29 1:39 postgres:
checkpointer process
postgres 11500 0.0 0.3 16109503
>>> If your command does overwrite, then the server currently emitting the
>>> 8D files will become unrecoverable once those files start getting
>>> overwritten. If it refuses to overwrite, but returns a zero status,
>>> then the server currently emitting 6D would become unrecoverable once
>>> it
On Wed, Jan 30, 2013 at 3:13 PM, Adrian Klaver wrote:
> On 01/30/2013 11:16 AM, Jeff Janes wrote:
>>
>> On Wed, Jan 30, 2013 at 12:58 AM, Neil Worden
>> wrote:
>>
>>
>>> If not, how do i prevent files from being overwritten when using an
>>> archive_command ?
>>
>>
>> It is the archive_command's
On 01/30/2013 11:16 AM, Jeff Janes wrote:
On Wed, Jan 30, 2013 at 12:58 AM, Neil Worden wrote:
If not, how do i prevent files from being overwritten when using an
archive_command ?
It is the archive_command's job to refuse to overwrite. From the docs:
"It is advisable to test your propose
On Wed, Jan 30, 2013 at 12:58 AM, Neil Worden wrote:
>
> As you can see it recycles existing files by using them with their exact
> name as they already exist (next file to be overwritten is the ..91-file).
> So far so good. I have, just a few minutes ago, set archive_mode to "on" and
> set an arc
Hi all,
i am not sure whether i have fully understood the implications of
archiving wal-files and i have a few questions.
We currently keep a rather long backlog of wal-files, since we have a few
hot-standbys over slow and unreliable lines that might fall back. So this
is an extract from my curr
11 matches
Mail list logo
