Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-03 Thread Andreas Pflug

Bruce Momjian wrote:

Andreas Pflug wrote:


Dave Page wrote:







-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED] 
Sent: 02 July 2005 21:30

To: Bruce Momjian
Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development
Subject: Re: [PATCHES] Dbsize backend integration


Is a new version of this patch coming?



Yup, attached. Per our earlier conversation, pg_dbfile_size() now
returns the size of a table or index, and pg_relation_size() returns the
total size of a relation and all associated indexes and toast tables
etc.


pg_relation_size's name is quite unfortunate, since the 8.0 contrib 
function does something different. And pg_dbfile_size sounds misleading, 
suggesting it takes a filename or relfilenode as parameter.



Hmm.  I don't see how we can call it pg_table_size because people think
of tables and indexes, while relation has a more inclusive suggestion.


We could, taking the same logic as GRANT which uses the keyword TABLE 
for sequences and Indexes too, but it's certainly not favourable.


As far as pg_dbfile_size, do you have any other idea for a name?  To me,
it returns the size of the 'db file' associated with the
heap/index/toast.


How about pg_relation_size(oid, bool) with the second optional parameter 
 to count all additional objects too (the 'total' flag).


Regards,
Andreas


---(end of broadcast)---
TIP 3: 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] contrib/pgcrypto patch for OpenSSL 0.9.8

2005-07-03 Thread Marko Kreen
On Sat, Jul 02, 2005 at 10:33:05PM -0400, Bruce Momjian wrote:
 Patch applied.  Thanks.
 ---
 Michael Fuhr wrote:
  This patch allows contrib/pgcrypto to build with OpenSSL 0.9.8
  (currently in beta) when cryptolib = openssl.  According to the
  following checkin message from several years ago, OpenSSL application
  developers should no longer rely on openssl/evp.h to include
  everything they need:
  
  http://cvs.openssl.org/chngview?cn=9888
  
  This patch adds the necessary header files.  It doesn't appear to
  break anything when building against OpenSSL 0.9.7.
  
  BTW, core appears to build and work fine with OpenSSL 0.9.8.  I've
  built 7.3 through HEAD against 0.9.8-beta6 without noticing any
  problems.

Thanks for the patch.

Bruce, please apply this additional patch, that fixes the
auto-detection of AES.

Now openssl.c just checks OpenSSL version.  Whoever compiles
newer OpenSSL without AES is on his own.

-- 
marko

Index: contrib/pgcrypto/openssl.c
===
RCS file: /projects/cvsroot/pgsql/contrib/pgcrypto/openssl.c,v
retrieving revision 1.18
diff -p -u -r1.18 openssl.c
--- contrib/pgcrypto/openssl.c  3 Jul 2005 02:32:56 -   1.18
+++ contrib/pgcrypto/openssl.c  3 Jul 2005 05:17:29 -
@@ -39,11 +39,12 @@
 #include openssl/des.h
 
 /*
- * Is OpenSSL compiled with AES? 
+ * Does OpenSSL support AES? 
  */
 #undef GOT_AES
-#ifdef AES_ENCRYPT
+#if OPENSSL_VERSION_NUMBER = 0x00907000L
 #define GOT_AES
