Monday, August 4, 2008

[BUGS] BUG #4339: The postgreSQL service stops abnormally

The following bug has been logged online:

Bug reference: 4339
Logged by: Bhaskar Sirohi
Email address: bhaskar.sirohi@druvaa.com
PostgreSQL version: 8.3.3
Operating system: Windows 2003 Server
Description: The postgreSQL service stops abnormally
Details:

Hi All,

The postgreSQL service stops abnormally,I can't restart it until I enter the
password for the \postgre login account. Once I do that, everything is fine
again.

Below are the snaps of pg_logs

2008-07-29 09:14:46 EDT LOG: database system was interrupted; last known up
at 2008-07-28 23:13:20 EDT
2008-07-29 09:14:46 EDT LOG: database system was not properly shut down;
automatic recovery in progress
2008-07-29 09:14:46 EDT LOG: record with zero length at 2/D0E47B88
2008-07-29 09:14:46 EDT LOG: redo is not required
2008-07-29 09:14:46 EDT LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2008-07-29 09:14:46 EDT FATAL: the database system is starting up
2008-07-29 09:14:46 EDT LOG: database system is ready to accept
connections
2008-07-29 09:14:46 EDT LOG: autovacuum launcher started
2008-07-29 09:14:47 EDT LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2008-07-29 09:15:29 EDT LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2008-07-29 16:26:19 EDT LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2008-07-29 16:41:03 EDT LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2008-07-29 16:50:57 EDT LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2008-07-29 16:51:27 EDT LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2008-07-29 17:30:13 EDT LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"


2008-07-30 03:03:44 EDT LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2008-07-30 05:35:15 EDT LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2008-07-30 10:27:35 EDT LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2008-07-30 15:05:01 EDT LOG: checkpoints are occurring too frequently (28
seconds apart)
2008-07-30 15:05:01 EDT HINT: Consider increasing the configuration
parameter "checkpoint_segments".
2008-07-30 15:13:34 EDT LOG: checkpoints are occurring too frequently (29
seconds apart)
2008-07-30 15:13:34 EDT HINT: Consider increasing the configuration
parameter "checkpoint_segments".
2008-07-30 15:18:50 EDT LOG: checkpoints are occurring too frequently (28
seconds apart)
2008-07-30 15:18:50 EDT HINT: Consider increasing the configuration
parameter "checkpoint_segments".
2008-07-30 15:19:21 EDT LOG: received fast shutdown request
2008-07-30 15:19:21 EDT LOG: aborting any active transactions
2008-07-30 15:19:21 EDT ERROR: canceling statement due to user request
2008-07-30 15:19:21 EDT STATEMENT: COMMIT
2008-07-30 15:19:21 EDT ERROR: canceling statement due to user request
2008-07-30 15:19:21 EDT STATEMENT: ROLLBACK
2008-07-30 15:19:21 EDT ERROR: current transaction is aborted, commands
ignored until end of transaction block
2008-07-30 15:19:21 EDT STATEMENT: SELECT type, cino, ctime FROM folder
WHERE ino = 2 AND name = 'Michael H. Modee' AND dtime = 0
2008-07-30 15:19:21 EDT ERROR: current transaction is aborted, commands
ignored until end of transaction block
2008-07-30 15:19:21 EDT STATEMENT: SELECT type, cino, ctime FROM folder
WHERE ino = 2 AND name = 'Michael H. Modee' AND dtime = 0
2008-07-30 15:19:21 EDT ERROR: canceling autovacuum task
2008-07-30 15:19:21 EDT CONTEXT: automatic analyze of table
"notebookbkp.public.bmap"
2008-07-30 15:19:21 EDT FATAL: terminating connection due to administrator
command
2008-07-30 15:19:21 EDT FATAL: terminating connection due to administrator
command
2008-07-30 15:19:21 EDT LOG: autovacuum launcher shutting down
2008-07-30 15:19:24 EDT LOG: shutting down
2008-07-30 15:19:24 EDT LOG: database system is shut down

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [pgadmin-hackers] Support for integrated tsearch configuration

On Fri, Aug 1, 2008 at 11:05 AM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
>
> I worked three days on it. The fourth was more about testing it on different
> platforms (GTK, Windows, Mac). Now, It's working. I don't attach the patch
> because it's really big, but here is a URL to get it compressed:

Cool :-). The usual list of random thoughts....

- Should we call objects 'FTS xxxx'? All the 'Text Search xxxx' labels
look a little long.

- There are some tokens to add to the ctlSQLBox list - at least
GETTOKEN, LEXTYPES, HEADLINE, INIT, LEXIZE

- There is a little inconsistency in the RE-SQL formatting - for a
template for example we have:

CREATE TEXT SEARCH TEMPLATE fred (
INIT = dsimple_init,
LEXIZE = dsimple_lexize);

and for a dictionary:

CREATE TEXT SEARCH DICTIONARY fred (
TEMPLATE = "simple"
);

Note the ); position.

- I got a crash when trying to create a config with no tokens.

0 pgAdmin3-Debug 0x00021b63
wxArrayString::GetCount() const + 9 (arrstr.h:144)
1 pgAdmin3-Debug 0x000fed06
dlgTextSearchConfiguration::GetSql() + 1634
(dlgTextSearchConfiguration.cpp:346)
2 pgAdmin3-Debug 0x000cbf7f
dlgProperty::OnOK(wxCommandEvent&) + 335 (dlgProperty.cpp:759)
...

- The Dictionaries textbox is oddly sized on the Tokens tab of the
Configuration.

- The dialogue boxes default to different sizes. They should all be
consistently sized.

- Don't forget to add new headers to precomp.h.

I only gave the code a cusory glance - you've got lot's of pgAdmin
experience now so I trust that it's all as clean as the bits I looked
at :-)

Overall, looks pretty good :-)

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[COMMITTERS] pgbouncer - pgbouncer: exit immediately on SIGINT if suspend was in

Log Message:
-----------
exit immediately on SIGINT if suspend was in progress

Modified Files:
--------------
pgbouncer/src:
main.c (r1.44 -> r1.45)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/main.c.diff?r1=1.44&r2=1.45)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [SQL] return setof record - strange behavior



2008/8/4 Marcin Krawczyk <jankes.mk@gmail.com>
Hi everybody. Can anyone enlighten me what's wrong with this function :

CREATE OR REPLACE FUNCTION month_year(mon integer, intv integer, OUT
ro integer, OUT mi integer)
 RETURNS SETOF record AS
$BODY$
DECLARE
w       record;
cy      integer := EXTRACT (YEAR FROM current_date);

BEGIN

FOR w IN
       SELECT (CASE WHEN  m > 12 THEN cy + 1 ELSE cy END)::integer, (CASE
WHEN  m > 12 THEN m - 12 ELSE m END)::integer
       FROM generate_series(mon + 1, mon + intv) AS m
LOOP
       RETURN next;
END LOOP;

END;

$BODY$
 LANGUAGE 'plpgsql' VOLATILE;


SELECT * FROM month_year(10, 5);

Why does it return empty SET ? The amount of rows is correct though ....
I'm running 8.1.4

regards
mk

--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

Hi

merlin=# CREATE OR REPLACE FUNCTION month_year(mon integer, intv integer)
 RETURNS SETOF record AS
$BODY$
DECLARE
w       record;
cy      integer := EXTRACT (YEAR FROM current_date);
BEGIN
FOR w IN
       SELECT (CASE WHEN  m > 12 THEN cy + 1 ELSE cy END)::integer, (CASE
WHEN  m > 12 THEN m - 12 ELSE m END)::integer
       FROM generate_series(mon + 1, mon + intv) AS m
LOOP
       RETURN next w;
END LOOP;
END;
$BODY$
 LANGUAGE 'plpgsql' VOLATILE;

and

merlin=# SELECT * FROM month_year(10, 5) as (x integer, y integer);
  x   | y
------+----
 2008 | 11
 2008 | 12
 2009 |  1
 2009 |  2
 2009 |  3
(5 rows)


without output params


--
--
Serdecznie pozdrawiam

Pawel Socha
pawel.socha@gmail.com

programista/administrator

perl -le 's**02).4^&-%2,).^9%4^!./4(%2^3,!#+7!2%^53%2&**y%& -;^[%"`-{ a%%s%%$_%ee'

[HACKERS] DROP DATABASE always seeing database in use

It seems there's something wrong with CheckOtherDBBackends() but I haven't
exactly figured out what. There are no other sessions but drop database keeps
saying "regression" is being accessed by other users. I do see Autovacuum
touching tables in regression but CheckOtherDBBackends() is supposed to send
it a sigkill if it finds it and it doesn't seem to be doing so.

I've been hacking on unrelated stuff in this database and have caused multiple
core dumps and autovacuum is finding orphaned temp tables. It's possible some
state is corrupted in some way here but I don't see what.


postgres=# select * from pg_stat_activity;
datid | datname | procpid | usesysid | usename | current_query | waiting | xact_start | query_start | backend_start | client_addr | client_port
-------+----------+---------+----------+---------+---------------------------------+---------+-------------------------------+-------------------------------+-------------------------------+-------------+-------------
11505 | postgres | 5616 | 10 | stark | select * from pg_stat_activity; | f | 2008-08-04 11:46:05.438479+01 | 2008-08-04 11:46:05.438956+01 | 2008-08-04 11:45:19.827702+01 | | -1
(1 row)

postgres=# commit;
COMMIT

postgres=# drop database regression;
ERROR: 55006: database "regression" is being accessed by other users
LOCATION: dropdb, dbcommands.c:678


