[BUGS] BUG #6689: socket file name convention doesn't allow different IPs and the same port for different pgclusters
The following bug has been logged on the website: Bug reference: 6689 Logged by: Mark Email address: m...@it-infrastrukturen.org PostgreSQL version: 9.1.3 Operating system: unbuntu-server 12.04 LTS Description: When using /var/run/postgresql/ as unix_socket_directory for "main" and "second" pgcluster and different IP-interfaces (addresse) for every pgcluster (but the same default port number), there are different pid file names (like 9.1-main.pid and 9.1-secondpg.pid) *but* names of unix_sockek files doesn't follow such name conventions. It results in error when trying to run the second pgcluster with another IP but the same (default port 5432): Error: Port conflict: another instance is already running on on /var/run/postgresql with port 5432 regards, Mark -- 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 #6690: ALL and ANY array operators
The following bug has been logged on the website: Bug reference: 6690 Logged by: sergey Email address: sergey-1...@yandex.ru PostgreSQL version: 9.1.2 Operating system: FreeBSD 8.1 Description: As I see in documentation, http://www.postgresql.org/docs/current/static/functions-aggregate.html there is an ambiguity with bool_or aggregate and ANY array operator, so bool_or cannot has standard name ANY. So ANY should always mean array operator. But such query produces syntax error: select 1 = ANY((select ARRAY[1, 2]::integer[])) I.e. when I try to check is some element in array, that is calculated in subquery, I cannot. I can use: select ARRAY[1] && (select ARRAY[1, 2]::integer[]) but what about ANY operator? For example this works: select 1 = ANY(ARRAY[1, 2]::integer[]); select 1 in (select * from unnest(ARRAY[1, 2]::integer[])) -- 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 #6650: CPU system time utilization rising few times a day
It has happened again. Twice today. We have one perf dump. But it is over 600 MB of bzip2-ed data (3.5 GB of plain binary perf data). We'll go deeper into that, and if we don't come to any conclusions we will upload it to our anonymous FTP. Don't know if this perf dump is ok, as it was again triggered by our sciprt upon system load rise. Maybe it is too late... Another question: is errors count from my strace log not high? -- Andrzej Krawiec 2012/6/8 Robert Haas > On Fri, Jun 1, 2012 at 2:17 AM, Andrzej Krawiec > wrote: > > 2012/5/31 Robert Haas : > >> How long was strace -s run for to generate this? > > > > Strace - s was running for about 2 minutes. > > Hmm, I'm sort of confused then. This only shows a total of 1.815816 > seconds of system time, which is a lot less than 99% utilization * 2 > minutes. > >
[BUGS] BUG #6691: Unable to install PostgrSQL
The following bug has been logged on the website: Bug reference: 6691 Logged by: Paul Jardine Email address: pjard...@stertiluk.com PostgreSQL version: 9.1.4 Operating system: Windows 7 SP1 (64-Bit), with Sophos Anti-virus Description: Have tried to install both 32 and 64-bit versions but both failed with the warning message "Problem running post-install step. Installation may not complete correctly. The database cluster initialisation failed." Any help/advice will be very gratefully received. PJ -- 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 #6692: Potential Bug in equalfuncs.c
The following bug has been logged on the website: Bug reference: 6692 Logged by: Ken Cheung Email address: msrbugzi...@gmail.com PostgreSQL version: 9.1.3 Operating system: Linux Description: I observed a code clone in the following files. The function "COMPARE_LOCATION_FIELD" is called in some functions and missed in other functions. I wonder if this is a bug. Hope it helps. function : _equalA_ArrayExpr @ (file: "postgresql-9.1.3/src/backend/nodes/equalfuncs.c", line: 2118)~2121 COMPARE_NODE_FIELD(elements); COMPARE_LOCATION_FIELD(location); return true; function : _equalAlternativeSubPlan @ (file: "postgresql-9.1.3/src/backend/nodes/equalfuncs.c", line: 415)~417 COMPARE_NODE_FIELD(subplans); return true; function : _equalColumnRef @ (file: "postgresql-9.1.3/src/backend/nodes/equalfuncs.c", line: 2051)~2054 COMPARE_NODE_FIELD(fields); COMPARE_LOCATION_FIELD(location); return true; function : _equalDoStmt @ (file: "postgresql-9.1.3/src/backend/nodes/equalfuncs.c", line: 1306)~1308 COMPARE_NODE_FIELD(args); return 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 #6693: Potential Bug in rewriteManip.c
The following bug has been logged on the website:
Bug reference: 6693
Logged by: Ken Cheung
Email address: msrbugzi...@gmail.com
PostgreSQL version: 9.1.3
Operating system: Linux
Description:
I observed a code clone in the following files. In these functions,
qry->resultRelation is computed differently but the comment above mentions
the same functionality. I wonder if this is a bug. Hope it helps.
function : ChangeVarNodes @ (file:
"postgresql-9.1.3/src/backend/rewrite/rewriteManip.c", line: 570)~608
context.rt_index = rt_index;
context.new_index = new_index;
context.sublevels_up = sublevels_up;
/*
* Must be prepared to start with a Query or a bare expression tree; if
* it's a Query, go straight to query_tree_walker to make sure that
* sublevels_up doesn't get incremented prematurely.
*/
if (node && IsA(node, Query))
{
Query *qry = (Query *) node;
/*
* If we are starting at a Query, and sublevels_up is zero,
then we
* must also fix rangetable indexes in the Query itself ---
namely
* resultRelation and rowMarks entries. sublevels_up cannot be
zero
* when recursing into a subquery, so there's no need to have
the same
* logic inside ChangeVarNodes_walker.
*/
if (sublevels_up == 0)
{
ListCell *l;
if (qry->resultRelation == rt_index)
qry->resultRelation = new_index;
foreach(l, qry->rowMarks)
{
RowMarkClause *rc = (RowMarkClause *) lfirst(l);
if (rc->rti == rt_index)
rc->rti = new_index;
}
}
query_tree_walker(qry, ChangeVarNodes_walker,
(void *) &context, 0);
}
else
ChangeVarNodes_walker(node, &context);
function : OffsetVarNodes @ (file:
"postgresql-9.1.3/src/backend/rewrite/rewriteManip.c", line: 402)~438
context.offset = offset;
context.sublevels_up = sublevels_up;
/*
* Must be prepared to start with a Query or a bare expression tree; if
* it's a Query, go straight to query_tree_walker to make sure that
* sublevels_up doesn't get incremented prematurely.
*/
if (node && IsA(node, Query))
{
Query *qry = (Query *) node;
/*
* If we are starting at a Query, and sublevels_up is zero,
then we
* must also fix rangetable indexes in the Query itself ---
namely
* resultRelation and rowMarks entries. sublevels_up cannot be
zero
* when recursing into a subquery, so there's no need to have
the same
* logic inside OffsetVarNodes_walker.
*/
if (sublevels_up == 0)
{
ListCell *l;
if (qry->resultRelation)
qry->resultRelation += offset;
foreach(l, qry->rowMarks)
{
RowMarkClause *rc = (RowMarkClause *) lfirst(l);
rc->rti += offset;
}
}
query_tree_walker(qry, OffsetVarNodes_walker,
(void *) &context, 0);
}
else
OffsetVarNodes_walker(node, &context);
--
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 #6694: 9.2 beta 2 : psql commands \db and \db+ fail
The following bug has been logged on the website: Bug reference: 6694 Logged by: Philippe Beaudoin Email address: phb.e...@free.fr PostgreSQL version: Unsupported/Unknown Operating system: linux Description: Using the latest 9.2 beta 2 version, I got an error when issuing \db or \db+ psql command. paf=# select version(); version -- PostgreSQL 9.2beta2 on i686-pc-linux-gnu, compiled by gcc (GCC) 4.4.0 20090506 (Red Hat 4.4.0-4), 32-bit (1 row) paf=# \db ERROR: column "spclocation" does not exist LINE 3: spclocation AS "Location" ^ paf=# \db+ ERROR: column "spclocation" does not exist LINE 3: spclocation AS "Location", ^ I presume this is linked to the "Remove the spclocation field from pg_tablespace" item of the release notes and that something like the new pg_tablespace_location() function should be used by psql. Regards. Philippe. -- 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 #6694: 9.2 beta 2 : psql commands \db and \db+ fail
On Wed, Jun 13, 2012 at 07:17:11PM +, phb.e...@free.fr wrote: > The following bug has been logged on the website: > > Bug reference: 6694 > Logged by: Philippe Beaudoin > Email address: phb.e...@free.fr > PostgreSQL version: Unsupported/Unknown > Operating system: linux > Description: > > Using the latest 9.2 beta 2 version, I got an error when issuing \db or \db+ > psql command. > > paf=# select version(); > > version > > > -- > > PostgreSQL 9.2beta2 on i686-pc-linux-gnu, compiled by gcc (GCC) 4.4.0 > 20090506 (Red Hat 4.4.0-4), 32-bit > > (1 row) > > > > paf=# \db > > ERROR: column "spclocation" does not exist > > LINE 3: spclocation AS "Location" > > ^ > > paf=# \db+ > > ERROR: column "spclocation" does not exist > > LINE 3: spclocation AS "Location", > > ^ > I presume this is linked to the "Remove the spclocation field from > pg_tablespace" item of the release notes > and that something like the new pg_tablespace_location() function should be > used by psql. Are you using the psql provided by 9.2 beta 2? Or an older version? It appears that the version of psql in 9.2 beta 2 does the correct thing, look at src/bin/psql/describe.c line 142 or so. > > Regards. Philippe. > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs -Ryan Kelly -- 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 #6694: 9.2 beta 2 : psql commands \db and \db+ fail
On Thu, Jun 14, 2012 at 1:34 PM, Ryan Kelly wrote: > On Wed, Jun 13, 2012 at 07:17:11PM +, phb.e...@free.fr wrote: >> paf=# \db >> >> ERROR: column "spclocation" does not exist >> >> LINE 3: spclocation AS "Location" >> >> ^ >> > Are you using the psql provided by 9.2 beta 2? Or an older version? It > appears that the version of psql in 9.2 beta 2 does the correct thing, > look at src/bin/psql/describe.c line 142 or so. Yeah, the OP must be using a 9.1 or earlier psql to connect to the 9.2beta2 server showed in his version() output. There's a reason we print out a warning like this: WARNING: psql version X.a, server version Y.b Some psql features might not work. when the major version of psql and the server it is connecting to don't match. Josh -- 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 #6695: PgAdminIII
The following bug has been logged on the website: Bug reference: 6695 Logged by: Fábio Hentz Lunkes Email address: fabio.lun...@gmail.com PostgreSQL version: 9.1.0 Operating system: Windows 7 Description: Quando criado usuário(CREATE USER) com a opção CONNECTION LIMIT, a interface gráfica do PgAdmin III parece não respeitar o parâmetro, ou está criando novas conexões desnecessárias. Isso pode ser simulado criando um usuário com CONNECTION LIMIT 1, dar GRANT para uma tabela e tentar acessar os dados pela interface do PGAdmin III. Vai ocorrer mensagem de erro que o número de conexões ultrapassou, porém isso não é verdade. -- 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 #6691: Unable to install PostgrSQL
Can we get to see the installation log? (%TEMP%\install-postgresql.log) On Wed, Jun 13, 2012 at 6:39 PM, wrote: > The following bug has been logged on the website: > > Bug reference: 6691 > Logged by: Paul Jardine > Email address: pjard...@stertiluk.com > PostgreSQL version: 9.1.4 > Operating system: Windows 7 SP1 (64-Bit), with Sophos Anti-virus > Description: > > Have tried to install both 32 and 64-bit versions but both failed with the > warning message "Problem running post-install step. Installation may not > complete correctly. The database cluster initialisation failed." > > Any help/advice will be very gratefully received. > > PJ > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs > -- Regards, Sachin Srivastava EnterpriseDB, India
Re: [BUGS] BUG #6689: socket file name convention doesn't allow different IPs and the same port for different pgclusters
On Wed, Jun 13, 2012 at 2:45 AM, wrote: > The following bug has been logged on the website: > > Bug reference: 6689 > Logged by: Mark > Email address: m...@it-infrastrukturen.org > PostgreSQL version: 9.1.3 > Operating system: unbuntu-server 12.04 LTS > Description: > > When using /var/run/postgresql/ as unix_socket_directory for "main" and > "second" pgcluster and different IP-interfaces (addresse) for every > pgcluster (but the same default port number), there are different pid file > names (like 9.1-main.pid and 9.1-secondpg.pid) *but* names of unix_sockek > files doesn't follow such name conventions. > > It results in error when trying to run the second pgcluster with another IP > but the same (default port 5432): > Error: Port conflict: another instance is already running on on > /var/run/postgresql with port 5432 First of all, this is not a bug - this is intended behaviour. Perhaps the documentation needs to be clearified on the fact that the port number needs to be unique across all instances though. One reason is that the port number is used to control several other things. Just the Unix socket is only one of the things - it also controls the name of shared memory segments, so it still won't work if you work around that. All instances need to have their own ports. If you want to listen on the same port on different IPs, you will need to use something like kernel level ip forwarding to rewrite the access, and actually run PostgreSQL on different ports still. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