+#include openssl/aes.h
 #endif
 
 /*

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


[PATCHES] ALTER OBJECT SET SCHEMA

2005-07-03 Thread Bernd Helmle
Here's my current patch for ALTER OBJECT SET SCHEMA: the attached patch 
file implements
schema move for FUNCTION, SEQUENCE, TYPE, DOMAIN and TABLE with all 
improvements discussed on -hackers recently. Altering OPERATOR, OPERATOR 
CLASS, AGGREGATE and CONVERSION are currently not implemented (since i ran 
out of time) :(


Supported syntax is

ALTER TABLE name SET SCHEMA name;
ALTER SEQUENCE name SET SCHEMA name;
ALTER FUNCTION name SET SCHEMA name;
ALTER TYPE name SET SCHEMA name;
ALTER DOMAIN name SET SCHEMA name;

TIA

--
 Bernd

pgsql_alter.patch.bz2
Description: Binary data

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [PATCHES] PATCH to allow concurrent VACUUMs to not lock each

2005-07-03 Thread Hannu Krosing
On E, 2005-05-23 at 11:42 -0400, Tom Lane wrote:
 Hannu Krosing [EMAIL PROTECTED] writes:
  I can't think of any other cases where it could matter, as at least the
  work done inside vacuum_rel() itself seema non-rollbackable.
 
 VACUUM FULL's tuple-moving is definitely roll-back-able, so it might be
 prudent to only do this for lazy VACUUM.  But on the other hand, VACUUM
 FULL holds an exclusive lock on the table so no one else is going to see
 its effects concurrently anyway.

Ok, this is a new version of the vacuum patch with the following changes
following some suggestions in this thread.

* changed the patch to affect only lazy vacuum 
* moved inVacuum handling to use PG_TRY
* moved vac_update_relstats() out of lazy_vacuum_rel into a separate
  transaction. The code to do this may not be the prettiest, maybe it
  should use a separate struct.

-- 
Hannu Krosing [EMAIL PROTECTED]
Index: src/backend/access/transam/xact.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/access/transam/xact.c,v
retrieving revision 1.209
diff -c -r1.209 xact.c
*** src/backend/access/transam/xact.c	29 Jun 2005 22:51:53 -	1.209
--- src/backend/access/transam/xact.c	3 Jul 2005 15:59:09 -
***
*** 1402,1407 
--- 1402,1416 
  	AfterTriggerBeginXact();
  
  	/*
+ 	 * mark the transaction as not VACUUM  (vacuum_rel will set isVacuum 
+ 	 * to true directly after calling BeginTransactionCommand() )
+ 	 *
+ 	 * this can probably be moved to be done only once when establishing 
+ 	 * connection as this is now quaranteedto be reset to false in vacuum.c
+ 	 */
+ 	MyProc-inVacuum = false;
+ 
+ 	/*
  	 * done with start processing, set current transaction state to in
  	 * progress
  	 */
Index: src/backend/commands/vacuum.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/commands/vacuum.c,v
retrieving revision 1.310
diff -c -r1.310 vacuum.c
*** src/backend/commands/vacuum.c	14 Jun 2005 22:15:32 -	1.310
--- src/backend/commands/vacuum.c	3 Jul 2005 15:59:15 -
***
*** 37,42 
--- 37,43 
  #include miscadmin.h
  #include storage/freespace.h
  #include storage/procarray.h
+ #include storage/proc.h
  #include storage/smgr.h
  #include tcop/pquery.h
  #include utils/acl.h
***
*** 903,908 
--- 904,913 
  	Oid			toast_relid;
  	bool		result;
  
+ 	BlockNumber	stats_rel_pages=0;
+ 	double		stats_rel_tuples=0;
+ 	bool		stats_hasindex=false;
+ 
  	/* Begin a transaction for vacuuming this relation */
  	StartTransactionCommand();
  	/* functions in indexes may want a snapshot set */
***
*** 1016,1039 
  	 */
  	toast_relid = onerel-rd_rel-reltoastrelid;
  
! 	/*
! 	 * Do the actual work --- either FULL or lazy vacuum
! 	 */
! 	if (vacstmt-full)
! 		full_vacuum_rel(onerel, vacstmt);
! 	else
! 		lazy_vacuum_rel(onerel, vacstmt);
  
! 	result = true;/* did the vacuum */
  
! 	/* all done with this class, but hold lock until commit */
! 	relation_close(onerel, NoLock);
  
! 	/*
! 	 * Complete the transaction and free all temporary memory used.
! 	 */
! 	StrategyHintVacuum(false);
! 	CommitTransactionCommand();
  
  	/*
  	 * If the relation has a secondary toast rel, vacuum that too while we
--- 1021,1071 
  	 */
  	toast_relid = onerel-rd_rel-reltoastrelid;
  