select * from pg_stat_activity;
postgres=# datid | datname | procpid | usesysid | usename | current_query | waiting | xact_start | query_start | backend_start | client_addr | client_port
-------+----------+---------+----------+---------+---------------------------------+---------+-------------------------------+-------------------------------+-------------------------------+-------------+-------------
11505 | postgres | 5616 | 10 | stark | select * from pg_stat_activity; | f | 2008-08-04 11:46:45.619642+01 | 2008-08-04 11:46:45.620115+01 | 2008-08-04 11:45:19.827702+01 | | -1
(1 row)


--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[COMMITTERS] pgbouncer - pgbouncer: suspend_socket_list can drop sockets, so needs

Log Message:
-----------
suspend_socket_list can drop sockets, so needs _safe

Modified Files:
--------------
pgbouncer/src:
janitor.c (r1.29 -> r1.30)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/janitor.c.diff?r1=1.29&r2=1.30)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [HACKERS] Location for pgstat.stat

Index: backend/postmaster/pgstat.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/postmaster/pgstat.c,v
retrieving revision 1.176
diff -c -r1.176 pgstat.c
*** backend/postmaster/pgstat.c 30 Jun 2008 10:58:47 -0000 1.176
--- backend/postmaster/pgstat.c 4 Aug 2008 09:39:23 -0000
***************
*** 67,74 ****
* Paths for the statistics files (relative to installation's $PGDATA).
* ----------
*/
! #define PGSTAT_STAT_FILENAME "global/pgstat.stat"
! #define PGSTAT_STAT_TMPFILE "global/pgstat.tmp"

/* ----------
* Timer definitions.
--- 67,76 ----
* Paths for the statistics files (relative to installation's $PGDATA).
* ----------
*/
! #define PGSTAT_STAT_PERMANENT_FILENAME "global/pgstat.stat"
! #define PGSTAT_STAT_PERMANENT_TMPFILE "global/pgstat.tmp"
! #define PGSTAT_STAT_FILENAME "pgstat_tmp/pgstat.stat"
! #define PGSTAT_STAT_TMPFILE "pgstat_tmp/pgstat.tmp"

/* ----------
* Timer definitions.
***************
*** 218,225 ****
static void pgstat_beshutdown_hook(int code, Datum arg);

static PgStat_StatDBEntry *pgstat_get_db_entry(Oid databaseid, bool create);
! static void pgstat_write_statsfile(void);
! static HTAB *pgstat_read_statsfile(Oid onlydb);
static void backend_read_statsfile(void);
static void pgstat_read_current_status(void);

--- 220,227 ----
static void pgstat_beshutdown_hook(int code, Datum arg);

static PgStat_StatDBEntry *pgstat_get_db_entry(Oid databaseid, bool create);
! static void pgstat_write_statsfile(bool permanent);
! static HTAB *pgstat_read_statsfile(Oid onlydb, bool permanent);
static void backend_read_statsfile(void);
static void pgstat_read_current_status(void);

***************
*** 509,514 ****
--- 511,517 ----
pgstat_reset_all(void)
{
unlink(PGSTAT_STAT_FILENAME);
+ unlink(PGSTAT_STAT_PERMANENT_FILENAME);
}

#ifdef EXEC_BACKEND
***************
*** 2595,2601 ****
* zero.
*/
pgStatRunningInCollector = true;
! pgStatDBHash = pgstat_read_statsfile(InvalidOid);

/*
* Setup the descriptor set for select(2). Since only one bit in the set
--- 2598,2604 ----
* zero.
*/
pgStatRunningInCollector = true;
! pgStatDBHash = pgstat_read_statsfile(InvalidOid, true);

/*
* Setup the descriptor set for select(2). Since only one bit in the set
***************
*** 2635,2641 ****
if (!PostmasterIsAlive(true))
break;

! pgstat_write_statsfile();
need_statwrite = false;
need_timer = true;
}
--- 2638,2644 ----
if (!PostmasterIsAlive(true))
break;

! pgstat_write_statsfile(false);
need_statwrite = false;
need_timer = true;
}
***************
*** 2803,2809 ****
/*
* Save the final stats to reuse at next startup.
*/
! pgstat_write_statsfile();

exit(0);
}
--- 2806,2812 ----
/*
* Save the final stats to reuse at next startup.
*/
! pgstat_write_statsfile(true);

exit(0);
}
***************
*** 2891,2897 ****
* ----------
*/
static void
! pgstat_write_statsfile(void)
{
HASH_SEQ_STATUS hstat;
HASH_SEQ_STATUS tstat;
--- 2894,2900 ----
* ----------
*/
static void
! pgstat_write_statsfile(bool permanent)
{
HASH_SEQ_STATUS hstat;
HASH_SEQ_STATUS tstat;
***************
*** 2901,2917 ****
PgStat_StatFuncEntry *funcentry;
FILE *fpout;
int32 format_id;

/*
* Open the statistics temp file to write out the current values.
*/
! fpout = fopen(PGSTAT_STAT_TMPFILE, PG_BINARY_W);
if (fpout == NULL)
{
ereport(LOG,
(errcode_for_file_access(),
errmsg("could not open temporary statistics file \"%s\": %m",
! PGSTAT_STAT_TMPFILE)));
return;
}

--- 2904,2922 ----
PgStat_StatFuncEntry *funcentry;
FILE *fpout;
int32 format_id;
+ const char *tmpfile = permanent?PGSTAT_STAT_PERMANENT_TMPFILE:PGSTAT_STAT_TMPFILE;
+ const char *statfile = permanent?PGSTAT_STAT_PERMANENT_FILENAME:PGSTAT_STAT_FILENAME;

/*
* Open the statistics temp file to write out the current values.
*/
! fpout = fopen(tmpfile, PG_BINARY_W);
if (fpout == NULL)
{
ereport(LOG,
(errcode_for_file_access(),
errmsg("could not open temporary statistics file \"%s\": %m",
! tmpfile)));
return;
}

***************
*** 2978,3002 ****
ereport(LOG,
(errcode_for_file_access(),
errmsg("could not write temporary statistics file \"%s\": %m",
! PGSTAT_STAT_TMPFILE)));
fclose(fpout);
! unlink(PGSTAT_STAT_TMPFILE);
}
else if (fclose(fpout) < 0)
{
ereport(LOG,
(errcode_for_file_access(),
errmsg("could not close temporary statistics file \"%s\": %m",
! PGSTAT_STAT_TMPFILE)));
! unlink(PGSTAT_STAT_TMPFILE);
}
! else if (rename(PGSTAT_STAT_TMPFILE, PGSTAT_STAT_FILENAME) < 0)
{
ereport(LOG,
(errcode_for_file_access(),
errmsg("could not rename temporary statistics file \"%s\" to \"%s\": %m",
! PGSTAT_STAT_TMPFILE, PGSTAT_STAT_FILENAME)));
! unlink(PGSTAT_STAT_TMPFILE);
}
}

--- 2983,3007 ----
ereport(LOG,
(errcode_for_file_access(),
errmsg("could not write temporary statistics file \"%s\": %m",
! tmpfile)));
fclose(fpout);
! unlink(tmpfile);
}
else if (fclose(fpout) < 0)
{
ereport(LOG,
(errcode_for_file_access(),
errmsg("could not close temporary statistics file \"%s\": %m",
! tmpfile)));
! unlink(tmpfile);
}
! else if (rename(tmpfile, statfile) < 0)
{
ereport(LOG,
(errcode_for_file_access(),
errmsg("could not rename temporary statistics file \"%s\" to \"%s\": %m",
! tmpfile, statfile)));
! unlink(tmpfile);
}
}

***************
*** 3006,3015 ****
*
* Reads in an existing statistics collector file and initializes the
* databases' hash table (whose entries point to the tables' hash tables).
* ----------
*/
static HTAB *
! pgstat_read_statsfile(Oid onlydb)
{
PgStat_StatDBEntry *dbentry;
PgStat_StatDBEntry dbbuf;
--- 3011,3025 ----
*
* Reads in an existing statistics collector file and initializes the
* databases' hash table (whose entries point to the tables' hash tables).
+ *
+ * If reading from the permanent file (which happens during collector
+ * startup, but never from backends), the file is removed once it's been
+ * successfully read. The temporary file is also removed at this time,
+ * to make sure backends don't read data from previous runs.
* ----------
*/
static HTAB *
! pgstat_read_statsfile(Oid onlydb, bool permanent)
{
PgStat_StatDBEntry *dbentry;
PgStat_StatDBEntry dbbuf;
***************
*** 3024,3029 ****
--- 3034,3040 ----
FILE *fpin;
int32 format_id;
bool found;
+ const char *statfile = permanent?PGSTAT_STAT_PERMANENT_FILENAME:PGSTAT_STAT_FILENAME;

/*
* The tables will live in pgStatLocalContext.
***************
*** 3052,3058 ****
* return zero for anything and the collector simply starts from scratch
* with empty counters.
*/
! if ((fpin = AllocateFile(PGSTAT_STAT_FILENAME, PG_BINARY_R)) == NULL)
return dbhash;

/*
--- 3063,3069 ----
* return zero for anything and the collector simply starts from scratch
* with empty counters.
*/
! if ((fpin = AllocateFile(statfile, PG_BINARY_R)) == NULL)
return dbhash;

/*
***************
*** 3241,3246 ****
--- 3252,3263 ----
done:
FreeFile(fpin);

+ if (permanent)
+ {
+ unlink(PGSTAT_STAT_PERMANENT_FILENAME);
+ unlink(PGSTAT_STAT_FILENAME);
+ }
+
return dbhash;
}

***************
*** 3259,3267 ****

/* Autovacuum launcher wants stats about all databases */
if (IsAutoVacuumLauncherProcess())
! pgStatDBHash = pgstat_read_statsfile(InvalidOid);
else
! pgStatDBHash = pgstat_read_statsfile(MyDatabaseId);
}


