Hi,
On 2020-06-05 18:39:28 -0700, Jeff Davis wrote:
> On Fri, 2020-06-05 at 14:49 -0700, Andres Freund wrote:
> > FWIW, with gcc 10 and glibc 2.30 I don't see such a switch. Taking a
> > profile shows me:
>
> ...
>
> > 4.65 │ → callqmemcpy@plt
> >│ LogicalTapeWrite(
On Fri, 2020-06-05 at 21:50 -0400, Tom Lane wrote:
> Or possibly casting the whole thing to int or unsigned int would be
> better. Point being that I bet it's int vs long that is making the
> difference.
That did it, and it's much more tolerable as a workaround. Thank you.
I haven't tested end-t
Jeff Davis writes:
> On Thu, 2020-06-04 at 16:35 -0400, Alvaro Herrera wrote:
>> If it is something worth worrying about, let's discuss what's a good
>> fix for it.
> While making a minimal test case for the GCC bug report, I found
> another surprisingly-small workaround. Patch attached.
Ugh :-(
On Thu, 2020-06-04 at 16:35 -0400, Alvaro Herrera wrote:
> If it is something worth worrying about, let's discuss what's a good
> fix for it.
While making a minimal test case for the GCC bug report, I found
another surprisingly-small workaround. Patch attached.
Regards,
Jeff Davis
diff -
On Fri, 2020-06-05 at 14:49 -0700, Andres Freund wrote:
> FWIW, with gcc 10 and glibc 2.30 I don't see such a switch. Taking a
> profile shows me:
...
> 4.65 │ → callqmemcpy@plt
>│ LogicalTapeWrite():
>
> I.e. normal memcpy is getting called.
>
> That's with -D_FOR
On Thu, 2020-06-04 at 21:41 -0400, Tom Lane wrote:
> I think what'd make more sense is to file this as a gcc bug ("why
> doesn't
> it remove the useless object size check?")
Filed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556
Regards,
Jeff Davis
Hi,
On 2020-04-19 15:07:22 -0700, Jeff Davis wrote:
> I brought up an issue where GCC in combination with FORTIFY_SOURCE[2]
> causes a perf regression for logical tapes after introducing
> LogicalTapeSetExtend()[3]. Unfortunately, FORTIFY_SOURCE is used by
> default on ubuntu. I have not observed
Jeff Davis writes:
> On Thu, 2020-06-04 at 16:35 -0400, Alvaro Herrera wrote:
>> If it is something worth worrying about, let's discuss what's a good
>> fix for it.
> I did post a fix for it, but it's not a very clean fix. I'm slightly
> inclined to proceed with that fix, but I was hoping someone
On Thu, 2020-06-04 at 16:35 -0400, Alvaro Herrera wrote:
> If it is something worth worrying about, let's discuss what's a good
> fix for it.
I did post a fix for it, but it's not a very clean fix. I'm slightly
inclined to proceed with that fix, but I was hoping someone else would
have a better su
On Sun, 2020-04-19 at 16:19 -0700, Peter Geoghegan wrote:
> Is it possible that the issue has something to do with what the
> compiler knows about the alignment of the tapes back when they were a
> flexible array vs. now, where it's a separate allocation? Perhaps I'm
> over reaching, but it occurs
Speaking with my RMT hat on, I'm concerned that this item is not moving
forward at all. ISTM we first and foremost need to decide whether this
is a problem worth worrying about, or not.
If it is something worth worrying about, let's discuss what's a good
fix for it.
--
Álvaro Herrera
On Sun, 2020-04-19 at 16:19 -0700, Peter Geoghegan wrote:
> Is it possible that the issue has something to do with what the
> compiler knows about the alignment of the tapes back when they were a
> flexible array vs. now, where it's a separate allocation? Perhaps I'm
> over reaching, but it occurs
On Sun, Apr 19, 2020 at 3:07 PM Jeff Davis wrote:
> 1. Is my analysis correct?
> 2. What is the scale of this problem? What about other platforms or
> compilers? Are there other cases in PostgreSQL that might suffer from
> the use of FORTIFY_SOURCE?
> 3. Even if this is the compiler's fault, shoul
There was a previous thread[1], but I think it needs some wider
discussion.
I brought up an issue where GCC in combination with FORTIFY_SOURCE[2]
causes a perf regression for logical tapes after introducing
LogicalTapeSetExtend()[3]. Unfortunately, FORTIFY_SOURCE is used by
default on ubuntu. I h
14 matches
Mail list logo
