Jeff Janes wrote
>
> It seems like it shouldn't be all that hard to write a tool to parse
> WAL logs in a context-free basis (i.e. without the backup to start
> applying them to) and emit some kind of descriptions of the records
> and their sizes. But I don't know about such a tool already exist
On Mon, Aug 20, 2012 at 1:51 PM, delongboy wrote:
>
> Jeff Janes wrote
>>
>> Maybe there is an easier way, but one thing would be to compile a test
>> server (of the same version as the production) with WAL_DEBUG defined
>> in src/include/pg_config_manual.h, turn on the wal_debug guc, and
>> crank
Jeff Janes wrote
>
> Maybe there is an easier way, but one thing would be to compile a test
> server (of the same version as the production) with WAL_DEBUG defined
> in src/include/pg_config_manual.h, turn on the wal_debug guc, and
> crank up trace_recovery_messages. Then replay the WAL log file
On Fri, Aug 17, 2012 at 10:53 AM, delongboy wrote:
>
> Josh Berkus wrote
>>
>>> We are not doing anything to postgres that would cause the rise and
>>> drop.
>>> Data base activity is pretty consistent. nor are we doing any kind
>>> of
>>> purge. This week the drop occurred after 6 days. We are
Josh Berkus wrote
>
>> We are not doing anything to postgres that would cause the rise and
>> drop.
>> Data base activity is pretty consistent. nor are we doing any kind
>> of
>> purge. This week the drop occurred after 6 days. We are thinking it
>> must
>> be some kind of internal postgres ac
> We are not doing anything to postgres that would cause the rise and
> drop.
> Data base activity is pretty consistent. nor are we doing any kind
> of
> purge. This week the drop occurred after 6 days. We are thinking it
> must
> be some kind of internal postgres activity but we can't track it
delongboy wrote:
> We are not doing anything to postgres that would cause the rise
> and drop. Data base activity is pretty consistent. nor are we
> doing any kind of purge. This week the drop occurred after 6
> days. We are thinking it must be some kind of internal postgres
> activity but we
We are not doing anything to postgres that would cause the rise and drop.
Data base activity is pretty consistent. nor are we doing any kind of
purge. This week the drop occurred after 6 days. We are thinking it must
be some kind of internal postgres activity but we can't track it down.
--
V
> Any ideas on any of this? Why the sawteeth? Why the rise-then-drop?
Well, my first thought on the sawteeth is that you have archive_timeout
set to 15 minutes. No?
As for the gradual buildup over days, that most likely corresponds to
either changes in application activity levels, or some kind
http://i.imgur.com/sva4H.png
In the image above, please find the traffic we have seen from our main
postgresql node to our cloud backup.
A few notes on that image:
a) We're only interested in looking at the blue - outbound - traffic
b) In general, this pipe is almost exclusively for WAL usage
10 matches
Mail list logo