! 	PG_TRY();
! 	{
! 		/*
! 		 * Do the actual work --- either FULL or lazy vacuum
! 		 */
! 		if (vacstmt-full)
! 			full_vacuum_rel(onerel, vacstmt);
! 		else
! 			/* mark this transaction as being a lazy vacuum */
! 			MyProc-inVacuum = true;
  
! 			lazy_vacuum_rel(onerel, vacstmt, stats_rel_pages, stats_rel_tuples, stats_hasindex);
  
! 		result = true;/* did the vacuum */
  
! 		/* all done with this class, but hold lock until commit */
! 		relation_close(onerel, NoLock);
! 
! 		/*
! 		 * Complete the transaction and free all temporary memory used.
! 		 */
! 		StrategyHintVacuum(false);
! 		CommitTransactionCommand();
! 	}
! 	PG_CATCH();
! 	{
! 		/* make sure in-vacuum flag is cleared is cleared */
! 		MyProc-inVacuum = false;
! 		PG_RE_THROW();
! 	}
! 	PG_END_TRY();
! 	MyProc-inVacuum = false;
! 
! 
! /* use yet another transaction for saving stats from lazy_vacuum_rel into pg_class */
! if (stats_rel_pages  0) {
! 		StartTransactionCommand();
! 		ActiveSnapshot = CopySnapshot(GetTransactionSnapshot()); /* is this needed ? */		
! 		/* Update statistics in pg_class */
! 		vac_update_relstats(RelationGetRelid(onerel),
! 			stats_rel_pages,
! 			stats_rel_tuples,
! 			stats_hasindex);
! 		CommitTransactionCommand();
! 	}
  
  	/*
  	 * If the relation has a secondary toast rel, vacuum that too while we
Index: src/backend/commands/vacuumlazy.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/commands/vacuumlazy.c,v
retrieving revision 1.54
diff -c -r1.54 vacuumlazy.c
*** 

Re: [PATCHES] PATCH to allow concurrent VACUUMs to not lock each

2005-07-03 Thread Tom Lane
Hannu Krosing [EMAIL PROTECTED] writes:
 Ok, this is a new version of the vacuum patch with the following changes
 following some suggestions in this thread.

The more I look at this, the uglier it looks ... and I still haven't
seen any convincing demonstration that it *works*, ie doesn't have
bad side-effects on the transaction-is-in-progress logic.  I'm
particularly concerned about what happens to the RecentXmin horizon
for pg_subtrans and pg_multixact operations.

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] Dbsize backend integration

2005-07-03 Thread Tom Lane
Dawid Kuroczko [EMAIL PROTECTED] writes:
 Oh, I think pg_dbfile_size is best so far.

I think it's by far the ugliest suggestion yet :-(

Andreas's suggestion of having just one function with a bool parameter
might be a workable compromise.

regards, tom lane

---(end of broadcast)---
TIP 3: 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] per user/database connections limit again

2005-07-03 Thread Petr Jelinek

Stephen Frost wrote:


This should almost certainly be a pg_database_ownercheck() call instead.
 

Right there wasn't pg_database_ownercheck at the time I was writing it, 
fixed


The rest needs to be updated for roles, but looks like it should be 
pretty easy to do.  Much of it just needs to be repatched, the parts 
that do need to be changed look to be pretty simple changes.
 


Done.


I believe the use of SessionUserId is probably correct in this patch.
This does mean that this patch will only be for canlogin roles, but that
seems like it's probably correct.  Handling roles w/ members would
require much more thought.
 

I don't think that having max connection for roles w/ members is doable 
because you can have 5 roles which has 1 user as member and each role 
has different number of max conections and there is no right way to 
decide what to do.



New version which works with roles is attached (diffed against cvs), 
everything else is mostly same.
I also had to readd roleid to flatfiles because I need it in 
InitProcess() function.


--
Regards
Petr Jelinek (PJMODOS)


Index: src/backend/commands/dbcommands.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/commands/dbcommands.c,v
retrieving revision 1.164
diff -c -r1.164 dbcommands.c
*** src/backend/commands/dbcommands.c   30 Jun 2005 00:00:50 -  1.164
--- src/backend/commands/dbcommands.c   3 Jul 2005 22:47:39 -
***
*** 53,60 
  
  /* non-export function prototypes */
  static bool get_db_info(const char *name, Oid *dbIdP, Oid *ownerIdP,
!   int *encodingP, bool *dbIsTemplateP, bool *dbAllowConnP,
!   Oid *dbLastSysOidP,
TransactionId *dbVacuumXidP, TransactionId 
*dbFrozenXidP,
Oid *dbTablespace);
  static bool have_createdb_privilege(void);
