[PATCHES] Assorted typos
A few assorted typos and grammar corrections I caught while skimming source Index: src/backend/access/gin/ginvacuum.c === RCS file: /projects/cvsroot/pgsql/src/backend/access/gin/ginvacuum.c,v retrieving revision 1.7 diff -c -r1.7 ginvacuum.c *** src/backend/access/gin/ginvacuum.c 4 Oct 2006 00:29:48 - 1.7 --- src/backend/access/gin/ginvacuum.c 4 Jan 2007 12:45:44 - *** *** 34,40 /* * Cleans array of ItemPointer (removes dead pointers) * Results are always stored in *cleaned, which will be allocated ! * if its needed. In case of *cleaned!=NULL caller is resposible to * enough space. *cleaned and items may point to the same * memory addres. */ --- 34,40 /* * Cleans array of ItemPointer (removes dead pointers) * Results are always stored in *cleaned, which will be allocated ! * if it's needed. In case of *cleaned!=NULL caller is resposible to * enough space. *cleaned and items may point to the same * memory addres. */ Index: src/backend/access/heap/tuptoaster.c === RCS file: /projects/cvsroot/pgsql/src/backend/access/heap/tuptoaster.c,v retrieving revision 1.66 diff -c -r1.66 tuptoaster.c *** src/backend/access/heap/tuptoaster.c5 Oct 2006 23:33:33 - 1.66 --- src/backend/access/heap/tuptoaster.c4 Jan 2007 12:45:45 - *** *** 1113,1119 return; /* !* Open the toast relation and it's index */ toastrel = heap_open(attr-va_content.va_external.va_toastrelid, RowExclusiveLock); --- 1113,1119 return; /* !* Open the toast relation and its index */ toastrel = heap_open(attr-va_content.va_external.va_toastrelid, RowExclusiveLock); *** *** 1337,1343 endoffset = (sliceoffset + length - 1) % TOAST_MAX_CHUNK_SIZE; /* !* Open the toast relation and it's index */ toastrel = heap_open(attr-va_content.va_external.va_toastrelid, AccessShareLock); --- 1337,1343 endoffset = (sliceoffset + length - 1) % TOAST_MAX_CHUNK_SIZE; /* !* Open the toast relation and its index */ toastrel = heap_open(attr-va_content.va_external.va_toastrelid, AccessShareLock); Index: src/include/catalog/pg_type.h === RCS file: /projects/cvsroot/pgsql/src/include/catalog/pg_type.h,v retrieving revision 1.172 diff -c -r1.172 pg_type.h *** src/include/catalog/pg_type.h 4 Oct 2006 00:30:08 - 1.172 --- src/include/catalog/pg_type.h 4 Jan 2007 12:45:59 - *** *** 236,242 * */ ! /* keep the following ordered by OID so that later changes can be made easier*/ /* Make sure the typlen, typbyval, and typalign values here match the initial values for attlen, attbyval, and attalign in both places in pg_attribute.h --- 236,242 * */ ! /* keep the following ordered by OID so that later changes can be made more easily */ /* Make sure the typlen, typbyval, and typalign values here match the initial values for attlen, attbyval, and attalign in both places in pg_attribute.h -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Assorted typos
Gregory, You missed one in the first sentence you fixed: ! * if its needed. In case of *cleaned!=NULL caller is resposible to s/resposible/responsible/ Regards, -- Guillaume ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [PATCHES] Patch to log usage of temporary files
In response to Andrew Dunstan [EMAIL PROTECTED]: Bill Moran wrote: Andrew Dunstan [EMAIL PROTECTED] wrote: Bill Moran wrote: +if (trace_temp_files != -1) Might be more robust to say if (trace_temp_files = 0) Because it would allow for the easy addition of more negative numbers with magic value? because ISTM any negative number here should mean no action is to be taken. Otherwise how else is it different from 0? ?? I specified in the GUC config that minimum allowable value is -1. /usr/local/etc/rc.d/postgresql start FATAL: -5 is outside the valid range for parameter trace_temp_files (-1 .. 2147483647) set trace_temp_files to -8; ERROR: -8 is outside the valid range for parameter trace_temp_files (-1 .. 2147483647) Perhaps there's another reason to use the = 0 check, but handling invalid values with POLA doesn't seem to be a good one. -- Bill Moran Collaborative Fusion Inc. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] wal_checksum = on (default) | off
In this thread, I outlined an idea for reducing cost of WAL CRC checking http://archives.postgresql.org/pgsql-hackers/2006-10/msg01299.php wal_checksum = on (default) | off Recovery can occur with/without same setting of wal_checksum, to avoid complications from crashes immediately after turning GUC on. Patch enclosed here against CVS HEAD, passes make check. Useful reduction in CPU for both normal operation and recovery. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ? GNUmakefile ? RUIP-Oct12.patch ? UIP-datetime.patch ? WAL_notes.txt ? autovac.patch ? backup_minor_changes.patch ? backup_single_transaction.patch ? backup_typo.patch ? cache_option.sql ? check ? checl ? commitsiblings.v1.patch ? config.log ? config.status ? copy_noWAL.patch ? copy_noWAL2.patch ? crc ? d.out ? datatype_frequency.sql ? dbtValidate.sql ? ddl_caveats.patch ? edbDataValidation.sql ? error.sql ? executestricttest ? explain_analyze_timer.v1.patch ? f.sql ? faq.patch ? fastcopytest.sql ? iub_doc.patch ? iubackup.patch ? keepcache.patch ? logfile ? notintransblock.patch ? num_commits++ ? on.sql ? pg_standby.v2.tar ? pg_standby.v3.tar ? pgbenchValidate.sql ? pgre.tar ? pitr_cleanup.patch ? portals_per_user.v1.patch ? ps.txt ? relationkeepcache.patch ? relopt ? restartablerecovery_docs.patch ? ri_initial_check.sql ? sel.patch ? singletransdocpatch.patch ? sss ? table_options.patch ? test_warm_standby.tar ? testcrc ? toast_options.sql ? toast_relopts.patch ? toastcache.patch ? tracedocs.patch ? uip_both.patch ? unlink_pg_internal_at_startup.patch ? wal_checksum.v1.patch ? wrap_limit.patch ? xlog_clog_truncate.patch ? xlog_relcache.patch ? xlogswitchtuning.patch ? xlogswitchtuning2.patch ? contrib/pg_relation_extend ? contrib/pg_standby ? contrib/pgbench/.runtest.sh.swp ? contrib/pgbench/pgbench ? contrib/pgbench/tpc_b.sql ? contrib/pgbench/truckin.pgb ? doc/src/sgml/check ? doc/src/sgml/trace.sgml ? src/Makefile.global ? src/backend/postgres ? src/backend/access/nbtree/nbttuple.c ? src/backend/catalog/postgres.bki ? src/backend/catalog/postgres.description ? src/backend/catalog/postgres.shdescription ? src/backend/utils/mb/conversion_procs/conversion_create.sql ? src/backend/utils/mb/conversion_procs/ascii_and_mic/libascii_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/cyrillic_and_mic/libcyrillic_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/euc_cn_and_mic/libeuc_cn_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/euc_jp_and_sjis/libeuc_jp_and_sjis.so.0.0 ? src/backend/utils/mb/conversion_procs/euc_kr_and_mic/libeuc_kr_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/euc_tw_and_big5/libeuc_tw_and_big5.so.0.0 ? src/backend/utils/mb/conversion_procs/latin2_and_win1250/liblatin2_and_win1250.so.0.0 ? src/backend/utils/mb/conversion_procs/latin_and_mic/liblatin_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_ascii/libutf8_and_ascii.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_big5/libutf8_and_big5.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_cyrillic/libutf8_and_cyrillic.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_cn/libutf8_and_euc_cn.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_jp/libutf8_and_euc_jp.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_kr/libutf8_and_euc_kr.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_tw/libutf8_and_euc_tw.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_gb18030/libutf8_and_gb18030.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_gbk/libutf8_and_gbk.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_iso8859/libutf8_and_iso8859.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_iso8859_1/libutf8_and_iso8859_1.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_johab/libutf8_and_johab.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_sjis/libutf8_and_sjis.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_uhc/libutf8_and_uhc.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_win/libutf8_and_win.so.0.0 ? src/bin/initdb/initdb ? src/bin/ipcclean/ipcclean ? src/bin/pg_config/pg_config ? src/bin/pg_controldata/pg_controldata ? src/bin/pg_ctl/pg_ctl ? src/bin/pg_dump/pg_dump ? src/bin/pg_dump/pg_dumpall ? src/bin/pg_dump/pg_restore ? src/bin/pg_resetxlog/pg_resetxlog ? src/bin/psql/psql ? src/bin/scripts/clusterdb ? src/bin/scripts/createdb ? src/bin/scripts/createlang ? src/bin/scripts/createuser ? src/bin/scripts/dropdb ? src/bin/scripts/droplang ? src/bin/scripts/dropuser ? src/bin/scripts/reindexdb ? src/bin/scripts/vacuumdb ? src/include/pg_config.h ? src/include/stamp-h ? src/interfaces/ecpg/compatlib/libecpg_compat.so.2.2 ? src/interfaces/ecpg/ecpglib/libecpg.so.5.2 ? src/interfaces/ecpg/include/ecpg_config.h ? src/interfaces/ecpg/pgtypeslib/libpgtypes.so.2.2 ? src/interfaces/ecpg/preproc/ecpg ? src/interfaces/ecpg/test/pg_regress ? src/interfaces/ecpg/test/compat_informix/charfuncs ?
Re: [HACKERS] [PATCHES] Patch to log usage of temporary files
Bill Moran wrote: In response to Andrew Dunstan [EMAIL PROTECTED]: Bill Moran wrote: Andrew Dunstan [EMAIL PROTECTED] wrote: Bill Moran wrote: + if (trace_temp_files != -1) Might be more robust to say if (trace_temp_files = 0) Because it would allow for the easy addition of more negative numbers with magic value? because ISTM any negative number here should mean no action is to be taken. Otherwise how else is it different from 0? ?? I specified in the GUC config that minimum allowable value is -1. OK, missed that, sorry. Please return to normal viewing ... cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Assorted typos
Gregory Stark [EMAIL PROTECTED] writes: A few assorted typos and grammar corrections I caught while skimming source Applied, thanks. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Assorted typos
Guillaume Smet [EMAIL PROTECTED] writes: s/resposible/responsible/ Somebody seems to have caught that already. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Patch to log usage of temporary files
Bill Moran [EMAIL PROTECTED] writes: Andrew Dunstan [EMAIL PROTECTED] wrote: Might be more robust to say if (trace_temp_files = 0) I specified in the GUC config that minimum allowable value is -1. I'd still tend to go with Andrew's suggestion because it makes this particular bit of code self-defending against bad values. Yes, it's reasonably safe given that bit of coding way over yonder in guc.c, but there's no particularly good reason why this code has to depend on that to avoid doing something stupid. And it's easier to understand too --- you don't have to go looking in guc.c to convince yourself it's safe. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] wal_checksum = on (default) | off
Simon Riggs [EMAIL PROTECTED] writes: In this thread, I outlined an idea for reducing cost of WAL CRC checking http://archives.postgresql.org/pgsql-hackers/2006-10/msg01299.php wal_checksum = on (default) | off This still seems awfully dangerous to me. Recovery can occur with/without same setting of wal_checksum, to avoid complications from crashes immediately after turning GUC on. Surely not. Otherwise even the on setting is not really a defense. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] wal_checksum = on (default) | off
On Thu, 2007-01-04 at 10:00 -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: In this thread, I outlined an idea for reducing cost of WAL CRC checking http://archives.postgresql.org/pgsql-hackers/2006-10/msg01299.php wal_checksum = on (default) | off This still seems awfully dangerous to me. Understood. Recovery can occur with/without same setting of wal_checksum, to avoid complications from crashes immediately after turning GUC on. Surely not. Otherwise even the on setting is not really a defense. Only when the CRC is exactly zero, which happens very very rarely. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] wal_checksum = on (default) | off
Simon Riggs [EMAIL PROTECTED] writes: On Thu, 2007-01-04 at 10:00 -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: Recovery can occur with/without same setting of wal_checksum, to avoid complications from crashes immediately after turning GUC on. Surely not. Otherwise even the on setting is not really a defense. Only when the CRC is exactly zero, which happens very very rarely. It works most of the time doesn't exactly satisfy me. What's the use-case for changing the variable on the fly anyway? Seems a better solution is just to lock down the setting at postmaster start. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Patch to log usage of temporary files
In response to Tom Lane [EMAIL PROTECTED]:
Bill Moran [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] wrote:
Might be more robust to say
if (trace_temp_files = 0)
I specified in the GUC config that minimum allowable value is -1.
I'd still tend to go with Andrew's suggestion because it makes this
particular bit of code self-defending against bad values. Yes, it's
reasonably safe given that bit of coding way over yonder in guc.c,
but there's no particularly good reason why this code has to depend
on that to avoid doing something stupid. And it's easier to understand
too --- you don't have to go looking in guc.c to convince yourself it's
safe.
Ahh ... well, I've probably already argued about it more than it's worth.
The patch is easy enough to adjust, find attached.
--
Bill Moran
Collaborative Fusion Inc.
diff -c -r src.orig/backend/storage/file/fd.c src/backend/storage/file/fd.c
*** src.orig/backend/storage/file/fd.c Thu Dec 7 15:44:42 2006
--- src/backend/storage/file/fd.c Wed Jan 3 15:05:54 2007
***
*** 50,55
--- 50,56
#include access/xact.h
#include storage/fd.h
#include storage/ipc.h
+ #include utils/guc.h
/*
***
*** 938,944
void
FileClose(File file)
{
! Vfd *vfdP;
Assert(FileIsValid(file));
--- 939,946
void
FileClose(File file)
{
! Vfd *vfdP;
! struct stat filestats;
Assert(FileIsValid(file));
***
*** 968,973
--- 970,992
{
/* reset flag so that die() interrupt won't cause problems */
vfdP-fdstate = ~FD_TEMPORARY;
+ PG_TRACE1(temp__file__cleanup, vfdP-fileName);
+ if (trace_temp_files = 0)
+ {
+ if (stat(vfdP-fileName, filestats) == 0)
+ {
+ if (filestats.st_size = trace_temp_files)
+ {
+ ereport(LOG,
+ (errmsg(temp file: size %lu path \%s\,
+ filestats.st_size, vfdP-fileName)));
+ }
+ }
+ else
+ {
+ elog(LOG, Could not stat \%s\: %m, vfdP-fileName);
+ }
+ }
if (unlink(vfdP-fileName))
elog(LOG, failed to unlink \%s\: %m,
vfdP-fileName);
diff -c -r src.orig/backend/utils/misc/guc.c src/backend/utils/misc/guc.c
*** src.orig/backend/utils/misc/guc.c Wed Nov 29 09:50:07 2006
--- src/backend/utils/misc/guc.c Wed Jan 3 13:51:14 2007
***
*** 180,186
int log_min_messages = NOTICE;
int client_min_messages = NOTICE;
int log_min_duration_statement = -1;
!
int num_temp_buffers = 1000;
char *ConfigFileName;
--- 180,187
int log_min_messages = NOTICE;
int client_min_messages = NOTICE;
int log_min_duration_statement = -1;
! int trace_temp_files = -1;
!
int num_temp_buffers = 1000;
char *ConfigFileName;
***
*** 1471,1477
log_min_duration_statement,
-1, -1, INT_MAX / 1000, NULL, NULL
},
!
{
{bgwriter_delay, PGC_SIGHUP, RESOURCES,
gettext_noop(Background writer sleep time between rounds in milliseconds),
--- 1472,1478
log_min_duration_statement,
-1, -1, INT_MAX / 1000, NULL, NULL
},
!
{
{bgwriter_delay, PGC_SIGHUP, RESOURCES,
gettext_noop(Background writer sleep time between rounds in milliseconds),
***
*** 1657,1662
--- 1658,1673
},
server_version_num,
PG_VERSION_NUM, PG_VERSION_NUM, PG_VERSION_NUM, NULL, NULL
+ },
+
+ {
+ {trace_temp_files, PGC_USERSET, LOGGING_WHAT,
+ gettext_noop(Log the use of temp files larger than this size.),
+ gettext_noop(Size and location of each temp file is reported.),
+ NULL
+ },
+ trace_temp_files,
+ -1, -1, INT_MAX, NULL, NULL
},
/* End-of-list marker */
diff -c -r src.orig/backend/utils/misc/postgresql.conf.sample src/backend/utils/misc/postgresql.conf.sample
*** src.orig/backend/utils/misc/postgresql.conf.sample Mon Nov 20 20:23:37 2006
--- src/backend/utils/misc/postgresql.conf.sample Wed Jan 3 11:05:48 2007
***
*** 333,338
--- 333,341
#log_statement = 'none' # none, ddl, mod, all
#log_hostname = off
+ #trace_temp_files = -1 # Log usage of temporary files larger than
+ # the specified size (in bytes). -1 disables.
+ # 0 effectively logs all temp file usage.
#---
# RUNTIME STATISTICS
diff -c -r src.orig/include/utils/guc.h src/include/utils/guc.h
*** src.orig/include/utils/guc.h Thu Oct 19 14:32:47 2006
--- src/include/utils/guc.h Wed Jan 3 13:45:52 2007
***
*** 123,128
--- 123,129
extern int log_min_messages;
extern int client_min_messages;
extern int log_min_duration_statement;
+ extern int trace_temp_files;
extern int num_temp_buffers;
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] wal_checksum = on (default) | off
On Thu, 2007-01-04 at 11:09 -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: On Thu, 2007-01-04 at 10:00 -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: Recovery can occur with/without same setting of wal_checksum, to avoid complications from crashes immediately after turning GUC on. Surely not. Otherwise even the on setting is not really a defense. Only when the CRC is exactly zero, which happens very very rarely. It works most of the time doesn't exactly satisfy me. What's the use-case for changing the variable on the fly anyway? Seems a better solution is just to lock down the setting at postmaster start. That would prevent us from using the secondary checkpoint location, in the case of a crash effecting the primary checkpoint when it is a shutdown checkpoint where we changed the setting of wal_checksum. It seemed safer to allow a very rare error through to the next level of error checking rather than to close the door so tight that recovery would not be possible in a very rare case. If your're good with server start, so am I. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] wal_checksum = on (default) | off
On Thu, 2007-01-04 at 17:58 +0100, Florian Weimer wrote: * Simon Riggs: Surely not. Otherwise even the on setting is not really a defense. Only when the CRC is exactly zero, which happens very very rarely. Have you tried switching to Adler32 instead of CRC32? No. Please explain further. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] wal_checksum = on (default) | off
Florian Weimer [EMAIL PROTECTED] writes: Have you tried switching to Adler32 instead of CRC32? Is anything known about the error detection capabilities of Adler32? There's a lot of math behind CRCs but AFAIR Adler's method is pretty much ad-hoc. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] wal_checksum = on (default) | off
Simon Riggs [EMAIL PROTECTED] writes: On Thu, 2007-01-04 at 11:09 -0500, Tom Lane wrote: It works most of the time doesn't exactly satisfy me. It seemed safer to allow a very rare error through to the next level of error checking rather than to close the door so tight that recovery would not be possible in a very rare case. If a DBA is turning checksums off at all, he's already bought into the assumption that he's prepared to recover from backups. What you don't seem to get here is that this feature is pretty darn questionable in the first place, and for it to have a side effect of poking a hole in the system's reliability even when it's off is more than enough to get it rejected outright. It's just a No Sale. I don't believe that the hole is real small, either, as overwrite-with-zeroes is not exactly an unheard-of failure mode for filesystems. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Small vcbuild patch
Magnus Hagander [EMAIL PROTECTED] writes: Oneliner that adds the capability to deal with defines that set string values - needs to be quoted in XML. Applied, thanks. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [Patch] - Fix for bug #2558, InitDB failed to run
Sorry, Im not an expert, and I have the same win 2003 server installation problem, but dont know what to do with the tree .c files downloaded as a patch, can you please direct me on how to use the patch? Thanks ! Andrew Dunstan wrote: 1. a patch is generated by the program diff 2. before we do anything, as Tom Lane says, we need verification of the problem, preferably in writing from Microsoft. cheers andrew dror wrote: 1. When saying: Please submit the changes as patches, instead of the whole files. Do you mean to send each file seperately? or other issues as well? 2. The change was test and design for 8.1.14, but as far as I see it is also true for any other version. Of course merge is needed in case that the files were changed since then, however , due to the fact that it is only few rows it will be easy to do it. 3. Alvaro wrote: it may be useful to lose the redirection only on the cases where it fails, so we still have reasonable behavior on non-broken platforms Nice idea, but it is really doesn't matter: on other platform than win32, the code left unchanged! the fix is only relevant for win32 on which (as I explained) the MSI installer (if used) redirect the output by default to a log file. Regards Dror Date: Mon, 14 Aug 2006 12:40:25 -0400 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: pgsql-patches@postgresql.org Subject: Re: [PATCHES] [Patch] - Fix for bug #2558, InitDB failed to run on windows 2003 dror wrote: There were two options to solve this issue: Create a new file , grant a write permission for the Postgres user and redirect the output to that file. (EnterpriseDB use this method) Canceling the redirection at all. I choose the second option and omit the redirection in any case that it windows machine and the redirection was sent to DEVNULL. The only files that I changed are: initDB.c, exec.c and pg_ctl.c Please submit the changes as patches, instead of the whole files. Also, please specify which branch do these patches apply -- is this for 8.1, or for the current development code? When checked against the 8.1 pg_ctl.c, the file you sent only contains a regression for a bug fix, and no change related to what you describe above. On the other hand, it may be useful to lose the redirection only on the cases where it fails, so we still have reasonable behavior on non-broken platforms. Or maybe there's a better solution. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support Express yourself instantly with Windows Live Messenger! Windows Live Messenger! http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-ussource=joinmsncom/messenger ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- View this message in context: http://www.nabble.com/-PatchFix-for-bug---2558%2C--InitDB-failed-to-run-on-windows-2003-tf2103710.html#a8164273 Sent from the PostgreSQL - patches mailing list archive at Nabble.com. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] wal_checksum = on (default) | off
Tom Lane wrote: Florian Weimer [EMAIL PROTECTED] writes: Have you tried switching to Adler32 instead of CRC32? Is anything known about the error detection capabilities of Adler32? There's a lot of math behind CRCs but AFAIR Adler's method is pretty much ad-hoc. As I understand it, it's kinda well studied; but has known weaknesses in its ability to detect errors under some conditions. Quoting wikipedia: Adler-32 has a weakness for short messages with few hundred bytes, because the checksums for these messages have a poor coverage of the 32 available bits...Jonathan Stone discovered in 2001 that Adler-32 has a weakness...An extended explanation can be found in RFC 3309, which mandates the use of CRC32 instead of Adler-32 I'm not sure if I'm kidding or not here, but I wonder if the not uncommon requests on the lists of weakening protective features in postgresql (full-page writes, fsync off, but mysql says, etc) suggest that a dont_protect_against_os_or_hardware_failures mode might be in demand for non-critical / development instances. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] wal_checksum = on (default) | off
Ron Mayer [EMAIL PROTECTED] writes: Quoting wikipedia: Adler-32 has a weakness for short messages with few hundred bytes, because the checksums for these messages have a poor coverage of the 32 available bits...Jonathan Stone discovered in 2001 that Adler-32 has a weakness...An extended explanation can be found in RFC 3309, which mandates the use of CRC32 instead of Adler-32 [ looks at the RFC... ] Yeah, so that pretty much kills it for WAL entries, which are mostly short. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] wal_checksum = on (default) | off
* Tom Lane: Florian Weimer [EMAIL PROTECTED] writes: Have you tried switching to Adler32 instead of CRC32? Is anything known about the error detection capabilities of Adler32? There's a lot of math behind CRCs but AFAIR Adler's method is pretty much ad-hoc. Correct me if I'm wrong, but the main reason for the WAL CRC is to detect partial WAL writes (due to improper caching, for instance). This means that you're out of the realm of traditional CRC analysis anyway, because the things you are guarding against are neither burts errors nor n-bit errors (for small n). ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] wal_checksum = on (default) | off
Florian Weimer [EMAIL PROTECTED] writes: * Tom Lane: There's a lot of math behind CRCs but AFAIR Adler's method is pretty much ad-hoc. Correct me if I'm wrong, but the main reason for the WAL CRC is to detect partial WAL writes (due to improper caching, for instance). Well, that's *a* reason, but not the only one, and IMHO not one that gives any particular guidance on what kind of checksum to use. This means that you're out of the realm of traditional CRC analysis anyway, because the things you are guarding against are neither burts errors nor n-bit errors (for small n). I think short burst errors are fairly likely: the kind of scenario I'm worried about is a wild store corrupting a word of a WAL entry while it's waiting around to be written in the WAL buffers. So the CRC math does give me some comfort that that'll be detected. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] [Fwd: Index Advisor]
Hi All, Please find attached the latest version of the patch attached. It is based on REL8_2_STABLE. It includes a few bug fixes and an improvement to the size estimation function. It also includes a work-around to circumvent the problem we were facing earlier in xact.c; it now fakes itself to be a PL/xxx module by surrounding the BIST()/RARCST() calls inside an SPI_connect()/SPI_finish() block. Please note that the sample_*.txt files in the contrib module, which show a few different sample runs, may be a little out of date. Best regards, -- [EMAIL PROTECTED] [EMAIL PROTECTED] gmail | hotmail | yahoo }.com pg_index_adviser-REL8_2_STABLE20061208-v22.patch.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] wal_checksum = on (default) | off
Florian Weimer [EMAIL PROTECTED] writes: Ah, does this mean that each WAL entry gets its own checksum? Right. (I had assumed that PostgreSQLs WAL checksumming was justified by the partial write issue. The wild store could easily occur with a heap page, too, and AFAIK, tuples, aren't checksummed. Which would be an interesting option, I guess.) We've discussed it but there's never been a pressing reason to do it. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] Add pg_shdescription to the reindex docs
Adds the new pg_shdescription to the list of shared system catalogs on the reindex page. Index: doc/src/sgml/ref/reindex.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/reindex.sgml,v retrieving revision 1.34 diff -c -r1.34 reindex.sgml *** doc/src/sgml/ref/reindex.sgml 31 Oct 2006 01:52:31 - 1.34 --- doc/src/sgml/ref/reindex.sgml 4 Jan 2007 22:52:45 - *** *** 202,208 structnamepg_auth_members/structname, structnamepg_database/structname, structnamepg_pltemplate/structname, !structnamepg_shdepend/structname, and structnamepg_tablespace/structname), then a standalone server must be used to repair it. commandREINDEX/ will not process shared catalogs in multiuser mode. --- 202,209 structnamepg_auth_members/structname, structnamepg_database/structname, structnamepg_pltemplate/structname, !structnamepg_shdepend/structname, !structnamepg_shdescription/structname, and structnamepg_tablespace/structname), then a standalone server must be used to repair it. commandREINDEX/ will not process shared catalogs in multiuser mode. signature.asc Description: This is a digitally signed message part
Re: [PATCHES] Add pg_shdescription to the reindex docs
Greg Sabino Mullane [EMAIL PROTECTED] writes: Adds the new pg_shdescription to the list of shared system catalogs on the reindex page. Good catch --- added. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