--- 3276,3284 ----

/* Autovacuum launcher wants stats about all databases */
if (IsAutoVacuumLauncherProcess())
! pgStatDBHash = pgstat_read_statsfile(InvalidOid, false);
else
! pgStatDBHash = pgstat_read_statsfile(MyDatabaseId, false);
}


Index: bin/initdb/initdb.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/initdb/initdb.c,v
retrieving revision 1.158
diff -c -r1.158 initdb.c
*** bin/initdb/initdb.c 19 Jul 2008 04:01:29 -0000 1.158
--- bin/initdb/initdb.c 4 Aug 2008 09:39:23 -0000
***************
*** 2461,2467 ****
"pg_multixact/offsets",
"base",
"base/1",
! "pg_tblspc"
};

progname = get_progname(argv[0]);
--- 2461,2468 ----
"pg_multixact/offsets",
"base",
"base/1",
! "pg_tblspc",
! "pgstat_tmp"
};

progname = get_progname(argv[0]);
Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Tom Lane wrote:
>>> It doesn't seem to me that it'd be hard to support two locations for the
>>> stats file --- it'd just take another parameter to the read and write
>>> routines. pgstat.c already knows the difference between a normal write
>>> and a shutdown write ...
>
>> Right. Should it be removed from the permanent location when the server
>> starts?
>
> Yes, I would say so. There are two possible exit paths: normal shutdown
> (where we'd write a new file) and crash. In a crash we'd wish to delete
> the file anyway for fear that it's corrupted.
>
> Startup: read permanent file, then delete it.
>
> Post-crash: remove any permanent file (same as now)
>
> Shutdown: write permanent file.
>
> Normal stats collector write: write temp file.
>
> Backend stats fetch: read temp file.

Attached is a patch that implements this. I went with the option of just
storing it in a temporary directory that can be symlinked, and not
bothering with a GUC for it. Comments? (documentation updates are also
needed, but I'll wait with those until I hear patch comments :-P)


//Magnus

[SQL] return setof record - strange behavior

The function behaves as expected when in plain SQL, only plpgsql
function has the above mentioned problem.

regards
mk

--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

Re: [pgadmin-hackers] pgScript patch

Hi Mickael

On Sun, Jul 27, 2008 at 3:34 PM, Mickael Deloison <mdeloison@gmail.com> wrote:
> Hi pgadmin hackers,
>
> pgScript can now be integrated into pgAdmin3. I have made a patch on
> revision 7394 of pgAdmin. This patch is big therefore I do not post it
> in this email, it is instead available on the following server:
> http://pgscript.projects.postgresql.org/pgadmin

Cool. It is indeed a huge patch, so I'll have to leave it to your
mentor to undertake a more extensive code review, but here are a few
points I noticed whilst testing on Mac:

- Please include "Copyright (C) 2002 - 2008, The pgAdmin Development
Team" in the copyright notices at the top of each source file. I'm
happy for you to include your own copyright there also, but it makes
things much easier from a legal POV if you list us as well.

- The build failed initially with:

./pgscript/statements/pgsStmtList.cpp: In member function 'virtual
void pgsStmtList::eval(pgsVarMap&) const':
./pgscript/statements/pgsStmtList.cpp:56: error: cannot use typeid
with -fno-rtti
./pgscript/statements/pgsStmtList.cpp:56: error: cannot use typeid
with -fno-rtti
./pgscript/statements/pgsStmtList.cpp:57: error: cannot use typeid
with -fno-rtti
./pgscript/statements/pgsStmtList.cpp:57: error: cannot use typeid
with -fno-rtti
./pgscript/statements/pgsStmtList.cpp: In member function 'virtual
void pgsStmtList::eval(pgsVarMap&) const':
./pgscript/statements/pgsStmtList.cpp:56: error: cannot use typeid
with -fno-rtti
./pgscript/statements/pgsStmtList.cpp:56: error: cannot use typeid
with -fno-rtti
./pgscript/statements/pgsStmtList.cpp:57: error: cannot use typeid
with -fno-rtti
./pgscript/statements/pgsStmtList.cpp:57: error: cannot use typeid
with -fno-rtti
lipo: can't figure out the architecture type of:
/var/folders/uk/ukdzizfJHxe07gKAk8a+NE+++TI/-Tmp-//ccIbnqxz.out
make[2]: *** [pgsStmtList.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

After removing -fno-rtti from acinclude.m4:

- I see the following warnings:

./pgadmin/include/frm/frmQuery.h: In constructor
'frmQuery::frmQuery(frmMain*, const wxString&, pgConn*, const
wxString&, const wxString&)':
../pgadmin/include/frm/frmQuery.h:75: warning: 'frmQuery::pgscript'
will be initialized after
../pgadmin/include/frm/frmQuery.h:71: warning: 'wxTimer frmQuery::timer'
./frm/frmQuery.cpp:130: warning: when initialized here
../pgadmin/include/frm/frmQuery.h: In constructor
'frmQuery::frmQuery(frmMain*, const wxString&, pgConn*, const
wxString&, const wxString&)':
../pgadmin/include/frm/frmQuery.h:75: warning: 'frmQuery::pgscript'
will be initialized after
../pgadmin/include/frm/frmQuery.h:71: warning: 'wxTimer frmQuery::timer'
./frm/frmQuery.cpp:130: warning: when initialized here

- The following script crashes (yes, I realise it's missing a cast)

declare @i, @t;

set @i = 0;

while @i < 20
begin
set @t = 'aa' + @i;
create table @t (id serial primary key, data text);

set @i = @i + 1;
end

- The corrected script gives no feedback that it's finished, other
than re-enabling buttons. I would expect to see the appropriate
notices from the server about each table that is created, and the
status message on the status bar should change.

- The following script (with missing increment of @i) gave appropriate
errors when run the first time, but ran silently the second:

declare @i, @t;

set @i = 0;

while @i < 20
begin
set @t = 'aa' + cast(@i as string);
create table @t (id serial primary key, data text);
end

- Cancelling that script the first time round is awkward (we should
offer a cancel option on the error dialogue). Using the Stop button
seems to crash.

I'll leave it at that for now, and look forward to the next patch :-)

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [HACKERS] Mini improvement: statement_cost_limit

"Josh Berkus" <josh@agliodbs.com> writes:

> Tom,
>
>> Wasn't this exact proposal discussed and rejected awhile back?
>
> We rejected Greenplum's much more invasive resource manager, because it
> created a large performance penalty on small queries whether or not it was
> turned on. However, I don't remember any rejection of an idea as simple
> as a cost limit rejection.

The idea's certainly come up before. It probably received the usual
non-committal cold shoulder rather than an outright "rejection".

> This would, IMHO, be very useful for production instances of PostgreSQL.
> The penalty for mis-rejection of a poorly costed query is much lower than
> the penalty for having a bad query eat all your CPU.

Well that's going to depend on the application.... But I suppose there's
nothing wrong with having options which aren't always a good idea to use. The
real question I guess is whether there's ever a situation where it would be a
good idea to use this. I'm not 100% sure.

What I would probably use myself is an option to print a warning before
starting the query. That would be handy for interactive sessions so you would
be able to hit C-c instead of waiting for several minutes and then wondering
whether you got the query wrong.

I wonder if it would be useful to have a flag on some GUC options to make them
not globally settable. That is, for example, you could set enable_seqscan in
an individual session but not in postgres.conf. Or perhaps again just print a
warning that it's not recommended as a global configuration.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[SQL] return setof record - strange behavior

Hi everybody. Can anyone enlighten me what's wrong with this function :

CREATE OR REPLACE FUNCTION month_year(mon integer, intv integer, OUT
ro integer, OUT mi integer)
RETURNS SETOF record AS
$BODY$
DECLARE
w record;
cy integer := EXTRACT (YEAR FROM current_date);

BEGIN

FOR w IN
SELECT (CASE WHEN m > 12 THEN cy + 1 ELSE cy END)::integer, (CASE
WHEN m > 12 THEN m - 12 ELSE m END)::integer
FROM generate_series(mon + 1, mon + intv) AS m
LOOP
RETURN next;
END LOOP;

END;

$BODY$
LANGUAGE 'plpgsql' VOLATILE;


SELECT * FROM month_year(10, 5);

Why does it return empty SET ? The amount of rows is correct though ....
I'm running 8.1.4

regards
mk

--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

[GENERAL] Efficient data structures and UI for product matrix

Hi!

We wish to provide our users with a simple-to-use web-based processor-selection tool, where a user could select a couple of attribute values and be presented with a list of matching processors. The basis of the required data would be provided by our editors as Excel documents of the following structure:

attribute_1 attribute_2 ...
processor_a some_value some_value ...
processor_b some_value some_value
...

This data would be normalized to the following structure on import:

CREATE TABLE processors
(
id serial NOT NULL,
processor_name text NOT NULL,
CONSTRAINT "processors_pkey" PRIMARY KEY (id)
)WITHOUT OIDS;

CREATE TABLE attributes
(
id serial NOT NULL,
attribute_name text NOT NULL,
CONSTRAINT "attributes_pkey" PRIMARY KEY (id)
)WITHOUT OIDS;

CREATE TABLE processor_attributes
(
processor_id integer NOT NULL,
attribute_id integer NOT NULL,
value_id integer NOT NULL,
CONSTRAINT "pk_processor_attributes" PRIMARY KEY (processor_id, attribute_id, value_id),
CONSTRAINT "fk_processor_id" FOREIGN KEY (processor_id) REFERENCES processors(id) ON UPDATE CASCADE ON DELETE CASCADE,
CONSTRAINT "fk_attribute_id" FOREIGN KEY (attribute_id) REFERENCES attributes(id) ON UPDATE CASCADE ON DELETE CASCADE,
CONSTRAINT "fk_value_id" FOREIGN KEY (value_id) REFERENCES attribute_values(id)
)WITHOUT OIDS;

CREATE TABLE attribute_values
(
id serial NOT NULL,
value text,
attribute_id integer NOT NULL,
CONSTRAINT "attribute_values_pkey" PRIMARY KEY (id),
CONSTRAINT "fk_attribute_id" FOREIGN KEY (attribute_id) REFERENCES attributes(id) ON UPDATE CASCADE ON DELETE CASCADE
)WITHOUT OIDS;

The (web-based) UI should provide a dropdown field for each attribute (none selected per default) and a pageable table with the matching results underneath. The user should be kept from having to find out that there's no match for a selected combination of attribute-values, so after each selected dropdown, the as yet unselected dropdown-lists must be filtered to show only the still available attribute values - we intend to use some AJAX functions here. It'd be nice if the UI could be made fully dynamic, that's to say that it should reflect any changes to the number and names of attributes or their available values without any change to the application's code; the latter is in fact a must have, whereas the number and names of attributes would not change quite as frequently, so moderate changes to the code would be alright.

Now, has anyone done anything similar recently and could provide some insight? I'd be particularly interested in any solutions involving some sort of de-normalization, views, procedures and suchlike to speed up performance of the drop-down-update process, especially as the number of attributes and the number of legal values for each attribute increases. Does anybody know of some sort of example application for this type of problem where we could find to inspiration?

Kind regards

Markus


Computec Media AG
Sitz der Gesellschaft und Registergericht: Fürth (HRB 8818)
Vorstandsmitglieder: Johannes S. Gözalan (Vorsitzender) und Rainer Rosenbusch
Vorsitzender des Aufsichtsrates: Jürg Marquard
Umsatzsteuer-Identifikationsnummer: DE 812 575 276

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [planet] Adding blog to planetpostgresql.org

Hi Bernd,

Sorry for the delay -- you just landed Planet :)

Cheers, Devrim

On Mon, 2008-07-21 at 13:00 +0200, Bernd Helmle wrote:
> Devrim,
>
> I would like to repeat my request for adding my blog located at
>
> http://psoos.blogspot.com/search/label/PostgreSQL
>
> to planetpostgresql.org. Let me know if there's something missing.
>
> Thanks.
>
--
Devrim GÜNDÜZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

Re: [Fwd: [planet] Add blog feed to planetpostgresql.org]

> Can you help add my blog feed from http://blogs.sun.com/robertlor/ to
> planetpostgresql.org?

Hi Robert,

For some reason, I did not get the e-mail above. Magnus forwarded it to
me -- and you are on Planet now.

I also added you to planet-subscribers@lists.planetpostgresql.org

Cheers,

--
Devrim GÜNDÜZ , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/

Re: [HACKERS] unnecessary code in_bt_split

Tom Lane napsal(a):
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> I found that _bt_split function calls PageGetTempPage, but next call is
>> _bt_page_init which clear all contents anyway. Is there any reason to call
>> PageGetTempPage instead of palloc?
>
> Not violating a perfectly good abstraction?

OK. Abstraction is nice, but what I see in the PageGetTempPage It is more like
code which makes everything but usability is zero. It is used only in two places
and in both it is used for different purpose. _bt_split() needs only allocate
empty temp page and gistplacetopage() .


By my opinion It would be better to have three functions:

PageCreateTempPage - only allocate memory and call pageinit
PageCloneSpecial - copy special section from source page
PageRestoreTempPage - no change.


Zdenek

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] bytea encode performance issues

