On Wed, 2007-09-26 at 04:33 -0400, Bruce Momjian wrote:
> This has been saved for the 8.4 release:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Already applied.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)--
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Simon Riggs wrote:
> On Thu, 2007-06-28 at 20:23 -0400, Tom Lane wrote:
> > "Simon Riggs" <[EMAIL PROTECTED]> writes:
On Wed, 2007-07-18 at 01:01 +0100, Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > Where are we on this?
>
> Well Simon just sent the reworked patch yesterday so the answer is we haven't
> started tuning this parameter. (Bruce's message is referring to the discussion
> ab
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Where are we on this?
Well Simon just sent the reworked patch yesterday so the answer is we haven't
started tuning this parameter. (Bruce's message is referring to the discussion
about what the optimal value of lsns per clog page would be.)
I intend
Where are we on this?
---
Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > I'd guess that storing 8 per page would be optimal, so each stored xid would
> > track 4,000 transactions - probably around 1
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> I'd guess that storing 8 per page would be optimal, so each stored xid would
> track 4,000 transactions - probably around 1 sec worth of transactions when
> the feature is used.
This is something we can experiment with but I suspect that while 8 might b
On Thu, 2007-06-28 at 20:23 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Thu, 2007-06-28 at 15:16 -0400, Tom Lane wrote:
> >> A quick grep suggests that VACUUM FULL might be at risk here.
>
> > No we're clear: I caught that issue specifically for VACUUM FULL fairly
> >
On Fri, 2007-06-29 at 11:13 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Thu, 2007-06-28 at 20:23 -0400, Tom Lane wrote:
> >> The methodology I suggested earlier (involving tracking LSN only at the
> >> level of pg_clog pages) isn't going to make that work, unless you
>
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Thu, 2007-06-28 at 20:23 -0400, Tom Lane wrote:
>> The methodology I suggested earlier (involving tracking LSN only at the
>> level of pg_clog pages) isn't going to make that work, unless you
>> somehow force the XID counter forward to the next page bo
On Thu, 2007-06-28 at 20:23 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Thu, 2007-06-28 at 15:16 -0400, Tom Lane wrote:
> >> A quick grep suggests that VACUUM FULL might be at risk here.
>
> > No we're clear: I caught that issue specifically for VACUUM FULL fairly
> >
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Thu, 2007-06-28 at 15:16 -0400, Tom Lane wrote:
>> A quick grep suggests that VACUUM FULL might be at risk here.
> No we're clear: I caught that issue specifically for VACUUM FULL fairly
> early on. VF assumes all hint bits are set after the first sca
On Thu, 2007-06-28 at 15:29 -0400, Alvaro Herrera wrote:
> Tom Lane escribió:
> > Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > > AFAICS, we can just simply remove the assertion. But is there any
> > > codepaths that assume that after calling HeapTupleSatisfiesSnapshot, all
> > > appropriate
On Thu, 2007-06-28 at 15:16 -0400, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > AFAICS, we can just simply remove the assertion. But is there any
> > codepaths that assume that after calling HeapTupleSatisfiesSnapshot, all
> > appropriate hint bits are set?
>
> There had
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> A quick grep suggests that VACUUM FULL might be at risk here.
> That particular case seems easily fixed since VACUUM FULL must hold an
> exclusive lock; and we can forcibly set sync commit for VACUUM FULL.
Uh, that wouldn't help.
Tom Lane escribió:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > AFAICS, we can just simply remove the assertion. But is there any
> > codepaths that assume that after calling HeapTupleSatisfiesSnapshot, all
> > appropriate hint bits are set?
>
> There had better not be, since we are goin
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> AFAICS, we can just simply remove the assertion. But is there any
> codepaths that assume that after calling HeapTupleSatisfiesSnapshot, all
> appropriate hint bits are set?
There had better not be, since we are going to postpone setting hint
bits
Pavan Deolasee wrote:
During one of HOT stress tests, an asserition failed at tqual.c:1178
in HeapTupleSatisfiesVacuum(). The assertion failure looked really
strange because the assertion checks for HEAP_XMAX_COMMITTED
which we set just couple of lines above. I inspected the core dump
and found t
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> So we suspected an interaction between multiple processes each holding
> a SHARE lock and setting/checking different bits in the infomask and
> we could theoritically say that such interaction can potentially lead to
> missing hint bit updates.
Yeah.
During one of HOT stress tests, an asserition failed at tqual.c:1178
in HeapTupleSatisfiesVacuum(). The assertion failure looked really
strange because the assertion checks for HEAP_XMAX_COMMITTED
which we set just couple of lines above. I inspected the core dump
and found that the flag is *set* p
19 matches
Mail list logo
