"Kevin Grittner" writes:
> Tom Lane wrote:
>> Unfortunately, the problem we're dealing with here is exactly that
>> we can't write to stderr. So it's a bit hard to see what we can
>> usefully do to report that we have a problem (short of crashing,
>> which isn't a net improvement).
> Are you s
Tom Lane wrote:
> Unfortunately, the problem we're dealing with here is exactly that
> we can't write to stderr. So it's a bit hard to see what we can
> usefully do to report that we have a problem (short of crashing,
> which isn't a net improvement).
Are you sure that crashing on an assertio
On Tue, Oct 18, 2011 at 6:01 PM, Tom Lane wrote:
> The chunks are sent indivisibly, because they are less than the pipe
> buffer size. Read the pipe man page. It's guaranteed that the write
> will either succeed or fail as a whole, not write a partial message.
> If we cared to retry a failure, t
On tis, 2011-10-18 at 16:13 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On tis, 2011-10-18 at 15:43 -0400, Tom Lane wrote:
> >> I don't actually see that warning on my Fedora 15 machine, with
> >> gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC)
>
> > You get the "unused return value"
Heikki Linnakangas writes:
> On 18.10.2011 23:28, Tom Lane wrote:
>> I don't think the assert is a good idea. If it ever did happen, that
>> would promote the problem from "corrupted data in the log" to "database
>> crash".
> I believe the idea is that if there's a platform that does that, we wa
I wrote:
> I think a large fraction of the -Waddress warnings are coming from
> this line in the heap_getattr macro:
> AssertMacro((tup) != NULL), \
> Seems to me we could just lose that test and be no worse off, since
> the macro is surely gonna dump core anyway on a null pointer.
Actually,
Tom Lane wrote:
> As far as getting rid of the compiler warning is concerned, I find
> that the
>
> rc = write(...);
> (void) rc;
>
> suggestion works for me (gcc 4.6.1).
That silences the warning on my machine, too.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hacker
"Kevin Grittner" writes:
> Tom Lane wrote:
>> I don't think the assert is a good idea. If it ever did happen,
>> that would promote the problem from "corrupted data in the log" to
>> "database crash".
> ... on a --enable-cassert build.
> If we think it's even remotely possible that it could
Tom Lane wrote:
> I don't think the assert is a good idea. If it ever did happen,
> that would promote the problem from "corrupted data in the log" to
> "database crash".
... on a --enable-cassert build.
If we think it's even remotely possible that it could happen, maybe
we should do the lo
On 18.10.2011 23:28, Tom Lane wrote:
"Kevin Grittner" writes:
Would it be too weird to do something like this for each?:
- write(fileno(stderr), line, len);
+ rc = write(fileno(stderr), line, len);
+ if (rc>= 0&& rc != len)
+ {
+ Assert(false);
+
"Kevin Grittner" writes:
> Would it be too weird to do something like this for each?:
> - write(fileno(stderr), line, len);
> + rc = write(fileno(stderr), line, len);
> + if (rc >= 0 && rc != len)
> + {
> + Assert(false);
> + return;
> + }
I don
On Tue, Oct 18, 2011 at 4:13 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On tis, 2011-10-18 at 15:43 -0400, Tom Lane wrote:
>>> I don't actually see that warning on my Fedora 15 machine, with
>>> gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC)
>
>> You get the "unused return value" warni
Peter Eisentraut writes:
> On tis, 2011-10-18 at 15:43 -0400, Tom Lane wrote:
>> I don't actually see that warning on my Fedora 15 machine, with
>> gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC)
> You get the "unused return value" warnings with -D_FORTIFY_SOURCE=2,
> which has been the defaul
Robert Haas wrote:
> Unfortunately, whether Tom's right or not, we still don't have a
> solution to the compiler warning.
Would it be too weird to do something like this for each?:
diff --git a/src/backend/utils/error/elog.c
b/src/backend/utils/error/elog.c
index f0b3b1f..bea5489 100644
---
Tom Lane wrote:
> What are the people who do see it using?
Currently:
gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
on
Linux version 2.6.38-11-generic (buildd@allspice) (gcc version 4.5.2
(Ubuntu/Linaro 4.5.2-8ubuntu4) ) #50-Ubuntu SMP Mon Sep 12 21:17:25
UTC 2011
I've seen it on earlier ve
On tis, 2011-10-18 at 15:43 -0400, Tom Lane wrote:
> Robert Haas writes:
> > Unfortunately, whether Tom's right or not, we still don't have a
> > solution to the compiler warning.
>
> I don't actually see that warning on my Fedora 15 machine, with
> gcc version 4.6.1 20110908 (Red Hat 4.6.1
Robert Haas writes:
> Unfortunately, whether Tom's right or not, we still don't have a
> solution to the compiler warning.
I don't actually see that warning on my Fedora 15 machine, with
gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC)
What are the people who do see it using?
(I do se
On Tue, Oct 18, 2011 at 3:03 PM, Kevin Grittner
wrote:
> Andrew Dunstan wrote:
>
>> My dim recollection is that Tom and I and maybe some others did
>> tests on a bunch of platforms at the time we introduced the
>> protocol to make sure it did work this way, since it's crucial to
>> making sure we
Andrew Dunstan wrote:
> My dim recollection is that Tom and I and maybe some others did
> tests on a bunch of platforms at the time we introduced the
> protocol to make sure it did work this way, since it's crucial to
> making sure we don't get interleaved log lines.
Testing is good; I like te
Tom Lane wrote:
> If the O_NONBLOCK flag is clear, a write request may cause the
> thread to block, but on normal completion it shall return
> nbyte.
>
> Note the last in particular. Short writes are specifically
> disallowed on pipes.
OK, that's pretty definitive. I yield the point.
On 10/18/2011 01:35 PM, Tom Lane wrote:
Robert Haas writes:
On Tue, Oct 18, 2011 at 1:01 PM, Tom Lane wrote:
The chunks are sent indivisibly, because they are less than the pipe
buffer size. Read the pipe man page. It's guaranteed that the write
will either succeed or fail as a whole, not
Robert Haas writes:
> On Tue, Oct 18, 2011 at 1:01 PM, Tom Lane wrote:
>> The chunks are sent indivisibly, because they are less than the pipe
>> buffer size. Read the pipe man page. It's guaranteed that the write
>> will either succeed or fail as a whole, not write a partial message.
>> If we
On tis, 2011-10-18 at 09:36 -0400, Tom Lane wrote:
> But some of the remaining -Waddress warnings are not so painless to
> get rid of. Ultimately we might have to add -Wno-address to the
> default CFLAGS.
Here is the bug report to gcc on this issue:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=487
"Kevin Grittner" writes:
> Tom Lane wrote:
>> I think that what Kevin was on about was something else entirely,
>> namely whether we need to retry writes to disk.
> I would phrase it that we need to *continue* a write to disk if the
> OS chooses to write a portion of it and return to the caller
On Tue, Oct 18, 2011 at 1:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Oct 18, 2011 at 12:26 PM, Tom Lane wrote:
>>> And it would break the code. The whole point here is that the message
>>> must be sent indivisibly.
>
>> How is that different than the chunking that the while loop is
Robert Haas writes:
> On Tue, Oct 18, 2011 at 12:26 PM, Tom Lane wrote:
>> And it would break the code. The whole point here is that the message
>> must be sent indivisibly.
> How is that different than the chunking that the while loop is already doing?
The chunks are sent indivisibly, because
On Tue, Oct 18, 2011 at 12:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Oct 18, 2011 at 10:06 AM, Peter Eisentraut wrote:
>>> No, I believe we are OK everywhere else. We are only ignoring the
>>> result in cases where we are trying to report errors in the first place.
>
>> The releva
Tom Lane wrote:
> And it would break the code. The whole point here is that the
> message must be sent indivisibly.
If the new code splits the message, it would previously have been
truncated. Is that less broken?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
Robert Haas writes:
> On Tue, Oct 18, 2011 at 10:06 AM, Peter Eisentraut wrote:
>> No, I believe we are OK everywhere else. We are only ignoring the
>> result in cases where we are trying to report errors in the first place.
> The relevant code is:
> while (len > PIPE_MAX_PAYLOAD)
> {
"Kevin Grittner" wrote:
> http://archives.postgresql.org/pgsql-hackers/2011-02/msg01719.php
Although, it being a quick example of the general idea, I have an
obvious bug there -- the write location would have to be "buffer +
t".
I think Noah might have also posted some example code a month o
Robert Haas wrote:
> Which it seems to me we could change by doing rc = write(). Then
> if rc <= 0, we bail out. If not, we add and subtract rc, rather
> than PIPE_MAX_PAYLOAD.
Something along the general lines of this?:
http://archives.postgresql.org/pgsql-hackers/2011-02/msg01719.php
>
On Tue, Oct 18, 2011 at 10:06 AM, Peter Eisentraut wrote:
> No, I believe we are OK everywhere else. We are only ignoring the
> result in cases where we are trying to report errors in the first place.
The relevant code is:
while (len > PIPE_MAX_PAYLOAD)
{
p.proto.is_last = (dest
On tis, 2011-10-18 at 09:32 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > It is a pity we can't just tell the compiler to turn off the warning in
> > a particular case.
>
> I haven't tested, but won't an explicit cast to void silence the
> warning?
>
> (void) fwrite(...);
No, tried
Tom Lane wrote:
> I think that what Kevin was on about was something else entirely,
> namely whether we need to retry writes to disk.
I would phrase it that we need to *continue* a write to disk if the
OS chooses to write a portion of it and return to the caller with
the number actually writte
Peter Eisentraut writes:
> On tis, 2011-10-18 at 01:00 -0700, Jeff Davis wrote:
>> I'm not sure if these can/should be fixed or not, but here are the
>> compiler warnings I'm getting on gcc and clang on ubuntu 11.10 with -O2.
>> The gcc ones are mostly new.
> They are expected with gcc 4.6. Ther
Andrew Dunstan writes:
> It is a pity we can't just tell the compiler to turn off the warning in
> a particular case.
I haven't tested, but won't an explicit cast to void silence the
warning?
(void) fwrite(...);
There are places, notably the calls in elog.c, where ignoring write
failur
On 10/18/2011 09:03 AM, Kevin Grittner wrote:
Jeff Davis wrote:
I'm not sure if these can/should be fixed or not, but here are the
compiler warnings I'm getting on gcc and clang on ubuntu 11.10 with
-O2.
elog.c: In function ‘write_pipe_chunks’:
elog.c:2479:8: warning: ignoring return valu
On Tue, Oct 18, 2011 at 9:03 AM, Kevin Grittner
wrote:
> Jeff Davis wrote:
>
>> I'm not sure if these can/should be fixed or not, but here are the
>> compiler warnings I'm getting on gcc and clang on ubuntu 11.10 with
>> -O2.
>
>> elog.c: In function ‘write_pipe_chunks’:
>> elog.c:2479:8: warning
Jeff Davis wrote:
> I'm not sure if these can/should be fixed or not, but here are the
> compiler warnings I'm getting on gcc and clang on ubuntu 11.10 with
> -O2.
> elog.c: In function ‘write_pipe_chunks’:
> elog.c:2479:8: warning: ignoring return value of ‘write’, declared
> with attribute w
On tis, 2011-10-18 at 01:00 -0700, Jeff Davis wrote:
> I'm not sure if these can/should be fixed or not, but here are the
> compiler warnings I'm getting on gcc and clang on ubuntu 11.10 with -O2.
> The gcc ones are mostly new.
They are expected with gcc 4.6. There isn't anything we can do about
I'm not sure if these can/should be fixed or not, but here are the
compiler warnings I'm getting on gcc and clang on ubuntu 11.10 with -O2.
The gcc ones are mostly new.
GCC
$ gcc --version
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Fr
Tom Lane wrote:
> Bruce Momjian writes:
> > I can remove this warning by casting the pointer to (void *), rather
> > than (const void *) because that is what the prototype uses on my system
> > uses (libz.so.1.1.4):
>
> > ZEXTERN int ZEXPORTgzwrite OF((gzFile file,
> >
Bruce Momjian writes:
> I can remove this warning by casting the pointer to (void *), rather
> than (const void *) because that is what the prototype uses on my system
> uses (libz.so.1.1.4):
> ZEXTERN int ZEXPORTgzwrite OF((gzFile file,
> const voidp buf, unsig
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Robert Haas wrote:
> > > I recently started getting these:
> > >
> > > plpython.c: In function ?PLy_output?:
> > > plpython.c:3468: warning: format not a string literal and no format
> > > arguments
> > > plpython.c: In function ?PLy_elog?:
> > > pl
Bruce Momjian writes:
>> And I see this warning:
>>
>> compress_io.c:597: warning: passing arg 2 of `gzwrite' discards
>> qualifiers from pointer target type
> I can remove this warning by casting the pointer to (void *), rather
> than (const void *) because that is what the prototype uses on my
Bruce Momjian wrote:
> Robert Haas wrote:
> > I recently started getting these:
> >
> > plpython.c: In function ?PLy_output?:
> > plpython.c:3468: warning: format not a string literal and no format
> > arguments
> > plpython.c: In function ?PLy_elog?:
> > plpython.c:3620: warning: format not a st
On Wed, Jan 26, 2011 at 5:20 PM, Peter Eisentraut wrote:
> On ons, 2011-01-26 at 17:00 -0500, Robert Haas wrote:
>> More to the point, regardless of whether the warning is reasonable or
>> not, there's tangible value in a warning-free build, which we have had
>> on most of the systems I use until
Peter Eisentraut writes:
> It turns out you need -Wformat-security with newer GCC versions.
Ah-hah.
> We might want to add that to the standard options set.
+1. Probably this will require an extra configure test, but even so
it's well worthwhile.
regards, tom lane
--
On ons, 2011-01-26 at 17:00 -0500, Robert Haas wrote:
> More to the point, regardless of whether the warning is reasonable or
> not, there's tangible value in a warning-free build, which we have had
> on most of the systems I use until recently.
I don't disagree that the warnings are valid. I'd j
Robert Haas writes:
> But I think I did get it on a recently-updated Fedora 13 box also, I
> can check if it's important.
F-13 doesn't show it for me. I get the impression from these results
that maybe gcc versions >= about 4.4 have been tweaked to not show it
... which doesn't really seem like
On Wed, Jan 26, 2011 at 4:50 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On ons, 2011-01-26 at 06:33 -0500, Robert Haas wrote:
>>> I recently started getting these:
>>>
>>> plpython.c: In function ‘PLy_output’:
>>> plpython.c:3468: warning: format not a string literal and no format
>>> arg
Peter Eisentraut writes:
> On ons, 2011-01-26 at 06:33 -0500, Robert Haas wrote:
>> I recently started getting these:
>>
>> plpython.c: In function âPLy_outputâ:
>> plpython.c:3468: warning: format not a string literal and no format arguments
>> plpython.c: In function âPLy_elogâ:
>> plpy
On Wed, Jan 26, 2011 at 4:20 PM, Peter Eisentraut wrote:
> On ons, 2011-01-26 at 06:33 -0500, Robert Haas wrote:
>> I recently started getting these:
>>
>> plpython.c: In function ‘PLy_output’:
>> plpython.c:3468: warning: format not a string literal and no format arguments
>> plpython.c: In funct
On ons, 2011-01-26 at 06:33 -0500, Robert Haas wrote:
> I recently started getting these:
>
> plpython.c: In function ‘PLy_output’:
> plpython.c:3468: warning: format not a string literal and no format arguments
> plpython.c: In function ‘PLy_elog’:
> plpython.c:3620: warning: format not a string
Robert Haas wrote:
> I recently started getting these:
>
> plpython.c: In function ?PLy_output?:
> plpython.c:3468: warning: format not a string literal and no format arguments
> plpython.c: In function ?PLy_elog?:
> plpython.c:3620: warning: format not a string literal and no format arguments
> p
I recently started getting these:
plpython.c: In function ‘PLy_output’:
plpython.c:3468: warning: format not a string literal and no format arguments
plpython.c: In function ‘PLy_elog’:
plpython.c:3620: warning: format not a string literal and no format arguments
plpython.c:3627: warning: format n
56 matches
Mail list logo