On 2008-08-03 12:12, Sim Zacks wrote:

> SELECT m.message_idnr,k.messageblk
> FROM dbmail_messageblks k
> JOIN dbmail_physmessage p ON k.physmessage_id = p.id
> JOIN dbmail_messages m ON p.id = m.physmessage_id
> WHERE
> mailbox_idnr = 8
> AND status IN (0,1 )
> AND k.is_header = '0'
> GROUP BY m.message_idnr,k.messageblk
> HAVING ENCODE(k.messageblk::bytea,'escape') LIKE '%John%'

What is this encode() for? I think it is not needed and kills
performance, as it needs to copy every message body in memory, possibly
several times.

Why not just "HAVING k.messageblk LIKE '%John%'"?


Try this:

=> \timing

=> create temporary table test as
select
decode(
repeat(
'lorem ipsum dolor sit amet '
||s::text||E'\n'
,1000
),
'escape'
) as a
from generate_series(1,10000) as s;
SELECT
Time: 10063.807 ms

=> select count(*) from test where a like '%John%';
count
-------
0
(1 row)

Time: 1280.973 ms

=> select count(*) from test where encode(a,'escape') like '%John%';
count
-------
0
(1 row)

Time: 5690.097 ms


Without encode search is 5 times faster. And for bigger bytea a
difference is even worse.


Even better:

=> select count(*) from test where position('John' in a) != 0;
select count(*) from test where position('John' in a) != 0;
count
-------
0
(1 row)

Time: 1098.768 ms

Regards
Tometzky
--
...although Eating Honey was a very good thing to do, there was a
moment just before you began to eat it which was better than when you
were...
Winnie the Pooh

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] postgres-r patch: autoconf/make problem

hi,

I am trying to compile the postgres-r patch, but ran into problems.. Probably just a simple lack of understanding of the make system. Any help is appreciated.

I got the CVS head for postgres on Jul-31 and applying the Jul-31 patch from here: http://www.postgres-r.org/downloads/. The patch applies fine; no problems. When running autoconf it gives me the following warning when running "./configure --enable-replication" once the configure scripts has ran:

$ ./configure --enable-replication
...
configure: WARNING: option ignored: --enable-replication
$

Subsequent compilation by simply typing "make" seems *not* to compile anything in "src/backend/replication" (teh compilation as such goes through). When going directly to this directory and typing "make", a few compilation errors appear for the file "local.c". I attached the output at the end of this e-mail. But they might simply be caused by some compilation flags not correctly set due to earlier problems.

I' sure it's just a simple problem me not specifying some command line option (compilation host is RHEL5). So in hope of a simple answer, this question: Am I missing some compilation options?

Markus

