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
columns have
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 seems like a
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
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 first
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
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 them. I
Andres Freund and...@2ndquadrant.com 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
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==
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
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 it's
Heikki Linnakangas hlinnakan...@vmware.com 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
Andres Freund and...@2ndquadrant.com 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
On 05/16/2014 06:43 PM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com 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
Heikki Linnakangas hlinnakan...@vmware.com 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
Heikki Linnakangas hlinnakan...@vmware.com 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
Hi,
On 2014-05-16 15:31:52 -0400, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com 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
16 matches
Mail list logo