--- 53,60 
  
  /* non-export function prototypes */
  static bool get_db_info(const char *name, Oid *dbIdP, Oid *ownerIdP,
!   int *encodingP, int *dbMaxConnP, bool *dbIsTemplateP, 
!   bool *dbAllowConnP, Oid *dbLastSysOidP,
TransactionId *dbVacuumXidP, TransactionId 
*dbFrozenXidP,
Oid *dbTablespace);
  static bool have_createdb_privilege(void);
***
*** 74,79 
--- 74,80 
int src_encoding;
boolsrc_istemplate;
boolsrc_allowconn;
+   int src_maxconn;
Oid src_lastsysoid;
TransactionId src_vacuumxid;
TransactionId src_frozenxid;
***
*** 91,100 
--- 92,103 
DefElem*downer = NULL;
DefElem*dtemplate = NULL;
DefElem*dencoding = NULL;
+   DefElem*dmaxconn = NULL;
char   *dbname = stmt-dbname;
char   *dbowner = NULL;
const char *dbtemplate = NULL;
int encoding = -1;
+   int dbmaxconn = -1;
  
  #ifndef WIN32
charbuf[2 * MAXPGPATH + 100];
***
*** 140,145 
--- 143,156 
 errmsg(conflicting or 
redundant options)));
dencoding = defel;
}
+   else if (strcmp(defel-defname, maxconnections) == 0)
+   {
+   if (dmaxconn)
+   ereport(ERROR,
+   (errcode(ERRCODE_SYNTAX_ERROR),
+errmsg(conflicting or 
redundant options)));
+   dmaxconn = defel;
+   }
else if (strcmp(defel-defname, location) == 0)
{
ereport(WARNING,
***
*** 185,190 
--- 196,203 
elog(ERROR, unrecognized node type: %d,
 nodeTag(dencoding-arg));
}
+   if (dmaxconn  dmaxconn-arg)
+   dbmaxconn = intVal(dmaxconn-arg);
  
/* obtain OID of proposed owner */
if (dbowner)
***
*** 218,224 
 * idea, so accept possibility of race to create.  We will check again
 * after we grab the exclusive lock.
 */
!   if (get_db_info(dbname, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL, NULL))
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_DATABASE),
--- 231,237 
 * idea, so accept possibility of race to create.  We will check again
 * after we grab the exclusive lock.
 */
!   if (get_db_info(dbname, NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL, NULL))
ereport(ERROR,

[PATCHES] reindexdb into scripts

2005-07-03 Thread Euler Taveira de Oliveira
Hi,

Sorry for the delay. I'm too busy the last days. Based in the
discussions [1], here is a patch that translate the reindexdb shell
script to a C program. Like the other scripts, this is a wrapper for
REINDEX. Docs are include but need some improvement.

Hope that it could be included in 8.1.

http://archives.postgresql.org/pgsql-hackers/2005-06/msg01578.php


Euler Taveira de Oliveira
euler[at]yahoo_com_br





___ 
Yahoo! Acesso Grátis - Internet rápida e grátis. 
Instale o discador agora! http://br.acesso.yahoo.com/

reindexdb.tgz
Description: 431253405-reindexdb.tgz

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PATCHES] Disable WAL backup pages when fsync is off

2005-07-03 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian pgman@candle.pha.pa.us writes:
  The following patch disables WAL backup pages when fsync is off.
 
 This is a good idea why?

There is no need to write backup pages if fsync is off.  Our TODO has:

* Turn off after-change writes if fsync is disabled

  If fsync is off, there is no purpose in writing full pages to WAL

Basically, with fsync off, you are saying you don't care about crash
recovery, so why write those pages?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [PATCHES] Disable WAL backup pages when fsync is off

2005-07-03 Thread Bruce Momjian
Russell Smith wrote:
 On Sun, 3 Jul 2005 03:51 pm, Tom Lane wrote:
  Bruce Momjian pgman@candle.pha.pa.us writes:
   The following patch disables WAL backup pages when fsync is off.
  
  This is a good idea why?
  
 If it is, why do we write wal at all if fsync is off?

Good question.  WAL is to recover the file system files in case of a
crash.  WAL is used in cases where PostgreSQL crashes, but the operating
system is still running.  WAL brings the file system files back to a
consistent state containing all completed transactions.

fsync() is for forcing the data to disk so an operating system crash is
recoverable.  If that isn't happening, the cleanup of partial page
writes is hardly important because the system is not consistent.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PATCHES] contrib/pgcrypto patch for OpenSSL 0.9.8

2005-07-03 Thread Bruce Momjian

Patch applied.  Thanks.

---


Marko Kreen wrote:
 On Sat, Jul 02, 2005 at 10:33:05PM -0400, Bruce Momjian wrote:
  Patch applied.  Thanks.
  ---
  Michael Fuhr wrote:
   This patch allows contrib/pgcrypto to build with OpenSSL 0.9.8
   (currently in beta) when cryptolib = openssl.  According to the
   following checkin message from several years ago, OpenSSL application
   developers should no longer rely on openssl/evp.h to include
   everything they need:
   
   http://cvs.openssl.org/chngview?cn=9888
   
   This patch adds the necessary header files.  It doesn't appear to
   break anything when building against OpenSSL 0.9.7.
   
   BTW, core appears to build and work fine with OpenSSL 0.9.8.  I've
   built 7.3 through HEAD against 0.9.8-beta6 without noticing any
   problems.
 
 Thanks for the patch.
 
 Bruce, please apply this additional patch, that fixes the
 auto-detection of AES.
 
 Now openssl.c just checks OpenSSL version.  Whoever compiles
 newer OpenSSL without AES is on his own.
 
 -- 
 marko
 

[ Attachment, skipping... ]

 
 ---(end of broadcast)---
 TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [PATCHES] contrib/pgcrypto patch for OpenSSL 0.9.8

2005-07-03 Thread Neil Conway

Bruce Momjian wrote:

Patch applied.  Thanks.


Should either or both of these patches be applied to back branches?

-Neil

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [PATCHES] contrib/pgcrypto patch for OpenSSL 0.9.8

2005-07-03 Thread Michael Fuhr
On Mon, Jul 04, 2005 at 12:22:03PM +1000, Neil Conway wrote:
 
 Should either or both of these patches be applied to back branches?

Considering that OpenSSL 0.9.8 is supposed to be final very soon[1],
probably much sooner than PostgreSQL 8.1, some people will probably
install it and have pgcrypto build problems.  Any chance of applying
the patches to at least REL8_0_STABLE?

[1] http://www.mail-archive.com/openssl-announce@openssl.org/msg00062.html

-- 
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [PATCHES] per user/database connections limit again

2005-07-03 Thread Alvaro Herrera
On Mon, Jul 04, 2005 at 01:08:05AM +0200, Petr Jelinek wrote:
 Stephen Frost wrote:

 New version which works with roles is attached (diffed against cvs), 
 everything else is mostly same.
 I also had to readd roleid to flatfiles because I need it in 
 InitProcess() function.

I was wondering if there was some way to defer the user check till a
later time, when the pg_authid relation could be checked?  Not sure if
that's a good idea, but it may help reduce the impact of the change, and
thus chances that it'd be rejected.

-- 
Alvaro Herrera (alvherre[a]surnet.cl)
La espina, desde que nace, ya pincha (Proverbio africano)

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [PATCHES] [HACKERS] HEAD doesn't cope with libraries in non-default locations

