On Sat, May 17, 2014 at 11:46:39PM +0300, Heikki Linnakangas wrote:
> >AFAICS, what we have to do is mark the wider gbtreekeyNN types as
> >requiring double alignment. This will break pg_upgrade'ing any index in
> >which they're used as non-first columns, unless perhaps all the preceding
> >column
Heikki Linnakangas wrote:
> On 05/18/2014 12:23 AM, Tom Lane wrote:
> >A larger issue is that we evidently have no buildfarm animals that are
> >picky about alignment, or at least none that are running a modern-enough
> >buildfarm script to be running the contrib/logical_decoding test.
> >That seem
On 05/18/2014 12:23 AM, Tom Lane wrote:
A larger issue is that we evidently have no buildfarm animals that are
picky about alignment, or at least none that are running a modern-enough
buildfarm script to be running the contrib/logical_decoding test.
That seems like a significant gap. I don't wan
Andres Freund writes:
> On 2014-05-17 23:46:39 +0300, Heikki Linnakangas wrote:
>> I doubt there are many people using btree_gist on int8 or float8
>> columns.
> I don't think it's that unlikely. It can make a fair amount of sense to
> have multicolumn indexes where one columns is over an int8 an
On 2014-05-17 23:46:39 +0300, Heikki Linnakangas wrote:
> On 05/17/2014 11:12 PM, Tom Lane wrote:
> >I wrote:
> >>BTW, the *real* problem with all this stuff is that the gbtreekeyNN types
> >>are declared as having int alignment, even though some of the opclasses
> >>store double-aligned types in t
On 05/17/2014 11:12 PM, Tom Lane wrote:
I wrote:
BTW, the *real* problem with all this stuff is that the gbtreekeyNN types
are declared as having int alignment, even though some of the opclasses
store double-aligned types in them. I imagine it's possible to provoke
bus errors on machines that a
I wrote:
> BTW, the *real* problem with all this stuff is that the gbtreekeyNN types
> are declared as having int alignment, even though some of the opclasses
> store double-aligned types in them. I imagine it's possible to provoke
> bus errors on machines that are picky about alignment. The firs
Hi,
On 2014-05-16 15:31:52 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 05/16/2014 06:43 PM, Tom Lane wrote:
> >> Dunno what's the problem for the varlena types, but that's a completely
> >> separate code path.
>
> > It seems to be a similar issue to what I fixed in the bit type ea
Heikki Linnakangas writes:
> ISTM the "correct" fix would be to define a gbtreekey12 data type and
> use that. That's not back-patchable though, and introducing a whole new
> type to save a few bytes is hardly worth it. What you did makes sense.
BTW, the *real* problem with all this stuff is th
Heikki Linnakangas writes:
> On 05/16/2014 06:43 PM, Tom Lane wrote:
>> Dunno what's the problem for the varlena types, but that's a completely
>> separate code path.
> It seems to be a similar issue to what I fixed in the bit type earlier.
> When the lower+upper keys are stored as one varlen Da
On 05/16/2014 06:43 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 05/16/2014 01:28 PM, Andres Freund wrote:
Presumably it's because the type is a fixed width type with a length of
6. I guess it's allocating stuff sizeof(macaddr) but then passes the
result around as a Datum which doesn't wo
Andres Freund writes:
> After Heikki has fixed the bit btree_gist bugs my valgrind run shows a
> bug in macaddr.
AFAICT none of these traces represent live bugs, but I've pushed fixes
for them into HEAD.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-h
Heikki Linnakangas writes:
> On 05/16/2014 01:28 PM, Andres Freund wrote:
>> Presumably it's because the type is a fixed width type with a length of
>> 6. I guess it's allocating stuff sizeof(macaddr) but then passes the
>> result around as a Datum which doesn't work well.
I've not tried valgrind
On 2014-05-16 17:08:40 +0300, Heikki Linnakangas wrote:
> On 05/16/2014 01:28 PM, Andres Freund wrote:
> >Hi,
> >
> >After Heikki has fixed the bit btree_gist bugs my valgrind run shows a
> >bug in macaddr.
> >
> >Presumably it's because the type is a fixed width type with a length of
> >6. I guess
On 05/16/2014 01:28 PM, Andres Freund wrote:
Hi,
After Heikki has fixed the bit btree_gist bugs my valgrind run shows a
bug in macaddr.
Presumably it's because the type is a fixed width type with a length of
6. I guess it's allocating stuff sizeof(macaddr) but then passes the
result around as a
Hi,
After Heikki has fixed the bit btree_gist bugs my valgrind run shows a
bug in macaddr.
Presumably it's because the type is a fixed width type with a length of
6. I guess it's allocating stuff sizeof(macaddr) but then passes the
result around as a Datum which doesn't work well.
==14219== Inva
16 matches
Mail list logo
