On 08.03.2011 10:49, daveg wrote:
On Tue, Mar 08, 2011 at 10:37:24AM +0200, Heikki Linnakangas wrote:
On 08.03.2011 10:00, Heikki Linnakangas wrote:
Another idea is to give up on the warning when it appears that
oldestxmin has moved backwards, and assume that it's actually fine. We
could still
On 08.03.2011 10:38, daveg wrote:
I read this to mean that it is safe to ignore this warning and that these
databases are not at risk for data corruption or wrong results so long as
the warning is due to oldestxmin. Please correct me if I have misunderstood.
Yes, that's correct.
--
Heikki L
On Tue, Mar 08, 2011 at 10:37:24AM +0200, Heikki Linnakangas wrote:
> On 08.03.2011 10:00, Heikki Linnakangas wrote:
> >Another idea is to give up on the warning when it appears that
> >oldestxmin has moved backwards, and assume that it's actually fine. We
> >could still warn in other cases where t
On Tue, Mar 08, 2011 at 10:00:01AM +0200, Heikki Linnakangas wrote:
> On 08.03.2011 04:07, Greg Stark wrote:
> >Well from that log you definitely have OldestXmin going backwards. And
> >not by a little bit either. at 6:33 it set the all_visible flag and
> >then at 7:01 it was almost 1.3 million tra
On 08.03.2011 10:00, Heikki Linnakangas wrote:
Another idea is to give up on the warning when it appears that
oldestxmin has moved backwards, and assume that it's actually fine. We
could still warn in other cases where the flag appears to be incorrectly
set, like if there is a deleted tuple on th
On 08.03.2011 04:07, Greg Stark wrote:
Well from that log you definitely have OldestXmin going backwards. And
not by a little bit either. at 6:33 it set the all_visible flag and
then at 7:01 it was almost 1.3 million transactions earlier. In fact
to precisely the same value that was in use for a
On Mon, Mar 7, 2011 at 11:53 PM, daveg wrote:
>> Looking at the code, I don't see how that situation could arise, though.
>> The value calculated by GetOldestXmin() should never move backwards. And
>> GetOldestXmin() is called in lazy_vacuum_rel(), after it has acquired a
>> lock on the table, whi
On Fri, Mar 04, 2011 at 05:52:29PM +0200, Heikki Linnakangas wrote:
> Hmm, if these all came from the same database, then it looks OldestXmin
> has moved backwards. That would explain the warnings. First one vacuum
> determines that all the tuples are visible to everyone and sets the
> flag. The
On 04.03.2011 11:00, daveg wrote:
Thanks, I've applied both patches to one host. I'll probably have to back
down on the debugging logging soon, as the output is pretty voluminious,
it is producing 100MB of message log every few minutes. I'll try Merlins
patch to get the case setting the bit first
On Thu, Mar 03, 2011 at 09:04:04AM -0600, Merlin Moncure wrote:
> On Thu, Mar 3, 2011 at 2:16 AM, Heikki Linnakangas
> wrote:
> > On 03.03.2011 09:12, daveg wrote:
> >>
> >> Question: what would be the consequence of simply patching out the setting
> >> of this flag? Assuming that the incorrect PD
On Thu, Mar 3, 2011 at 2:16 AM, Heikki Linnakangas
wrote:
> On 03.03.2011 09:12, daveg wrote:
>>
>> Question: what would be the consequence of simply patching out the setting
>> of this flag? Assuming that the incorrect PD_ALL_VISIBLE flag is the only
>> problem (big assumption perhaps) then simpl
On Thu, Mar 03, 2011 at 10:16:29AM +0200, Heikki Linnakangas wrote:
> On 03.03.2011 09:12, daveg wrote:
> >Question: what would be the consequence of simply patching out the setting
> >of this flag? Assuming that the incorrect PD_ALL_VISIBLE flag is the only
> >problem (big assumption perhaps) then
On 03.03.2011 09:12, daveg wrote:
Question: what would be the consequence of simply patching out the setting
of this flag? Assuming that the incorrect PD_ALL_VISIBLE flag is the only
problem (big assumption perhaps) then simply never setting it would at least
avoid the possibility of returning wr
On Tue, Mar 01, 2011 at 08:40:37AM -0500, Robert Haas wrote:
> On Mon, Feb 28, 2011 at 10:32 PM, Greg Stark wrote:
> > On Tue, Mar 1, 2011 at 1:43 AM, David Christensen
> > wrote:
> >> Was this cluster upgraded to 8.4.4 from 8.4.0? It sounds to me like a
> >> known bug in 8.4.0 which was fixed
On Mon, Feb 28, 2011 at 10:32 PM, Greg Stark wrote:
> On Tue, Mar 1, 2011 at 1:43 AM, David Christensen wrote:
>> Was this cluster upgraded to 8.4.4 from 8.4.0? It sounds to me like a known
>> bug in 8.4.0 which was fixed by this commit:
>>
>
> The reproduction script described was running vacu
On Tue, Mar 1, 2011 at 1:43 AM, David Christensen wrote:
> Was this cluster upgraded to 8.4.4 from 8.4.0? It sounds to me like a known
> bug in 8.4.0 which was fixed by this commit:
>
The reproduction script described was running vacuum repeatedly. A
single vacuum run out to be sufficient to cl
16 matches
Mail list logo
