> The original naming complaint reflected a concern that
> the symbol looked like it was supplied by the system headers, rather
> than being of Postgres origin. Heikki's suggestion deals with that,
> and I think it's fine as-is.
OK, fine with me.
--Ian
--
Sent via pgsql-bugs mailing list (pgsq
"Turner, Ian" writes:
>> I'll rename it to PG_MAX_AUTH_TOKEN_LENGTH, unless someone has a better
>> suggestion.
> If we are not changing this for all authentication schemes, then the name
> should probably reflect that this is for GSS and SSPI only (not even KRB5).
Then we'd have to rename the
> I'll rename it to PG_MAX_AUTH_TOKEN_LENGTH, unless someone has a better
> suggestion.
If we are not changing this for all authentication schemes, then the name
should probably reflect that this is for GSS and SSPI only (not even KRB5).
--Ian
--
Sent via pgsql-bugs mailing list (pgsql-bugs@po
Tom Lane wrote:
> Peter Eisentraut writes:
>> A small wish in case we go with this: The constant should be named
>> something like PG_...; otherwise it looks like we are defining or
>> overriding an official symbol from the GSS API.
>
> I'd be inclined to just s/2000/32767/ and not bother with a
Magnus Hagander wrote:
> 2009/10/13 Tom Lane :
>> Heikki Linnakangas writes:
>>> Magnus Hagander wrote:
Actually, I found a note that said it's recommended to never increase
it about 65535 - so perhaps we should put our limit at that instead od
32767?
>>> Yeah, setting it at 65535 s
2009/10/13 Tom Lane :
> Heikki Linnakangas writes:
>> Magnus Hagander wrote:
>>> Actually, I found a note that said it's recommended to never increase
>>> it about 65535 - so perhaps we should put our limit at that instead od
>>> 32767?
>
>> Yeah, setting it at 65535 seems like a good idea then. I
Heikki Linnakangas writes:
> Magnus Hagander wrote:
>> Actually, I found a note that said it's recommended to never increase
>> it about 65535 - so perhaps we should put our limit at that instead od
>> 32767?
> Yeah, setting it at 65535 seems like a good idea then. I'm tempted to
> backport this,
Magnus Hagander wrote:
> FWIW, the default max token size on Win2k is ~8Kb. In some service
> pack and then in Win2003, it was increased to 12Kb. But it is possible
> to increase that by a registry key on the domain controller - and I
> read somewhere that Win2008 actually will increase this size
>
Tom Lane:
> I'd be inclined to just s/2000/32767/ and not bother with a symbol,
Heikki Linnakangas:
> The corresponding limit in pg_SSPI_recvauth() probably needs to be
> raised too..
Magnus Hagander:
> Actually, I found a note that said it's recommended to never increase
> it [above] 65535 - so
Peter Eisentraut wrote:
> On Mon, 2009-10-12 at 20:42 -0400, Turner, Ian wrote:
> > --- postgresql-8.4-8.4.1/src/backend/libpq/auth.c 2009-06-25
> > 12:30:08.0 +0100
> > +++ postgresql-8.4-8.4.1-fixed/src/backend/libpq/auth.c 2009-09-15
> > 20:27:01.0 +0100
> > @@ -166,6 +16
Peter Eisentraut writes:
> A small wish in case we go with this: The constant should be named
> something like PG_...; otherwise it looks like we are defining or
> overriding an official symbol from the GSS API.
I'd be inclined to just s/2000/32767/ and not bother with a symbol,
misleadingly name
On Mon, 2009-10-12 at 20:42 -0400, Turner, Ian wrote:
> --- postgresql-8.4-8.4.1/src/backend/libpq/auth.c 2009-06-25
> 12:30:08.0 +0100
> +++ postgresql-8.4-8.4.1-fixed/src/backend/libpq/auth.c 2009-09-15
> 20:27:01.0 +0100
> @@ -166,6 +166,8 @@
> #endif
>
> static int
2009/10/13 Heikki Linnakangas :
> Turner, Ian wrote:
>> While trying to connect our PostgreSQL database to our Kerberos realm, we
>> encountered the obscure message "Invalid message length". Tracking this
>> down, we discovered that it was emitted by src/backend/libpq/pqcomm.c in
>> response to
Turner, Ian wrote:
> While trying to connect our PostgreSQL database to our Kerberos realm, we
> encountered the obscure message "Invalid message length". Tracking this down,
> we discovered that it was emitted by src/backend/libpq/pqcomm.c in response
> to a rather large Kerberos message. The r
14 matches
Mail list logo