Re: btree_gist macaddr valgrind woes
От | Tom Lane |
---|---|
Тема | Re: btree_gist macaddr valgrind woes |
Дата | |
Msg-id | 4183.1400361838@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: btree_gist macaddr valgrind woes (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: btree_gist macaddr valgrind woes
|
Список | pgsql-hackers |
Andres Freund <andres@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 over an int8 and the other > over the datatype requiring the gist index to be used. I've certainly > done that. Yeah; the whole point of having these opclasses at all is to allow a GIST index to index a scalar column along with some GIST-only functionality. However, given the lack of field complaints, it seems likely that nobody is trying to do that on non-Intel architectures; or at least, not on a non-Intel architecture where the kernel is unwilling to mask the problem via trap emulation. So my feeling about it is we don't need to try to back-patch a fix. I'd like to see it fixed in HEAD, though. 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 want to volunteer to run a critter on my HPPA box: it's old enough, and eats enough electricity, that I no longer want to leave it on 24x7. Plus a lot of the time its response to a bus error is to lock up in a tight loop rather than report an error, so a failure wouldn't get reported usefully by the buildfarm anyway. Does anyone have an ARM or PPC box where they can configure the kernel not to mask misaligned fetches? regards, tom lane
В списке pgsql-hackers по дате отправления: