From: | Daniel Farina <daniel(at)heroku(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sync Rep v17 |
Date: | 2011-02-24 06:39:42 |
Message-ID: | AANLkTi=un9ycBfJtvJ14D5qPgyGfeh6Z4-FHj3HUyFrQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 18, 2011 at 4:06 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> Well, good news all round.
>
> v17 implements what I believe to be the final set of features for sync
> rep. This one I'm actually fairly happy with. It can be enjoyed best at
> DEBUG3.
I've been messing with this patch and am wondering if this behavior is expected:
I've been frobbing the server around (I was messing around with the
syncrep feature, but do not know if this is related just yet), and
came upon a case I do not expect: it would appear that prior to
establishing a connection to do streaming replication, the "startup
process" (which is recovering) is very slowly catching up (or so it
would be indicated by txid_current_snapshot()) and eating up enormous
amounts of memory, such as 6GB at a time in RES, monotonically
increasing. Furthermore, the incrementation of the txid_snapshot is
very slow, and it doesn't seem like I'm coming close to making full
use of my resources: cpu and block devices are not very busy. There
may have been a brief spurt of pgbench activity that would generate
such WAL traffic to replay.
I have not done a hard shutdown to my knowledge, and the server does
allow me to query relatively quickly as a standby.
Looks like I'm about to hit 7+GB. Is there something I'm missing?
--
fdr
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Farina | 2011-02-24 06:42:06 | Re: Sync Rep v17 |
Previous Message | PostgreSQL - Hans-Jürgen Schönig | 2011-02-24 06:13:36 | Re: WIP: cross column correlation ... |