On Tue, Mar 8, 2016 at 1:51 PM, Andres Freund wrote:
> On 2016-03-08 13:45:25 +0900, Michael Paquier wrote:
>> On Mon, Mar 7, 2016 at 10:26 AM, Andres Freund wrote:
>> > FWIW I'm considering implementing elog/ereport properly for the
>> > frontend. We've grown several hacks around that not being
On 2016-03-08 13:45:25 +0900, Michael Paquier wrote:
> On Mon, Mar 7, 2016 at 10:26 AM, Andres Freund wrote:
> > FWIW I'm considering implementing elog/ereport properly for the
> > frontend. We've grown several hacks around that not being present, and
> > I think those by now have a higher aggreg
On Mon, Mar 7, 2016 at 10:26 AM, Andres Freund wrote:
> FWIW I'm considering implementing elog/ereport properly for the
> frontend. We've grown several hacks around that not being present, and
> I think those by now have a higher aggregate complexity than a proper
> implementation would have.
Th
Joe Conway writes:
> Committed/pushed with exit(EXIT_FAILURE)
Thanks! I lit off a new run on gaur/pademelon to confirm. Should
have results in six hours or so...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
On 03/07/2016 08:02 AM, Joe Conway wrote:
> On 03/06/2016 07:34 PM, Tom Lane wrote:
>> Joe Conway writes:
>>> On 03/06/2016 05:47 PM, Tom Lane wrote:
That's much better, but is there a reason you're using exit(2)
and not exit(EXIT_FAILURE) ?
>>
>>> Only because I was trying to stick with
On 03/06/2016 07:34 PM, Tom Lane wrote:
> Joe Conway writes:
>> On 03/06/2016 05:47 PM, Tom Lane wrote:
>>> That's much better, but is there a reason you're using exit(2)
>>> and not exit(EXIT_FAILURE) ?
>
>> Only because I was trying to stick with what was originally in
>> src/bin/pg_controldata
Joe Conway writes:
> On 03/06/2016 05:47 PM, Tom Lane wrote:
>> That's much better, but is there a reason you're using exit(2)
>> and not exit(EXIT_FAILURE) ?
> Only because I was trying to stick with what was originally in
> src/bin/pg_controldata/pg_controldata.c
Meh. It looks to me like the
On 03/06/2016 05:47 PM, Tom Lane wrote:
> Joe Conway writes:
>> Something like the attached what you had in mind?
>
> That's much better, but is there a reason you're using exit(2)
> and not exit(EXIT_FAILURE) ?
Only because I was trying to stick with what was originally in
src/bin/pg_controldat
Joe Conway writes:
> Something like the attached what you had in mind?
That's much better, but is there a reason you're using exit(2)
and not exit(EXIT_FAILURE) ?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On 2016-03-06 17:16:42 -0800, Joe Conway wrote:
> - #ifndef FRONTEND
> - /* NOTE: caller must provide gettext call around the format string */
> - #define log_error(...) \
> - elog(ERROR, __VA_ARGS__)
> - #else
> - #define log_error(...) \
> - do { \
> - char *
On 03/06/2016 01:26 PM, Joe Conway wrote:
> On 03/06/2016 01:24 PM, Tom Lane wrote:
>> * It's randomly unlike every single other place we've addressed the
>> same problem. Everywhere else in src/common does it like this:
[...snip...]
>> and I think that's what this needs to do too, especially in
On 03/06/2016 01:24 PM, Tom Lane wrote:
> * It's randomly unlike every single other place we've addressed the
> same problem. Everywhere else in src/common does it like this:
>
> #ifndef FRONTEND
> ereport(ERROR,
> (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
>
My attention was drawn to the log_error() stuff in controldata_utils.c by
the fact that buildfarm member pademelon spit up on it. The reason for
that compile failure is that pademelon's dinosaur of a compiler doesn't
support __VA_ARGS__. I do not feel a need to get into a discussion about
whether
13 matches
Mail list logo