2005-07-03 Thread Bruce Momjian
Tom Lane wrote:
 CVS tip fails with 
   ./configure --with-openssl \
 --with-includes=/usr/local/ssl/include --with-libs=/usr/local/ssl/lib
 
 ...
 make[3]: Entering directory `/home/postgres/pgsql/src/interfaces/libpq'
 ...
 /usr/ccs/bin/ld +h libpq.sl.4 -b +b /home/postgres/testversion/lib  fe-auth.o 
 fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o 
 fe-protocol3.o pqexpbuffer.o pqsignal.o fe-secure.o md5.o ip.o wchar.o 
 encnames.o noblock.o pgstrcasecmp.o thread.o getaddrinfo.o -lssl -lcrypto  
 `gcc -L../../../src/port -L/usr/local/ssl/lib -Wl,-z -Wl,+b 
 -Wl,/home/postgres/testversion/lib -print-libgcc-file-name` 
 -L../../../src/port -L/usr/local/ssl/lib  -o libpq.sl.4
 /usr/ccs/bin/ld: Can't find library for -lssl
 make[3]: *** [libpq.sl.4] Error 1
 
 It appears that somebody has changed things so that the -L switches
 appear after the -l switches (ie, too late).  I'm too tired to
 investigate now, but my money is on Autoconf 2.59 being the problem ...

I wonder if it was this commit.  I am attaching the patch so you can
test to see if it fixes it.  If it does, please let us know.

---

revision 1.91
date: 2005/07/02 23:28:22;  author: momjian;  state: Exp;  lines: +2 -2
 A quick look shows that when you use --with-libraries=/foo/bar the
 generated link line for libraries says

  -L/foo/bar -lpq

 and it should probably be the other way around (as it is for the
 executables).

 So I suspect we need some makefile tuning.

You were correct. This patch fixes it.

Jim C. Nasby

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073
Index: Makefile.shlib
===
RCS file: /cvsroot/pgsql/src/Makefile.shlib,v
retrieving revision 1.90
retrieving revision 1.91
diff -c -c -r1.90 -r1.91
*** Makefile.shlib  20 Nov 2004 21:13:04 -  1.90
--- Makefile.shlib  2 Jul 2005 23:28:22 -   1.91
***
*** 240,246 
SHLIB_LINK  += -ltermcap -lstdc++.r4 -lbind -lsocket 
-L/boot/develop/lib/x86
  endif
  
! SHLIB_LINK := $(filter -L%, $(LDFLAGS)) $(SHLIB_LINK)
  ifeq ($(enable_rpath), yes)
  SHLIB_LINK += $(rpath)
  endif
--- 240,246 
SHLIB_LINK  += -ltermcap -lstdc++.r4 -lbind -lsocket 
-L/boot/develop/lib/x86
  endif
  
! SHLIB_LINK := $(SHLIB_LINK) $(filter -L%, $(LDFLAGS))
  ifeq ($(enable_rpath), yes)
  SHLIB_LINK += $(rpath)
  endif

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


[PATCHES] Disable page writes when fsync off, add GUC

2005-07-03 Thread Bruce Momjian
This patch disables page writes to WAL when fsync is off, because with
no fsync guarantee, the page write recovery isn't useful.

This also adds a full_page_writes GUC to turn off page writes to WAL. 
Some people might not want full_page_writes, but still might want fsync.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/runtime.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.335
diff -c -c -r1.335 runtime.sgml
*** doc/src/sgml/runtime.sgml   2 Jul 2005 19:16:36 -   1.335
--- doc/src/sgml/runtime.sgml   4 Jul 2005 03:58:34 -
***
*** 1687,1692 
--- 1687,1723 
/listitem
   /varlistentry
   
+  varlistentry id=guc-full-page-writes xreflabel=full_page_writes
+   indexterm
+primaryvarnamefull_page_writes/ configuration parameter/primary
+   /indexterm
+   termvarnamefull_page_writes/varname (typeboolean/type)/term
+   listitem
+para
+ A page write in process during an operating system crash might
+ be only partially written to disk, leading to an on-disk page
+ that contains a mix of old and new data. During recovery, the
+ row changes stored in WAL are not enough to recover from this
+ situation.
+/para
+ 
+para
+ When this option is on, the productnamePostgreSQL/ server
+ writes full pages when first modified after a checkpoint to WAL
+ so full recovery is possible. Turning this option off might lead
+ to a corrupt system after an operating system crash because
+ uncorrected partial pages might contain inconsistent or corrupt
+ data. The risks are less but similar to varnamefsync/.
+/para
+ 
+para
+ This option can only be set at server start or in the
+ filenamepostgresql.conf/filename file.  The default is
+ literalon/.
+/para
+   /listitem
+  /varlistentry
+  
   varlistentry id=guc-wal-buffers xreflabel=wal_buffers
termvarnamewal_buffers/varname (typeinteger/type)/term
indexterm
Index: src/backend/access/transam/xlog.c
===
RCS file: /cvsroot/pgsql/src/backend/access/transam/xlog.c,v
retrieving revision 1.205
diff -c -c -r1.205 xlog.c
*** src/backend/access/transam/xlog.c   30 Jun 2005 00:00:50 -  1.205
--- src/backend/access/transam/xlog.c   4 Jul 2005 03:58:38 -
***
*** 97,102 
--- 97,103 
  char *XLogArchiveCommand = NULL;
  char *XLOG_sync_method = NULL;
  const charXLOG_sync_method_default[] = DEFAULT_SYNC_METHOD_STR;
+ bool  fullPageWrites = true;
  
  #ifdef WAL_DEBUG
  bool  XLOG_DEBUG = false;
***
*** 593,599 
{
/* OK, put it in this slot */
dtbuf[i] = rdt-buffer;
!   if (XLogCheckBuffer(rdt, 
(dtbuf_lsn[i]), (dtbuf_xlg[i])))
{
dtbuf_bkp[i] = true;
rdt-data = NULL;
--- 594,602 
{
/* OK, put it in this slot */
dtbuf[i] = rdt-buffer;
!   /* If fsync is off, no need to backup 
pages. */
!   if (enableFsync  fullPageWrites 
!   XLogCheckBuffer(rdt, 
(dtbuf_lsn[i]), (dtbuf_xlg[i])))
{
dtbuf_bkp[i] = true;
rdt-data = NULL;
Index: src/backend/utils/misc/guc.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.271
diff -c -c -r1.271 guc.c
*** src/backend/utils/misc/guc.c28 Jun 2005 05:09:02 -  1.271
--- src/backend/utils/misc/guc.c4 Jul 2005 03:58:46 -
***
*** 82,87 
--- 82,88 
  extern intCommitDelay;
  extern intCommitSiblings;
  extern char *default_tablespace;
+ extern bool   fullPageWrites;
  
  static const char *assign_log_destination(const char *value,
   bool doit, GucSource source);
***
*** 482,487 
--- 483,500 
false, NULL, NULL
},
{
+   {full_page_writes, PGC_SIGHUP, 

Re: [PATCHES] [HACKERS] HEAD doesn't cope with libraries in non-default

2005-07-03 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian pgman@candle.pha.pa.us writes:
  Tom Lane wrote:
  It appears that somebody has changed things so that the -L switches
  appear after the -l switches (ie, too late).  I'm too tired to
  investigate now, but my money is on Autoconf 2.59 being the problem ...
 
  I wonder if it was this commit.  I am attaching the patch so you can
  test to see if it fixes it.  If it does, please let us know.
   
  ! SHLIB_LINK := $(filter -L%, $(LDFLAGS)) $(SHLIB_LINK)
  ...  
  ! SHLIB_LINK := $(SHLIB_LINK) $(filter -L%, $(LDFLAGS))
 
 Urgh.  This was considered a good idea why exactly?

I didn't like it myself but it fixed a problem with a build farm
machine, and no one objected, so I applied it, but it seemed pretty
strange to be reversing those. I will reverse the patch.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PATCHES] Constraint Exclusion (Partitioning) - Initial Review

2005-07-03 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes:
 Simon Riggs wrote:
 Oh, why would someone want to set enable_constraint_exclusion to false?
 
 The included functionality performs the exclusion at plan time. If a
 query was prepared for later execution, it *could* return the wrong
 answer when the plan was executed at a later time since plans are not
 invalidated when constraints change. So, in general, this should be set
 to false except for circumstances where the user can guarantee no such
 mistake would be made.

 Ah, so there is a small additional restriction (changing constraints on
 planned queries) that this would affect.

This is a stopgap until we have automatic plan invalidation.

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [PATCHES] [HACKERS] HEAD doesn't cope with libraries in non-default locations

2005-07-03 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes:
 Tom Lane wrote:
 It appears that somebody has changed things so that the -L switches
 appear after the -l switches (ie, too late).  I'm too tired to
 investigate now, but my money is on Autoconf 2.59 being the problem ...

 I wonder if it was this commit.  I am attaching the patch so you can
 test to see if it fixes it.  If it does, please let us know.
  
 ! SHLIB_LINK := $(filter -L%, $(LDFLAGS)) $(SHLIB_LINK)
 ...  
 ! SHLIB_LINK := $(SHLIB_LINK) $(filter -L%, $(LDFLAGS))

Urgh.  This was considered a good idea why exactly?

regards, tom lane

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings