Robert Haas writes:
> Excellent. Are you going to look at MauMau's patch for bug #6011 also?
No. I don't do Windows, so I can't test it.
(On general principles, I don't think that hacking write_eventlog the
way he did is appropriate; such a function should write the log, not
editorialize. But
Noah Misch writes:
> Adding a memory definedness check to printtup() turned up one more culprit:
> tsquery_and.
Patch applied, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
On Tue, May 24, 2011 at 2:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, May 24, 2011 at 2:11 PM, Noah Misch wrote:
>>> QTN2QT() allocates memory for a TSQuery using palloc(). TSQuery contains an
>>> array of QueryItem, which contains three bytes of padding between its first
>>> and
>
Robert Haas writes:
> On Tue, May 24, 2011 at 2:11 PM, Noah Misch wrote:
>> QTN2QT() allocates memory for a TSQuery using palloc(). TSQuery contains an
>> array of QueryItem, which contains three bytes of padding between its first
>> and
>> second members. Those bytes don't get initialized, so
On Tue, May 24, 2011 at 2:11 PM, Noah Misch wrote:
>> OK, I can't see what's broken. Help?
>
> QTN2QT() allocates memory for a TSQuery using palloc(). TSQuery contains an
> array of QueryItem, which contains three bytes of padding between its first
> and
> second members. Those bytes don't get
On Tue, May 24, 2011 at 02:05:33PM -0400, Robert Haas wrote:
> On Mon, May 23, 2011 at 1:12 AM, Noah Misch wrote:
> > On Tue, Apr 26, 2011 at 11:51:35PM -0400, Noah Misch wrote:
> >> On Tue, Apr 26, 2011 at 07:23:12PM -0400, Tom Lane wrote:
> >> [input functions aren't the only problematic source
On Mon, May 23, 2011 at 1:12 AM, Noah Misch wrote:
> On Tue, Apr 26, 2011 at 11:51:35PM -0400, Noah Misch wrote:
>> On Tue, Apr 26, 2011 at 07:23:12PM -0400, Tom Lane wrote:
>> [input functions aren't the only problematic source of uninitialized datum
>> bytes]
>>
>> > We've run into other manife
On Tue, Apr 26, 2011 at 11:51:35PM -0400, Noah Misch wrote:
> On Tue, Apr 26, 2011 at 07:23:12PM -0400, Tom Lane wrote:
> [input functions aren't the only problematic source of uninitialized datum
> bytes]
>
> > We've run into other manifestations of this issue before. Awhile ago
> > I made a pu
Noah Misch writes:
> On Tue, Apr 26, 2011 at 07:23:12PM -0400, Tom Lane wrote:
> [input functions aren't the only problematic source of uninitialized datum
> bytes]
> FWIW, when I was running the test suite under valgrind, these were the
> functions that left uninitialized bytes in datums: array
Greg Stark writes:
> On Wed, Apr 27, 2011 at 12:23 AM, Tom Lane wrote:
>> Any ideas about better answers?
> Here's a crazy idea. We could use string equality of the out
> function's representation instead. If an output function doesn't
> consistently output the same data for things that are equa
On Tue, Apr 26, 2011 at 07:23:12PM -0400, Tom Lane wrote:
[input functions aren't the only problematic source of uninitialized datum
bytes]
> We've run into other manifestations of this issue before. Awhile ago
> I made a push to ensure that datatype input functions didn't leave any
> ill-define
On Wed, Apr 27, 2011 at 12:23 AM, Tom Lane wrote:
> Any ideas about better answers?
>
Here's a crazy idea. We could use string equality of the out
function's representation instead. If an output function doesn't
consistently output the same data for things that are equal or
different data for thi
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Any ideas about better answers?
Seems like you covered it - anything other than memcmp() is going
to require a lot of brainz and have lots of sharp edges.
> But this example shows that we'd really have to enforce the rule
> of "no ill-defi
I looked into David Johnston's report of curious planner behavior:
http://archives.postgresql.org/pgsql-general/2011-04/msg00885.php
What is happening is that the planner doesn't reliably see the
expression ti_status = ANY ('{ACTIVE,DISPATCHED,FAILURE}'::text[])
as equal to other copies of itself,
14 matches
Mail list logo
