Daniel Farina 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 bloated to two gigs
On Tue, Mar 13, 2012 at 4:53 PM, Josh Berkus 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 fail over a
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 8.4,
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,
> atho
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 insert/up
On Tue, Mar 13, 2012 at 7:05 PM, Fujii Masao 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 guess that's boggin
On Wed, Mar 14, 2012 at 8:53 AM, Josh Berkus 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 might have clev
On Tue, Mar 13, 2012 at 4:53 PM, Josh Berkus 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 might have clev
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 serve
