Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have been thinking we could improve how quickly VACUUM can expire rows
> > if we update procArray.xmin more frequently for non-SERIALIZABLE
> > transactions.
> > The attached patch updates procArray.xmin in this manner.
>
> This pat
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have been thinking we could improve how quickly VACUUM can expire rows
> if we update procArray.xmin more frequently for non-SERIALIZABLE
> transactions.
> The attached patch updates procArray.xmin in this manner.
This patch is incredibly broken. Didn
Bruce Momjian wrote:
> The attached patch updates procArray.xmin in this manner. Here is an
> example of how the patch improves dead row reuse:
I don't think this really works. Consider what happens if I change
session 2 this way:
> Session #:
> 1 2
VACUUM treats dead tuple with an xmax less than all procArray.xmin's as
invisible with space ready to be reused.
Right now, we set procArray.xmin at transaction start to the required
SERIALIZABLE value. We currently don't update procArray.xmin when we
know we are in a READ COMMITTED transaction,
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Yup, that was indeed the problem. I assume you'll do the honors.
>
> Yeah, the comments need fixed too. I'll do it later today.
Thanks.
//Magnus
---(end of broadcast)---
TIP 6: expl
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Yup, that was indeed the problem. I assume you'll do the honors.
Yeah, the comments need fixed too. I'll do it later today.
regards, tom lane
---(end of broadcast)---
TIP 4: Hav
Magnus Hagander wrote:
> Tom Lane wrote:
>> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> The SEG parameters going into seg_overlap() look perfectly correct, and
>>> seg_overlap() actually returns 0. But this is somehow later turned into
>>> 't'. Any pointers for where to look for how that happen
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> The SEG parameters going into seg_overlap() look perfectly correct, and
>> seg_overlap() actually returns 0. But this is somehow later turned into
>> 't'. Any pointers for where to look for how that happens?
>
> I'll betcha that MSVC
Magnus Hagander <[EMAIL PROTECTED]> writes:
> The SEG parameters going into seg_overlap() look perfectly correct, and
> seg_overlap() actually returns 0. But this is somehow later turned into
> 't'. Any pointers for where to look for how that happens?
I'll betcha that MSVC is generating code that
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Anyway, I think you probably need to load up the old debugger and put a
>> break point in the overlap function ... surely the error can't be in
>> float4in or else we'd have seen other regression problems.
>
> One of the failing te
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Anyway, I think you probably need to load up the old debugger and put a
> break point in the overlap function ... surely the error can't be in
> float4in or else we'd have seen other regression problems.
One of the failing test cases is for seg_over_
Magnus Hagander wrote:
contrib/seg fails regression tests on my msvc build (reason Ididn't notice
earlier is probably that you couldn't run contribcheck on the vcbuild).
regression.diff attached.
Anybody see a smoking gun? I don't really know what seg is supposed to be
doing, so I don't know whe
On Fri, Mar 23, 2007 at 01:15:10PM +0300, Teodor Sigaev wrote:
> >Anybody see a smoking gun? I don't really know what seg is supposed to be
> >doing, so I don't know where to start.
>
> As crazy idea only: try to modify seg_overlap to
> bool
> seg_overlap(SEG * a, SEG * b)
> {
> return (
>
Anybody see a smoking gun? I don't really know what seg is supposed to be
doing, so I don't know where to start.
As crazy idea only: try to modify seg_overlap to
bool
seg_overlap(SEG * a, SEG * b)
{
return (
((a->upper >= b->upper) && (a->lower <= b->upper))
||
contrib/seg fails regression tests on my msvc build (reason Ididn't notice
earlier is probably that you couldn't run contribcheck on the vcbuild).
regression.diff attached.
Anybody see a smoking gun? I don't really know what seg is supposed to be
doing, so I don't know where to start.
(had to sen
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I certainly don't see the point of the implementation as you have it
--- it adds a great deal of unnecessary infrastructure compared to just
installing a symlink at share/postgresql/timezone.
The point of my solution is
On Thu, Mar 22, 2007 at 12:33:30PM -0400, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > contrib/spi has a Makefile that uses $(addsuffix) makefile rules for
> > DATA_built and DOCS. It's the only Makefile in contrib that does it.
> > I would like to change that to actually listi
17 matches
Mail list logo
