Sorry, I forgot to add pgsql-commiters email adress. So I re-post our e-mail
discussion.
> (2014/01/28 11:50), Peter Geoghegan wrote:
>> On Mon, Jan 27, 2014 at 6:31 PM, KONDO Mitsumasa
>> <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>> No. I don't say root user is superuser. Executing initdb user will be
>>> postgres superuser. But it can change non-superuser after creating database.
>>
>> Okay. I still don't understand what your point is, or how this patch
>> makes any worse what you'd consider to be a general problem. It
>> doesn't even differ from a security standpoint to the original
>> pg_stat_statements from 2009.
> At least, only postgres superuser can see pg_stat_statemnet view in old version.
> And you should change document at this sentences.
>
> By the way, when we set postgres log to only syslog, I think that it is because
> we don't show statement log to outside when we get backup or other operation. But
> your patch doesn't have option that is on or off. So user must show statement
> log to outside without what to do. I think that Robert and Tom saying is right,
> when we can see database file we can see the whole data. However, even so, it
> feels sense of incongruity to make most of all statement logs are always open
> with a text format every time.
>
>> I think it's incongruous that you chose to make your opinion known at
>> this time and in this way. You knew about this patch several months
>> ago; are your surprised that it does what it was prominently
>> advertised to do?
> IMHO, I have thought your approach is very rough and have some problems. Therefore, I thought
> it will be return with feed back by Tom.
>
> I'm not sure about your patch in detail. However, I think your patch have another
> porblem that is happened in lessor write-back cache enviroment systems which are
> like Windows system. It may cause extreme less performance in these systems. Did
> you test it? When we use shared_buffers, it does not let you do physical-
> disk-write untill we want to write it. But your patch cannot control it, it may
> cause more lessor performance than linux systems. It will be less performance
> than removing LWLock. And your patch might works well only at linux system or
> having good write-back cache enviroment systems.
>
> I'm very sorry for my late comment. If community say that is no problem, I
> will sincerely accept this patch.
>
> Regards,
> --
> Mitsumasa KONDO
> NTT Open Source Software Center
--
Mitsumasa KONDO
NTT Open Source Software Center