On 6/7/13 2:57 PM, Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com writes:
I had a customer pulling their hair out today because they couldn't
login to their system. The error was consistently:
2013-06-07 08:42:44 MST postgres 10.1.11.67 27440 FATAL: password
authentication failed
On 06/19/2013 08:24 AM, Peter Eisentraut wrote:
I think it's intentional that we don't tell the *client* that level of
detail. I could see emitting a log message about it, but it's not clear
whether that will help an unsophisticated user.
Usually, when I log in somewhere and the password is
* Tom Lane wrote:
it supposes that rolvaliduntil represents an expiration date for the
user, but really it's only an expiration date for the password.)
Does anyone think the docs for CREATE ROLE/VALID UNTIL should mention
this more clearly? Currently, it is described as
The VALID
On 06/08/2013 04:07 AM, Joshua D. Drake wrote:
FATAL: Authentication failed: Check server log for specifics
And then we make sure we log proper info?
FATAL: Authentication using method 'password' failed, possible reasons
are no/wrong password sent, account expired; see server log for details ?
On 06/07/2013 12:31 PM, Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com writes:
On 06/07/2013 11:57 AM, Tom Lane wrote:
I think it's intentional that we don't tell the *client* that level of
detail.
Why? That seems rather silly.
The general policy on authentication failure reports
Hello,
I had a customer pulling their hair out today because they couldn't
login to their system. The error was consistently:
2013-06-07 08:42:44 MST postgres 10.1.11.67 27440 FATAL: password
authentication failed for user user
However the problem had nothing to do with password
Joshua D. Drake j...@commandprompt.com writes:
I had a customer pulling their hair out today because they couldn't
login to their system. The error was consistently:
2013-06-07 08:42:44 MST postgres 10.1.11.67 27440 FATAL: password
authentication failed for user user
However the problem
On 06/07/2013 11:57 AM, Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com writes:
I had a customer pulling their hair out today because they couldn't
login to their system. The error was consistently:
2013-06-07 08:42:44 MST postgres 10.1.11.67 27440 FATAL: password
authentication
Tom Lane-2 wrote
Joshua D. Drake lt;
jd@
gt; writes:
I had a customer pulling their hair out today because they couldn't
login to their system. The error was consistently:
2013-06-07 08:42:44 MST postgres 10.1.11.67 27440 FATAL: password
authentication failed for user user
However
Joshua D. Drake j...@commandprompt.com writes:
On 06/07/2013 11:57 AM, Tom Lane wrote:
I think it's intentional that we don't tell the *client* that level of
detail.
Why? That seems rather silly.
The general policy on authentication failure reports is that we don't
tell the client anything
David Johnston pol...@yahoo.com writes:
I presume that password in this context refers to the method by which
identity is checked; some alternatives being trust and ident?
Right.
Using the same logic of why you would not expose the fact that the user is
expired versus the user has provided
On 06/07/2013 12:31 PM, Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com writes:
On 06/07/2013 11:57 AM, Tom Lane wrote:
I think it's intentional that we don't tell the *client* that level of
detail.
Why? That seems rather silly.
The general policy on authentication failure reports
On Fri, 07 Jun 2013 13:07:21 -0700
Joshua D. Drake j...@commandprompt.com wrote:
On 06/07/2013 12:31 PM, Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com writes:
On 06/07/2013 11:57 AM, Tom Lane wrote:
I think it's intentional that we don't tell the *client* that
level of detail.
Joshua D. Drake wrote
On 06/07/2013 12:31 PM, Tom Lane wrote:
Joshua D. Drake lt;
jd@
gt; writes:
On 06/07/2013 11:57 AM, Tom Lane wrote:
I think it's intentional that we don't tell the *client* that level of
detail.
Why? That seems rather silly.
The general policy on authentication
On 06/07/2013 01:41 PM, David Johnston wrote:
Please check server log for specifics is not a good message for something
sent to a client that in many normal situation would have no access to said
logs.
I don't agree. The user doesn't need access to the logs. If they get
that error they
On Oct 1, 2008, at 12:12 AM, Gurjeet Singh wrote:
On Wed, Oct 1, 2008 at 9:39 AM, Tom Lane [EMAIL PROTECTED] wrote:
Gurjeet Singh [EMAIL PROTECTED] writes:
On Wed, Oct 1, 2008 at 3:07 AM, Decibel! [EMAIL PROTECTED]
wrote:
ERROR: aggregates not allowed in WHERE clause
No, the real issue
From -HEAD:
ERROR: aggregates not allowed in WHERE clause
STATEMENT: SELECT *
FROM loans l
WHERE id IN ( SELECT max(l.id)
FROM loans
JOIN customers c ON c.id =
l.customer_id
On Wed, Oct 1, 2008 at 3:07 AM, Decibel! [EMAIL PROTECTED] wrote:
From -HEAD:
ERROR: aggregates not allowed in WHERE clause
STATEMENT: SELECT *
FROM loans l
WHERE id IN ( SELECT max(l.id)
FROM loans
Gurjeet Singh [EMAIL PROTECTED] writes:
On Wed, Oct 1, 2008 at 3:07 AM, Decibel! [EMAIL PROTECTED] wrote:
ERROR: aggregates not allowed in WHERE clause
No, the real issue is that you are referencing the outer table's column's
max() in the inner query (correlated sub-query).
Yeah. It's not
On Wed, Oct 1, 2008 at 9:39 AM, Tom Lane [EMAIL PROTECTED] wrote:
Gurjeet Singh [EMAIL PROTECTED] writes:
On Wed, Oct 1, 2008 at 3:07 AM, Decibel! [EMAIL PROTECTED] wrote:
ERROR: aggregates not allowed in WHERE clause
No, the real issue is that you are referencing the outer table's
20 matches
Mail list logo