From: | Granthana Biswas <granthana(at)zedo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Sergey Konoplev <gray(dot)ru(at)gmail(dot)com>, PostgreSQL General Discussion Forum <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Dead rows not getting removed during vacuum |
Date: | 2014-03-28 04:36:57 |
Message-ID: | CAACh-pVBvx4svJfcmCcTfTcSD1VmmKfttouvjYvTMkd262WyAA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thank you Tom. We will be upgrading soon.
Regards,
Granthana
On Mon, Mar 24, 2014 at 7:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Granthana Biswas <granthana(at)zedo(dot)com> writes:
> > Version is PostgreSQL 9.1.4.
>
> You do realize you're missing almost two years' worth of bug fixes?
> The current release in that branch is 9.1.13, and a quick look through
> the git history shows quite a number of replication-related fixes.
>
> One that seems particularly notable in this connection is:
>
> commit 16222f32ed56d3ebc4136133662d932299188955
> Author: Simon Riggs <simon(at)2ndQuadrant(dot)com>
> Date: Thu Jun 7 19:24:47 2012 +0100
>
> Wake WALSender to reduce data loss at failover for async commit.
> WALSender now woken up after each background flush by WALwriter,
> avoiding
> multi-second replication delay for an all-async commit workload.
> Replication delay reduced from 7s with default settings to 200ms,
> allowing
> significantly reduced data loss at failover.
>
> Andres Freund and Simon Riggs
>
> You wouldn't happen to be running with synchronous_commit off, would you?
>
> Whether this is the explanation for your problem or not, it's really
> irresponsible to still be running 9.1.4 at this point. There are several
> known data-loss-inducing bugs in it that will eat your data sooner or
> later.
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Khangelani Gama | 2014-03-28 05:51:44 | Re: Synchronizing a table that is two different databases : Need to dump a table a insert from db1 and change the insert statements into UPDATE statements |
Previous Message | Michael Ainsworth | 2014-03-28 01:36:25 | The result of the last function call overwrites the result of previous function calls |