Re: replicating DROP commands across servers

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: replicating DROP commands across servers
Дата
Msg-id CAHoyFK9YmTDmqEU_pjJ4e-0=CZuY400mo9=xE4wACmrkVeA+hg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: replicating DROP commands across servers  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: hash_create API changes (was Re: speedup tidbitmap patch: hash BlockNumber)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: hash_create API changes (was Re: speedup tidbitmap patch: hash BlockNumber)