Re: [BUGS] BUG #6406: Included pgAdmin does not have .sql file extension mapped
On Mon, 2012-01-23 at 01:08 +, a...@arencambre.com wrote: > The following bug has been logged on the website: > > Bug reference: 6406 > Logged by: Aren Cambre > Email address: a...@arencambre.com > PostgreSQL version: 9.1.2 > Operating system: Windows 7 x64 > Description: > > When I install Postgres, the included pgAdmin III is not set up correctly: > the installer does not associate .sql file extensions with pgAdmin III, so > when I double-click on a .sql file, or even right-click on it and select > "Open with", pgAdmin III doesn't even show as an option. > > I checked with pgAdmin III developers, and with them, I confirmed that the > pgAdmin III installer, as downloaded from their own site, indeed sets up > file extensions correctly. Guillaume Lelarge of pgAdmin dev team suspects it > may be a problem with how you've bundled pgAdmin III with Postgres. > And I also said you should complain to the packager which is EnterpriseDB, not the PostgreSQL developers. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com PostgreSQL Sessions #3: http://www.postgresql-sessions.org -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Different error messages executing CREATE TABLE or ALTER TABLE to create a column "xmin"
Hi all, trying to create a table with a column xmin I get the following error message: test=> create table lx (xmin int); ERROR: column name "xmin" conflicts with a system column name Instead I get a different (and less understandable) error message if I try to add a column named xmin to an existent table: test=> create table lx (i int); CREATE TABLE test=> alter table lx add xmin int; ERROR: column "xmin" of relation "lx" already exists. The same problem occurs using "xmax" as column name. I'm on Ubuntu 11.04. Tried on both PostgreSQL 8.4.10 and 9.1.2 Regards. -- Giuseppe Sucameli -- 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] Different error messages executing CREATE TABLE or ALTER TABLE to create a column "xmin"
Am 22.01.12 14:22, schrieb Giuseppe Sucameli: > Hi all, > > trying to create a table with a column xmin I get the > following error message: > > test=> create table lx (xmin int); > ERROR: column name "xmin" conflicts with a system > column name > > Instead I get a different (and less understandable) error > message if I try to add a column named xmin to an > existent table: > > test=> create table lx (i int); > CREATE TABLE > test=> alter table lx add xmin int; > ERROR: column "xmin" of relation "lx" already exists. > > The same problem occurs using "xmax" as column name. > > I'm on Ubuntu 11.04. > Tried on both PostgreSQL 8.4.10 and 9.1.2 That is not a bug, but a feature. See section 5.4 of the documentation "System Columns": "Every table has several system columns that are implicitly defined by the system. Therefore, these names cannot be used as names of user-defined columns. (Note that these restrictions are separate from whether the name is a key word or not; quoting a name will not allow you to escape these restrictions.) You do not really need to be concerned about these columns; just know they exist." and further down: "xmin The identity (transaction ID) of the inserting transaction for this row version. (A row version is an individual state of a row; each update of a row creates a new row version for the same logical row.)" -- 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] Different error messages executing CREATE TABLE or ALTER TABLE to create a column "xmin"
On Mon, Jan 23, 2012 at 11:25, Marc Balmer wrote: > Am 22.01.12 14:22, schrieb Giuseppe Sucameli: > > test=> create table lx (xmin int); > > ERROR: column name "xmin" conflicts with a system > > column name > > > > test=> create table lx (i int); > > CREATE TABLE > > test=> alter table lx add xmin int; > > ERROR: column "xmin" of relation "lx" already exists. > > That is not a bug, but a feature. > I see it as a message bug. Why wouldn't ALTER TABLE also tell us that xmin is a system column? It makes things much more clear for newbies who don't see the column yet are told it exists if they're also told it's a system column. I would try to cook up a patch but I have no skills :-(
[BUGS] pgcrypto decrypt_iv() issue
We are using the raw decryption features of contrib/pgcrypto here to
decode certain AES128 encrypted data. However depending on the data to
decode and what statements have been executed in the same session before
we are seeing different (and sometimes completely wrong) answers
this is 9.1.2 on Debian/amd64 compiled with -enable-debug (note that the
the first and the third query do not result in the same answer):
mastermind@mastermind:~/playground$ ./pginst/bin/psql -p 5435 postgres
psql (9.1.2)
Type "help" for help.
postgres=# select
encode(decrypt_iv(decode('c89a929fa8dbefaa88609ea3b637d783ce926b8a0985ae02a100c0f89d8a8e5aca793d1519f5829a61b9fbd1d582fb66ff','hex')::bytea,
decode('636F6E73756D6572326772696430','hex')::bytea,
decode('2D4C526240141e029696969696969696','hex')::bytea,
'aes-cbc/pad:none')::bytea, 'hex');
encode
00
(1 row)
postgres=# select
encode(decrypt_iv(decode('c89a929fa8dbefaa88609ea3b637d783ce926b8a0985ae02a100c0f89d8a8e5aca793d1519f5829a61b9fbd1d582fb66','hex')::bytea,
decode('636F6E73756D6572326772696430','hex')::bytea,
decode('2D4C526240141e029696969696969696','hex')::bytea,
'aes-cbc/pad:none')::bytea, 'hex');
encode
--
2f2f066d198694b1030b040369540d0004833c042b330004ab3c2f2f2f2f2f2f2f2f2f2f2f2f
(1 row)
postgres=# select
encode(decrypt_iv(decode('c89a929fa8dbefaa88609ea3b637d783ce926b8a0985ae02a100c0f89d8a8e5aca793d1519f5829a61b9fbd1d582fb66ff','hex')::bytea,
decode('636F6E73756D6572326772696430','hex')::bytea,
decode('2D4C526240141e029696969696969696','hex')::bytea,
'aes-cbc/pad:none')::bytea, 'hex');
encode
2f2f066d198694b1030b040369540d0004833c042b330004ab3c2f2f2f2f2f2f2f2f2f2f2f2f00
(1 row)
on some other 9.1.1 installation(standard debian package) we get:
test=# select
encode(decrypt_iv(decode('c89a929fa8dbefaa88609ea3b637d783ce926b8a0985ae02a100c0f89d8a8e5aca793d1519f5829a61b9fbd1d582fb66ff','hex')::bytea,
decode('636F6E73756D6572326772696430','hex')::bytea,
decode('2D4C526240141e029696969696969696','hex')::bytea,
'aes-cbc/pad:none')::bytea, 'hex'); encode
23002a0a00c69327907f00
(1 row)
test=# select
encode(decrypt_iv(decode('c89a929fa8dbefaa88609ea3b637d783ce926b8a0985ae02a100c0f89d8a8e5aca793d1519f5829a61b9fbd1d582fb66ff','hex')::bytea,
decode('636F6E73756D6572326772696430','hex')::bytea,
decode('2D4C526240141e029696969696969696','hex')::bytea,
'aes-cbc/pad:none')::bytea, 'hex'); encode
190064000300030000
(1 row)
test=# select
encode(decrypt_iv(decode('c89a929fa8dbefaa88609ea3b637d783ce926b8a0985ae02a100c0f89d8a8e5aca793d1519f5829a61b9fbd1d582fb66ff','hex')::bytea,
decode('636F6E73756D6572326772696430','hex')::bytea,
decode('2D4C526240141e029696969696969696','hex')::bytea,
'aes-cbc/pad:none')::bytea, 'hex'); encode
907f40
(1 row)
on 8.3 we even managed to produce(slightly different version of the
query) the following once:
select decrypt_iv(data, key, iv, 'aes-cbc/pad:none') from (select
decode('c89a929fa8dbefaa88609ea3b637d783ce926b8a0985ae02a100c0f89d8a8e5aca793d1519f5829a61b9fbd1d582fb66ff','hex')::bytea
as data, decode('636F6E73756D6572326772696430','hex')::bytea as key,
decode('2D4C526240141e029696969696969696','hex')::bytea as iv) as c;
decrypt_iv
-
/lib/postgresql/8.3/lib/pgcrypto.so\000\012\000\000\000\200\000\000\000\000\000\000\000\000
(1 row)
which seems even more of a "wtf"?!
Stefan
--
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 #6200: standby bad memory allocations on SELECT
Hello, We upgraded to postgres 9.1.2 two weeks ago, and we are also experiencing an issue that seems very similar to the one reported as bug 6200. We see approximately 2 dozen alloc errors per day across 3 slaves, and we are getting one segfault approximately every 3 days. We did not experience this issue before our upgrade (we were on version 8.4, and used skytools for replication). We are attempting to get a core dump on segfault (our last attempt did not work due to a config issue for the core dump). We're also attempting to repro the alloc errors on a test setup, but it seems like we may need quite a bit of load to trigger the issue. We're not certain that the alloc issues and the sefaults are "the same issue" - but it seems that it may be since the OP for bug 6200 sees the same behavior. We have seen no issues on the master, all alloc errors and segfaults have been on the slaves. We've seen the alloc errors on a few different tables, but most frequently on logins. Rows are added to the logins table one-by-one, and updates generally happen one row at a time. The table is pretty basic, it looks like this... CREATE TABLE logins ( login_id bigserial NOT NULL, CONSTRAINT logins_pkey PRIMARY KEY (login_id ), ) WITH ( FILLFACTOR=80, OIDS=FALSE ); The queries that trigger the alloc error on this table look like this (we use hibernate hence the funny underscoring...) select login0_.login_id as login1_468_0_, l... from logins login0_ where login0_.login_id=$1 The alloc error in the logs looks like this: -01-12_080925.log:2012-01-12 17:33:46 PST [16034]: [7-1] [24/25934] ERROR: invalid memory alloc request size 18446744073709551613 The alloc error is nearly always for size 18446744073709551613 - though we have seen one time where it was a different amount... We have been in touch with the OP for bug 6200, who said he may have time to help us out a bit on debugging this. It seems like what is being suggested is getting a build of postgres that will capture a stack trace for each alloc issue and/or simply dump core when that happens. As this is a production system we would prefer the former. As I mentioned above we're also trying to get a core dump for the segfault. We are treating this as extremely high priority as it is currently causing 2 dozen failures for users of our site per day, as well as a few min of downtime for the segfault every 3 days. I realize there may be little that the postgres experts can do until we provide more information - but since our use case is really not very complicated here (basic use of HS), and another site is also experiencing it, I figured it would be worth posting about what we're seeing. Thanks, -Bridget Frey Redfin
[BUGS] Segfault in backend CTE code
Running Postgres 9.1.2. I've attached a backtrace. Looking at the backtrace it looks like ExecGetResultType() gets called with a NULL planstate and causes the segmentation fault: https://github.com/postgres/postgres/blob/master/src/backend/executor/execUtils.c#L470 Following the stack I see that an optimization for writeable CTE's inserts a NULL subplanstate: https://github.com/postgres/postgres/blob/master/src/backend/executor/execMain.c#L2344 ExecInitCteScan() is what eventually passes it to ExecGetResultType(): https://github.com/postgres/postgres/blob/master/src/backend/executor/nodeCtescan.c#L255 I've also attached a proposed fix. In this optimized case it says that we won't ever use the subplan anyway, so I figured that not setting the scan tuple type won't matter. I also added an Assert() to ExecGetResultType(). I modified the declaration of 'slot' to remove a compiler warning. This patch is against master but should backport to 9.1 cleanly. It also passed all regression tests. If you end up using this patch please also credit Rick Pufky who helped me with this. #0 ExecGetResultType (planstate=0x0) at execUtils.c:479 #1 0x005893d9 in ExecInitCteScan (node=0x13d3a30, estate=0x143d6f0, eflags=) at nodeCtescan.c:259 #2 0x00570f75 in ExecInitNode (node=0x0, estate=0x143d6f0, eflags=21224384) at execProcnode.c:227 #3 0x0056e564 in EvalPlanQualStart (epqstate=0x141ea30, parentestate=) at execMain.c:2293 #4 EvalPlanQualBegin (epqstate=0x141ea30, parentestate=) at execMain.c:2144 #5 0x0056ec96 in EvalPlanQual (estate=0x141d6a0, epqstate=0x141ea30, relation=, rti=3, tid=0x7fff46ea4630, priorXmax=) at execMain.c:1710 #6 0x00586e91 in ExecUpdate (node=0x141e990) at nodeModifyTable.c:587 #7 ExecModifyTable (node=0x141e990) at nodeModifyTable.c:838 #8 0x00570d98 in ExecProcNode (node=0x141e990) at execProcnode.c:371 #9 0x0058956c in CteScanNext (node=0x1426a00) at nodeCtescan.c:103 #10 0x00577fce in ExecScanFetch (node=0x1426a00, accessMtd=, recheckMtd=) at execScan.c:82 #11 ExecScan (node=0x1426a00, accessMtd=, recheckMtd=) at execScan.c:167 #12 0x00570ce8 in ExecProcNode (node=0x1426a00) at execProcnode.c:424 #13 0x0058a835 in ExecSetParamPlan (node=0x1430e90, econtext=0x142c3b0) at nodeSubplan.c:922 #14 0x00576bd7 in ExecEvalParamExec (exprstate=, econtext=0x1a30, isNull=0x7fff46ea481f "", isDone=0x1) at execQual.c:990 #15 0x005710cc in ExecEvalNot (notclause=, econtext=0x1a30, isNull=0x7fff46ea481f "", isDone=) at execQual.c:2566 #16 0x005715df in ExecQual (qual=, econtext=0x142c3b0, resultForNull=0 '\000') at execQual.c:5006 #17 0x00587fe6 in ExecResult (node=0x142c2a0) at nodeResult.c:82 #18 0x00570da8 in ExecProcNode (node=0x142c2a0) at execProcnode.c:367 #19 0x00577fce in ExecScanFetch (node=0x1429958, accessMtd=, recheckMtd=) at execScan.c:82 #20 ExecScan (node=0x1429958, accessMtd=, recheckMtd=) at execScan.c:167 #21 0x00570d18 in ExecProcNode (node=0x1429958) at execProcnode.c:412 #22 0x0058653e in ExecModifyTable (node=0x1429048) at nodeModifyTable.c:765 #23 0x00570d98 in ExecProcNode (node=0x1429048) at execProcnode.c:371 #24 0x0056fc32 in ExecutePlan (queryDesc=0x1409670, direction=6704, count=0) at execMain.c:1439 #25 standard_ExecutorRun (queryDesc=0x1409670, direction=6704, count=0) at execMain.c:313 #26 0x7f386af2a68b in explain_ExecutorRun (queryDesc=, direction=, count=) at auto_explain.c:214 #27 0x005913f1 in _SPI_pquery (plan=, paramLI=, snapshot=, crosscheck_snapshot=, read_only=0 '\000', fire_triggers=, tcount=) at spi.c:2110 #28 _SPI_execute_plan (plan=, paramLI=, snapshot=, crosscheck_snapshot=, read_only=0 '\000', fire_triggers=, tcount=) at spi.c:1922 #29 0x005917ac in SPI_execute_plan_with_paramlist (plan=0x1396340, params=, read_only=0 '\000', tcount=) at spi.c:423 #30 0x7f36ddb6f9dd in exec_stmt_execsql (estate=0x7fff46ea4f70, stmt=0x1387350) at pl_exec.c:3036 #31 0x7f36ddb71c6e in exec_stmt (estate=0x7fff46ea4f70, stmts=) at pl_exec.c:1342 #32 exec_stmts (estate=0x7fff46ea4f70, stmts=) at pl_exec.c:1241 #33 0x7f36ddb7330f in exec_stmt_block (estate=, block=) at pl_exec.c:1179 #34 0x7f36ddb73e82 in plpgsql_exec_function (func=0x1344358, fcinfo=0x135e220) at pl_exec.c:319 #35 0x7f36ddb68f33 in plpgsql_call_handler (fcinfo=) at pl_handler.c:122 #36 0x006fd6c9 in fmgr_security_definer (fcinfo=) at fmgr.c:968 #37 0x005762bd in ExecMakeFunctionResult (fcache=0x135e1b0, econtext=, isNull=0x135f4c8 "", isDone=) at execQual.c:1824 #38 0x005717d6 in ExecTargetList (projInfo=, isDone=) at execQual.c:5104 #39 ExecProject (projInfo=, isDone=) at execQual.c:5319 #40 0x00587f9b
Re: [BUGS] Segfault in backend CTE code
Phil Sorber writes: > I've attached a backtrace. How about a test case? I have no faith in the proposed patch without some evidence of what it's supposed to fix. 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
