Re: cleanup in code

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: cleanup in code
Date: 2014-01-07 07:00:10
Message-ID: CAApHDvpCv8kb3S9guBmDjby5wfcMp-4WhZLxKtjK6vGqOK8h9A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 7, 2014 at 7:46 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:

> Having said above, I think there must be a reason to have elevel_ which I
> am
> not aware.
>
>
I think it will be like Andres said up thread, to stop multiple evaluations
of the expression passed to the macro.

If someone did:

elog(mylevel++, "Something bad just happened");

With assigning this to a variable the user will have the mylevel increase
by 1, but if we didn't then it would get increase more times.

I didn't look at all the elog usages in core, but my guess is that we're
probably not using any expressions like this in elog, but we can't really
speak for any third party code which uses the macro. Likely to get rid of
that variable something would have to go into the release notes to get
users to check for volatile expressions being used in elog and fix them up.

The only other way to fix it that I can think of is the patch you posted
above which is pretty much the same one as I posted on the other thread too.

Regards

David Rowley

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2014-01-07 07:03:33 Re: Long paths for tablespace leads to uninterruptible hang in Windows
Previous Message Amit Kapila 2014-01-07 06:46:43 Re: cleanup in code