On 05/06/2014 07:36 PM, Andres Freund wrote:
On 2014-05-06 13:33:01 +0300, Heikki Linnakangas wrote:
On 03/31/2014 09:08 PM, Robert Haas wrote:
On Wed, Mar 26, 2014 at 9:45 PM, Peter Geoghegan wrote:
On Wed, Nov 27, 2013 at 9:10 AM, Noah Misch wrote:
The threat is that rounding the read siz
On 2014-05-06 13:33:01 +0300, Heikki Linnakangas wrote:
> On 03/31/2014 09:08 PM, Robert Haas wrote:
> >On Wed, Mar 26, 2014 at 9:45 PM, Peter Geoghegan wrote:
> >>On Wed, Nov 27, 2013 at 9:10 AM, Noah Misch wrote:
> >>>The threat is that rounding the read size up to the next MAXALIGN would
> >>
On 03/31/2014 09:08 PM, Robert Haas wrote:
On Wed, Mar 26, 2014 at 9:45 PM, Peter Geoghegan wrote:
On Wed, Nov 27, 2013 at 9:10 AM, Noah Misch wrote:
The threat is that rounding the read size up to the next MAXALIGN would cross
into an unreadable memory page, resulting in a SIGSEGV. Every pa
Hi,
We really should fix this one of these days.
On 2014-03-26 18:45:54 -0700, Peter Geoghegan wrote:
> Attached patch silences the "Invalid read of size n" complaints of
> Valgrind. I agree with your general thoughts around backpatching. Note
> that the patch addresses a distinct complaint from
On Wed, Mar 26, 2014 at 9:45 PM, Peter Geoghegan wrote:
> On Wed, Nov 27, 2013 at 9:10 AM, Noah Misch wrote:
>> The threat is that rounding the read size up to the next MAXALIGN would cross
>> into an unreadable memory page, resulting in a SIGSEGV. Every palloc chunk
>> has MAXALIGN'd size under
On Wed, Nov 27, 2013 at 9:10 AM, Noah Misch wrote:
> The threat is that rounding the read size up to the next MAXALIGN would cross
> into an unreadable memory page, resulting in a SIGSEGV. Every palloc chunk
> has MAXALIGN'd size under the hood, so the excess read of "toDelete" cannot
> cause a S
On 11/26/13, 5:14 PM, Kevin Grittner wrote:
> I happened to build in a shell that was still set up for the clang
> address sanitizer, and got the attached report. On a rerun it was
> repeatable. XLogInsert() seems to read past the end of a variable
> allocated on the stack in doPickSplit(). I hav
On 2013-11-27 15:29:24 -0500, Noah Misch wrote:
> > If you are confident that neither of these is a real risk, I'll
> > relax about this.
>
> If there is a real risk, I'm not seeing it.
Me neither.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
Pos
On Wed, Nov 27, 2013 at 11:38:23AM -0800, Kevin Grittner wrote:
> Noah Misch wrote:
> > The threat is that rounding the read size up to the next MAXALIGN
> > would cross into an unreadable memory page, resulting in a
> > SIGSEGV. Every palloc chunk has MAXALIGN'd size under the hood,
> > so the e
Noah Misch wrote:
> (Kevin, I saw no attachment.)
Apologies. Trying again.
> The threat is that rounding the read size up to the next MAXALIGN
> would cross into an unreadable memory page, resulting in a
> SIGSEGV. Every palloc chunk has MAXALIGN'd size under the hood,
> so the excess read of
On Wed, Nov 27, 2013 at 06:23:38AM -0800, Kevin Grittner wrote:
> Andres Freund wrote:
> > On 2013-11-26 14:14:38 -0800, Kevin Grittner wrote:
> >
> >> I happened to build in a shell that was still set up for the clang
> >> address sanitizer, and got the attached report. On a rerun it was
(Kevin
Andres Freund wrote:
> On 2013-11-26 14:14:38 -0800, Kevin Grittner wrote:
>
>> I happened to build in a shell that was still set up for the clang
>> address sanitizer, and got the attached report. On a rerun it was
>> repeatable. XLogInsert() seems to read past the end of a variable
>> allocate
On 2013-11-26 14:14:38 -0800, Kevin Grittner wrote:
> I happened to build in a shell that was still set up for the clang
> address sanitizer, and got the attached report. On a rerun it was
> repeatable. XLogInsert() seems to read past the end of a variable
> allocated on the stack in doPickSplit(
I happened to build in a shell that was still set up for the clang
address sanitizer, and got the attached report. On a rerun it was
repeatable. XLogInsert() seems to read past the end of a variable
allocated on the stack in doPickSplit(). I haven't tried to analyze
it past that, since this part
14 matches
Mail list logo