PS: the configure output:
$ ./configure --enable-replication
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking which template to use... linux
checking whether to build with 64-bit integer date/time support... yes
checking whether NLS is wanted... no
checking for default port number... 5432
checking for block size... 8kB
checking for segment size... 1GB
checking for WAL block size... 8kB
checking for WAL segment size... 16MB
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking if gcc supports -Wdeclaration-after-statement... yes
checking if gcc supports -Wendif-labels.... yes
checking if gcc supports -fno-strict-aliasing... yes
checking if gcc supports -fwrapv... yes
checking whether the C compiler still works.... yes
checking how to run the C preprocessor... gcc -E
checking allow thread-safe client libraries... no
checking whether to build with Tcl... no
checking whether to build Perl modules... no
checking whether to build Python modules... no
checking whether to build with GSSAPI support... no
checking whether to build with Kerberos 5 support... no
checking whether to build with PAM support... no
checking whether to build with LDAP support... no
checking whether to build with Bonjour support... no
checking whether to build with OpenSSL support... no
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for ranlib... ranlib
checking for strip... strip
checking whether it is possible to strip libraries... yes
checking for tar... /bin/tar
checking whether ln -s works... yes
checking for gawk... gawk
checking for bison... bison -y
configure: using bison (GNU Bison) 2.3
checking for flex... /usr/bin/flex
configure: using /usr/bin/flex version 2.5.4
checking for perl... /usr/bin/perl
checking for main in -lm... yes
checking for library containing setproctitle.... no
checking for library containing dlopen... -ldl
checking for library containing socket... none required
checking for library containing shl_load... no
checking for library containing getopt_long... none required
checking for library containing crypt... -lcrypt
checking for library containing fdatasync... none required
checking for library containing shmget... none required
checking for -lreadline... yes (-lreadline -ltermcap)
checking for inflate in -lz... yes
checking for ANSI C header files.... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h.... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking crypt.h usability... yes
checking crypt.h presence... yes
checking for crypt.h... yes
checking dld.h usability... no
checking dld.h presence... no
checking for dld.h... no
checking fp_class.h usability... no
checking fp_class.h presence... no
checking for fp_class.h... no
checking getopt.h usability... yes
checking getopt.h presence... yes
checking for getopt.h... yes
checking ieeefp.h usability... no
checking ieeefp.h presence... no
checking for ieeefp.h... no
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo..h... yes
checking poll.h usability... yes
checking poll.h presence... yes
checking for poll.h... yes
checking pwd.h usability... yes
checking pwd.h presence... yes
checking for pwd.h... yes
checking sys/ipc.h usability... yes
checking sys/ipc.h presence... yes
checking for sys/ipc..h... yes
checking sys/poll.h usability... yes
checking sys/poll.h presence... yes
checking for sys/poll.h... yes
checking sys/pstat.h usability... no
checking sys/pstat.h presence... no
checking for sys/pstat.h.... no
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking sys/sem.h usability... yes
checking sys/sem.h presence... yes
checking for sys/sem.h... yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking sys/shm.h usability... yes
checking sys/shm.h presence... yes
checking for sys/shm.h... yes
checking sys/tas.h usability... no
checking sys/tas.h presence... no
checking for sys/tas.h... no
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking sys/un.h usability... yes
checking sys/un.h presence... yes
checking for sys/un.h... yes
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking wctype.h usability... yes
checking wctype.h presence... yes
checking for wctype.h... yes
checking kernel/OS.h usability... no
checking kernel/OS.h presence... no
checking for kernel/OS.h... no
checking kernel/image.h usability... no
checking kernel/image.h presence... no
checking for kernel/image.h... no
checking SupportDefs.h usability... no
checking SupportDefs.h presence... no
checking for SupportDefs.h... no
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking for netinet/tcp.h... yes
checking readline/readline.h usability... yes
checking readline/readline.h presence... yes
checking for readline/readline.h... yes
checking readline/history.h usability... yes
checking readline/history.h presence... yes
checking for readline/history.h... yes
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking whether byte ordering is bigendian... no
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for preprocessor stringizing operator... yes
checking for signed types... yes
checking for working volatile... yes
checking for __func__... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for struct tm.tm_zone... yes
checking for tzname... yes
checking for union semun... no
checking for struct sockaddr_un... yes
checking for struct sockaddr_storage... yes
checking for struct sockaddr_storage.ss_family.... yes
checking for struct sockaddr_storage.__ss_family... no
checking for struct sockaddr_storage.ss_len... no
checking for struct sockaddr_storage.__ss_len... no
checking for struct sockaddr.sa_len... no
checking for struct addrinfo... yes
checking for struct cmsgcred... no
checking for struct fcred... no
checking for struct sockcred... no
checking for struct option... yes
checking for z_streamp... yes
checking for int timezone... yes
checking types of arguments for accept()... int, int, struct sockaddr *, size_t *
checking whether gettimeofday takes only one argument... no
checking for cbrt... yes
checking for dlopen... yes
checking for fcvt... yes
checking for fdatasync... yes
checking for getpeereid.... no
checking for getrlimit... yes
checking for memmove... yes
checking for poll... yes
checking for pstat... no
checking for readlink... yes
checking for setproctitle... no
checking for setsid... yes
checking for sigprocmask... yes
checking for symlink... yes
checking for sysconf... yes
checking for towlower... yes
checking for utime... yes
checking for utimes... yes
checking for waitpid... yes
checking for wcstombs... yes
checking whether fdatasync is declared... yes
checking whether posix_fadvise is declared... yes
checking whether strlcat is declared... no
checking whether strlcpy is declared... no
checking whether F_FULLFSYNC is declared... no
checking for struct sockaddr_in6... yes
checking for PS_STRINGS... no
checking for snprintf... yes
checking for vsnprintf... yes
checking whether snprintf is declared... yes
checking whether vsnprintf is declared... yes
checking for isinf... yes
checking for crypt... yes
checking for getopt... yes
checking for getrusage... yes
checking for inet_aton... yes
checking for random... yes
checking for rint... yes
checking for srandom... yes
checking for strdup... yes
checking for strerror... yes
checking for strlcat... no
checking for strlcpy... no
checking for strtol... yes
checking for strtoul... yes
checking for unsetenv... yes
checking for getaddrinfo... yes
checking for getopt_long... yes
checking for rl_completion_append_character... yes
checking for rl_completion_matches... yes
checking for rl_filename_completion_function... yes
checking for replace_history_entry... yes
checking for sigsetjmp... yes
checking whether sys_siglist is declared... yes
checking for syslog... yes
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking for optreset.... no
checking for strtoll... yes
checking for strtoull... yes
checking for atexit... yes
checking for fseeko... yes
checking for _LARGEFILE_SOURCE value needed for large files... no
checking test program... ok
checking whether long int is 64 bits... no
checking whether long long int is 64 bits... yes
checking snprintf format for long long int... %lld
checking for unsigned long... yes
checking size of unsigned long... 4
checking for size_t... yes
checking size of size_t... 4
checking whether to build with float4 passed by value... yes
checking whether to build with float8 passed by value... no
checking for short... yes
checking alignment of short... 2
checking for int... yes
checking alignment of int... 4
checking for long... yes
checking alignment of long... 4
checking for long long int... yes
checking alignment of long long int... 4
checking for double... yes
checking alignment of double... 4
checking for int8... no
checking for uint8... no
checking for int64... no
checking for uint64... no
checking for sig_atomic_t... yes
checking for POSIX signal interface... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for off_t... yes
checking size of off_t... 8
checking for working memcmp... yes
checking for onsgmls... onsgmls
checking for openjade... openjade
checking for DocBook V4.2... yes
checking for DocBook stylesheets... /usr/share/sgml/docbook/dsssl-stylesheets
checking for collateindex.pl... /usr/bin/collateindex.pl
checking for sgmlspl... sgmlspl
checking if gcc supports -Wl,--as-needed... no
configure: using CFLAGS=-O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv
configure: using CPPFLAGS= -D_GNU_SOURCE
configure: using LDFLAGS=
configure: creating ./config.status
config.status: creating GNUmakefile
config.status: creating src/Makefile.global
config.status: creating src/include/pg_config.h
config.status: creating src/interfaces/ecpg/include/ecpg_config.h
config.status: linking ./src/backend/port/tas/dummy.s to src/backend/port/tas.s
config.status: linking ./src/backend/port/dynloader/linux.c to src/backend/port/dynloader.c
config.status: linking ./src/backend/port/sysv_sema.c to src/backend/port/pg_sema.c
config.status: linking ./src/backend/port/sysv_shmem.c to src/backend/port/pg_shmem.c
config.status: linking ./src/backend/port/dynloader/linux.h to src/include/dynloader.h
config.status: linking ./src/include/port/linux.h to src/include/pg_config_os.h
config.status: linking ./src/makefiles/Makefile.linux to src/Makefile.port
configure: WARNING: option ignored: --enable-replication
$

PS2:
$ pwd
/home/ml/pg/pgsql/src/backend/replication
$ make
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -I../../.../src/include -D_GNU_SOURCE -c -o gc_utils.o gc_utils.c
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -I../../../src/include -D_GNU_SOURCE -c -o gc_egcs.o gc_egcs.c
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -I../../../src/include -D_GNU_SOURCE -c -o gc_ensemble.o gc_ensemble.c
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -I../../../src/include -D_GNU_SOURCE -c -o gc_spread.o gc_spread.c
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -I../../../src/include -D_GNU_SOURCE -c -o cset.o cset.c
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -I../../../src/include -D_GNU_SOURCE -c -o local.o local.c
local.c: In function 'send_backend_ready_msg':
local.c:66: error: 'ReplicationManagerPid' undeclared (first use in this function)
local.c:66: error: (Each undeclared identifier is reported only once
local.c:66: error: for each function it appears in.)
local.c: In function 'send_cset':
local.c:101: error: 'ReplicationManagerPid' undeclared (first use in this function)
local.c: In function 'StartupReplication':
local.c:198: error: 'ReplicationManagerPid' undeclared (first use in this function)
local.c: In function 'replication_request_sequence_increment':
local.c:281: error: 'ReplicationManagerPid' undeclared (first use in this function)
local.c: In function 'cset_replicate':
local.c:409: error: 'PGPROC' has no member named 'abortFlag'
local.c:416: error: 'PGPROC' has no member named 'abortFlag'
local.c:444: error: 'PGPROC' has no member named 'abortFlag'
local.c:448: error: 'PGPROC' has no member named 'abortFlag'
local.c:482: error: 'PGPROC' has no member named 'abortFlag'
make: *** [local.o] Error 1
$

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[COMMITTERS] pgbouncer - pgbouncer: proper log message for console client cancel

Log Message:
-----------
proper log message for console client cancel

Modified Files:
--------------
pgbouncer/src:
objects.c (r1.48 -> r1.49)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/objects.c.diff?r1=1.48&r2=1.49)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgbouncer - pgbouncer: cleaner socket_row()

Log Message:
-----------
cleaner socket_row()

Modified Files:
--------------
pgbouncer/src:
admin.c (r1.36 -> r1.37)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/admin.c.diff?r1=1.36&r2=1.37)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgtcl - libpgtcl: Add clock_to_precise_sql_time

Log Message:
-----------
Add clock_to_precise_sql_time

Modified Files:
--------------
libpgtcl/playpen/pghelpers:
postgres-helpers.README (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgtcl/libpgtcl/playpen/pghelpers/postgres-helpers.README.diff?r1=1.1&r2=1.2)
postgres-helpers.tcl (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgtcl/libpgtcl/playpen/pghelpers/postgres-helpers.tcl.diff?r1=1.1&r2=1.2)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [pgadmin-hackers] First public pre-alpha release of GQB (Graphical Query Builder) for pgAdmin

Hi Luis

On Sun, Jul 27, 2008 at 6:13 AM, Luis Ochoa <ziul1979@gmail.com> wrote:
>
> Where is located the patch?
> http://svn.assembla.com/svn/vsqlbuilder/Jul/27/prealpha-test-gqb-july-27.patch

I'm just going to list all the issues I found here so you can work
through them easily. I'm testing on a Mac today, and feeling
particularly pedantic :-p.

- The patch failed to apply frmQuery.h. During manual application, I
found that you have app headers inbetween wx headers (wx headers
should always be first), and a wx header quoted with " " instead of <
>.

- Some compilation warnings:

./frm/frmQuery.cpp: In constructor 'frmQuery::frmQuery(frmMain*, const
wxString&, pgConn*, const wxString&, const wxString&)':
./frm/frmQuery.cpp:368: warning: unused variable 'view'
./frm/frmQuery.cpp: In constructor 'frmQuery::frmQuery(frmMain*, const
wxString&, pgConn*, const wxString&, const wxString&)':
./frm/frmQuery.cpp:368: warning: unused variable 'view'
./frm/frmQuery.cpp: In member function 'void
frmQuery::OnChangeConnection(wxCommandEvent&)':
./frm/frmQuery.cpp:881: warning: cannot pass objects of non-POD type
'class wxString' through '...'; call will abort at runtime
./frm/frmQuery.cpp: In member function 'void
frmQuery::OnTest3(wxNotebookEvent&)':
./frm/frmQuery.cpp:1027: warning: cannot pass objects of non-POD type
'class wxString' through '...'; call will abort at runtime
./frm/frmQuery.cpp: In member function 'void
frmQuery::OnChangeConnection(wxCommandEvent&)':
./frm/frmQuery.cpp:881: warning: cannot pass objects of non-POD type
'class wxString' through '...'; call will abort at runtime
./frm/frmQuery.cpp: In member function 'void
frmQuery::OnTest3(wxNotebookEvent&)':
./frm/frmQuery.cpp:1027: warning: cannot pass objects of non-POD type
'class wxString' through '...'; call will abort at runtime

(The last four *will* cause crashes - normally you just add .c_str()
to any wxString arguments passed as arguments to variadic functions).

<hits brick wall>

Following that, I ran into the same errors as Guillaume. Please supply
an updated patch, that uses only wxWidgets controls (using GTK classes
definitely isn't going to work on Mac).

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [GENERAL] recovery via base + WAL replay failure

Rob Adams wrote:
> I'm trying to demonstrate recovery using the "continuous archiving"
> backup technique. I'm using 8.3 on Windows.
>
> I made a base backup while the postgres was running using the following
> batch file:
>
> --------------------------
> psql -d test_database -U user_name -c "SELECT pg_start_backup('test');"
>
> 7za a -tzip "C:\backup\base.zip" "C:\Program Files\PostgreSQL\8.3\data"
>
> psql -d test_database -U user_name -c "SELECT pg_stop_backup();"
> --------------------------
>
> No indication of any errors. However, I am unable to recover. Here are
> my steps:
>
> 1. Stop service, replace the data directory w/ the base backup.
> 2. Create recovery.conf with this setting:
> restore_command = 'copy C:\backup\%f "%p"'
> 3. Try to start service
>
> After about 90 seconds, the dos prompt displays:
> "(postgres 8.3) service could not be started"
> "The service did not report an error"
>
> Does anyone know what I am probably doing wrong?

You'll need to look at the PostgreSQL logs to see what they say.

But I'm curious about the 7za step. It gives no errors or warnings?
IIRC, you need to use VSS on Windows to avoid sharing violations when
opening the files unless a specific open mode is used. It could be that
7za uses that by default, but it's also possible tha tit's not actually
backing up all files...

//Magnus

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[pgsql-it-generale] == Postgres Weekly News - 3 agosto 2008 ==

Quando leggerete questo, la commitfest di luglio sarà finita.
Tante nuove funzionalità sono state introdotte.
Nella commitfest di settembre prestate attenzione alle Common Table
Expressions e alle Windowing Functions.

== Postgres News prodotti ==

Rilasciato Npgsql2 RC1.
http://www.npgsql.org

Rilasciato pgbouncer 1.2.1.
http://pgfoundry.org/projects/pgbouncer/

== PostgreSQL news locali ==

Il pgDay a San Francisco ci sarà il 5 agosto. Schedule:
http://pugs.postgresql.org/node/447
Registratevi qui:
http://www.linuxworldexpo.com/live/12/ehall//SN460564

Il Prato Linux User Group terrà dei talk su PostgreSQL talks a Settembre.
Il calendario in italiano si trova all'url:
http://www.prato.linux.it/serate_a_tema_2008

Sponsorizzate il PGDay Europeo!
http://www.pgday.org/en/sponsors/campaign

E' iniziato il call for papers per il PGDay europeo.
http://www.pgday.org/en/call4papers

Il PGCon Brasile 2008 ci sara' il 26 e 27 settembre 2008 a Unicamp, Campinas.
http://pgcon.postgresql.org.br/index.en.html

Il PgDay.fr ci sarà il 4 ottobrea a Toulouse. Il Call for Papers è aperto:
http://www.postgresqlfr.org/?q=node/1686
Per registrarsi:
http://www.pgday.fr/doku.php/inscription

Il PGDay.(IT|EU) 2008 ci sarà il 17 e 18 ottobre a Prato.
http://www.pgday.org/it/

== News su PostgreSQL ==

Planet PostgreSQL: http://www.planetpostgresql.org/

General Bits, archivi e nuovi articoli occasionali:
http://www.varlena.com/GeneralBits/

PostgreSQL Weekly News è stato spedito questa settimana grazie a David Fetter.

Per segnalare news e annunci invia un email in inglese entro le ore 15,
fuso orario della costa orientale degli U.S.A, di domenica.

Per segnalazioni in inglese david@fetter.org, per segnalazioni in
Tedesco pwn@pgug.de, per segnalazioni in italiano pwn@itpug.org


== Patch applicate ==

Tom Lane committed:

- Update 8.1 and 8.0 plpython to work with Python 2.5. This backports
several fixes made during the 8.2 development cycle, but not
backported at the time for lack of confidence in the new coding. I
didn't touch 7.4 because it has more problems than this: the
configure probe for Python fails.

- Add a new, improved version of citext as a contrib module. David E.
Wheeler.

- Replace the hard-wired type knowledge in TypeCategory() and
IsPreferredType() with system catalog lookups, as was foreseen to be
necessary almost since their creation. Instead put the information
into two new pg_type columns, typcategory and typispreferred. Add
support for setting these when creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum),
allowing a crude form of user extensibility of the category list:
just use an otherwise-unused character. This seems sufficient for
foreseen uses, but we could upgrade to having an actual category
catalog someday, if there proves to be a huge demand for custom type
categories. In this patch I have attempted to hew exactly to the
behavior of the previous hardwired logic, except for introducing new
type categories for arrays, composites, and enums. In particular
the default preferred state for user-defined types remains TRUE.
That seems worth revisiting, but it should be done as a separate
patch from introducing the infrastructure. Likewise, any adjustment
of the standard set of categories should be done separately.

- Adjust citext to make use of the new ability to declare its type
category: by putting it into the standard string category, we cause
casts from citext to text to be recognized as "preferred" casts.
This eliminates the need for creation of alias functions and
operators that only serve to prevent ambiguous-function errors; get
rid of the ones that were in the original commit.

- Flip the default typispreferred setting from true to false. This
affects only type categories in which the previous coding made
*every* type preferred; so there is no change in effective behavior,
because the function resolution rules only do something different
when faced with a choice between preferred and non-preferred types
in the same category. It just seems safer and less surprising to
have CREATE TYPE default to non-preferred status ...

- Allow I/O conversion casts to be applied to or from any type that is
a member of the STRING type category, thereby opening up the
mechanism for user-defined types. This is mainly for the benefit of
citext, though; there aren't likely to be a lot of types that are
all general-purpose character strings. Per discussion with David
Wheeler.

- Require superuser privilege to create base types (but not
composites, enums, or domains). This was already effectively
required because you had to own the I/O functions, and the I/O
functions pretty much have to be written in C since we don't let PL
functions take or return cstring. But given the possible security
consequences of a malicious type definition, it seems prudent to
enforce superuser requirement directly. Per recent discussion.

- Fix parser so that we don't modify the user-written ORDER BY list in
order to represent DISTINCT or DISTINCT ON. This gets rid of a
longstanding annoyance that a view or rule using SELECT DISTINCT
will be dumped out with an overspecified ORDER BY list, and is one
small step along the way to decoupling DISTINCT and ORDER BY enough
so that hash-based implementation of DISTINCT will be possible. In
passing, improve transformDistinctClause so that it doesn't reject
duplicate DISTINCT ON items, as was reported by Steve Midgley a
couple weeks ago.

- Rearrange the querytree representation of ORDER BY/GROUP BY/DISTINCT
items as per my recent proposal: 1. Fold SortClause and GroupClause
into a single node type SortGroupClause. We were already relying on
them to be struct-equivalent, so using two node tags wasn't
accomplishing much except to get in the way of comparing items with
equal(). 2. Add an "eqop" field to SortGroupClause to carry the
associated equality operator. This is cheap for the parser to get
at the same time it's looking up the sort operator, and storing it
eliminates the need for repeated not-so-cheap lookups during
planning. In future this will also let us represent GROUP/DISTINCT
operations on datatypes that have hash opclasses but no btree
opclasses (ie, they have equality but no natural sort order). The
previous representation simply didn't work for that, since its only
indicator of comparison semantics was a sort operator. 3. Add a
hasDistinctOn boolean to struct Query to explicitly record whether
the distinctClause came from DISTINCT or DISTINCT ON. This allows
removing some complicated and not 100% bulletproof code that
attempted to figure that out from the distinctClause alone. This
patch doesn't in itself create any new capability, but it's
necessary infrastructure for future attempts to use hash-based
grouping for DISTINCT and UNION/INTERSECT/EXCEPT.

- In pgsql/src/test/regress/pg_regress.c, fix copy-and-pasteo that's
causing pg_regress to lie about which file it can't read when the
--temp-config argument is bad. Noted while wondering why buildfarm
member dungbeetle is failing ... this isn't why, but it is why the
error report isn't very helpful ...

- In pgsql/src/backend/catalog/pg_type.c, tighten up the sanity checks
in TypeCreate(): pass-by-value types must have a size that is one of
the supported values, not just anything <= sizeof(Datum).
Cross-check the alignment specification against size as well.

- Make GROUP BY work properly for datatypes that only support hashing
and not sorting. The infrastructure for this was all in place
already; it's only necessary to fix the planner to not assume that
sorting is always an available option.

Magnus Hagander committed:

- In pgsql/doc/src/sgml/install-win32.sgml, document which versions of
ActivePerl and ActiveTcl are required for building on MSVC, and that
the free distribution is enough (no need for the enterprise
version). Per gripe from Martin Zaun.

