On 01/27/2014 05:32 PM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost writes:
Check dup2() results in syslogger
Consistently check the dup2() call results throughout syslogger.c.
It's pretty unlikely that they'll error out, but if they do,
ereport(FATAL) instead of
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Check dup2() results in syslogger
> > Consistently check the dup2() call results throughout syslogger.c.
> > It's pretty unlikely that they'll error out, but if they do,
> > ereport(FATAL) instead of blissfully continuing on.
>
>
Relax the requirement that all lwlocks be stored in a single array.
This makes it possible to store lwlocks as part of some other data
structure in the main shared memory segment, or in a dynamic shared
memory segment. There is still a main LWLock array and this patch does
not move anything out o
Stephen Frost writes:
> Check dup2() results in syslogger
> Consistently check the dup2() call results throughout syslogger.c.
> It's pretty unlikely that they'll error out, but if they do,
> ereport(FATAL) instead of blissfully continuing on.
Meh. Have you actually tested that an ereport(FATAL)
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Please note also that the comment just above
>> this implies that we are deliberately ignoring any failures here, so I
>> think FATAL was probably the wrong thing in any case.
> We were explicitly ignoring the errors from the close
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> You shouldn't really raise that argument against the guy who made the
> original commit in question ;-).
Figures. :) Not sure how I missed that.
[...]
Right, I had followed that.
> Now ideally, the way we do that is to reconnect its stderr to /dev/null,
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> In short, this patch was ill considered. Please revert. If we need
>> to silence a Coverity complaint, perhaps a cast-to-void will do?
> Sure, I'll adjust it accordingly.
Feel free to improve the comment if you think it could be
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 t
KONDO Mitsumasa 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 imagine that root can't see
On Mon, Jan 27, 2014 at 5:12 PM, KONDO Mitsumasa
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, pg_stat_statements
didn't bo
Peter Geoghegan writes:
> On Mon, Jan 27, 2014 at 5:12 PM, KONDO Mitsumasa
> 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
On 01/27/2014 08:23 PM, Tom Lane wrote:
Peter Geoghegan writes:
On Mon, Jan 27, 2014 at 5:12 PM, KONDO Mitsumasa
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
On Mon, Jan 27, 2014 at 5:23 PM, Tom Lane 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 with a
MAC-centric
On Mon, Jan 27, 2014 at 5:34 PM, Andrew Dunstan 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 constants
if things ar
(2014/01/28 10:15), Peter Geoghegan wrote:
On Mon, Jan 27, 2014 at 5:12 PM, KONDO Mitsumasa
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. Unti
Peter Geoghegan writes:
> On Mon, Jan 27, 2014 at 5:34 PM, Andrew Dunstan 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 s
On Mon, Jan 27, 2014 at 6:04 PM, KONDO Mitsumasa
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 creating
> database clust
Log a detail message for auth failures due to missing or expired password.
It's worth distinguishing these cases from run-of-the-mill wrong-password
problems, since users have been known to waste lots of time pursuing the
wrong theory about what's failing. Now, our longstanding policy about how
t
(2014/01/28 10:23), Tom Lane wrote:
> Peter Geoghegan writes:
>> On Mon, Jan 27, 2014 at 5:12 PM, KONDO Mitsumasa
>> 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 qu
KONDO Mitsumasa 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 query-text file.
> Yes, that's
(2014/01/28 11:07), Peter Geoghegan wrote:
On Mon, Jan 27, 2014 at 6:04 PM, KONDO Mitsumasa
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-s
On Mon, Jan 27, 2014 at 6:08 PM, Tom Lane 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 after another q
On Mon, Jan 27, 2014 at 9:31 PM, KONDO Mitsumasa
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 annoyed
>> that that
On Mon, Jan 27, 2014 at 6:31 PM, KONDO Mitsumasa
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
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
wrote:
No. I don't say root user is superuser. Executing initdb user will be
postgres superuser. But it can cha
And it was from Peter.
On Mon, Jan 27, 2014 at 8:20 PM, KONDO Mitsumasa
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 o
27 matches
Mail list logo
