Re: replicating DROP commands across servers - Mailing list pgsql-hackers

From David Rowley
Subject Re: replicating DROP commands across servers
Date
Msg-id CAHoyFK9YmTDmqEU_pjJ4e-0=CZuY400mo9=xE4wACmrkVeA+hg@mail.gmail.com
Whole thread Raw
In response to Re: replicating DROP commands across servers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 25 December 2014 at 04:47, Tom Lane <tgl@sss.pgh.pa.us> wrote:
David Rowley <dgrowley@gmail.com> writes:
> On 25 December 2014 at 00:34, Andres Freund <andres@2ndquadrant.com> wrote:
>> I really wonder if we can't make msvc reliably recognize this kind of
>> scenario - especially this case is pretty trivial?

> The attached patch removes the warning, but likely can't be used in case
> someone somewhere is doing elog(var++, "my error");

Yeah, we're *not* doing that.  There are definitely places where
ereport/elog are used with nonconstant elevel.


Agreed. The patch was intended as a demo of where the problem is. Although I don't see why non-const elevel matters. Non-stable expressions are what actually matter.
 
It's curious though that MSVC fails to notice that the variable never
changes.  I wonder whether we could get away with changing the elog
macro to do
      const int elevel_ = (elevel);
as ereport does, and whether it would help if so.


Unlikely, as the one that was just fixed above is an ereport.

I'll dig around a little more and see if there's some way to get MSVC to optimise this somehow. The 1% reduction in the postgres.exe seems worth a little bit of investigation time.

Regards

David Rowley

pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: hash_create API changes (was Re: speedup tidbitmap patch: hash BlockNumber)
Next
From: Tom Lane
Date:
Subject: Re: hash_create API changes (was Re: speedup tidbitmap patch: hash BlockNumber)