- In pgsql/doc/src/sgml/install-win32.sgml, clean up reference to
config.pl so it makes sense not only in SGML source but in the
actual web/pdf viewer...

- Move ident authentication code into auth.c along with the other
authenciation routines, leaving hba.c to deal only with processing
the HBA specific files.

- In pgsql/src/backend/libpq/auth.c, rearrange the code in auth.c so
that all functions for a single authentication method is grouped
together in a reasonably similar way, keeping the "global shared
functions" together in their own section as well. Makes it a lot
easier to find your way around the code.

Bruce Momjian committed:

- Add URL for TODO: "Consider decreasing the I/O caused by updating
tuple hint bits."

Alvaro Herrera committed:

- Add a few more DTrace probes to the backend. Robert Lor.

- Cope with Tcl versions that do not create a tclsh symlink to the
version- numbered program. Per persistent buildfarm failures. Tom
Lane.

== Patch rigettate (per ora) ==
Nessuno è stato scontentato questa settimana :-)

== Patch in attesa ==

Tatsuo Ishii sent in another revision of Yoshiuki Asaba's CTE patch.

Hitoshi Harada sent in another revision of his windowing functions
patch.

Jan Urbanski sent in two more revisions of his patch to add
selectivity functions for text search types.

KaiGai Kohei sent in another revision of his SE-PostgreSQL patch.

Abhijit Menon-Sen sent in two more revisions of his \ef (edit
function) patch for psql along with a patch to add
pg_get_functiondef() as an SQL-callable function.

Robert Lor sent in two more revisions of his DTrace probes patch.

ITAGAKI Takahiro sent in a patch to add STORAGE and reloptions to
CREATE TABLE ... LIKE.

Alvaro Herrera sent in two updates to Robert Lor's DTrace probes
patch.

ITAGAKI Takahiro sent in a patch to use NDirectFileRead and
NDirectFileWrite statistics counters for counting reads and writes in
BufFile.

Heikki Linnakangas sent in new revisions of his Relation Forks and FSM
rewrite patches, the latter depending on the former.


--
(all opinions expressed are my own)
Federico Campoli
PostgreSQL Consulting -> PGHost http://www.pghost.eu

--
Sent via pgsql-it-generale mailing list (pgsql-it-generale@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-it-generale

Re: [HACKERS] Mini improvement: statement_cost_limit

On Sun, Aug 03, 2008 at 10:57:55PM -0400, Robert Treat wrote:
>
> ISTR that what ended up killing the enthusiasm for this was that most people
> realized that this GUC was just a poor tool to take a stab at solving other
> problems (ie. rate limiting cpu for queries).

I'm not concerned with that, I want developers to have feed back on costs in
a way that is obvious.

> > > I think a variation on this could be very useful in development and test
> > > environments. Suppose it raised a warning or notice if the cost was over
> > > the limit. Then one could set a limit of a few million on the development
> > > and test servers and developers would at least have a clue that they
> > > needed to look at explain for that query. As it is now, one can exhort
> > > them to run explain, but it has no effect. Instead we later see queries
> > > killed by a 24 hour timeout with estimated costs ranging from "until they
> > > unplug the machine and dump it" to "until the sun turns into a red
> > > giant".
> >
> > Great argument. So that's 4 in favour at least.
> >
>
> Not such a great argument. Cost models on development servers can and often
> are quite different from those on production, so you might be putting an
> artifical limit on top of your developers.

We load the production dumps into our dev environment, which are the same
hardware spec, so the costs should be identical.

> I still think it is worth revisiting what problems people are trying to solve,
> and see if there are better tools they can be given to solve them. Barring
> that, I suppose a crude solution is better than nothing, though I fear people
> might point at the crude solution as a good enough solution to justify not
> working on better solutions.

Alerting developers and QA to potentially costly queries would help solve
some of the probems we are trying to solve. Better tools are welcome, an
argument that the good is the enemy of the best so we should be content with
nothing is not.

-dg

--
David Gould daveg@sonic.net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] unnecessary code in_bt_split

On Sun, 2008-08-03 at 19:44 -0400, Tom Lane wrote:
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> > I found that _bt_split function calls PageGetTempPage, but next call is
> > _bt_page_init which clear all contents anyway. Is there any reason to call
> > PageGetTempPage instead of palloc?
>
> Not violating a perfectly good abstraction?
>
> I agree that PageGetTempPage isn't amazingly efficient, but internal
> refactoring would halve its cost; and if you have some evidence that
> there's a real performance issue then we could think about adjusting
> the temp-page API to allow _bt_pageinit to be combined with it. But
> I have a real problem with hacking up _bt_split so that it will call
> PageRestoreTempPage on something it didn't get from PageGetTempPage.
>
> Considering the WAL and regular I/O that will be induced by a split,
> I kinda doubt this is even worth worrying about anyway...

Improving this should help, since the existing page is write locked
during _bt_split. The I/O won't happen at the point that these blocks
are critical contention points.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Initial Unsigned Integer data type performance test results.

Hello All,

I wanted to pass some performance data on to the group regarding the
unsigned integer
data types I am working on. I tested on two systems running Ubuntu
Hardy. The first system
is an 8 x 2.66GHz x86-64 processor system. The second system is a 2 x
533 celeron i386
system. For this test I disabled autovaccuum and manually ran the
vacuum during times that
were not timed. I also added some sleep and sync commands to try and
stabalize the test
results. The integer and unsigned integer test results were also
interleaved to compensate for
other system activities. Finally, I have not done a lot of bench
marking, so feedback and
improvement ideas are welcome!

I benchmarked four tests:
32-bit int2 vs uint2 -- My expectation is these results
would be approximately
-- equal. The uint2 casts
up to an int4 which is still 32-bits.

32-bit int4 vs uint4 -- My expectation is <> operator
should be approximately
-- equal since I explicitly
added int4 <> uint4 operators.

64-bit int2 vs uint2 -- My expectation is these results
would be approximately
-- equal. The uint2 casts
up to an int4 which is less than
-- the 64-bit processor bus width.

64-bit int4 vs uint4 -- My expectation is these results
would be approximately
-- equal. The uint4 casts
up to an int8 which is the processor
-- bus width.

Here is the definition of each column (times are displayed in seconds):

Rows -- The number of rows added to the table.
Test -- The test number (I ran each benchmark 3 times).
S Load -- Time to load the table with signed integers.
U Load -- Time to load the table with unsigned integers.
S <> OP -- Time to perform an <> operator on each row in the
table (signed integers)
U <> OP -- Time to perform an <> operator on each row in the
table (unsigned integers)
S & OP -- Time to perform an AND operator on each row in
the table (signed integers)
U & OP -- Time to perform an AND operator on each row in
the table (unsigned integers)


I still have some more investigating to do into the results of this
data (i.e. why is the signed <> OP cheaper for int2 than uint2 types,
etc),
but I wanted to share this performance data with the community. Rough
calculations show about a 4% performance hit for 32-bit processors
to use the int8 type and a 6% performance hit for 64-bit processors.
This seems like a reasonable trade-off for the reduced storage space
I am after, and the reduction in operators Greg and Tom were concerned
about. If there are no objections from the community, I will plan to
complete my implementation of Tom's proposal at:
http://archives.postgresql.org/pgsql-hackers/2008-07/msg01204.php.

Thanks!

- Ryan

P.S. The code I have so far is not ready for review. It was
implemented quickly to get performance numbers to determine if Tom's
proposal
would be acceptable by the community. I can send it out if people are
interested, but I am planning on submitting it to a future commit fest
once I have it cleaned up and better tested.

Benchmark Data:
==================================

32-bit int2 vs. uint2

Rows Test S Load U Load S <> OP U <> OP S
& OP U & OP
--------------------------------------------------------------------------------------
100 1 000.002888 000.002151 000.010881 000.014691
000.011124 000.011000
100 2 000.002780 000.002127 000.011729 000.011611
000.012014 000.011925
100 3 000.002747 000.002085 000.010193 000.010318
000.010588 000.010576

1000 1 000.003201 000.003870 000.037837 000.037360
000.032064 000.032478
1000 2 000.003259 000.003912 000.033495 000.036281
000.032502 000.035195
1000 3 000.003201 000.003913 000.039156 000.035592
000.032405 000.040543

10000 1 000.024683 000.021306 000.255958 000.329045
000.255887 000.283782
10000 2 000.020214 000.021224 000.260252 000.290933
000.281468 000.255171
10000 3 000.020371 000.020940 000.276401 000.264791
000.257598 000.257258

100000 1 001.669571 001.687523 002.591442 002.682428
003.410724 003.490362
100000 2 001.682251 001.702598 003.379377 002.855622
002.549476 002.583431
100000 3 001.693429 001.684732 002.546024 002.641240
002.540556 003.366534

500000 1 010.138317 011.014532 015.707597 015.699991
015.394598 015.502639
500000 2 010.042176 010.179163 015.290994 015.407479
015.332925 016.321578
500000 3 010.047930 010.206489 015.016276 015.430527
015.201759 015.411601

1000000 1 020.762680 022.145950 030.338606 030.997060
030.971243 031.191622
1000000 2 020.645634 021.480215 031.222100 031.044017
031.489913 031.145342
1000000 3 020.908854 021.612863 031.735141 031.378030
033.323409 031.141103

5000000 1 108.538334 109.016628 151.732077 174.010438
183.003246 191.651814
5000000 2 109.040097 108.891102 152.354661 167.138746
183.423955 193.882820
5000000 3 108.302860 109.358920 151.745248 165.654813
182.462140 178.345020

