On 2013-11-30 17:06:31 +0100, Andres Freund wrote:
> On 2013-11-30 10:57:43 -0500, Tom Lane wrote:
> > Alvaro Herrera writes:
> > > Okay, I have pushed all these patches, including the fixes suggested
> > > here and then some.
> >
> > Not sure exactly which patch caused it, but I'm getting a warn
On 2013-11-30 10:57:43 -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > Okay, I have pushed all these patches, including the fixes suggested
> > here and then some.
>
> Not sure exactly which patch caused it, but I'm getting a warning
> in 9.0 through 9.2:
>
> multixact.c:1553: warning: no pr
On Fri, 2013-11-29 at 22:15 -0300, Alvaro Herrera wrote:
> Okay, I have pushed all these patches, including the fixes suggested
> here and then some.
Something in these patches is causing a new compiler warning in the 9.2
branch:
multixact.c:1553:1: warning: no previous prototype for
‘TrimMultiXa
Alvaro Herrera writes:
> Okay, I have pushed all these patches, including the fixes suggested
> here and then some.
Not sure exactly which patch caused it, but I'm getting a warning
in 9.0 through 9.2:
multixact.c:1553: warning: no previous prototype for 'TrimMultiXact'
Okay, I have pushed all these patches, including the fixes suggested
here and then some.
Hats off to Andres, who handled all the bug analysis, figured out the
test cases that tickled things in all the wrong ways, and came up with
the patches. Whenever we meet again, let's make sure to find a real
On 2013-11-29 13:26:00 -0800, Kevin Grittner wrote:
> Alvaro Herrera wrote:
>
> > New versions of all these patches, plus one more patch which
> > removes the behavior that HeapTupleGetUpdateXid checks for
> > aborted updates. (Turns out this was necessary to get freezing
> > right.) My previous
Alvaro Herrera wrote:
> New versions of all these patches, plus one more patch which
> removes the behavior that HeapTupleGetUpdateXid checks for
> aborted updates. (Turns out this was necessary to get freezing
> right.) My previous patch to avoid InvalidXid as page prune
> point is reverted in
On 2013-11-29 16:30:08 -0300, Alvaro Herrera wrote:
> As a second bug, heap_freeze_tuple() didn't properly handle multixacts
> that need to be frozen according to cutoff_multi, but whose updater xid
> is still alive. Instead of preserving the update Xid, it just set Xmax
> invalid, which leads to
On 2013-11-29 16:30:08 -0300, Alvaro Herrera wrote:
> New versions of all these patches, plus one more patch which removes the
> behavior that HeapTupleGetUpdateXid checks for aborted updates.
> From 0dce0b75da2732ca93f4c451b9bae6d4416794c3 Mon Sep 17 00:00:00 2001
> From: Alvaro Herrera
> Date:
On 2013-11-29 12:49:32 -0300, Alvaro Herrera wrote:
> + * - xidFullScanLimit (also known as the table freeze age) represents the
> + * minimum Xid age past which a vacuum will be turned into a full-table
> one,
> + * to freeze tuples across the whole table. Vacuuming a table younger than
> +
Hi,
Thanks, looks saner than my version ;)
On 2013-11-29 01:00:35 -0300, Alvaro Herrera wrote:
> ! /*
> ! * FIXME this calls TransactionIdDidAbort()
> internally,
> ! * falsifying the claim in the comment at th
Andres Freund escribió:
> Patch 02 has changed its shape slightly since the version I posted here,
> because it's a prerequisite for the fix for the multixact bugs around
> heap_freeze_tuple() and heap_tuple_needs_freeze() I've written about
> nearby. I think Alvaro plans to work over my fixes to
On 2013-11-28 19:23:29 -0500, Robert Haas wrote:
> On Wed, Nov 27, 2013 at 5:42 PM, Andres Freund wrote:
> > So, I've done this for 9.3+ for now. Testing around that turned up that
> > our current way to schedule anti mxid wraparounds doesn't really work:
> > 1) autovacuum.c knows about such vacuu
On Wed, Nov 27, 2013 at 5:42 PM, Andres Freund wrote:
> So, I've done this for 9.3+ for now. Testing around that turned up that
> our current way to schedule anti mxid wraparounds doesn't really work:
> 1) autovacuum.c knows about such vacuums, but vacuum.c doesn't. Leading
> to a long cycle of pa
Hi,
Heikki's comments about StartupMultiXact() being executed too late in
http://archives.postgresql.org/message-id/528C9392.804%40vmware.com
made me look at how multixact truncation works, since that's where
SimpleLruTruncate() would trigger an error because of an unitialized
latest_page_numb
15 matches
Mail list logo
