Re: replicating DROP commands across servers

On 25 December 2014 at 00:34, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:

> On 2014-12-24 21:54:20 +1300, David Rowley wrote:
> > On 24 December 2014 at 07:41, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
> > wrote:
> >
> > > I have pushed patches 0001 through 0004, with some revisions. Only the
> > > final part is missing.
> > >
> > >
> > Hi Alvaro,
> >
> > Would you be able to commit the attached? It just fixes a new compiler
> > warning that I'm seeing on MSVC.
> >
> > src\backend\parser\parse_type.c(795): warning C4715:
> 'typeStringToTypeName'
> > : not all control paths return a value [D:\Postgres\a\postgres.vcxproj]
>
> Pushed.
>
> Thanks

> I really wonder if we can't make msvc reliably recognize this kind of
> scenario - especially this case is pretty trivial?
>
> Which of:
> #if defined(HAVE__BUILTIN_UNREACHABLE) && !defined(USE_ASSERT_CHECKING)
> #define pg_unreachable() __builtin_unreachable()
> #elif defined(_MSC_VER) && !defined(USE_ASSERT_CHECKING)
> #define pg_unreachable() __assume(0)
> #else
> #define pg_unreachable() abort()
> #endif
>
>
I don't think the problem is here. The problem is the the elevel being set
to a variable in the elog macro to prevent the multiple evaluation problem,
then since it does int elevel_ = elevel ... if (elevel_ >= ERROR) that's
not constant, or at least the microsoft compiler is not smart enough to see
that it is.

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

Compiling with the attached shaves almost 1% off the size of postgres.exe:

before; 5,882,368 bytes
after: 5,830,656 bytes

I've been trawling around to try to see if anything
like __builtin_constant_p() exists for MSVC, but so far I've not found
anything useful.

Kind Regards

David Rowley