10000000 1 217.707537 220.407657 313.047263 360.890670
415.392358 413.828828
10000000 2 217.200579 219.571731 307.769243 362.820028
404.587188 412.644460
10000000 3 218.502164 225.425290 308.132310 351.845443
401.132601 411.143661


32-bit int4 vs. uint4

Rows Test S Load U Load S <> OP U <> OP S
& OP U & OP
--------------------------------------------------------------------------------------
100 1 000.001379 000.004707 000.017991 000.004928
000.005532 000.023357
100 2 000.001192 000.008546 000.007557 000.004901
000.020157 000.008509
100 3 000.001211 000.009639 000.007729 000.004634
000.020458 000.008506

1000 1 000.003032 000.024415 000.049310 000.038847
000.028273 000.033758
1000 2 000.003094 000.023647 000.053854 000.029543
000.027895 000.030389
1000 3 000.003089 000.023558 000.049282 000.031464
000.028082 000.030534

10000 1 000.022861 000.206507 000.450483 000.294142
000.270429 000.285299
10000 2 000.020130 000.218892 000.452674 000.265420
000.294738 000.280119
10000 3 000.020216 000.207972 000.498028 000.264987
000.269354 000.307225

100000 1 001.654366 002.222839 003.158899 002.711246
002.797589 003.223520
100000 2 001.635678 002.117398 003.184728 002.687387
002.732426 002.908151
100000 3 001.641013 002.228674 003.122391 002.737217
002.726568 002.854913

500000 1 010.517882 011.035098 015.867863 015.819520
016.651296 017.366898
500000 2 010.301478 010.890427 015.898800 015.694182
016.374195 017.139048
500000 3 010.308812 011.336613 016.010874 015.694566
016.172569 017.050617

1000000 1 021.748016 022.032479 031.718041 031.377681
032.836890 034.495359
1000000 2 021.668741 022.764860 031.585905 031.485409
032.597464 034.408479
1000000 3 021.797422 022.287219 031.501989 031.310628
032.891124 034.352729

5000000 1 112.363704 113.290859 156.780144 157.629888
169.741430 178.738164
5000000 2 111.912800 113.728177 155.814622 157.592556
169.063996 177.893192
5000000 3 113.204484 113.338839 155.942430 157.708378
168.438944 177.544739

10000000 1 225.834990 227.816448 314.965601 318.707127
343.067000 355.863962
10000000 2 227.519247 227.054232 315.291132 318.536013
340.437748 356.954030
10000000 3 226.436991 227.728902 316.953600 319.432702
341.731871 356.278195


64-bit int2 vs. uint2

Rows Test S Load U Load S <> OP U <> OP S
& OP U & OP
--------------------------------------------------------------------------------------
100 1 000.000264 000.000378 000.005095 000.004019
000.004019 000.003967
100 2 000.000234 000.000149 000.005168 000.007987
000.008077 000.008046
100 3 000.000283 000.000422 000.000898 000.001001
000.003046 000.003973

1000 1 000.000472 000.000406 000.005944 000.004000
000.008402 000.006523
1000 2 000.000472 000.000614 000.003220 000.007445
000.008007 000.007899
1000 3 000.000434 000.000522 000.004744 000.003945
000.003904 000.003978

10000 1 000.003583 000.002897 000.027068 000.024923
000.026969 000.027948
10000 2 000.002681 000.002879 000.023959 000.028943
000.028847 000.024163
10000 3 000.002713 000.002826 000.027868 000.024297
000.027626 000.027936

100000 1 000.147438 000.158207 000.181544 000.281516
000.216321 000.256955
100000 2 000.122763 000.158806 000.262845 000.262513
000.206650 000.242393
100000 3 000.165053 000.137694 000.199290 000.200812
000.190772 000.231532

500000 1 000.861558 001.857679 001.201773 001.141055
001.146796 001.196645
500000 2 000.751839 001.769231 001.124357 001.096142
001.154715 001.156669
500000 3 000.757383 000.746437 001.046433 001.043038
001.092662 001.188915

1000000 1 001.624921 001.501079 002.219032 002.221471
002.351225 002.259619
1000000 2 001.635181 001.490060 002.132329 002.179557
002.230080 002.230306
1000000 3 001.642645 001.578584 002.204351 002.204351
002.271596 002.251025

5000000 1 008.175122 007.608278 012.993807 024.737981
032.636002 023.532173
5000000 2 008.402995 007.788409 022.455597 022.722125
023.375628 024.364674
5000000 3 008.146802 007.560563 011.000594 023.479316
023.127872 023.647729

10000000 1 027.417696 025.444743 035.633955 044.665248
056.828230 053.103862
10000000 2 026.629527 015.461252 033.425061 047.231670
058.463149 059.917299
10000000 3 026.714370 015.133970 033.187095 045.359560
059.858288 060.539286


64-bit int4 vs. uint4

Rows Test S Load U Load S <> OP U <> OP S
& OP U & OP
--------------------------------------------------------------------------------------
100 1 000.000283 000.000146 000.000887 000.000648
000.003931 000.000884
100 2 000.000285 000.000174 000.000884 000.000690
000.000652 000.000725
100 3 000.000225 000.000137 000.000657 000.003389
000.000738 000.000720

1000 1 000.000507 000.000409 000.002872 000.002924
000.003109 000.005706
1000 2 000.000458 000.000386 000.005279 000.003111
000.003007 000.002984
1000 3 000.000526 000.000458 000.003005 000.003102
000.007094 000.003343

10000 1 000.003591 000.002837 000.026670 000.025760
000.025237 000.026846
10000 2 000.002800 000.002690 000.023960 000.029733
000.031866 000.026354
10000 3 000.002718 000.002645 000.023977 000.024667
000.024566 000.034090

100000 1 000.149074 000.134729 000.212927 000.231054
000.236246 000.267968
100000 2 000.133630 000.116737 000.224492 000.218364
000.197834 000.213061
100000 3 000.142504 000.111011 000.239096 000.227658
000.213063 000.246546

500000 1 000.758492 000.716535 001.122045 001.088708
001.189956 001.211962
500000 2 000.771229 000.762520 001.084013 001.131540
001.171574 001.171354
500000 3 000.784780 000.694077 001.110563 001.207835
001.148557 001.239808

1000000 1 001.538802 001.519817 002.143364 002.182663
002.347049 002.496311
1000000 2 001.588864 001.438750 002.196512 002.236763
002.378072 002.443330
1000000 3 001.565230 001.535085 002.127375 002.468330
002.325026 002.470508

5000000 1 008.095642 007.514390 020.867962 011.222382
024.817883 025.539325
5000000 2 008.279959 007.822827 023.514454 024.288419
025.346532 025.263223
5000000 3 008.313125 007.794659 023.427362 023.892352
026.224463 024.725105

10000000 1 025.903194 027.249769 048.426016 045.101048
051.549006 052.169178
10000000 2 025.365287 026.901960 046.175783 045.509540
049.219715 052.168185
10000000 3 027.882902 028.379166 047.237950 048.097603
049.311239 051.762996

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Mini improvement: statement_cost_limit

On Sun, 2008-08-03 at 22:57 -0400, Robert Treat wrote:

> I still think it is worth revisiting what problems people are trying
> to solve, and see if there are better tools they can be given to solve
> them. Barring that, I suppose a crude solution is better than
> nothing, though I fear people might point at the crude solution as a
> good enough solution to justify not working on better solutions.

I advocate solutions to the problems of users I've worked with.

My preference is to help people in the next release, then improve from
there. We need to work with what we have.

In this case, an existing solution has been found.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgsql-de-allgemein] Erlaubte Zeichen in Datenbanknamen

udono schrieb:
>>> Gibt es noch weitere erlaubte Zeichen oder andere Sachen die ich bei
>>> der Prüfung beachten muss?

Ich glaube, Deine Beschreibung (63 alphanumerische Zeichen) ist nicht
korrekt: es sind 64 *Bytes* (inklusive dem 0-Byte am Ende), und alle
Zeichen sind möglich.

Siehe bpchar_name in src/backend/utils/adt/varchar.c.

Allerdings ist es intelligent, die Eingabe auf Kleinbuchstaben, Ziffern und
Unterstriche zu beschränken.

>> IIRC nicht, aber ich versteh nicht ganz, warum Du den Namen einer DB als
>> Benutzereingabe prüfen willst/mußt. Der DB-Name ist doch eher, ähm,
>> statisch.
>
> Ja, bei der Software handelt es sich um ein ERP (Enterprice Resource
> Planning) Tool für kleine und mittelgroße Unternehmen.
> Wenn man eine neue einzelne Firma anlegt, dann werden alle Daten in
> eine Postgresdatenbank eingefügt. Deren Name muss der Administrator
> angeben um sie neu erstellen zu lassen. Wir haben diesen Dialog in
> das GUI gelegt, um die Konfiguration zu vereinfachen.
> Bei der Eingabe des Datenbank-Namens wird gleich auf Validität
> geprüft. (Also es sind nur alpha-nummerische Zeichen erlaubt und
> Unterstrich, das erste Zeichen muss ein Buchstabe sein, die Anzahl
> der eingegebenen Zeichen ist auf 63 begrenzt.) Quasi
> Fehlervermeidung, statt Fehlermeldung...

Ein Bedenken gegen das Design möchte ich kundtun:

Das bedeutet, daß das Programm mit einem User mit hohen Privilegien
(CREATEDB oder gar SUPERUSER) an die Datenbank verbunden sein muß.

Vielen Leuten macht das vielleicht nichts aus, aber es gibt Menschen
(und Unternehmen), für die sowas ein Ausschließungsgrund für eine
Software ist.

Warum kann das nicht einfach ein neues Schema statt einer neuen
Datenbank sein?

Liebe Grüße,
Laurenz Albe

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein