Keep pg_stat_statements' query texts in a file, not in shared memory.
This change allows us to eliminate the previous limit on stored query
length, and it makes the shared-memory hash table very much smaller,
allowing more statements to be tracked. (The default value of
pg_stat_statements.max is
Hi,
(2014/01/28 5:38), Tom Lane wrote:
Keep pg_stat_statements' query texts in a file, not in shared memory.
This patch has security problem that root can easily see the statement file in
database cluster.
Is it OK or disscussed? If root user and operation user don't have access
privilege in
KONDO Mitsumasa kondo.mitsum...@lab.ntt.co.jp writes:
(2014/01/28 5:38), Tom Lane wrote:
Keep pg_stat_statements' query texts in a file, not in shared memory.
This patch has security problem that root can easily see the statement file in
database cluster.
What's your point? It's idle to
On Mon, Jan 27, 2014 at 5:12 PM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
This patch has security problem that root can easily see the statement file
in database cluster.
By default, we always serialize statements along with their query
texts to disk on shutdown. Until May of 2012,
Peter Geoghegan p...@heroku.com writes:
On Mon, Jan 27, 2014 at 5:12 PM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
This patch has security problem that root can easily see the statement file
in database cluster.
By default, we always serialize statements along with their query
On 01/27/2014 08:23 PM, Tom Lane wrote:
Peter Geoghegan p...@heroku.com writes:
On Mon, Jan 27, 2014 at 5:12 PM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
This patch has security problem that root can easily see the statement file
in database cluster.
By default, we always
On Mon, Jan 27, 2014 at 5:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Root can certainly also look at query texts in shared memory, or for that
matter in the local memory of any process. So can anybody else running as
the postgres userid.
I think that the concern may have had something to do
On Mon, Jan 27, 2014 at 5:34 PM, Andrew Dunstan and...@dunslane.net wrote:
The query texts are particularly uninteresting since I assume the data
values in the query have already been mostly dissolved away by
pg_stat_statements.
Actually, it is possible for the query string to still have
(2014/01/28 10:15), Peter Geoghegan wrote:
On Mon, Jan 27, 2014 at 5:12 PM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
This patch has security problem that root can easily see the statement file
in database cluster.
By default, we always serialize statements along with their query
Peter Geoghegan p...@heroku.com writes:
On Mon, Jan 27, 2014 at 5:34 PM, Andrew Dunstan and...@dunslane.net wrote:
The query texts are particularly uninteresting since I assume the data
values in the query have already been mostly dissolved away by
pg_stat_statements.
Actually, it is
On Mon, Jan 27, 2014 at 6:04 PM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
It is written in documents; For security reasons, non-superusers are not
allowed to see the text of queries executed by other users. Is root user
superuser? And initdb user might change to non-superuser after
(2014/01/28 10:23), Tom Lane wrote:
Peter Geoghegan p...@heroku.com writes:
On Mon, Jan 27, 2014 at 5:12 PM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
This patch has security problem that root can easily see the statement file
in database cluster.
By default, we always serialize
KONDO Mitsumasa kondo.mitsum...@lab.ntt.co.jp writes:
(2014/01/28 10:23), Tom Lane wrote:
Also, current query texts are probably less interesting to an intruder
than the contents of the database itself, which is stored in the same
directory tree with the same permissions (0600) as the
(2014/01/28 11:07), Peter Geoghegan wrote:
On Mon, Jan 27, 2014 at 6:04 PM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
It is written in documents; For security reasons, non-superusers are not
allowed to see the text of queries executed by other users. Is root user
superuser? And
On Mon, Jan 27, 2014 at 6:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Timed just right? I could see it possibly happening due to queryid
collisions, but I'm not seeing how it would happen absent such a hash
collision.
Consider what happens when there is a pg_stat_statements_reset() call
query
On Mon, Jan 27, 2014 at 9:31 PM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
Why is your concern with pg_stat_statements after this patch in
particular?
You'll need to serialize the file at least once before seeing it, but
then it's there for good (on old versions, before Magnus got
On Mon, Jan 27, 2014 at 6:31 PM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.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
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.mitsum...@lab.ntt.co.jp wrote:
No. I don't say root user is superuser. Executing initdb user will be
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
19 matches
Mail list logo
