Re: [BUGS] rollback to savepoint leads to transaction already in progress
On 14/10/10 12:14, Itagaki Takahiro wrote: Which solution is better? Or, another idea? This does seem to be an new bug in previously working code. While any solution that fixes the problem is good, it might pay to look the code that worked before. As reported, it worked for ecpg (PostgreSQL 8.3.8) 4.4.1. -- 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] rollback to savepoint leads to transaction already in progress
On Thu, Oct 14, 2010 at 3:52 PM, David Newall wrote: > This does seem to be an new bug in previously working code. While any > solution that fixes the problem is good, it might pay to look the code that > worked before. As reported, it worked for ecpg (PostgreSQL 8.3.8) 4.4.1. It works on 8.3, but it's still broken. Here is the code in 8.3. It ignores "ROLLBACK TO savepoint", but also ignores "ROLLBACK TRANSACTION". if (strcmp(transaction, "commit") == 0 || strcmp(transaction, "rollback") == 0) con->committed = true; else con->committed = false; -- Itagaki Takahiro -- 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] libpq: system-wide root.crt
On Sat, Sep 25, 2010 at 3:38 PM, Peter Eisentraut wrote: > On fre, 2010-09-24 at 09:50 +0200, Magnus Hagander wrote: >> > I'm thinking, libpq could really use a global (and, for that matter, a >> > per-user) configuration file, where you could set defaults for some of >> > the things that you currently have to use environment variables for, >> > e.g., sslmode. And then you can configure the system-wide root.crt >> > location there. >> >> We already have this - pg_service.conf - no? > > Indeed. > >> > Alternatively, if you think that that is overkill, then using an >> > environment variable to configure this feature would be consistent with >> > the existing mechanisms. >> >> So in this case, a "sslfallbackroot=/etc/somewhere" parameter, that >> you could then stick in etc/pg_service.conf, or in any of the other >> places you can specify it? The one thing I think would be really >> needed for that to work is to support wildcard database names in >> pg_service.conf? > > Yes. What I gather from the discussion on this thread is that this patch needs to be revised before it can be considered for commit, so I'm going to mark it as Returned with Feedback in the CommitFest application. Hopefully, it will be revised and resubmitted for the then-current open CommitFest, which can always be found at: https://commitfest.postgresql.org/action/commitfest_view/open -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5694: Postgres ODBC SQLTables is not working correctly
On Tue, Oct 5, 2010 at 11:56 AM, Xiaohui Xue wrote: > > The following bug has been logged online: > > Bug reference: 5694 > Logged by: Xiaohui Xue > Email address: xiaohui@sap.com > PostgreSQL version: 8.3.4 > Operating system: Windows > Description: Postgres ODBC SQLTables is not working correctly > Details: > > Hi, > > I'm using PostgreSQL ODBC Unicode (version 8.01.02.00) to connect to a > PostgreSQL server (version 8.3.4). > > Following ODBC specification, when ODBC SQLTables is called with > - SchemaName is SQL_ALL_SCHEMAS > - CatalogName and TableName are empty strings > the result set contains a list of valid schemas for the data source. (All > columns except the TABLE_SCHEM column contain NULLs.) > http://msdn.microsoft.com/en-us/library/ms711831%28VS.85%29.aspx > > But PostgreSQL ODBC returns still the list of tables. As result, we get a > list of duplicated schemas, as many times as the number of the tables in the > schema. You may want to report this problem here: http://archives.postgresql.org/pgsql-odbc/ This list is for bugs in core PostgreSQL. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] rollback to savepoint leads to transaction already in progress
Am 14.10.2010 08:52, schrieb David Newall: On 14/10/10 12:14, Itagaki Takahiro wrote: Which solution is better? Or, another idea? This does seem to be an new bug in previously working code. While any solution that fixes the problem is good, it might pay to look the code that worked before. As reported, it worked for ecpg (PostgreSQL 8.3.8) 4.4.1. You seem to be answering to an email that I didn't see and couldn't find in the archive either. Was it send in private or to the list? If it went to the list I might be lagging behind. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- 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] rollback to savepoint leads to transaction already in progress
On Thu, Oct 14, 2010 at 6:53 AM, Michael Meskes wrote: > Am 14.10.2010 08:52, schrieb David Newall: >> >> On 14/10/10 12:14, Itagaki Takahiro wrote: >>> >>> Which solution is better? Or, another idea? >> >> This does seem to be an new bug in previously working code. While any >> solution that fixes the problem is good, it might pay to look the code >> that worked before. As reported, it worked for ecpg (PostgreSQL 8.3.8) >> 4.4.1. > > You seem to be answering to an email that I didn't see and couldn't find in > the archive either. Was it send in private or to the list? If it went to the > list I might be lagging behind. I didn't get it either. The original report was posted to pgsql-bugs on October 10. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] rollback to savepoint leads to transaction already in progress
On Mon, Oct 11, 2010 at 7:42 AM, David Newall
wrote:
> Trivial program to demonstrate problem:
>
> main() {
> ECPGdebug(1,stderr);
> exec sql connect to postgres;
> exec sql set autocommit to off;
> exec sql start transaction;
> exec sql savepoint s;
> exec sql rollback to s;
> exec sql commit;
> return 0;
> }
>
> Output:
> [28397]: ECPGdebug: set to 1
> [28397]: ECPGconnect: opening database postgres on port
> [28397]: ECPGsetcommit on line 4: action "off"; connection "postgres"
> [28397]: ECPGtrans on line 5: action "start transaction"; connection
> "postgres"
> [28397]: ECPGtrans on line 6: action "savepoint s"; connection "postgres"
> [28397]: ECPGtrans on line 7: action "rollback to s"; connection "postgres"
> [28397]: ECPGtrans on line 8: action "commit"; connection "postgres"
> [28397]: ECPGnoticeReceiver: there is already a transaction in progress
> [28397]: raising sqlcode -603
>
> Problem:
> It shouldn't raise "there is already a transaction in progress" error,
> particularly when doing a commit. Remove "rollback to s" and no problem.
>
> Environment:
> ecpg (PostgreSQL 8.4.5) 4.5.0
> This appears to be a regression; it doesn't occur with ecpg (PostgreSQL
> 8.3.8) 4.4.1
The bug comes from string-based transaction control in ECPGtrans().
The code cannot distinguish ROLLBACK TRANSACTION and ROLLBACK TO savepoint.
if (strncmp(transaction, "commit", 6) == 0 || strncmp(transaction,
"rollback", 8) == 0)
con->committed = true;
else
con->committed = false;
I think the string-comparison is unreliable. So, I'd like to replace
the code to use PQtransactionStatus(). I have two patches to do it:
The first one (ecpg-trans-quick_20101014.patch) is a quick fix
that replaces only the above test.
The second one (ecpg-trans-full_20101014.patch) replaces all of
struct connection->committed with PQtransactionStatus().
Which solution is better? Or, another idea?
--
Itagaki Takahiro
ecpg-trans-full_20101014.patch
Description: Binary data
ecpg-trans-quick_20101014.patch
Description: Binary data
--
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 #5709: PostgreSQL server 8.4.5 does not compile with gcc 4.5
The following bug has been logged online: Bug reference: 5709 Logged by: Daniel Gerzo Email address: dan...@freebsd.org PostgreSQL version: 8.4.5 Operating system: FreeBSD Description:PostgreSQL server 8.4.5 does not compile with gcc 4.5 Details: This is the error I get: gmake[1]: Leaving directory `/usr/ports/databases/postgresql84-server/work/postgresql-8.4.5/src/timezone ' gcc45 -O2 -pipe -Wl,-rpath=/usr/local/lib/gcc45 -O3 -flto -march=nocona -O3 -funroll-loops -fno-strict-aliasing -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -L../../src/port -Wl,-rpath=/usr/local/lib/gcc45 -O3 -flto -L/usr/local/lib -rpath=/usr/lib:/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -Wl,--as-needed -Wl,-R'/usr/local/lib' -Wl,-export-dynamic access/common/heaptuple.o access/common/indextuple.o access/common/printtup.o access/common/reloptions.o access/common/scankey.o access/common/tupdesc.o access/gist/gist.o access/gist/gistutil.o access/gist/gistxlog.o access/gist/gistvacuum.o access/gist/gistget.o access/gist/gistscan.o access/gist/gistproc.o access/gist/gistsplit.o access/hash/hash.o access/hash/hashfunc.o access/hash/hashinsert.o access/hash/hashovfl.o access/hash/hashpage.o access/hash/hashscan.o access/hash/hashsearch.o access/hash/hashsort.o access/hash/hashutil.o access/heap/heapam.o access/heap/hio.o access/heap/pruneheap.o access/heap/rewriteheap.o access/heap/syncscan.o access/heap/tuptoaster.o access/heap/visibilitymap.o access/index/genam.o access/index/indexam.o access/nbtree/nbtcompare.o access/nbtree/nbtinsert.o access/nbtree/nbtpage.o access/nbtree/nbtree.o access/nbtree/nbtsearch.o access/nbtree/nbtutils.o access/nbtree/nbtsort.o access/nbtree/nbtxlog.o access/transam/clog.o access/transam/transam.o access/transam/varsup.o access/transam/xact.o access/transam/xlog.o access/transam/xlogutils.o access/transam/rmgr.o access/transam/slru.o access/transam/subtrans.o access/transam/multixact.o access/transam/twophase.o access/transam/twophase_rmgr.o access/gin/ginutil.o access/gin/gininsert.o access/gin/ginxlog.o access/gin/ginentrypage.o access/gin/gindatapage.o access/gin/ginbtree.o access/gin/ginscan.o access/gin/ginget.o access/gin/ginvacuum.o access/gin/ginarrayproc.o access/gin/ginbulk.o access/gin/ginfast.o bootstrap/bootparse.o bootstrap/bootstrap.o catalog/catalog.o catalog/dependency.o catalog/heap.o catalog/index.o catalog/indexing.o catalog/namespace.o catalog/aclchk.o catalog/pg_aggregate.o catalog/pg_constraint.o catalog/pg_conversion.o catalog/pg_depend.o catalog/pg_enum.o catalog/pg_inherits.o catalog/pg_largeobject.o catalog/pg_namespace.o catalog/pg_operator.o catalog/pg_proc.o catalog/pg_shdepend.o catalog/pg_type.o catalog/storage.o catalog/toasting.o parser/analyze.o parser/gram.o parser/keywords.o parser/parser.o parser/parse_agg.o parser/parse_cte.o parser/parse_clause.o parser/parse_expr.o parser/parse_func.o parser/parse_node.o parser/parse_oper.o parser/parse_relation.o parser/parse_type.o parser/parse_coerce.o parser/parse_target.o parser/parse_utilcmd.o parser/scansup.o parser/kwlookup.o commands/aggregatecmds.o commands/alter.o commands/analyze.o commands/async.o commands/cluster.o commands/comment.o commands/conversioncmds.o commands/copy.o commands/dbcommands.o commands/define.o commands/discard.o commands/explain.o commands/foreigncmds.o commands/functioncmds.o commands/indexcmds.o commands/lockcmds.o commands/operatorcmds.o commands/opclasscmds.o commands/portalcmds.o commands/prepare.o commands/proclang.o commands/schemacmds.o commands/sequence.o commands/tablecmds.o commands/tablespace.o commands/trigger.o commands/tsearchcmds.o commands/typecmds.o commands/user.o commands/vacuum.o commands/vacuumlazy.o commands/variable.o commands/view.o executor/execAmi.o executor/execCurrent.o executor/execGrouping.o executor/execJunk.o executor/execMain.o executor/execProcnode.o executor/execQual.o executor/execScan.o executor/execTuples.o executor/execUtils.o executor/functions.o executor/instrument.o executor/nodeAppend.o executor/nodeAgg.o executor/nodeBitmapAnd.o executor/nodeBitmapOr.o executor/nodeBitmapHeapscan.o executor/nodeBitmapIndexscan.o executor/nodeHash.o executor/nodeHashjoin.o executor/nodeIndexscan.o executor/nodeMaterial.o executor/nodeMergejoin.o executor/nodeNestloop.o executor/nodeFunctionscan.o executor/nodeRecursiveunion.o executor/nodeResult.o executor/nodeSeqscan.o executor/nodeSetOp.o executor/nodeSort.o executor/nodeUnique.o executor/nodeValuesscan.o executor/nodeCtescan.o executor/nodeWorktablescan.o executor/nodeLimit.o executor/nodeGroup.o executor/nodeSubplan.o executor/nodeSubqueryscan.o executor/nodeTidscan.o executor/nodeWindowAgg.o executor/tstoreReceiver.o executor/spi.o foreign/foreign.o lib/dllist.o lib/stringinfo.o libpq/be-fsstubs.o libpq/be-secure.o libpq/auth.o libpq/crypt.o libpq/hba.o libpq/ip.o libpq/md
Re: [BUGS] BUG #5709: PostgreSQL server 8.4.5 does not compile with gcc 4.5
"Daniel Gerzo" writes: > libpq/auth.o: In function `pg_GSS_error.clone.2': > auth.c:(.text+0x1a9): undefined reference to `gss_display_status' > auth.c:(.text+0x1d1): undefined reference to `gss_release_buffer' > auth.c:(.text+0x203): undefined reference to `gss_display_status' > auth.c:(.text+0x223): undefined reference to `gss_release_buffer' > libpq/auth.o: In function `ClientAuthentication': > auth.c:(.text+0x704): undefined reference to `gss_accept_sec_context' > auth.c:(.text+0x787): undefined reference to `gss_delete_sec_context' > auth.c:(.text+0x7b4): undefined reference to `gss_release_cred' > auth.c:(.text+0x7cc): undefined reference to `gss_display_name' > auth.c:(.text+0xa46): undefined reference to `gss_release_buffer' > auth.c:(.text+0xb1d): undefined reference to `gss_release_buffer' > auth.c:(.text+0xd19): undefined reference to `gss_release_buffer' > auth.c:(.text+0x110b): undefined reference to `gss_release_buffer' > libpq/pqcomm.o: In function `pq_close': > pqcomm.c:(.text+0x14e): undefined reference to `gss_delete_sec_context' > pqcomm.c:(.text+0x171): undefined reference to `gss_release_cred' > collect2: ld returned 1 exit status > gmake: *** [postgres] Error 1 This is not a compiler issue, it's a library issue. Apparently you did --with-gssapi but your gssapi library doesn't actually work, or at least doesn't work the way Postgres is expecting. I'd suggest leaving off that configure option --- unless you really need it, in which case you're going to have to track down the reason for the incompatibility. 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] rollback to savepoint leads to transaction already in progress
Takahiro-san, I think the string-comparison is unreliable. So, I'd like to replace the code to use PQtransactionStatus(). I have two patches to do it: The first one (ecpg-trans-quick_20101014.patch) is a quick fix that replaces only the above test. The second one (ecpg-trans-full_20101014.patch) replaces all of struct connection->committed with PQtransactionStatus(). Which solution is better? Or, another idea? The full solution is the better one, but I'd prefer to not apply it to the stable versions as there's a slight chance it might break something. So that means I'd apply full for HEAD and quick for 9.0 and 8.4. Will you commit this? Or shall I? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- 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] rollback to savepoint leads to transaction already in progress
On Thu, Oct 14, 2010 at 6:53 AM, Michael Meskes wrote:
You seem to be answering to an email that I didn't see and couldn't find in
the archive either. Was it send in private or to the list? If it went to the
list I might be lagging behind.
On 14/10/10 22:51, Robert Haas wrote:
I didn't get it either. The original report was posted to pgsql-bugs
on October 10.
It might be lag; it'll probably turn up, about 6 seconds after I press *S
Original Message
Subject:Re: [BUGS] rollback to savepoint leads to transaction already
in progress
Date: Thu, 14 Oct 2010 10:44:50 +0900
From: Itagaki Takahiro
To: David Newall, PostgreSQL Hackers
CC: pgsql-bugs@postgresql.org
On Mon, Oct 11, 2010 at 7:42 AM, David Newall
wrote:
Trivial program to demonstrate problem:
main() {
ECPGdebug(1,stderr);
exec sql connect to postgres;
exec sql set autocommit to off;
exec sql start transaction;
exec sql savepoint s;
exec sql rollback to s;
exec sql commit;
return 0;
}
Output:
[28397]: ECPGdebug: set to 1
[28397]: ECPGconnect: opening database postgres on port
[28397]: ECPGsetcommit on line 4: action "off"; connection "postgres"
[28397]: ECPGtrans on line 5: action "start transaction"; connection
"postgres"
[28397]: ECPGtrans on line 6: action "savepoint s"; connection "postgres"
[28397]: ECPGtrans on line 7: action "rollback to s"; connection "postgres"
[28397]: ECPGtrans on line 8: action "commit"; connection "postgres"
[28397]: ECPGnoticeReceiver: there is already a transaction in progress
[28397]: raising sqlcode -603
Problem:
It shouldn't raise "there is already a transaction in progress" error,
particularly when doing a commit. Remove "rollback to s" and no problem.
Environment:
ecpg (PostgreSQL 8.4.5) 4.5.0
This appears to be a regression; it doesn't occur with ecpg (PostgreSQL
8.3.8) 4.4.1
The bug comes from string-based transaction control in ECPGtrans().
The code cannot distinguish ROLLBACK TRANSACTION and ROLLBACK TO savepoint.
if (strncmp(transaction, "commit", 6) == 0 || strncmp(transaction,
"rollback", 8) == 0)
con->committed = true;
else
con->committed = false;
I think the string-comparison is unreliable. So, I'd like to replace
the code to use PQtransactionStatus(). I have two patches to do it:
The first one (ecpg-trans-quick_20101014.patch) is a quick fix
that replaces only the above test.
The second one (ecpg-trans-full_20101014.patch) replaces all of
struct connection->committed with PQtransactionStatus().
Which solution is better? Or, another idea?
--
Itagaki Takahiro
--
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 #5710: lock requires unintuitive privileges
The following bug has been logged online: Bug reference: 5710 Logged by: Email address: mstone+postg...@mathom.us PostgreSQL version: 8.4.5 Operating system: Ubuntu Description:lock requires unintuitive privileges Details: I haven't been able to find specific documentation on what privileges are required to use various levels of the LOCK command. A comment somewhere in the interactive documentation (can't find it again) said that UPDATE is required for ROW EXCLUSIVE, which does seem to match reality. But the documentation in section 13.3 says that a ROW EXCLUSIVE lock is implicitly granted for "UPDATE, DELETE, and INSERT" -- which begs the question of why UPDATE is required for the explicit lock and INSERT is not sufficient. I'm not sure if this is a bug or a feature; if the latter I'd suggest that synchronizing the privileges required for explicit and implicit locks would be helpful. -- 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 #5650: Postgres service showing as stopped when in fact it is running
Robert Haas wrote: > On Mon, Sep 27, 2010 at 12:44 PM, Ashesh Vashi < > ashesh.va...@enterprisedb.com> wrote: > > > We're happy to see the problem resolved on your end. :-)-- > > > > However, it doesn't seem that we've actually done anything about the > underlying issue with pg_ctl. I will look at that in the next few weeks. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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 #5682: Postgres Service crashes with exception 0xC0000135
Craig Ringer wrote: > On 29/09/2010 5:11 PM, aswin jayaraman wrote: > > I ll try that out.Is there means to do an upgrade to 8.3 to 8.4/9.0 with > > the data in place? > > No, it requires a dump and reload. Sorry. You'll want to read the > release notes, as there have been changes between 8.3 and 9.0 that may > affect applications. > > http://www.postgresql.org/docs/9/static/release-8-4.html > http://www.postgresql.org/docs/9/static/release-9-0.html > > PostgreSQL has seen significant improvements in the Windows port, so > it's worth the update. I unfortunately cannot promise that it'll fix the > issue you're having, though. pg_upgrade works for upgrades from 8.3 to 9.0. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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 #5711: input out of error with haversine formual
The following bug has been logged online: Bug reference: 5711 Logged by: Vince Email address: vincecar...@gmail.com PostgreSQL version: 8.4 Operating system: Linux Description:input out of error with haversine formual Details: The following will return an input out of error as the acos() function cannot be -1 <= x <= 1. SELECT * FROM (SELECT *, (3959 * acos(cos(radians(37.7438640)) * cos(radians(37.7438640)) * cos(radians(-97.4631299) - radians(-97.4631299)) + sin(radians(37.7438640)) * sin(radians(37.7438640 AS distance FROM foo) AS distances WHERE distance < 10 ORDER BY distance If I break this down the following returns 1: SELECT (cos(radians(37.7438640)) * cos(radians(37.7438640)) * cos(radians(-97.4631299) - radians(-97.4631299)) + sin(radians(37.7438640)) * sin(radians(37.743864000))); acos(1) would give me 0. Thoughts? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
