Re: [BUGS] Re: BUG #4123: Statement.setQueryTimeout does not work with Postgres Java Driver
On Wed, 23 Apr 2008, valgog wrote:
Is it possible to implement the setStatementTimeout() as somethig
like:
s = c.prepareStatement("SELECT set_config('statement_timeout',
, false);" );
s.executeQuery();
c.commit();
Not really. This sets a global timeout for all queries while the JDBC API
specifies that it is per-Statement. Also this only protects against long
running queries. Recently there was some discussion on the JDBC list
about soft vs hard timeouts and it seemed the conclusion was that people
wanted setQueryTimeout to protect against things like the network
connection dropping that statement_timeout can't do.
In many cases statement_timeout is an adequate substitute for
setQueryTimeout, but not in the general case that the JDBC driver must
implement.
Kris Jurka
--
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
how to dump it ??? pg_dump is not working : pg_dump: query to obtain list of schemas failed: ERROR: more than one row returned by a subquery used as an expression Tom Lane пишет: 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 #4127: pg_dumpall -c unable to be restored without error
The following bug has been logged online: Bug reference: 4127 Logged by: Jacob Champlin Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.11 Operating system: SuSE 10.1 Description:pg_dumpall -c unable to be restored without error Details: In 8.0 I would do a pg_dumpall -c to backup my database. In 8.1 you guys have added functionality to the -c flag to make it now DROP and Recreate Roles. Nice feature and seems to be the right thing to do. However, with the DROP Roles in the file this causes the file to not be able to be restored. psql -f restore.sql results in: psql:/var/lib/pgsql/backups/restore.sql:11: ERROR: current user cannot be dropped psql:/var/lib/pgsql/backups/restore.sql:12: ERROR: role "postgres" already exists psql:/var/lib/pgsql/backups/restore.sql:17: ERROR: role "webapp" cannot be dropped because some objects depend on it DETAIL: access to database rief 113 objects in database rief psql:/var/lib/pgsql/backups/restore.sql:18: ERROR: role "webapp" already exists -- 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 #4127: pg_dumpall -c unable to be restored without error
"Jacob Champlin" <[EMAIL PROTECTED]> writes: > psql -f restore.sql > results in: > psql:/var/lib/pgsql/backups/restore.sql:11: ERROR: current user cannot be > dropped > psql:/var/lib/pgsql/backups/restore.sql:12: ERROR: role "postgres" already > exists > psql:/var/lib/pgsql/backups/restore.sql:17: ERROR: role "webapp" cannot be > dropped because some objects depend on it > DETAIL: access to database rief > 113 objects in database rief > psql:/var/lib/pgsql/backups/restore.sql:18: ERROR: role "webapp" already > exists And? The restore would've proceeded anyway. 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 #4127: pg_dumpall -c unable to be restored without error
And if this is expected correct behavior it shouldn't throw an error This is especially problematic for automated processes, in which you only want to know when they fail. Its possible to ignore error messages, but then when something real does go wrong you lose those. Don't get me wrong I know this is not the end of the world, but I also think its the wrong behavior, one that is problematic for me. Jacob Tom Lane wrote: "Jacob Champlin" <[EMAIL PROTECTED]> writes: psql -f restore.sql results in: psql:/var/lib/pgsql/backups/restore.sql:11: ERROR: current user cannot be dropped psql:/var/lib/pgsql/backups/restore.sql:12: ERROR: role "postgres" already exists psql:/var/lib/pgsql/backups/restore.sql:17: ERROR: role "webapp" cannot be dropped because some objects depend on it DETAIL: access to database rief 113 objects in database rief psql:/var/lib/pgsql/backups/restore.sql:18: ERROR: role "webapp" already exists And? The restore would've proceeded anyway. 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 #4128: The postmaster.opts.default file is begin ignored
The following bug has been logged online: Bug reference: 4128 Logged by: Gary Jay Peters Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: Linux/Debian Description:The postmaster.opts.default file is begin ignored Details: 1st, I already have a work-round, but I wanted to let someone know about the problem. 2nd, we are installing from source code and compiling the application ourselves. The problem -- As I understand it, the only the "pg_ctl" command uses the "postmaster.opts.default" file; it uses the arguments within "postmaster.opts.default" when spawning the "postmaster" process. In older versions (such as "7.4.2"), the file "postgresql-X.X.X/contrib/start-scripts/linux" uses "pg_ctl" (see variable "DAEMON") to start the "postmaster" process. Because of this, the arguments within the "postmaster.opts.default" file are use. In newer version (I am using "8.2.5", but "8.3.1" appears to handle it the same way), the file "postgresql-X.X.X/contrib/start-scripts/linux" does not use "pg_ctl" (see variable "PGCTL") to start the "postmaster" process. Because of this, the arguments within the "postmaster.opts.default" file are ignored. Quickly looking through the source code, I found that the only file to reference "postmaster.opts.default" is "/postgresql-X.X.X/src/bin/pg_ctl/pg_ctl.c". My work-around is to mutate the "postgresql-X.X.X/contrib/start-scripts/linux" file adding a line "DAEMON_START_ARGS=`[ -f $PGDATA/postmaster.opts.default ] && cat $PGDATA/postmaster.opts.default`" and then changing each occurrence of "$DAEMON -D '$PGDATA'" to "$DAEMON $DAEMON_START_ARGS -D '$PGDATA'". Lastly, to quote from the "postgresql-X.X.X/contrib/start-scripts/linux" file, "What to use to start up the postmaster (we do NOT use pg_ctl for this, as it adds no value and can cause the postmaster to misrecognize a stale lock file)". Gary Jay Peters Database Management Services / HomeCU (877) 670-2984 x 12 [EMAIL PROTECTED] -- 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 #4128: The postmaster.opts.default file is begin ignored
"Gary Jay Peters" <[EMAIL PROTECTED]> writes: > As I understand it, the only the "pg_ctl" command uses the > "postmaster.opts.default" file; it uses the arguments > within "postmaster.opts.default" when spawning the "postmaster" process. Actually, I'd vote for ripping out that "feature" altogether. That file has nothing whatever to recommend it, compared to editing postgresql.conf --- it's no easier certainly, and you'll never be able to change any options it sets without a postmaster restart. We've mostly deprecated setting options on the postmaster command line already, so why do we need another obscure way to do 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] BUG #4128: The postmaster.opts.default file is begin ignored
Tom Lane wrote: > "Gary Jay Peters" <[EMAIL PROTECTED]> writes: > > As I understand it, the only the "pg_ctl" command uses the > > "postmaster.opts.default" file; it uses the arguments > > within "postmaster.opts.default" when spawning the "postmaster" process. > > Actually, I'd vote for ripping out that "feature" altogether. I was about to say the same thing. I was surprised to find that it's still documented. -- 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 #4128: The postmaster.opts.default file is begin ignored
Tom Lane wrote: > We've mostly deprecated setting options on the postmaster command > line already, so why do we need another obscure way to do that? As long as we support the pg_ctl -o option, the file still necessary so that you get the same options after a restart. -- 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 #4126: KRB5/GSSAPI authenication fails for multipart kerberos principals
> From: "Peter Koczan" <[EMAIL PROTECTED]>
> To: pgsql-bugs@postgresql.org
> Date: Wed, 23 Apr 2008 17:17:01 GMT
> Subject: BUG #4126: KRB5/GSSAPI authenication fails for multipart kerberos
> principals
>
> 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.
I poked around the code a bit, and found something interesting in
src/backend/libpq/auth.c. Apparently, in 8.2, the kerberos username
gets transformed from a full authentication name to a local
authentication name before being compared to the received name (using
pg_an_to_ln), but in 8.3, this transformation doesn't happen, causing
a name mismatch and therefore an authentication failure. Putting this
back in "worked", in that now the names match, and
"wsbackup/ator.cs.wisc.edu" connects to the database as "wsbackup."
Reading the comment for pg_an_to_ln, I understand that it might be
best in the long run for this behavior to change (some sort of
principal mapping or saying that multipart principals should have
different database roles). However, right now it is a bug because it's
an authentication failure with no discernible workaround. I tried
creating a "wsbackup/ator.cs.wisc.edu" role in my database, but it
still failed because it wasn't even getting to the point of checking
roles in the database.
In any case, here's a patch to src/backend/libpq/auth.c that puts back
the old behavior for krb5 and gss authentication. I didn't check or
modify other auth methods because I don't use them.
Peter
Index: src/backend/libpq/auth.c
===
RCS file:
/s/postgresql-8.3.1/src/CVSROOT/postgresql-8.3.1/src/backend/libpq/auth.c,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 auth.c
*** src/backend/libpq/auth.c31 Mar 2008 20:26:15 - 1.1.1.1
--- src/backend/libpq/auth.c24 Apr 2008 18:00:59 -
***
*** 104,109
--- 104,132
#endif
/*
+ * pg_an_to_ln -- return the local name corresponding to an authentication
+ * name
+ *
+ * XXX Assumes that the first aname component is the user name. This is NOT
+ * necessarily so, since an aname can actually be something out of your
+ * worst X.400 nightmare, like
+ * ORGANIZATION=U. C. Berkeley/NAME=Paul M. [EMAIL PROTECTED]
+ * Note that the MIT an_to_ln code does the same thing if you don't
+ * provide an aname mapping database...it may be a better idea to use
+ * krb5_an_to_ln, except that it punts if multiple components are found,
+ * and we can't afford to punt.
+ */
+ static char *
+ pg_an_to_ln(char *aname)
+ {
+ char *p;
+
+ if ((p = strchr(aname, '/')) || (p = strchr(aname, '@')))
+ *p = '\0';
+ return aname;
+ }
+
+ /*
* Various krb5 state which is not connection specfic, and a flag to
* indicate whether we have initialised it yet.
*/
***
*** 275,280
--- 298,304
return STATUS_ERROR;
}
+ kusername = pg_an_to_ln(kusername);
if (pg_krb_caseins_users)
ret = pg_strncasecmp(port->user_name, kusername,
SM_DATABASE_USER);
else
***
*** 588,593
--- 612,618
return STATUS_ERROR;
}
+ gbuf.value = pg_an_to_ln(gbuf.value);
if (pg_krb_caseins_users)
ret = pg_strcasecmp(port->user_name, gbuf.value);
else
--
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 #4128: The postmaster.opts.default file is begin ignored
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> We've mostly deprecated setting options on the postmaster command >> line already, so why do we need another obscure way to do that? > As long as we support the pg_ctl -o option, the file still necessary so that > you get the same options after a restart. No, it's the "postmaster.opts.default" file that I'm complaining about, not the postmaster.opts file. 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
