On Tue, Mar 13, 2012 at 4:53 PM, Josh Berkus j...@agliodbs.com wrote:
4. On a high-UPDATE workload, this means that the replica assumes tables
have no free space until it starts to build a new FSM or autovacuum
kicks in on some of the tables, much later on.
5. If your hosting is such that you
Daniel Farina dan...@heroku.com writes:
but just today we promoted another system via streaming replication to
pick up the planner fix in 9.1.5 (did you know: that planner bug seems
to make GIN FTS indexes un-used in non-exotic cases, and one goes to
seqscan?), and then a 40MB GIN index
On 20.03.2012 23:41, Josh Berkus wrote:
Heikki,
The FSM is included in the base backup, and it is updated when VACUUM
records are replayed.
Oh? H. In that case, the issue I'm seeing in production is
something else. Unless that was a change for 9.1?
No, it's been like that since
Heikki,
The FSM is included in the base backup, and it is updated when VACUUM
records are replayed.
Oh? H. In that case, the issue I'm seeing in production is
something else. Unless that was a change for 9.1?
It is also updated when insert/update/delete records are replayed,
athough
On 14.03.2012 01:53, Josh Berkus wrote:
1. The Free Space Map is not replicated between servers.
2. Thus, when we fail over to a replica, it starts with a blank FSM.
The FSM is included in the base backup, and it is updated when VACUUM
records are replayed.
It is also updated when
All,
I've discovered a built-in performance issue with replication failover
at one site, which I couldn't find searching the archives. I don't
really see what we can do to fix it, so I'm posting it here in case
others might have clever ideas.
1. The Free Space Map is not replicated between
On Tue, Mar 13, 2012 at 4:53 PM, Josh Berkus j...@agliodbs.com wrote:
All,
I've discovered a built-in performance issue with replication failover
at one site, which I couldn't find searching the archives. I don't
really see what we can do to fix it, so I'm posting it here in case
others
On Wed, Mar 14, 2012 at 8:53 AM, Josh Berkus j...@agliodbs.com wrote:
All,
I've discovered a built-in performance issue with replication failover
at one site, which I couldn't find searching the archives. I don't
really see what we can do to fix it, so I'm posting it here in case
others
On Tue, Mar 13, 2012 at 7:05 PM, Fujii Masao masao.fu...@gmail.com wrote:
If it's really a high-UPDATE workload, wouldn't autovacuum start soon?
Also, while vacuum cleanup records are applied, could not the standby
also update its free space map, without having to send the actual FSM
updates? I