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
The following bug has been logged online:
Bug reference: 5110
Logged by: Kalev Toots
Email address: kalev.to...@probil.ee
PostgreSQL version: 8.3.8
Operating system: Ubuntu
Description:lower() function
Details:
Upgrade from 8.1.15 -> 8.3.8
lower(text) for Estonian c
The following bug has been logged online:
Bug reference: 5111
Logged by: Fendris
Email address: f.fend...@gmail.com
PostgreSQL version: 8.4.1
Operating system: x86_64 Debian 5.0.3
Description:Segmentation fault, if to_tsvector returns empty row to
ts_stat
Details:
e
2009/10/13 Kalev Toots :
>
> The following bug has been logged online:
>
> Bug reference: 5110
> Logged by: Kalev Toots
> Email address: kalev.to...@probil.ee
> PostgreSQL version: 8.3.8
> Operating system: Ubuntu
> Description: lower() function
> Details:
>
> Upgrade fr
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
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
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
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
The following bug has been logged online:
Bug reference: 5112
Logged by: Yury Don
Email address: y...@vpcit.ru
PostgreSQL version: 8.4.1
Operating system: Debian Linux (architecture amd64)
Description:Segmentation fault on ts_stat with empty words
Details:
When call
"Fendris" writes:
> SELECT * from ts_stat('SELECT to_tsvector(''simple'',)');
> [ dumps core ]
Thanks, looks like this code just missed the possibility of an empty
tree. Attached patch fixes it.
regards, tom lane
*** src/backend/utils/adt/tsvector_op.c.origThu J
I still don't know which is the bit that is syntactically not correct
> that a column name is a qualified reference to the function's OUT
parameter or
> that the function name is also a table alias
and the error message is not very helpful to find this out.
But I certainly l learned that I shoul
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
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
>
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,
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
The following bug has been logged online:
Bug reference: 5113
Logged by: dan
Email address: dan.boe...@roost.com
PostgreSQL version: 8.4.1
Operating system: redhat 5.3
Description:Postgres not scanning indexes
Details:
Let's say I have a table t with 5 columns c1 NO
On Oct 13, 2009, at 18:46 , dan wrote:
When I run the query:
select c1,c2 from t
I expect the explain to say index scan; instead it says table scan.
You're asking for the entire table: why perform the extra work of
using an index and then looking up entries in the table rather than
readi
On Tue, 13 Oct 2009, dan wrote:
> Let's say I have a table t with 5 columns c1 NOT NULL, c2 NOT NULL, c3, c4,
> c5
> and I have a UNIQUE index on (c1, c2) (remember c1 and c2 have a not null
> constraint)
>
> When I run the query:
> select c1,c2 from t
>
> I expect the explain to say index scan; i
> "dan" == "dan" writes:
dan> I expect the explain to say index scan; instead it says table scan.
dan> The index has ALL the info I need
It may have all the info _you_ need, but what it doesn't have is all the
info that _postgres_ needs; specifically it doesn't contain enough row
visibili
19 matches
Mail list logo
