Then I will post my response.
On Mon, Jan 27, 2014 at 8:54 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Mon, Jan 27, 2014 at 8:20 PM, KONDO Mitsumasa
> <kondo.mitsumasa@lab.ntt.co.jp> wrote:
>> At least, only postgres superuser can see pg_stat_statemnet view in old
>> version.
>> And you should change document at this sentences.
>
> No, it was precisely the same situation in every way that matters; the
> texts and other details were serialized to disk, on the same
> filesystem, with the same permissions. The only difference was that
> the texts might not be completely current back then, because time can
> pass between shutdown/serialization. From a security perspective,
> that's obviously 100% equivalent. Now, if you're saying that the
> option to not store the texts existed back then and that made a big
> difference, I'm completely unconvinced. That is not the security model
> that we follow. How could it be? You're asking us to believe that
> there is an environment in which statement execution costs and
> normalized query strings are more confidential than *all* of the
> actual data stored in the database. You're proposing that for some
> users the former is top secret, but the latter is somewhat less
> confidential, so it matters that root can also read query texts, a
> user already naturally entitled to read *all* data in the database.
> You have forced me to say what I would have preferred not to: that's
> nonsense, pure and simple.
>
>> 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.
>
> How did you know it was very rough without reading it?
>
>> 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.
>
> This is completely fatuous. Tom spent a number of days scrutinizing it
> in detail. Perhaps you should actually read the patch, or read the
> discussion, and then you'll know why he concluded that my approach was
> fundamentally sound. If you have a filesystem that can see huge spikes
> in latency due to a write() of a relatively tiny query text, you have
> many problems, but blocking other queries that need to record
> statement execution costs in the shared hashtable actually isn't one
> of them.
--
Peter Geoghegan