And it was from Peter.
On Mon, Jan 27, 2014 at 8:20 PM, KONDO Mitsumasa
<kondo.mitsum...@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
--
Mitsumasa KONDO
NTT Open Source Software Center
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
