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
On 6/7/13 2:57 PM, Tom Lane wrote:
> "Joshua D. Drake" 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 "u
* 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 UN
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 detai
On 06/07/2013 12:31 PM, Tom Lane wrote:
"Joshua D. Drake" 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
tel
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
Joshua D. Drake wrote
> On 06/07/2013 12:31 PM, Tom Lane wrote:
>> "Joshua D. Drake" <
> jd@
> > 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 poli
On Fri, 07 Jun 2013 13:07:21 -0700
"Joshua D. Drake" wrote:
>
> On 06/07/2013 12:31 PM, Tom Lane wrote:
> > "Joshua D. Drake" 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
On 06/07/2013 12:31 PM, Tom Lane wrote:
"Joshua D. Drake" 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
tel
David Johnston 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 invalid
"Joshua D. Drake" 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 it doesn't know
Tom Lane-2 wrote
> "Joshua D. Drake" <
> jd@
> > 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
>
On 06/07/2013 11:57 AM, Tom Lane wrote:
"Joshua D. Drake" 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
"Joshua D. Drake" 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 had nothing to d
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 authentica
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 r
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 out
"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.
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
>
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
20 matches
Mail list logo
