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
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
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
about what
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 sec worth
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 to
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
early on. VF
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 be
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
somehow
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
early on. VF
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 boundary.
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. This
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
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 for
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 going to
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. The
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 better not
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 hint bits
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 scan, so we
18 matches
Mail list logo
