[BUGS] BUG #4124: Error message: "You local administrators group contains 'Service users' this is a common configurat
The following bug has been logged online: Bug reference: 4124 Logged by: Blake Lovely Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 Operating system: Vista home premium Description:Error message: "You local administrators group contains 'Service users' this is a common configurat Details: Error message: "You local administrators group contains 'Service users' this is a common configuration error" When the installer is first trying to create the postgres service account. What should I do? -- 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] Patch for LISTEN/NOTIFY race condition?
Thanks all ... I'm going to do some more digging and see if I can isolate the problem. Meetesh Tom Lane wrote: Alvaro Herrera <[EMAIL PROTECTED]> writes: Meetesh Karia wrote: After upgrading to 8.3 and Slony 1.2.13, one of our import processes started constantly failing because of deadlock. Our import process (pl/pgsql function) just uses COPY FROM to populate a temp table and then inserts from that (without any special locks, etc). And, the deadlock error showed that the import process was waiting on sl_event and a slon process was waiting on pg_listener. I found the following thread in the archives: http://archives.postgresql.org/pgsql-bugs/2008-03/msg00117.php and it seemed like it could be the cause of the problem. Is the patch available anywhere? Also, if it will be available in 8.3.2, is there any information on when that will be released? Hmm, AFAICS the patch should be present on 8.3.1, because it was tagged on March 14th and the patch was committed on March 12. Yes, but in any case (a) that's about a race condition not a deadlock, and (b) the issue has been there since forever, so it is unlikely to explain or fix a problem that you weren't seeing before 8.3. regards, tom lane
[BUGS] help me please
Hello, help me please, I don't know how, but i got 2 postgres users. How can I delete the first one thx alot for your answers. /// select passwd,ctid,xmin,xmax,cmin,cmax from pg_shadow where usesysid =1; passwd| ctid | xmin | xmax | cmin | cmax -+---+--+--+--+- - | (0,1) |1 | 16754522 | 16754522 |0 md510db8c04d26d32185270721fcf32155 | (0,2) |2 |0 |0 |0 (2 rows) // select * from pg_shadow where usesysid=1; usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig --+--+-+--+---+- +--+--- postgres |1 | t | t| t | | | postgres |1 | t | t| t | md510db8c04d231142d5 270721fcf740ed5 | infinity | (2 rows) Tom Lane пишет: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: I have two "postgres" user. How to delete the first one ??? Let's see the system columns (ctid,xmin,xmax,cmin,cmax) for those two rows? 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
[BUGS] Re: BUG #4123: Statement.setQueryTimeout does not work with Postgres Java Driver
On Apr 22, 12:05 pm, [EMAIL PROTECTED] ("Amit Mujawar") wrote:
> The following bug has been logged online:
>
> Bug reference: 4123
> Logged by: Amit Mujawar
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.1
> Operating system: Windows XP
> Description: Statement.setQueryTimeout does not work with Postgres
> Java Driver
> Details:
>
> I am using PostgreSQL through JDBC
> PostgreSQL – 8.1, Driver - org.postgresql.Driver 8.1-408.jdbc3
>
> When I set Statement.setQueryTimeout, the timeout value does not show any
> effect on actual timeout...The query blocks for a specific time always [may
> be configured by another global variable - statement_timeout? not sure]
>
> I suspect there is a problem with JDBC driver implementation for
> setQueryTimeout API.
>
It is in the TODO list of the driver to be implemented. Actually the
TODO list for Postgres JDBC It is a good place to see what the
features you cannot use :-)
I am setting the timeout by the acquisition of the connection by the
pool (in ConnectionCustomizer in C3P0 pooling library) like that:
PreparedStatement s = null;
ResultSet rs = null;
try {
s = c.prepareStatement("SELECT set_config('statement_timeout', ?,
false);" );
s.setInt(1, 35000);
rs = s.executeQuery();
if ( rs.next() ) {
String newTimeout = rs.getString(1);
if ( logger.isInfoEnabled() ) {
logger.info("STATEMENT_TIMEOUT set to '" + newTimeout + "' (" +
parentDataSourceIdentityToken + ")");
}
} else {
if ( logger.isErrorEnabled() ) {
logger.error("STATEMENT_TIMEOUT could not be set! (" +
parentDataSourceIdentityToken + ")");
}
}
} catch (SQLException e) {
if ( logger.isErrorEnabled() ) {
logger.error("STATEMENT_TIMEOUT could not be set! (" +
parentDataSourceIdentityToken + ")", e);
}
} finally {
if ( rs != null ) rs.close();
if ( s != null ) s.close();
}
if you want to do it before you start some transaction, you can bring
this code into a function like Utils.setStatementTimeout(Connection c,
boolean isTransactionLocal) and call it after
Connection.setAutoCommit(false);
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: BUG #4123: Statement.setQueryTimeout does not work with Postgres Java Driver
On Apr 22, 5:53 pm, [EMAIL PROTECTED] (Kris Jurka) wrote:
> On Tue, 22 Apr 2008, Amit Mujawar wrote:
>
> > The following bug has been logged online:
>
> > Bug reference: 4123
> > PostgreSQL version: 8.1
> > Description: Statement.setQueryTimeout does not work with Postgres
> > Java Driver
> > Details:
>
> > I am using PostgreSQL through JDBC
> > PostgreSQL – 8.1, Driver - org.postgresql.Driver 8.1-408.jdbc3
>
> > I suspect there is a problem with JDBC driver implementation for
> > setQueryTimeout API.
>
> setQueryTimeout is not implemented at all. Newer drivers (8.3+) will
> throw an exception telling you that if you try to call setQueryTimeout
> while older drivers silently accept the value and do nothing.
>
> Kris Jurka
>
> --
> Sent via pgsql-bugs mailing list ([EMAIL PROTECTED])
> To make changes to your
> subscription:http://www.postgresql.org/mailpref/pgsql-bugs- Hide quoted text -
>
> - Show quoted text -
Hi Kris,
wanted to ask you that all the time, but never had found time to do
that.
Is it possible to implement the setStatementTimeout() as somethig
like:
s = c.prepareStatement("SELECT set_config('statement_timeout',
, false);" );
s.executeQuery();
c.commit();
With best regards,
-- Valentine Gogichashvili
--
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 #4124: Error message: "You local administrators group contains 'Service users' this is a common configurat
"Blake Lovely" <[EMAIL PROTECTED]> writes: > PostgreSQL version: 8.2 > Operating system: Vista home premium 8.2 was not supported on Vista as it came out long before Vista did. Try 8.3. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS]
Hi there, Can someone please send me the url to download the latest PostGreSQL database for windows. I would like a windows installer to do it. Thanks.
Re: [BUGS]
In response to "Adiel Davids" <[EMAIL PROTECTED]>: > Hi there, > > Can someone please send me the url to download the latest PostGreSQL > database for windows. > > I would like a windows installer to do it. http://www.postgresql.org/ftp/binary/v8.3.1/win32/ Or you could follow the download links on the home page. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- 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]
Adiel, > Can someone please send me the url to download the latest PostGreSQL > database for windows. > > I would like a windows installer to do it. http://www.postgresql.org/ftp/binary/v8.3.1/win32/ That is exactly 2 klicks away from www.postgresql.org. And the links are headlined with "latest release". What could we improve on the website to make it more likely for you to find that installer? Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 fx 01212-5-13695179 - EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned! -- 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 #4125: Strange ALTER TABLE behavior
The following bug has been logged online: Bug reference: 4125 Logged by: Vladimir Kanazir Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.6 Operating system: Fedora 7 Description:Strange ALTER TABLE behavior Details: If I execute this query: alter table history add incoming_id bigint default 0; the table will be locked until operation finishes (checked by executing the select query on the same table via another connection). But, if I do this: alter table history add incoming_id bigint; alter table history alter incoming_id set default 0; update history set incoming_id=0; the table will be locked only during alter table execution, which is very short time. I think that alter table with default values should work the same way. -- 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 #4125: Strange ALTER TABLE behavior
"Vladimir Kanazir" <[EMAIL PROTECTED]> writes: > If I execute this query: > alter table history add incoming_id bigint default 0; > the table will be locked until operation finishes (checked by executing the > select query on the same table via another connection). Indeed, because it has to physically fill the value zero into every table row. > But, if I do this: > alter table history add incoming_id bigint; > alter table history alter incoming_id set default 0; > update history set incoming_id=0; > the table will be locked only during alter table execution, which is very > short time. But this exposes the state where incoming_id isn't zero to other transactions. 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
[BUGS] HELP pls
Hello, help me please, I don't know how, but i got 2 postgres users. How can I delete the first one thx alot for your answers. Oleg -- 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] HELP pls
[EMAIL PROTECTED] wrote: > Hello, help me please, > I don't know how, but i got 2 postgres users. > How can I delete the first one > thx alot for your answers. You've got transaction wraparound problems. Start here: http://search.postgresql.org/search?q=transaction+wraparound&m=1&l=&d=365&s=r -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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 #4125: Strange ALTER TABLE behavior
> > But, if I do this: > > alter table history add incoming_id bigint; > > alter table history alter incoming_id set default 0; > > update history set incoming_id=0; > > the table will be locked only during alter table execution, which > > is very short time. > > But this exposes the state where incoming_id isn't zero to other > transactions. Yes, I can see your point... But if there is a system running, this will lock it up even current transactions doesn't care about the new field. That is how I noticed this :) But, I guess, you can't make everybody happy :) Thanks -- Regards Vladimir Kanazir -- 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] HELP pls
Alvaro Herrera <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: >> I don't know how, but i got 2 postgres users. > You've got transaction wraparound problems. Start here: Vacuuming isn't gonna help though. The tuple at (0,2) has been frozen, which means that vacuum has certainly been run on the table since the update; so he's wrapped around so far that vacuum doesn't think it can remove the (0,1) tuple. I assume the OP is just trying to dump this database so he can upgrade to something remotely modern. It might work to change the second tuple's usesysid to something else (eg, 2) so that pg_dump doesn't see multiple rows matching other objects' owner fields. 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
[BUGS] BUG #4126: KRB5/GSSAPI authenication fails for multipart kerberos principals
The following bug has been logged online: Bug reference: 4126 Logged by: Peter Koczan Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: Red Hat Enterprise Linux 5 Description:KRB5/GSSAPI authenication fails for multipart kerberos principals Details: When trying to connect to an 8.3 server using a multipart Kerberos principal (e.g. ator/[EMAIL PROTECTED] or koczan/[EMAIL PROTECTED] instead of [EMAIL PROTECTED] or [EMAIL PROTECTED]), the connection fails, claiming a name mismatch. This is a change from 8.2 and I found nothing in the changelog or documentation to suggest this change or offer a workaround. This happens no matter what client libraries I'm using (I'll connect using 8.3 clients only to illustrate this point). Here's what happens with a normal login principal: [EMAIL PROTECTED] ~ $ klist Ticket cache: FILE:/var/adm/krb5/tmp/tkt/krb5cc_3258_zWQIbO Default principal: [EMAIL PROTECTED] ... [EMAIL PROTECTED] koczan $ /s/postgresql-8.3/bin/psql -h sensei -p 5432 sushi Welcome to psql 8.3.1 (server 8.2.6), the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit WARNING: You are connected to a server with major version 8.2, but your psql client is major version 8.3. Some backslash commands, such as \d, might not work properly. SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) sushi=> select version(); version PostgreSQL 8.2.6 on i686-pc-linux-gnu, compiled by GCC gcc.bin (GCC) 3.4.4 (1 row) sushi=> select current_user; current_user -- koczan (1 row) [EMAIL PROTECTED] ~ $ /s/postgresql-8.3/bin/psql -h sensei -p 49173 sushi Welcome to psql 8.3.1, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) sushi=> select version(); version PostgreSQL 8.3.1 on i686-pc-linux-gnu, compiled by GCC gcc.bin (GCC) 3.4.4 (1 row) sushi=> select current_user; current_user -- koczan (1 row) And what happens with my "mail" instance: [EMAIL PROTECTED] ~]# su - koczan [EMAIL PROTECTED] ~ $ klist klist: No credentials cache found (ticket cache FILE:/var/adm/krb5/tmp/tkt/krb5cc_3258_xQK9wc) ... [EMAIL PROTECTED] ~ $ kinit -f -k -t /var/adm/krb5/quickauth/kt/koczan.mail.kt -l 1d koczan/[EMAIL PROTECTED] [EMAIL PROTECTED] ~ $ klist Ticket cache: FILE:/var/adm/krb5/tmp/tkt/krb5cc_3258_xQK9wc Default principal: koczan/[EMAIL PROTECTED] ... Connecting to an 8.2 server works just fine... [EMAIL PROTECTED] ~ $ /s/postgresql-8.3/bin/psql -h sensei -p 5432 sushi Welcome to psql 8.3.1 (server 8.2.6), the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit WARNING: You are connected to a server with major version 8.2, but your psql client is major version 8.3. Some backslash commands, such as \d, might not work properly. SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) sushi=> select version(); version PostgreSQL 8.2.6 on i686-pc-linux-gnu, compiled by GCC gcc.bin (GCC) 3.4.4 (1 row) sushi=> select current_user; current_user -- koczan (1 row) However, connecting to an 8.3 server... [EMAIL PROTECTED] ~ $ /s/postgresql-8.3/bin/psql -h sensei -p 49173 sushi psql: FATAL: no pg_hba.conf entry for host "128.105.162.36", user "koczan", database "sushi", SSL off And this shows up in the syslog... Apr 23 12:02:41 sensei postgres[23100]: [3-1] LOG: connection received: host=ator.cs.wisc.edu port=49188 Apr 23 12:02:41 sensei postgres[23100]: [4-1] LOG: unexpected Kerberos user name received from client (received "koczan", expected "koczan/mail") Apr 23 12:02:41 sensei postgres[23100]: [5-1] FATAL: Kerberos 5 authentication failed for user "koczan" Apr 23 12:02:41 sensei postgres[23101]: [3-1] LOG: connection received: host=ator.cs.wisc.edu port=49189 Apr 23 12:02:41 sensei postgres[23101]: [4-1] FATAL: no pg_hba.conf entry for host "128.105.162.36", user "koczan", database "sushi", SSL off The appropriate line in pg_hba.conf shows hostssl all all 128.105.0.0/16 krb5 I'm connecting via
[BUGS] problem
Hello, help me please, I don't know how, but i got 2 postgres users. How can I delete the first one thx alot for your answers. /// select passwd,ctid,xmin,xmax,cmin,cmax from pg_shadow where usesysid =1; passwd| ctid | xmin | xmax | cmin | cmax -+---+--+--+--+- - | (0,1) |1 | 16754522 | 16754522 |0 md510db8c04d26d32185270721fcf32155 | (0,2) |2 |0 |0 |0 (2 rows) // select * from pg_shadow where usesysid=1; usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig --+--+-+--+---+- +--+--- postgres |1 | t | t| t | | | postgres |1 | t | t| t | md510db8c04d231142d5 270721fcf740ed5 | infinity | (2 rows) Tom Lane пишет: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: I have two "postgres" user. How to delete the first one ??? Let's see the system columns (ctid,xmin,xmax,cmin,cmax) for those two rows? 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
