Re: [BUGS] Kerberos authentication, Active Directory, and PostgreSQL
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 seems like a good idea then. I'm tempted to >>> backport this, although it's not strictly speaking a bug fix. Any >>> objections? >> Why isn't it a bug fix? +1 for backport ... > > Yeah, +1 there. Ok, committed. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5107: Lock never released
t...@sss.pgh.pa.us (Tom Lane) writes: > "Christian DUPONT" writes: >> I use slony 1 v 1.2.14. >> After an unexpected stop, several tables remained locked : > > Is it possible that the locks are being held by a prepared transaction? > Next time it happens, look into the pg_prepared_xacts status view. The prepared statement idea seems pretty plausible; certainly it's something that can survive a backend restart. > If it's not that, it seems like this must be a Slony issue, not a > problem with Postgres proper. You'll probably get better results > if you ask about it on the Slony mailing lists. I can't think of anything offhand which would seize a lock so tenaciously in Slony, except, evidently with a prepared statement as an accomplice. -- select 'cbbrowne' || '@' || 'gmail.com'; http://linuxdatabases.info/info/emacs.html "I really only meant to point out how nice InterOp was for someone who doesn't have the weight of the Pentagon behind him. I really don't imagine that the Air Force will ever be able to operate like a small, competitive enterprise like GM or IBM." -- Kent England -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Kerberos authentication, Active Directory, and PostgreSQL
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 symbol, > misleadingly named or otherwise. If the value were actually being > used in more than one place, it'd be a different story, but to be > so used it would likely need a completely different name. It is used in two places in that file: pg_GSS_recvauth() and pg_SSPI_recvauth(). (the original patch neglected SSPI) I'll rename it to PG_MAX_AUTH_TOKEN_LENGTH, unless someone has a better suggestion. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] issue with integer nullable column and value 0
Hi guys, I'm not sure what the source of this bug is, as I'm getting a discrepancy between 8.1 on Linux vs. 8.4 on Windows, using the latest JDBC driver type 4. The issue is this, I have a nullable integer column in one of my tables. When I'm updating the column in 8.4 Windows with value 0, it stays as null, but on the Linux 8.1 it will try to update it with the value 0. Not sure if anyone else has come across this issue? Thanks in advance. Sean -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5114: database initialization
The following bug has been logged online: Bug reference: 5114 Logged by: Email address: flamindrag...@gmail.com PostgreSQL version: any Operating system: Win XP Pro SP2 Description:database initialization Details: Hey I keep getting the "failed to run initdb: 1 "error every time I try to install any postgre. How can I solve this -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] issue with integer nullable column and value 0
Sean Hsien wrote: > using the latest JDBC driver type 4. > I have a nullable integer column in one of my tables. When I'm > updating the column in 8.4 Windows with value 0, it stays as null, > but on the Linux 8.1 it will try to update it with the value 0. Could you post a small, self-contained example of code which exhibits this problem? Also, what are the OS and Java versions on the client side? -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5115: ADD UNIQUE table_constraint with expression
The following bug has been logged online:
Bug reference: 5115
Logged by: Vladimir Kokovic
Email address: vladimir.koko...@a-asoft.com
PostgreSQL version: PostgreSQL 8.4.
Operating system: Linux vlD-kuci 2.6.28-15-generic #52-Ubuntu SMP Wed Sep
9 10:49:34 UTC 2009 i686 GNU/Linux
Description:ADD UNIQUE table_constraint with expression
Details:
For ALTER TABLE ADD CONSTRAINT documentation says:
ADD table_constraint
This form adds a new constraint to a table using the same syntax as
CREATE TABLE.
But if expression is used in the constraint definition
server says:
# ALTER TABLE asoft_finansije.gk_promene ADD CONSTRAINT vk2
UNIQUE((substring(broj,10)),id)
asoft-# ;
ERROR: 42601: syntax error at or near "("
LINE 1: ...ft_finansije.gk_promene ADD CONSTRAINT vk2 UNIQUE((substring...
^
LOCATION: base_yyerror, scan.l:907
Create index is OK:
*# CREATE UNIQUE INDEX vk2 on
adefault_finansije.gk_promene((substring(broj,10)),id);
CREATE INDEX
(vl...@[local]:5432) 16:51:39 [asoft]
*#
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5115: ADD UNIQUE table_constraint with expression
"Vladimir Kokovic" wrote:
> For ALTER TABLE ADD CONSTRAINT documentation says:
> ADD table_constraint
> This form adds a new constraint to a table using the same syntax
< as CREATE TABLE.
Which is specified as UNIQUE ( column_name [, ... ] )
> But if expression is used
it's not supported syntax, per the above.
> Create index is OK:
as one would expect from the documentation:
( { column | ( expression ) } [ opclass ] [, ...] )
This is not a bug.
Maybe there's a feature request in there, but that would belong on
a different list.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5115: ADD UNIQUE table_constraint with expression
"Vladimir Kokovic" writes:
> For ALTER TABLE ADD CONSTRAINT documentation says:
> ADD table_constraint
> This form adds a new constraint to a table using the same syntax as
> CREATE TABLE.
> But if expression is used in the constraint definition
> server says:
> # ALTER TABLE asoft_finansije.gk_promene ADD CONSTRAINT vk2
> UNIQUE((substring(broj,10)),id)
> asoft-# ;
> ERROR: 42601: syntax error at or near "("
> LINE 1: ...ft_finansije.gk_promene ADD CONSTRAINT vk2 UNIQUE((substring...
> ^
Yeah, if you tried writing that in CREATE TABLE, it would complain too.
> Create index is OK:
> *# CREATE UNIQUE INDEX vk2 on
> adefault_finansije.gk_promene((substring(broj,10)),id);
> CREATE INDEX
This is not a CONSTRAINT clause in a CREATE TABLE.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5115: ADD UNIQUE table_constraint with expression
Vladimir Kokovic wrote:
> For ALTER TABLE ADD CONSTRAINT documentation says:
> ADD table_constraint
> This form adds a new constraint to a table using the same syntax as
> CREATE TABLE.
>
> But if expression is used in the constraint definition
> server says:
> # ALTER TABLE asoft_finansije.gk_promene ADD CONSTRAINT vk2
> UNIQUE((substring(broj,10)),id)
> asoft-# ;
> ERROR: 42601: syntax error at or near "("
> LINE 1: ...ft_finansije.gk_promene ADD CONSTRAINT vk2 UNIQUE((substring...
> ^
> LOCATION: base_yyerror, scan.l:907
>
>
> Create index is OK:
> *# CREATE UNIQUE INDEX vk2 on
> adefault_finansije.gk_promene((substring(broj,10)),id);
> CREATE INDEX
> (vl...@[local]:5432) 16:51:39 [asoft]
> *#
The docs says "This form adds a new constraint to a table using the same
syntax as *CREATE TABLE*", not CREATE INDEX. More precisely,
table_constraint is referring to the table_constraint rule in the
documentation of CREATE TABLE:
and table_constraint is:
[ CONSTRAINT constraint_name ]
{ UNIQUE ( column_name [, ... ] ) index_parameters |
PRIMARY KEY ( column_name [, ... ] ) index_parameters |
CHECK ( expression ) |
FOREIGN KEY ( column_name [, ... ] ) REFERENCES reftable [ ( refcolumn
[, ... ] ) ]
[ MATCH FULL | MATCH PARTIAL | MATCH SIMPLE ] [ ON DELETE action ] [
ON UPDATE action ] }
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]
That doesn't allow using an expression with UNIQUE. There is currently
no way to create a unique constraint on an expression. However as you
noticed, you can create a unique index on one with the same effect.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5115: ADD UNIQUE table_constraint with expression
=?UTF-8?B?VmxhZGltaXIgS29rb3ZpxIc=?= writes: > Real question is "Why we need two syntaxes for the same thing ?" Because the SQL standard says so: UNIQUE-constraint syntax is limited to simple column names. We can't just extend that because it would break the information_schema views, which are only capable of representing unique/pk constraints on simple columns. CREATE INDEX, being outside the scope of the spec, doesn't have to worry about that. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Kerberos authentication, Active Directory, and PostgreSQL
> 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Kerberos authentication, Active Directory, and PostgreSQL
"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 symbol anytime we applied it to some new auth scheme. 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. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Kerberos authentication, Active Directory, and PostgreSQL
> 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 (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5116: could not determine encoding for locale
The following bug has been logged online: Bug reference: 5116 Logged by: Nikolai Wendorf Email address: nikol...@embarqmail.com PostgreSQL version: 8.4.1 Operating system: Solaris 9 Description:could not determine encoding for locale Details: 30>psql psql (8.4.1) Type "help" for help. nick=# drop database dtrecon; DROP DATABASE nick=# create database dtrecon; WARNING: could not determine encoding for locale "en_US.ISO8859-1": codeset is "646" DETAIL: Please report this to . CREATE DATABASE -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5116: could not determine encoding for locale
"Nikolai Wendorf" writes: > Operating system: Solaris 9 > Description:could not determine encoding for locale > WARNING: could not determine encoding for locale "en_US.ISO8859-1": codeset > is "646" Well, that's truly stupid :-(. The only plausible referent for 646 that I've heard of is ISO/IEC 646 http://en.wikipedia.org/wiki/ISO_646 which arguably could describe *any* single-byte ASCII superset. It's certainly pretty awful as a descriptor of what I suppose is really ISO 8859-1. I'd suggest filing a bug with Sun suggesting that they ought to return something less ambiguous for nl_langinfo(CODESET) in this locale. Meanwhile, the warning isn't really hurting anything, it's just letting you know that Postgres isn't sure whether your locale and encoding settings match. As long as you don't tell it to use something besides the LATIN1 encoding in this locale, everything will work fine. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
