Andrew Dunstan [EMAIL PROTECTED] writes:
Of course, the linux kernel is aimed at a limited set of compilers - as I
understand it basically gcc although it has been made to build with Intel
compilers - which makes things somewhat easier for them. What is our target
set of compilers? What is our
Tom Lane wrote:
BTW, I haven't looked at the problem spots in detail. How many of them
are due to the use of MemSet in conjunction with other access to a chunk
of memory? ISTM that we need not worry about code motion around a
MemSet call, since that would require the compiler to prove that the
Andrew Dunstan wrote:
there were 3 calls to MemSet it complained about - all in
src/backend/storage/lmgr/proc.c, and all zeroing out the timeval
structure. (is MemSet actually a gain in this instance?)
And looking at it even closer, 2 of the 3 cases of calling MemSet appear
to be
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Resubmission of patch (for 7.4).
While I agree with the objection that we shouldn't break the strings
freeze for this, I do think it might be a good idea to apply the change
that prints CHECK constraints using pg_get_constraintdef() rather than
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Of course, the linux kernel is aimed at a limited set of compilers - as I
understand it basically gcc although it has been made to build with Intel
compilers
icc once compiled the kernel. But they had to teach it quite a lots of
Please commit the changes, file reviewed by Gaetano Mendola. Corrected a couple of
messages.
Regards,
Fabrizio Mazzoni
libpq-it.po
Description: Binary data
---(end of broadcast)---
TIP 8: explain analyze is your friend
Peter Eisentraut wrote:
Andrew Dunstan writes:
And looking at it even closer, 2 of the 3 cases of calling MemSet appear
to be unnecessary, as the zeroed out values are immediately overwritten.
We need to zero out the holes in the structures so that hash functions
work correctly.
I
On Tue, 2003-10-14 at 15:00, Manfred Spraul wrote:
I think we must either add -fno-strict-aliasing, or switch to the c
compiler memset functions for gcc.
The last time we did some benchmarking, using the builtin memset()
imposes a significant performance penalty on plenty of different
Manfred Spraul [EMAIL PROTECTED] writes:
I've asked the question on the gcc devel list. The first reply was that
MemSet violates strict aliasing rules:
No doubt it does, but that is not really the issue here; the issue IMHO
is whether there is any real risk involved. Remember that the macro
Tom Lane wrote:
I think we must either add -fno-strict-aliasing, or switch to the c
compiler memset functions for gcc.
We will not be doing the latter, for certain.
OK, what gcc versions support -fno-strict-aliasing? Do we need a
configure test for it? Would someone profile PostgreSQL
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, what gcc versions support -fno-strict-aliasing? Do we need a
configure test for it?
Perhaps ... although it is recognized in 2.95.3 and probably for a good
ways before that.
It looks to me like what has changed in gcc 3.3 is
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Given that gcc is smart enough not to move any code across the memset()
call,
Is it?
It had better be.
regards, tom lane
---(end of broadcast)---
TIP 8:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, what gcc versions support -fno-strict-aliasing? Do we need a
configure test for it?
Perhaps ... although it is recognized in 2.95.3 and probably for a good
ways before that.
It looks to me like what has changed in gcc 3.3 is not
Neil Conway writes:
On Tue, 2003-10-14 at 15:00, Manfred Spraul wrote:
I think we must either add -fno-strict-aliasing, or switch to the c
compiler memset functions for gcc.
The last time we did some benchmarking, using the builtin memset()
imposes a significant performance penalty on
On Tue, 2003-10-14 at 16:29, Peter Eisentraut wrote:
The last time I did some testing, the builtin memset() was significantly
faster on plenty of different platforms.
Oh? Which platforms are you referring to, and what tests were performed?
You can find the benchmark results I'm referring to in
Manfred Spraul [EMAIL PROTECTED] writes:
After some massaging, I've succeeded in generating bad code using a
slightly modified MemSetAligned macro (parameters -O2
-fstrict-aliasing): gcc pipelined the x*x around the memset.
As I already explained, we do not care about the MemSetAligned case.
Neil Conway writes:
Oh? Which platforms are you referring to, and what tests were performed?
http://archives.postgresql.org/pgsql-patches/2002-10/msg00085.php
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if
Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
After some massaging, I've succeeded in generating bad code using a
slightly modified MemSetAligned macro (parameters -O2
-fstrict-aliasing): gcc pipelined the x*x around the memset.
As I already explained, we do not care about
Recently I've been seeing regular but very occasional errors like the
following while using psql:
test= BEGIN ;
BEGIN
test= UPDATE language SET name_native = 'Français' WHERE lang_id='fr';
ERROR: current transaction is aborted, commands ignored until end of
transaction block
where the UPDATE
Manfred Spraul [EMAIL PROTECTED] writes:
Tom Lane wrote:
Is gcc 3.3 smart enough to optimize away the pointer alignment test
in the full macro?
3.2 optimizes away the pointer alignment test, but then doesn't pipeline
the x*x calculation.
Hm, confirmed here. So indeed it seems that Bruce
Ian Barwick [EMAIL PROTECTED] writes:
A patch for this using PQescapeString (is there another preferred method?) is
attached as a possible solution.
Surely all those replacements of \\ with are wrong. I agree that
it's insane not to be escaping the user input, though ...
new files
pg_resetxlog.po : src/bin/pg_resetxlog/po/sl.po
pg_controldata.po : src/bin/pg_controldata/po/sl.po
updated files
psql.po : src/bin/psql/po/sl.po
regards,
Aleksander
sl_tanslations.tar.gz
Description: GNU Zip compressed data
---(end of
22 matches
Mail list logo
