in the description of the ORDER BY clause
(http://www.postgresql.org/docs/current/static/sql-select.html#SQL-ORDERBY) it
says:
"Character-string data is sorted according to the locale-specific collation order
that was established when the database was created."
Which is no longer true with 9.
The following bug has been logged on the website:
Bug reference: 6412
Logged by: Andy Grimm
Email address: agr...@gmail.com
PostgreSQL version: 9.1.2
Operating system: Linux (Fedora)
Description:
When psql prompts for a password, it only reads the first 100 characters
On 1/27/2012 7:47 PM, Dharmendra Goyal wrote:
Nice analysis Eric. ANy idea why (which program set this) this
particular registry was set.
Thanks Dharmendra! It was pretty exhausting.
I haven't a clue how this got changed. I tried goofing around with
shift, ctrl, etc. and I wasn't even able to
On 27-01-2012 23:15, agr...@gmail.com wrote:
> When psql prompts for a password, it only reads the first 100 characters of
> the password. The limit in fe-connect.c (for when .pgpass is used) is
> weirder, a seemingly arbitrary 320 bytes for all fields combined. Other
> (postgresql-jdbc, PyGreSQL
Euler Taveira de Oliveira writes:
> I don't see it as a bug but a limitation. Why do you need such a long
> password?
Yeah, I think the reason we're not too consistent about this is that
nobody ever imagined that limits of 100 bytes or more would pose an
issue in practice. What's the use-case fo
On 28-01-2012 14:32, Andy Grimm wrote:
> IMHO, there is a subtle difference here. If psql raised an error
> message on passwords exceeding 100 characters, I would understand your
> perspective, but I think that simply truncating the password and
> continuing on is a bug. I also think that hard-co
The following bug has been logged on the website:
Bug reference: 6413
Logged by: James Stevenson
Email address: ja...@stev.org
PostgreSQL version: 8.4.9
Operating system: Linux - Debian Squeeze
Description:
I suspect pg_relation_size has a tolower in it to a table na
On Sat, Jan 28, 2012 at 11:55 AM, Euler Taveira de Oliveira
wrote:
> On 27-01-2012 23:15, agr...@gmail.com wrote:
>> When psql prompts for a password, it only reads the first 100 characters of
>> the password. The limit in fe-connect.c (for when .pgpass is used) is
>> weirder, a seemingly arbitra
On 28-01-2012 13:16, ja...@stev.org wrote:
> pg_relation_size('Attempts')
> and
> pg_relation_size('attempts')
>
pg_relation_size('"Attempts"')
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
On 28.01.2012 18:16, ja...@stev.org wrote:
I suspect pg_relation_size has a tolower in it to a table name called
Attempts will not work with pg_relation_size
Both
pg_relation_size('Attempts')
and
pg_relation_size('attempts')
fails with no such table.
After table rename from Attempts to attemp
I work with Bridget at Redfin.
We have a core dump from a once-in-5-days (multi-million queries) hot
standby segfault in pg 9.1.2 . (It might or might be the same root issue as
the "alloc" errors. If I should file a new bug report, let me know.
The postgres executable that crashed did not have de
On Sat, Jan 28, 2012 at 1:50 PM, Euler Taveira de Oliveira
wrote:
> On 28-01-2012 14:32, Andy Grimm wrote:
>> IMHO, there is a subtle difference here. If psql raised an error
>> message on passwords exceeding 100 characters, I would understand your
>> perspective, but I think that simply truncati
On 28 January 2012 21:34, Michael Brauwerman
wrote:
> We have the (5GB) core file, and are happy to do any more forensics anyone
> can advise.
Ideally, you'd be able to install debug information packages, which
should give a more detailed and useful stack trace, as described here:
http://wiki.po
Phil Sorber writes:
> On Wed, Jan 25, 2012 at 5:13 PM, Tom Lane wrote:
> I played around with removing the optimization, but there are other
> pieces further down the line that are upset but having a ModifyTable
> node in the execution tree.
Hm, yeah, obviously this scenario has never been teste
On 28-01-2012 18:55, Andy Grimm wrote:
> It's not uniform between the client and the server, though.
>
The server doesn't impose a hard limit for password length and AFAICS it
should not because we aim for backward compatibility.
> It sounds like you are suggesting
> that rather than increase the
Josh Berkus writes:
> SUMMARY: if you attempt to UPDATE or DELETE FROM a parent table in an
> inheritance relationship using a wCTE, you get the following error message:
> ERROR: could not find plan for CTE
Fixed, thanks for the report.
regards, tom lane
--
Sent
We did try that with a postgres 9.1.2, compiled from source with debug
flags, but we got 0x10 bad address in gdb. (Obviously we did it wrong
somehow)
We will keep trying to get a good set of symbols set up.
On Jan 28, 2012 2:34 PM, "Peter Geoghegan" wrote:
> On 28 January 2012 21:34, Michael Bra
Thomas Kellerer writes:
> in the description of the ORDER BY clause
> (http://www.postgresql.org/docs/current/static/sql-select.html#SQL-ORDERBY)
> it says:
> "Character-string data is sorted according to the locale-specific collation
> order that was established when the database was created."
Phil Sorber writes:
> http://www.postgresql.org/docs/devel/static/plpgsql-control-structures.html#PLPGSQL-UPSERT-EXAMPLE
> This example can lead to an infinite loop if there is another column
> that has a unique key constraint on it in addition to the primary key
> and someone tries to execute the
19 matches
Mail list logo
