Re: [HACKERS] Can't t compile current HEAD
On Thu, May 15, 2008 at 10:00 AM, Pavel Stehule <[EMAIL PROTECTED]> wrote: > Hello > > I got some errors: > > Works for me. I am on the same platform (FC 8). If you have CVS updated, did you use -d option to get the new directories added to the repository ? I see a new include/portability directory added yesterday. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Confusing message in log file
Hi All, I changed the postgresql.conf file (of an 8.2.4 server), and issued relaod using pg_reload_config(). Following are the messages I see in the log files: May 14 21:38:40 sfphotodb001 postgres[29658]: [19-1] 2008-05-14 21:38:40 PDTLOG: received SIGHUP, reloading configuration files May 14 21:38:40 sfphotodb001 postgres[29658]: [20-1] 2008-05-14 21:38:40 PDTLOG: parameter "shared_buffers" cannot be changed after server start; configuration file change ignored May 14 21:39:03 sfphotodb001 postgres[22928]: [21-1] 2008-05-14 21:39:03 PDTLOG: archived transaction log file "00010E2300C8" What's confusing about this is that the second message says 'configuration file change ignored', so I expect the changed (newly enabled) archive_command to not take effect. But in fact, it does take effect. The message probably should be rephrased to say that this setting (shared_buffers) will not be changed. Best regards, -- [EMAIL PROTECTED] [EMAIL PROTECTED] gmail | hotmail | indiatimes | yahoo }.com EnterpriseDB http://www.enterprisedb.com Mail sent from my BlackLaptop device
[HACKERS] Can't t compile current HEAD
Hello I got some errors: In file included from gistget.c:20: ../../../../src/include/pgstat.h:15:36: error: portability/instr_time.h: není souborem ani adresářem In file included from gistget.c:20: ../../../../src/include/pgstat.h:326: error: expected specifier-qualifier-list before 'instr_time' ../../../../src/include/pgstat.h:566: error: expected specifier-qualifier-list before 'instr_time' I have Fedora 8 Regards Pavel Stehule -- 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] missing $PostgreSQL:$
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Here's a very early cut. Tell me what extra intelligence you want and
I'll work something up. It certainly looks to me like many of these
should have markers. There are probably some other files we should be
checking, too.
I suggest adding -name "*.mk" and excluding generated files, like those
in libstemmer and ecpg/test/expected. And plperl/ppport.h
second pass. There are 130 files in this list. Offhand I'd say the vast
majority should have markers.
cheers
andrew
[EMAIL PROTECTED] pgsql.head]$ find . \( \( -name 'libstemmer' -o -name
'expected' -o -name 'ppport.h' \) -prune \) -o \( -name '*.[chly]' -o
-name '*akefile' -o -name '*.mk' -o -name '*.sgml' -o -name '*.p[lm]'
\) \( -exec grep -q '\$PostgreSQL' {} \; -o -print \)
./Makefile
./src/tools/fsync/test_fsync.c
./src/tools/entab/Makefile
./src/tools/msvc/config.pl
./src/test/performance/runtests.pl
./src/test/locale/de_DE.ISO8859-1/Makefile
./src/test/locale/gr_GR.ISO8859-7/Makefile
./src/test/locale/koi8-r/Makefile
./src/test/locale/sort-test.pl
./src/test/locale/koi8-to-win1251/Makefile
./src/test/locale/test-ctype.c
./src/test/regress/Makefile
./src/test/examples/testlibpq3.c
./src/test/examples/Makefile
./src/test/examples/testlibpq.c
./src/test/examples/testlibpq4.c
./src/test/examples/testlibpq2.c
./src/include/utils/cash.h
./src/include/port/sunos4.h
./src/include/port/aix.h
./src/include/port/sco.h
./src/include/port/univel.h
./src/include/port/ultrix4.h
./src/include/port/win32/pwd.h
./src/include/port/win32/sys/wait.h
./src/include/port/bsdi.h
./src/include/port/unixware.h
./src/include/commands/proclang.h
./src/include/commands/comment.h
./src/tutorial/complex.c
./src/port/pthread-win32.h
./src/port/strtol.c
./src/port/rand.c
./src/port/strlcat.c
./src/port/strtoul.c
./src/bin/pgevent/Makefile
./src/interfaces/libpq/win32.h
./src/interfaces/libpq/win32.c
./src/interfaces/ecpg/pgtypeslib/timestamp.c
./src/interfaces/ecpg/test/thread/Makefile
./src/interfaces/ecpg/test/pgtypeslib/Makefile
./src/interfaces/ecpg/test/sql/Makefile
./src/interfaces/ecpg/test/preproc/Makefile
./src/interfaces/ecpg/test/connect/Makefile
./src/interfaces/ecpg/test/compat_informix/Makefile
./src/interfaces/ecpg/test/regression.h
./src/interfaces/ecpg/preproc/type.h
./src/interfaces/ecpg/Makefile
./src/interfaces/ecpg/include/sql3types.h
./src/interfaces/ecpg/include/sqlca.h
./src/interfaces/ecpg/include/sqlda.h
./src/interfaces/ecpg/include/Makefile
./src/interfaces/ecpg/include/sqltypes.h
./src/pl/plperl/spi_internal.c
./src/backend/utils/mb/wstrcmp.c
./src/backend/utils/mb/wstrncmp.c
./src/backend/utils/mb/conversion_procs/proc.mk
./src/backend/port/dynloader/aix.c
./src/backend/port/dynloader/univel.c
./src/backend/port/dynloader/win32.h
./src/backend/port/dynloader/univel.h
./src/backend/port/dynloader/solaris.c
./src/backend/port/dynloader/svr4.c
./src/backend/port/dynloader/unixware.c
./src/backend/port/dynloader/sunos4.c
./src/backend/port/dynloader/sco.c
./src/backend/port/dynloader/unixware.h
./src/backend/port/darwin/system.c
./src/backend/port/nextstep/port.c
./contrib/tablefunc/tablefunc.h
./contrib/tablefunc/tablefunc.c
./contrib/pg_trgm/trgm_op.c
./contrib/pg_trgm/trgm_gin.c
./contrib/pg_trgm/trgm.h
./contrib/pg_trgm/trgm_gist.c
./contrib/pgstattuple/pgstatindex.c
./contrib/btree_gist/btree_int2.c
./contrib/btree_gist/btree_time.c
./contrib/btree_gist/btree_date.c
./contrib/btree_gist/btree_int8.c
./contrib/btree_gist/btree_utils_var.h
./contrib/btree_gist/btree_cash.c
./contrib/btree_gist/btree_bytea.c
./contrib/btree_gist/btree_inet.c
./contrib/btree_gist/btree_gist.h
./contrib/btree_gist/btree_utils_var.c
./contrib/btree_gist/btree_bit.c
./contrib/btree_gist/btree_int4.c
./contrib/btree_gist/btree_numeric.c
./contrib/btree_gist/btree_gist.c
./contrib/btree_gist/btree_oid.c
./contrib/btree_gist/btree_utils_num.c
./contrib/btree_gist/btree_utils_num.h
./contrib/btree_gist/btree_float8.c
./contrib/btree_gist/btree_macaddr.c
./contrib/btree_gist/btree_ts.c
./contrib/btree_gist/btree_interval.c
./contrib/btree_gist/btree_text.c
./contrib/btree_gist/btree_float4.c
./contrib/ltree/_ltree_op.c
./contrib/ltree/_ltree_gist.c
./contrib/intarray/_int_bool.c
./contrib/intarray/_int.h
./contrib/intarray/_intbig_gist.c
./contrib/intarray/bench/bench.pl
./contrib/intarray/_int_gist.c
./contrib/intarray/_int_tool.c
./contrib/intarray/_int_op.c
./contrib/intarray/_int_gin.c
./contrib/pgcrypto/rijndael.h
./contrib/spi/autoinc.c
./contrib/spi/refint.c
./contrib/spi/timetravel.c
./contrib/xml2/xslt_proc.c
./contrib/xml2/xpath.c
./contrib/pg_standby/pg_standby.c
./contrib/pageinspect/btreefuncs.c
./contrib/seg/seg-validate.pl
./contrib/seg/sort-segments.pl
./contrib/seg/segscan.l
./contrib/seg/seg.c
./contrib/seg/segparse.y
./contrib/seg/segdata.h
./contrib/hstore/hstore.h
./contrib/hstore/hstore_io.c
./contrib/hstore/hstore_gist.c
./contrib/hstore/hstore_gin.c
./contrib/hstore/crc32.c
./c
Re: [HACKERS] missing $PostgreSQL:$
Andrew Dunstan wrote: > Here's a very early cut. Tell me what extra intelligence you want and > I'll work something up. It certainly looks to me like many of these > should have markers. There are probably some other files we should be > checking, too. I suggest adding -name "*.mk" and excluding generated files, like those in libstemmer and ecpg/test/expected. And plperl/ppport.h -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] [rfc,patch] PL/Proxy in core
On Wednesday 14 May 2008 13:29, Marko Kreen wrote: > - SGML documentation. > - Makefile review. > - Integrate regression tests into main test framework. Has PL/proxy been tested on other OSes? FreeBSD/Solaris/Windows? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Permissions restrictions for function call statistics?
The just-committed patch for tracking function call stats allows anyone connected to a given database to see all function-call stats that have been collected within that database. I am wondering whether we need to clamp down on that at all. Knowing the runtime of a function is sometimes considered a possible security risk --- for instance, it might tell you something about the data operated on by a cryptographic function, or it might tell you whether a password was good (and allowed the function to proceed with some operation). So I thought about suggesting that we only allow people to see the stats for functions that they have the right to call. If they have that right, they can just call it and measure the runtime for themselves, so this seems an adequate permission check. On the other hand, if you don't have permission to call the function, then what you are seeing in the stats view is aggregate stats about calls made by other people, with arguments that you don't know. The traditional security risks seem pretty weak in that context. So maybe we don't need to do anything. Thoughts? regards, tom lane -- 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] missing $PostgreSQL:$
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
Do we have a script that goes looking for such files? Do we need one?
I don't think we have one but it would be nice to have.
Only if it's bright enough to know about files that we intentionally
don't put $PostgreSQL$ into ...
Here's a very early cut. Tell me what extra intelligence you want and
I'll work something up. It certainly looks to me like many of these
should have markers. There are probably some other files we should be
checking, too.
cheers
andrew
[EMAIL PROTECTED] pgsql.head]$ find . \( -name '*.[chly]' -o -name
'*akefile' -o -name '*.sgml' \) \( -exec grep -q '\$PostgreSQL' {} \; -o
-print \)
./Makefile
./src/tools/fsync/test_fsync.c
./src/tools/entab/Makefile
./src/test/locale/de_DE.ISO8859-1/Makefile
./src/test/locale/gr_GR.ISO8859-7/Makefile
./src/test/locale/koi8-r/Makefile
./src/test/locale/koi8-to-win1251/Makefile
./src/test/locale/test-ctype.c
./src/test/regress/Makefile
./src/test/examples/testlibpq3.c
./src/test/examples/Makefile
./src/test/examples/testlibpq.c
./src/test/examples/testlibpq4.c
./src/test/examples/testlibpq2.c
./src/include/utils/cash.h
./src/include/snowball/libstemmer/stem_ISO_8859_1_finnish.h
./src/include/snowball/libstemmer/stem_UTF_8_german.h
./src/include/snowball/libstemmer/stem_KOI8_R_russian.h
./src/include/snowball/libstemmer/stem_ISO_8859_1_portuguese.h
./src/include/snowball/libstemmer/stem_ISO_8859_1_norwegian.h
./src/include/snowball/libstemmer/stem_ISO_8859_1_german.h
./src/include/snowball/libstemmer/api.h
./src/include/snowball/libstemmer/stem_UTF_8_dutch.h
./src/include/snowball/libstemmer/stem_UTF_8_french.h
./src/include/snowball/libstemmer/stem_UTF_8_norwegian.h
./src/include/snowball/libstemmer/stem_ISO_8859_1_dutch.h
./src/include/snowball/libstemmer/stem_UTF_8_italian.h
./src/include/snowball/libstemmer/stem_ISO_8859_1_french.h
./src/include/snowball/libstemmer/stem_ISO_8859_1_swedish.h
./src/include/snowball/libstemmer/stem_UTF_8_turkish.h
./src/include/snowball/libstemmer/stem_UTF_8_romanian.h
./src/include/snowball/libstemmer/stem_UTF_8_portuguese.h
./src/include/snowball/libstemmer/stem_UTF_8_finnish.h
./src/include/snowball/libstemmer/stem_UTF_8_english.h
./src/include/snowball/libstemmer/stem_ISO_8859_1_english.h
./src/include/snowball/libstemmer/stem_ISO_8859_1_spanish.h
./src/include/snowball/libstemmer/stem_ISO_8859_2_romanian.h
./src/include/snowball/libstemmer/stem_ISO_8859_1_italian.h
./src/include/snowball/libstemmer/stem_UTF_8_hungarian.h
./src/include/snowball/libstemmer/header.h
./src/include/snowball/libstemmer/stem_ISO_8859_1_hungarian.h
./src/include/snowball/libstemmer/stem_UTF_8_danish.h
./src/include/snowball/libstemmer/stem_ISO_8859_1_danish.h
./src/include/snowball/libstemmer/stem_UTF_8_swedish.h
./src/include/snowball/libstemmer/stem_UTF_8_porter.h
./src/include/snowball/libstemmer/stem_UTF_8_spanish.h
./src/include/snowball/libstemmer/stem_ISO_8859_1_porter.h
./src/include/snowball/libstemmer/stem_UTF_8_russian.h
./src/include/port/sunos4.h
./src/include/port/aix.h
./src/include/port/sco.h
./src/include/port/univel.h
./src/include/port/ultrix4.h
./src/include/port/win32/pwd.h
./src/include/port/win32/sys/wait.h
./src/include/port/bsdi.h
./src/include/port/unixware.h
./src/include/commands/proclang.h
./src/include/commands/comment.h
./src/tutorial/complex.c
./src/port/pthread-win32.h
./src/port/strtol.c
./src/port/rand.c
./src/port/strlcat.c
./src/port/strtoul.c
./src/bin/pgevent/Makefile
./src/interfaces/libpq/win32.h
./src/interfaces/libpq/win32.c
./src/interfaces/ecpg/pgtypeslib/timestamp.c
./src/interfaces/ecpg/test/thread/Makefile
./src/interfaces/ecpg/test/pgtypeslib/Makefile
./src/interfaces/ecpg/test/sql/Makefile
./src/interfaces/ecpg/test/expected/preproc-comment.c
./src/interfaces/ecpg/test/expected/preproc-autoprep.c
./src/interfaces/ecpg/test/expected/sql-array.c
./src/interfaces/ecpg/test/expected/compat_informix-rfmtdate.c
./src/interfaces/ecpg/test/expected/sql-indicators.c
./src/interfaces/ecpg/test/expected/preproc-variable.c
./src/interfaces/ecpg/test/expected/sql-oldexec.c
./src/interfaces/ecpg/test/expected/connect-test4.c
./src/interfaces/ecpg/test/expected/compat_informix-charfuncs.c
./src/interfaces/ecpg/test/expected/connect-test3.c
./src/interfaces/ecpg/test/expected/sql-dyntest.c
./src/interfaces/ecpg/test/expected/sql-quote.c
./src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.c
./src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.c
./src/interfaces/ecpg/test/expected/sql-code100.c
./src/interfaces/ecpg/test/expected/sql-parser.c
./src/interfaces/ecpg/test/expected/compat_informix-test_informix.c
./src/interfaces/ecpg/test/expected/preproc-type.c
./src/interfaces/ecpg/test/expected/compat_informix-test_informix2.c
./src/interfaces/ecpg/test/expected/preproc-init.c
./src/interfaces/ecpg/test/expected/Makefile
./src/interfaces/ecpg/test/expected/thread-alloc.c
Re: [HACKERS] WAL file naming sequence definition
On Wed, 2008-05-14 at 14:25 -0700, Andrew Hammond wrote: > I'd confirmation on how WAL files are named. I'm trying to write a > tool which can tell me when we are missing a WAL file from the > sequence. I initially thought that the file names were monotonically > incrementing hexadecimal numbers. This doesn't appear to be the case. > > 000101B700FD > 000101B700FE > (there seem to be a whole bunch of missing filenames in the sequence > here) > 000101B8 > 000101B80001 ... > Since I didn't specify a wal_segsize at compile time, it seems that my > XLogSegsPerFile should be > 0x / (16 * 1024 * 1024) = 255 > Which matches nicely with what I'm observing. Yes, thats the default. > So, and this is where I want the double-check, a tool which verifies > there are no missing WAL files (based on names alone) in a series of > WAL files needs to know the following. > > 1) Timeline history (although perhaps not, it could simply verify all > existing timelines) > 2) What, if any, wal_segsize was specified for the database which is > generating the WAL files Yes. I wouldn't worry too much about the timeline id. Getting them sequential within a single timeline is 99.998% of the problem. > Am I missing anything? The format of .backup files seem pretty simple > to me. So I intend to do the following. > 1) find the most recent .backup file > 2) verify that all the files required for that .backup exist > 3) see if there are any newer files, and > 4) if there are newer files, warn if any are missing from the sequence > > Would this be reasonable and is there any community interest in > open-sourcing the tool that I'm building? Sounds good. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com -- 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] What to do with inline warnings?
On Wed, May 14, 2008 at 08:25:10PM +0100, Gregory Stark wrote: > The Linux kernel does have some macros meant to mark unlikely branches > (usually assertion failures) but I'm not sure how they work. And Gcc also has > a few optimizations which are driven by profiling data but I it doesn't sound > like this is one of them. There's a macro called __builtin_expect() where you can specify what the expected value of an expression is at runtime, so gcc can use this to decide which branch is more likely, or how often a loop might run. Normally you wrap it into macros like: #define likely(x)__builtin_expect(x,1) #define unlikely(x) __builtin_expect(x,0) So you say things like: if( likely( x==0 ) ) And gcc will optimise that the branch is likely to be taken. Using macros means that you can arrange it so that for non-gcc compilers it's a no-op. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
[HACKERS] WAL file naming sequence definition
I'd confirmation on how WAL files are named. I'm trying to write a tool
which can tell me when we are missing a WAL file from the sequence. I
initially thought that the file names were monotonically incrementing
hexadecimal numbers. This doesn't appear to be the case.
000101B700FD
000101B700FE
(there seem to be a whole bunch of missing filenames in the sequence here)
000101B8
000101B80001
This pattern repeats. I hunted through the code and discovered the following
in src/include/access/xlog_internal.h.
#define XLogFilePath(path, tli, log, seg) \
snprintf(path, MAXPGPATH, XLOGDIR "/%08X%08X%08X", tli, log, seg)
So, the names are not a single hexadecimal number, but instead three of them
concatenated together. This macro is used eight times in
src/backend/access/xlog.c. It seems clear that the first number, tli, is a
TimeLineID. I wasn't completely clear on the behavior of log and seg until I
found the following, also in xlog_internal.h.
#define NextLogSeg(logId, logSeg) \
do { \
if ((logSeg) >= XLogSegsPerFile-1) \
{ \
(logId)++; \
(logSeg) = 0; \
} \
else \
(logSeg)++; \
} while (0)
So, clearly log simply increments and seg increments until it gets up to
XLogSegsPerFile. Again, xlog_internal.h knows what that is.
/*
* We break each logical log file (xlogid value) into segment files of the
* size indicated by XLOG_SEG_SIZE. One possible segment at the end of each
* log file is wasted, to ensure that we don't have problems representing
* last-byte-position-plus-1.
*/
#define XLogSegSize ((uint32) XLOG_SEG_SIZE)
#define XLogSegsPerFile (((uint32) 0x) / XLogSegSize)
In src/include/pg_config.h.in, I see
/* XLOG_SEG_SIZE is the size of a single WAL file. This must be a power of 2
and larger than XLOG_BLCKSZ (preferably, a great deal larger than
XLOG_BLCKSZ). Changing XLOG_SEG_SIZE requires an initdb. */
#undef XLOG_SEG_SIZE
Then configure tells me the following
# Check whether --with-wal-segsize was given.
if test "${with_wal_segsize+set}" = set; then
withval=$with_wal_segsize;
case $withval in
yes)
{ { echo "$as_me:$LINENO: error: argument required for
--with-wal-segsize
echo "$as_me: error: argument required for --with-wal-segsize option" >&2;}
{ (exit 1); exit 1; }; }
;;
no)
{ { echo "$as_me:$LINENO: error: argument required for
--with-wal-segsize
echo "$as_me: error: argument required for --with-wal-segsize option" >&2;}
{ (exit 1); exit 1; }; }
;;
*)
wal_segsize=$withval
;;
esac
else
wal_segsize=16
fi
case ${wal_segsize} in
1) ;;
2) ;;
4) ;;
8) ;;
16) ;;
32) ;;
64) ;;
*) { { echo "$as_me:$LINENO: error: Invalid WAL segment size. Allowed
values a
echo "$as_me: error: Invalid WAL segment size. Allowed values are
1,2,4,8,16,32,
{ (exit 1); exit 1; }; }
esac
{ echo "$as_me:$LINENO: result: ${wal_segsize}MB" >&5
echo "${ECHO_T}${wal_segsize}MB" >&6; }
cat >>confdefs.h <<_ACEOF
#define XLOG_SEG_SIZE (${wal_segsize} * 1024 * 1024)
_ACEOF
Since I didn't specify a wal_segsize at compile time, it seems that my
XLogSegsPerFile should be
0x / (16 * 1024 * 1024) = 255
Which matches nicely with what I'm observing.
So, and this is where I want the double-check, a tool which verifies there
are no missing WAL files (based on names alone) in a series of WAL files
needs to know the following.
1) Timeline history (although perhaps not, it could simply verify all
existing timelines)
2) What, if any, wal_segsize was specified for the database which is
generating the WAL files
Am I missing anything? The format of .backup files seem pretty simple to me.
So I intend to do the following.
1) find the most recent .backup file
2) verify that all the files required for that .backup exist
3) see if there are any newer files, and
4) if there are newer files, warn if any are missing from the sequence
Would this be reasonable and is there any community interest in
open-sourcing the tool that I'm building?
Andrew
Re: [HACKERS] bug in localized \df+ output
Alvaro Herrera wrote: > So, in conclusion, the problem is that the environment is bogus, but I'm > not sure if something needs to be told to psql about that. FYI, psql is computing character lengths based on the client encoding set by psql. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [rfc,patch] PL/Proxy in core
Please consider this mail as submission of PL/Proxy into core. Documentation: https://developer.skype.com/SkypeGarage/DbProjects/PlProxy Previous submission with overview: http://archives.postgresql.org/pgsql-hackers/2007-03/msg01763.php - The code has changed rather little compared to first submission, biggest changes have been select()->poll() conversion and making scanner work with flex 2.5.4. - My interest in replacing dblink has decreased, it is for -hackers to decide if this is interesting goal or not. The patch itself: http://plproxy.projects.postgresql.org/plproxy-v1.diff.gz I have not much effort into patch, except made it compile in with main source. I'd like to get general consensus that the idea is acceptable first. Following are major parts that need work before committing: - SGML documentation. - Makefile review. - Integrate regression tests into main test framework. There are 2 things that could be migrated in to core code, but this can be done later: - Compat poll() function based on select() - can be used to get rid of #ifdef HAVE_POLL in various places in core code. - rowstamp.h - all the PL-s could use it to detect row changes. There are few code beautification ideas on which I'd like to get feedback from wider audience: - Drop CONNECT statement. This was added to make creating simple dblink style calls easier, but actually its not maintainable compared to CLUSTER, it can be used only for occasional hacks. OTOH, if we want to deprecate dblink and replace it with PL/Proxy, it should probably stay. - Drop SELECT statement. This was added as it was simple to do and also to be straightforward replacement for dblink. But it's conceptually ugly. Also it gives impression that there will be UPDATE, DELETE and IF... which will not happen. The good developement strategy when using plproxy is: 1. Create regular database with function-based API, keeping an eye that interfaces would support partitioning. 2. If load grows, split database to several pieces, directing clients to db where all functions are plproxy ones which will rediect to correct partition. Having the SELECT available discourages good design where all partitions are functional on their own. -- marko Diffstat for the patch: src/include/catalog/pg_pltemplate.h|1 src/pl/Makefile|2 src/pl/plproxy/Makefile| 97 +++ src/pl/plproxy/cluster.c | 542 ++ src/pl/plproxy/execute.c | 750 + src/pl/plproxy/expected/plproxy_clustermap.out | 71 ++ src/pl/plproxy/expected/plproxy_errors.out | 66 ++ src/pl/plproxy/expected/plproxy_init.out |1 src/pl/plproxy/expected/plproxy_many.out | 116 +++ src/pl/plproxy/expected/plproxy_select.out | 37 + src/pl/plproxy/expected/plproxy_test.out | 266 src/pl/plproxy/function.c | 408 + src/pl/plproxy/main.c | 218 +++ src/pl/plproxy/parser.y| 190 ++ src/pl/plproxy/plproxy.h | 314 ++ src/pl/plproxy/poll_compat.c | 140 src/pl/plproxy/poll_compat.h | 58 + src/pl/plproxy/query.c | 299 + src/pl/plproxy/result.c| 222 +++ src/pl/plproxy/rowstamp.h | 27 src/pl/plproxy/scanner.l | 329 ++ src/pl/plproxy/sql/plproxy_clustermap.sql | 56 + src/pl/plproxy/sql/plproxy_errors.sql | 63 ++ src/pl/plproxy/sql/plproxy_init.sql| 63 ++ src/pl/plproxy/sql/plproxy_many.sql| 66 ++ src/pl/plproxy/sql/plproxy_select.sql | 37 + src/pl/plproxy/sql/plproxy_test.sql| 164 + src/pl/plproxy/type.c | 308 ++ 28 files changed, 4909 insertions(+), 2 modifications(!) -- 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] bug in localized \df+ output
Alvaro Herrera wrote: > I'm seeing this: > > Liste des fonctions > -[ RECORD 1 > ]+ > Schéma | public > Nom | tg_backlink_a > Type de données du résultat| trigger > Type de données des paramètres | After much poking around and talking to Bruce on IM I noticed that this only shows up if the client is on a multibyte locale (I'm on an UTF8 locale) and the database has been created as SQL_ASCII. So the environment is bogus: psql is calculating widths for locale C, but psql is using the other locale. Witness what happens when I run psql in a non-UTF8 environment instead: regression=# select * from baz; trouvé | détail | tròis +-+ f | ááá | 3 (1 fila) (the alignment is correct, but the accented letter show up as UTF8 sequences interpreted as latin1) And this is what I get on the UTF8 xterm: regression=# select * from baz; trouv�| détail | tròis +-+ f | ááá | 3 (1 ligne) (the accents are OK but the alignment is messed up). So, in conclusion, the problem is that the environment is bogus, but I'm not sure if something needs to be told to psql about that. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 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: [HACKERS] What to do with inline warnings?
Gregory Stark <[EMAIL PROTECTED]> writes: > Fwiw, these two call sites are only for when HeapTupleSatisfiesMVCC finds a > tuples which has been moved away by VACUUM FULL... The latter for when it > finds such a tuple but the VACUUM FULL aborted. > It seems quite likely that the compiler is actually right (by chance) and we > shouldn't be optimizing those cases at the expense of more common cases. I trimmed the original message quite a bit --- there were a lot more than two call sites that it was deciding not to inline. Maybe it's making the right choices or maybe not. regards, tom lane -- 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] What to do with inline warnings?
"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes: > On Wed, May 14, 2008 at 12:45:49PM -0400, Tom Lane wrote: >> > tqual.c: In function ‘HeapTupleSatisfiesVacuum’: >> > tqual.c:88: error: inlining failed in call to ‘SetHintBits’: call is >> > unlikely and code size would grow >> > tqual.c:1057: error: called from here >> > tqual.c:88: error: inlining failed in call to ‘SetHintBits’: call is >> > unlikely and code size would grow >> > tqual.c:1061: error: called from here >> >> Hmm, it's a bit disturbing that the compiler is taking it upon itself to >> decide that these calls are "unlikely". > > Perhaps would should give it some idea about how likely they'd be, > because clearly it has no idea now. Fwiw, these two call sites are only for when HeapTupleSatisfiesMVCC finds a tuples which has been moved away by VACUUM FULL... The latter for when it finds such a tuple but the VACUUM FULL aborted. It seems quite likely that the compiler is actually right (by chance) and we shouldn't be optimizing those cases at the expense of more common cases. -- 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
Re: [HACKERS] What to do with inline warnings?
"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes: > On Wed, May 14, 2008 at 12:45:49PM -0400, Tom Lane wrote: >> > tqual.c: In function ‘HeapTupleSatisfiesVacuum’: >> > tqual.c:88: error: inlining failed in call to ‘SetHintBits’: call is >> > unlikely and code size would grow >> > tqual.c:1057: error: called from here >> > tqual.c:88: error: inlining failed in call to ‘SetHintBits’: call is >> > unlikely and code size would grow >> > tqual.c:1061: error: called from here >> >> Hmm, it's a bit disturbing that the compiler is taking it upon itself to >> decide that these calls are "unlikely". > > Perhaps would should give it some idea about how likely they'd be, > because clearly it has no idea now. Well they're buried in umpteen nested if/else blocks. I'm not really convinced it's wrong actually. Each individual call site is actually quite unlikely in the grand scheme of things. The compiler is faced with two alternatives (or some mixture of the two). Either a) it doesn't inline the function in which case the entire HeapTupleSatisfiesMVCC likely fits in cpu cache and the entirety of SetHintBits also likely fits in cache. On the other hand it incurs the function call overhead on every call. Or b) it inlines the function in all its myriad of call sites bloating HeapTupleSatisfiesMVCC quite a bit. That avoids the function call overhead but reduces the likelihood that the function remains in cache. I think this is actually worth profiling on different architectures to make sure we're not doing more harm than good here. Bloating HeapTupleSatisfiesMVCC by what looks offhand to be probably easily a factor of 2 if not quite a bit more could actually be slowing it down significantly. Using valgrind in cachegrind mode might also be interesting. The Linux kernel does have some macros meant to mark unlikely branches (usually assertion failures) but I'm not sure how they work. And Gcc also has a few optimizations which are driven by profiling data but I it doesn't sound like this is one of them. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres 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: [HACKERS] missing $PostgreSQL:$
Bruce Momjian <[EMAIL PROTECTED]> writes: > Andrew Dunstan wrote: >> Do we have a script that goes looking for such files? Do we need one? > I don't think we have one but it would be nice to have. Only if it's bright enough to know about files that we intentionally don't put $PostgreSQL$ into ... regards, tom lane -- 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] missing $PostgreSQL:$
Andrew Dunstan wrote: > > I have just noticed that pg_standby.c is missing a $PostgreSQL:$ line. > > Do we have a script that goes looking for such files? Do we need one? I don't think we have one but it would be nice to have. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] missing $PostgreSQL:$
I have just noticed that pg_standby.c is missing a $PostgreSQL:$ line. Do we have a script that goes looking for such files? Do we need one? cheers andrew -- 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] What to do with inline warnings?
On Wed, May 14, 2008 at 12:45:49PM -0400, Tom Lane wrote: > > tqual.c: In function âHeapTupleSatisfiesVacuumâ: > > tqual.c:88: error: inlining failed in call to âSetHintBitsâ: call is > > unlikely and code size would grow > > tqual.c:1057: error: called from here > > tqual.c:88: error: inlining failed in call to âSetHintBitsâ: call is > > unlikely and code size would grow > > tqual.c:1061: error: called from here > > Hmm, it's a bit disturbing that the compiler is taking it upon itself to > decide that these calls are "unlikely". Perhaps would should give it some idea about how likely they'd be, because clearly it has no idea now. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
Re: [HACKERS] Re: [COMMITTERS] pgsql: Improve logic for finding object files on OBJS lines in contrib
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Peter Eisentraut wrote: >> For the record, I'd be interested in trying out cmake. > Then let's talk about it at the developer's meeting. Is there anything that will be useful to say unless someone's done some experiments to look at? regards, tom lane -- 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] Re: [COMMITTERS] pgsql: Improve logic for finding object files on OBJS lines in contrib
Alvaro Herrera wrote: > Peter Eisentraut wrote: > > Am Freitag, 9. Mai 2008 schrieb Magnus Hagander: > > > Right. The easiest way if you're building something for scratch > > > is to use a system that natively supports msvc, such as cmake. > > > But that means a complete replacement of the build system, which > > > is certainly "somewhat invasive".. ;-) > > > > For the record, I'd be interested in trying out cmake. > > Then let's talk about it at the developer's meeting. +1. If there is time, let's please add that to the schedule. //Magnus -- 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] Placement for a /port sort of include file?
Tom Lane wrote: > Since the function-call-statistics patch is going to need the > "instr_time" stuff that's currently in src/include/executor/instrument.h, > I was looking at splitting that out into its own include file. My first > thought about where to put instr_time.h was under src/include/port/, > since it's basically a portability abstraction. But all the files that > are in there right now are platform-specific, so that doesn't seem quite > right. The precedent of rusagestub.h, getopt_long.h, and a few others > is to just drop it into src/include/ but that seems a bit ugly too. > Any thoughts on the matter? src/include/portable -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Placement for a /port sort of include file?
Since the function-call-statistics patch is going to need the "instr_time" stuff that's currently in src/include/executor/instrument.h, I was looking at splitting that out into its own include file. My first thought about where to put instr_time.h was under src/include/port/, since it's basically a portability abstraction. But all the files that are in there right now are platform-specific, so that doesn't seem quite right. The precedent of rusagestub.h, getopt_long.h, and a few others is to just drop it into src/include/ but that seems a bit ugly too. Any thoughts on the matter? regards, tom lane -- 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] What to do with inline warnings?
Peter Eisentraut <[EMAIL PROTECTED]> writes: > What do we do with warnings generated by -Winline? I believe we just put that in to see how many places inlining was being done or not. If you want to compile with -Werror you'd better take it out. > tqual.c: In function âHeapTupleSatisfiesVacuumâ: > tqual.c:88: error: inlining failed in call to âSetHintBitsâ: call is > unlikely and code size would grow > tqual.c:1057: error: called from here > tqual.c:88: error: inlining failed in call to âSetHintBitsâ: call is > unlikely and code size would grow > tqual.c:1061: error: called from here Hmm, it's a bit disturbing that the compiler is taking it upon itself to decide that these calls are "unlikely". regards, tom lane -- 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] Re: [COMMITTERS] pgsql: Improve logic for finding object files on OBJS lines in contrib
Peter Eisentraut wrote: > Am Freitag, 9. Mai 2008 schrieb Magnus Hagander: > > Right. The easiest way if you're building something for scratch is to > > use a system that natively supports msvc, such as cmake. But that means > > a complete replacement of the build system, which is certainly > > "somewhat invasive".. ;-) > > For the record, I'd be interested in trying out cmake. Then let's talk about it at the developer's meeting. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] how to perform silent installation on linux and solaris
Am Mittwoch, 14. Mai 2008 schrieb ranjit singh: > I have been trying to perform silent installation of postgres on linux and > solaris …..please help me with this apt-get|yum install postgresql >/dev/null or thereabouts ... -- 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] [COMMITTERS] pgsql: Improve logic for finding object files on OBJS lines in contrib
Peter Eisentraut wrote: Am Freitag, 9. Mai 2008 schrieb Tom Lane: Alvaro Herrera <[EMAIL PROTECTED]> writes: Andrew Dunstan wrote: Log Message: --- Improve logic for finding object files on OBJS lines in contrib Makefiles. If this unbreaks buildfarm mastodon, apply everywhere. I start to wonder why don't we just implement our own make in Perl ... http://search.cpan.org/~mhosken/Font-Fret-1.202/pmake.bat Interesting. But surely putting a GNU make binary at some download location would be even easier. As I have already pointed out elsewhere: "The point is not to emulate make. Gmake for windows already exists, anyway. The point is that building for MSVC is so very different from the way you build everywhere else. Our current tools build MSVC project files and then drive the build from there. Having a make equivalent won't help us much. " cheers andrew -- 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] Re: [COMMITTERS] pgsql: Improve logic for finding object files on OBJS lines in contrib
Am Freitag, 9. Mai 2008 schrieb Magnus Hagander: > Right. The easiest way if you're building something for scratch is to > use a system that natively supports msvc, such as cmake. But that means > a complete replacement of the build system, which is certainly > "somewhat invasive".. ;-) For the record, I'd be interested in trying out cmake. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] What to do with inline warnings?
What do we do with warnings generated by -Winline? I see this now: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -Werror -I../../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -c -o tuplesort.o tuplesort.c -MMD -MP -MF .deps/tuplesort.Po cc1: warnings being treated as errors tuplesort.c: In function ‘comparetup_index_btree’: tuplesort.c:2474: error: inlining failed in call to ‘myFunctionCall2’: --param large-stack-frame-growth limit reached tuplesort.c:2525: error: called from here tuplesort.c:2474: error: inlining failed in call to ‘myFunctionCall2’: --param large-stack-frame-growth limit reached tuplesort.c:2525: error: called from here and this: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -Werror -I../../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -c -o tqual.o tqual.c -MMD -MP -MF .deps/tqual.Po cc1: warnings being treated as errors tqual.c: In function ‘HeapTupleSatisfiesVacuum’: tqual.c:88: error: inlining failed in call to ‘SetHintBits’: call is unlikely and code size would grow tqual.c:1057: error: called from here tqual.c:88: error: inlining failed in call to ‘SetHintBits’: call is unlikely and code size would grow tqual.c:1061: error: called from here tqual.c:88: error: inlining failed in call to ‘SetHintBits’: call is unlikely and code size would grow tqual.c:1073: error: called from here tqual.c:88: error: inlining failed in call to ‘SetHintBits’: call is unlikely and code size would grow tqual.c:1077: error: called from here tqual.c:88: error: inlining failed in call to ‘SetHintBits’: call is unlikely and code size would grow tqual.c:1092: error: called from here tqual.c:88: error: inlining failed in call to ‘SetHintBits’: call is unlikely and code size would grow tqual.c:1099: error: called from here tqual.c:88: error: inlining failed in call to ‘SetHintBits’: call is unlikely and code size would grow tqual.c:1146: error: called from here tqual.c:88: error: inlining failed in call to ‘SetHintBits’: call is unlikely and code size would grow tqual.c:1164: error: called from here tqual.c:88: error: inlining failed in call to ‘SetHintBits’: call is unlikely and code size would grow tqual.c:1171: error: called from here -- 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] [COMMITTERS] pgsql: Improve logic for finding object files on OBJS lines in contrib
Am Freitag, 9. Mai 2008 schrieb Tom Lane: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Andrew Dunstan wrote: > >> Log Message: > >> --- > >> Improve logic for finding object files on OBJS lines in contrib > >> Makefiles. If this unbreaks buildfarm mastodon, apply everywhere. > > > > I start to wonder why don't we just implement our own make in Perl ... > > http://search.cpan.org/~mhosken/Font-Fret-1.202/pmake.bat Interesting. But surely putting a GNU make binary at some download location would be even easier. -- 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] psql \? help display
Patch applied, matching attached output. More suggestions welcomed.
---
Bruce Momjian wrote:
> Shane Ambler wrote:
> > Bruce Momjian wrote:
> > > Alvaro Herrera wrote:
> > >> Bruce Momjian wrote:
> > >>> I promised to review our psql \? output to see if I could improve it,
> > >>> particularly the "General" section at the top. Below are the results.
> > >>>
> > >>> Are the new sections ideal, and in the best ordering? Should \copyright
> > >>> be kept in "General" at the top? Should \? be listed?
> > >> Why do we have a section named "Copy, Large Objects"? It would seem to
> > >> make sense to put the LO stuff on its own section.
> > >
> > > OK, new version attached. I moved \copy into "External" and relabled
> > > the section as just "Large Object" (singular?).
> > >
> >
> > I would think copy would fit better with i/o - basically a
> > subset/variation of \i
> > external is more for executing external code than importing data.
>
> OK, new version attached.
>
> > Yes singular - all the others are singular. If we go plural variable and
> > maybe connection would fit plural as well (or maybe after the multi
> > connection patch)?
>
> OK, singular.
>
> --
> Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
> General
> \copyright show PostgreSQL usage and distribution terms
> \h [NAME] help on syntax of SQL commands, * for all commands
> \q quit psql
>
> Query Buffer
> \e [FILE] edit the query buffer (or file) with external editor
> \g [FILE] send query buffer to server (and results to file or |pipe)
> \p show the contents of the query buffer
> \r reset (clear) the query buffer
> \s [FILE] display history or save it to file
> \w FILEwrite query buffer to file
>
> Input/Output
> \copy ... perform SQL COPY with data stream to the client host
> \echo [STRING] write string to standard output
> \i FILEexecute commands from file
> \o [FILE] send all query results to file or |pipe
> \qecho [STRING] write string to query output stream (see \o)
>
> Informational
> \d [NAME] describe table, index, sequence, or view
> \d{t|i|s|v|S} [PATTERN] (add "+" for more detail)
> list tables/indexes/sequences/views/system tables
> \da [PATTERN] list aggregate functions
> \db [PATTERN] list tablespaces (add "+" for more detail)
> \dc [PATTERN] list conversions
> \dClist casts
> \dd [PATTERN] show comment for object
> \dD [PATTERN] list domains
> \df [PATTERN] list functions (add "+" for more detail)
> \dF [PATTERN] list text search configurations (add "+" for more detail)
> \dFd [PATTERN] list text search dictionaries (add "+" for more detail)
> \dFt [PATTERN] list text search templates
> \dFp [PATTERN] list text search parsers (add "+" for more detail)
> \dg [PATTERN] list roles (groups)
> \dn [PATTERN] list schemas (add "+" for more detail)
> \do [NAME] list operators
> \dllist large objects, same as \lo_list
> \dp [PATTERN] list table, view, and sequence access privileges
> \dT [PATTERN] list data types (add "+" for more detail)
> \du [PATTERN] list roles (users)
> \l list all databases (add "+" for more detail)
> \z [PATTERN] list table, view, and sequence access privileges (same as
> \dp)
>
> Formatting
> \a toggle between unaligned and aligned output mode
> \C [STRING]set table title, or unset if none
> \f [STRING]show or set field separator for unaligned query output
> \H toggle HTML output mode (currently off)
> \pset NAME [VALUE] set table output option
> (NAME := {format|border|expanded|fieldsep|footer|null|
> numericlocale|recordsep|tuples_only|title|tableattr|pager})
> \t show only rows (currently off)
> \T [STRING]set HTML tag attributes, or unset if none
> \x toggle expanded output (currently off)
>
> Connection
> \c[onnect] [DBNAME|- USER|- HOST|- PORT|-]
> connect to new database (currently "test")
> \encoding [ENCODING] show or set client encoding
> \password [USERNAME] securely change the password for a user
>
> External
> \cd [DIR] change the current working directory
> \timingtoggle timing of commands (currently off)
> \! [COMMAND] execute command in shell or start interactive shell
>
> Variable
> \prompt [TEXT] NAME prompt user to set internal variable
> \set [NAME [VALUE]] set internal variable, or list all if no parameters
> \unset NAME unset (delete) internal variable
>
> Large Object
> \lo_export LOBOID FILE
> \lo_import FILE [COMMENT]
> \lo_list
> \lo
[HACKERS] CVS HEAD warnings fixed
A few warnings have crept into CVS HEAD; the attached patch fixes them. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: src/bin/scripts/common.h === RCS file: /cvsroot/pgsql/src/bin/scripts/common.h,v retrieving revision 1.19 diff -c -c -r1.19 common.h *** src/bin/scripts/common.h 1 Jan 2008 19:45:56 - 1.19 --- src/bin/scripts/common.h 14 May 2008 15:11:36 - *** *** 42,45 --- 42,47 extern void setup_cancel_handler(void); + extern char *pg_strdup(const char *string); + #endif /* COMMON_H */ Index: src/interfaces/ecpg/ecpglib/prepare.c === RCS file: /cvsroot/pgsql/src/interfaces/ecpg/ecpglib/prepare.c,v retrieving revision 1.27 diff -c -c -r1.27 prepare.c *** src/interfaces/ecpg/ecpglib/prepare.c 12 May 2008 16:29:04 - 1.27 --- src/interfaces/ecpg/ecpglib/prepare.c 14 May 2008 15:11:37 - *** *** 117,123 struct statement *stmt; struct prepared_statement *this, *prev; - struct sqlca_t *sqlca = ECPGget_sqlca(); PGresult *query; con = ecpg_get_connection(connection_name); --- 117,122 -- 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] Execution Plan Cost
The read-only plan of the query (SELECT $1 > 5) is prepared, so there is not parsing or planning. Any insight into what operations account for the executor startup/shutdown time? Thanks a lot, Luis Vargas On May 8 2008, Tom Lane wrote: Luis Vargas <[EMAIL PROTECTED]> writes: At the backend, I'm measuring the cost of executing (via SPI_execute_plan) the read-only plan of a simple query with no reference to tables. E.g. simpleplan(int) AS SELECT $1 > 5 Executing this plan via SPI_execute takes around 70% more time than directly executing the relevant operator function (int4gt) and using DatumGetBool. Only that much? I'd have expected it to be several hundred times slower, considering that int4gt is an utterly trivial function and executor startup/shutdown is a fairly heavyweight operation. regards, tom lane -- ** PhD Research Student Room FE04, Computer Laboratory, University of Cambridge Office: +44 (0) 1223 763 776 Mobile: +44 (0) 7767 086 105 MSN Messenger: [EMAIL PROTECTED] ** -- 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] [PATCHES] stored procedure stats in collector
[ redirecting to pghackers for wider discussion ] Martin Pihlak <[EMAIL PROTECTED]> writes: >> What I think we should do about that is forget tracking getrusage()'s >> user/system/real time and just track elapsed time. > I find the utime/stime quite useful, compared with the actual time it > enables us to distinguish waiters (remote calls, sleeps, etc) from the > actual CPU hogs. Well, what it is going to cost us to have that is double the space in the pgstats file (64 bytes per function instead of 32) --- and that isn't a choice we can flip with a GUC. This is a hot button for a lot of people because we know that bloat in the pgstats file translates directly to continual I/O overhead. (Perhaps that'll be fixed by the time this patch hits production, but I'm not holding my breath.) The runtime overhead is pretty daunting also. It's not just twice as many kernel calls, it's which ones you are making. On a lot of modern machines gettimeofday() is optimized to not enter the kernel at all, while getrusage() will hardly be. [ click click, test test ] On my x86_64 Fedora 8 machine, it appears that gettimeofday() requires about 60 nsec per call, whereas getrusage(RUSAGE_SELF) requires 788 nsec. One other point here is that accuracy of the results is questionable. On Windows we will certainly find that gettimeofday is useless and we need to use QueryPerformanceCounter instead (see the code in instrument.h/.c). I wonder what the accuracy of GetProcessTimes is and whether it will even deliver answers consistent with QueryPerformanceCounter. On Unix-ish machines the corresponding worry is that getrusage results might be tracked only to the clock tick and not any finer grain. Double the pgstats storage and a dozen times as much runtime overhead in exchange for questionable numbers is a pretty hard sell. I remain of the opinion that we should just track elapsed time. regards, tom lane -- 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] Syntax decisions for pl/pgsql RAISE extension
"Zeugswetter Andreas OSB sIT" <[EMAIL PROTECTED]> writes: > Other db's go with SQLCODE and SQLSTATE. > Would SQLCODE be better than ERRCODE ? No, because SQLCODE has a specific meaning, and it's *not* either a condition name or a SQLSTATE --- it's the old SQL89-era error code numbering. I think this would just create confusion. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] how to perform silent installation on linux and solaris
Hi All I have been trying to perform silent installation of postgres on linux and solaris …..please help me with this Thanks and Regards Ranjeet Singh
Re: [HACKERS] Syntax decisions for pl/pgsql RAISE extension
> So right now I'm thinking I like my original proposal > http://archives.postgresql.org/pgsql-hackers/2008-05/msg00357.php > with the exception that we should go with > SQLSTATE 'xyzzy' > as the syntax in EXCEPTION lists. Also I'm willing to go with > ERRCODE rather than CODE as the name of the USING option, since Other db's go with SQLCODE and SQLSTATE. Would SQLCODE be better than ERRCODE ? SQLCODE is usually an integer value, but the values correspond to the strings used in pg. (Think of the strings as typedefs for a number, like DEVIDE_BY_ZERO == -11028 SQLSTATE '22012') Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
