Re: [PATCHES] Automatic adjustment of bgwriter_lru_maxpages
Sorry, I had a mistake in the patch I sent. This is a fixed version. I wrote: I'm working on making the bgwriter to write almost of dirty pages. This is the proposal for it using automatic adjustment of bgwriter_lru_maxpages. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center automatic_bgwriter_lru2.patch Description: Binary data ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] Trivial comment fix
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com Index: src/backend/access/nbtree/nbtinsert.c === RCS file: /home/hlinnaka/pgcvsrepository/pgsql/src/backend/access/nbtree/nbtinsert.c,v retrieving revision 1.152 diff -c -r1.152 nbtinsert.c *** src/backend/access/nbtree/nbtinsert.c 21 Feb 2007 20:02:17 - 1.152 --- src/backend/access/nbtree/nbtinsert.c 5 Mar 2007 09:47:37 - *** *** 1803,1810 BTPageOpaque opaque = (BTPageOpaque) PageGetSpecialPointer(page); /* ! * Scan over all items to see which ones need deleted according to ! * LP_DELETE flags. */ minoff = P_FIRSTDATAKEY(opaque); maxoff = PageGetMaxOffsetNumber(page); --- 1803,1810 BTPageOpaque opaque = (BTPageOpaque) PageGetSpecialPointer(page); /* ! * Scan over all items to see which ones need to be deleted ! * according to LP_DELETE flags. */ minoff = P_FIRSTDATAKEY(opaque); maxoff = PageGetMaxOffsetNumber(page); ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] Aggressive freezing in lazy-vacuum
Jim C. Nasby [EMAIL PROTECTED] wrote: * Aggressive freezing we will use OldestXmin as the threshold to freeze tuples in dirty pages or pages that have some dead tuples. Or, many UNFROZEN pages still remain after vacuum and they will cost us in the next vacuum preventing XID wraparound. Another good idea. If it's not too invasive I'd love to see that as a stand-alone patch so that we know it can get in. This is a stand-alone patch for aggressive freezing. I'll propose to use OldestXmin instead of FreezeLimit as the freeze threshold in the circumstances below: - The page is already dirty. - There are another tuple to be frozen in the same page. - There are another dead tuples in the same page. Freezing is delayed until the heap vacuum phase. Anyway we create new dirty buffers and/or write WAL then, so additional freezing is almost free. Keeping the number of unfrozen tuples low, we can reduce the cost of next XID wraparound vacuum and piggyback multiple freezing operations in the same page. The following test shows differences of the number of unfrozen tuples with or without the patch. Formerly, recently inserted tuples are not frozen immediately (1). Even if there are some dead tuples in the same page, unfrozen live tuples are not frozen (2). With patch, the number after first vacuum was already low (3), because the pages including recently inserted tuples were dirty and not written yet, so aggressive freeze was performed for it. Moreover, if there are dead tuples in a page, other live tuples in the same page are also frozen (4). # CREATE CAST (xid AS integer) WITHOUT FUNCTION AS IMPLICIT; [without patch] $ ./pgbench -i -s1 (including vacuum) # SELECT count(*) FROM accounts WHERE xmin 2; = 10 (1) # UPDATE accounts SET aid = aid WHERE aid % 20 = 0; = UPDATE 5000 # SELECT count(*) FROM accounts WHERE xmin 2; = 10 # VACUUM accounts; # SELECT count(*) FROM accounts WHERE xmin 2; = 10 (2) [with patch] $ ./pgbench -i -s1 (including vacuum) # SELECT count(*) FROM accounts WHERE xmin 2; = 2135 (3) # UPDATE accounts SET aid = aid WHERE aid % 20 = 0; = UPDATE 5000 # SELECT count(*) FROM accounts WHERE xmin 2; = 7028 # VACUUM accounts; # SELECT count(*) FROM accounts WHERE xmin 2; = 0 (4) Regards, --- ITAGAKI Takahiro NTT Open Source Software Center aggressive_freeze.patch Description: Binary data ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Trivial comment fix
On Mon, 2007-03-05 at 09:51 +, Heikki Linnakangas wrote: /* !* Scan over all items to see which ones need to be deleted !* according to LP_DELETE flags. */ Applied, thanks. -Neil ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] Aggressive freezing in lazy-vacuum
ITAGAKI Takahiro [EMAIL PROTECTED] writes: This is a stand-alone patch for aggressive freezing. I'll propose to use OldestXmin instead of FreezeLimit as the freeze threshold in the circumstances below: I think it's a really bad idea to freeze that aggressively under any circumstances except being told to (ie, VACUUM FREEZE). When you freeze, you lose history information that might be needed later --- for forensic purposes if nothing else. You need to show a fairly amazing performance gain to justify that, and I don't think you can. 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
[PATCHES] Heap page diagnostic/test functions (WIP)
WIP patch for diagnostic/test functions for heap pages. (Linked to
discussion thread on -hackers HOT - Whats Next?)
Specifically designed to allow test cases to be written that prove that
HOT works, as well as allowing diagnosis of general heap page content
errors.
Patch, plus additional file: /contrib/pgstattuple/pgstatheap.c
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Index: contrib/pgstattuple/Makefile
===
RCS file: /projects/cvsroot/pgsql/contrib/pgstattuple/Makefile,v
retrieving revision 1.7
diff -c -r1.7 Makefile
*** contrib/pgstattuple/Makefile 19 Oct 2006 17:40:03 - 1.7
--- contrib/pgstattuple/Makefile 5 Mar 2007 15:47:59 -
***
*** 7,13
#-
MODULE_big = pgstattuple
! OBJS = pgstattuple.o pgstatindex.o
DOCS = README.pgstattuple README.pgstattuple.euc_jp
DATA_built = pgstattuple.sql
DATA = uninstall_pgstattuple.sql
--- 7,13
#-
MODULE_big = pgstattuple
! OBJS = pgstattuple.o pgstatindex.o pgstatheap.o
DOCS = README.pgstattuple README.pgstattuple.euc_jp
DATA_built = pgstattuple.sql
DATA = uninstall_pgstattuple.sql
Index: contrib/pgstattuple/pgstattuple.sql.in
===
RCS file: /projects/cvsroot/pgsql/contrib/pgstattuple/pgstattuple.sql.in,v
retrieving revision 1.12
diff -c -r1.12 pgstattuple.sql.in
*** contrib/pgstattuple/pgstattuple.sql.in 4 Sep 2006 02:03:04 - 1.12
--- contrib/pgstattuple/pgstattuple.sql.in 5 Mar 2007 15:47:59 -
***
*** 107,109
--- 107,139
RETURNS int
AS 'MODULE_PATHNAME', 'pg_relpages'
LANGUAGE 'C' STRICT;
+
+ CREATE OR REPLACE FUNCTION bufpage_get_raw_page(text, int4)
+ RETURNS bytea
+ AS 'MODULE_PATHNAME', 'bufpage_get_raw_page'
+ LANGUAGE 'C' STRICT;
+
+ CREATE OR REPLACE FUNCTION heap_raw_page_header_is_valid(bytea)
+ RETURNS boolean
+ AS 'MODULE_PATHNAME', 'heap_raw_page_header_is_valid'
+ LANGUAGE 'C' STRICT;
+
+ CREATE TYPE heap_page_tuple_header_type AS (
+ itemid int4,
+ okboolean,
+ lenint4,
+ tctidtext,
+ xmnint4,
+ cnchar(1),
+ xmxint4,
+ cxchar(1),
+ cidint4,
+ nattsint2,
+ toidint4,
+ info_flag_text text
+ );
+
+ CREATE OR REPLACE FUNCTION heap_raw_page_tuple_headers(bytea)
+ RETURNS SETOF heap_page_tuple_header_type
+ AS 'MODULE_PATHNAME', 'heap_raw_page_tuple_headers'
+ LANGUAGE 'C' STRICT;
/*
* pgstatheap
*
*/
#include postgres.h
#include fmgr.h
#include funcapi.h
#include access/heapam.h
#include access/transam.h
#include catalog/namespace.h
#include catalog/pg_type.h
#include storage/bufpage.h
#include utils/builtins.h
#include utils/inval.h
PG_FUNCTION_INFO_V1(bufpage_get_raw_page);
PG_FUNCTION_INFO_V1(heap_raw_page_header_is_valid);
PG_FUNCTION_INFO_V1(heap_raw_page_tuple_headers);
extern Datum bufpage_get_raw_page(PG_FUNCTION_ARGS);
extern Datum heap_raw_page_header_is_valid(PG_FUNCTION_ARGS);
extern Datum heap_raw_page_tuple_headers(PG_FUNCTION_ARGS);
static void validate_raw_page(bytea *raw_page);
#define CHECK_RELATION_BLOCK_RANGE(rel, blkno) { \
if ( (blkno)0 RelationGetNumberOfBlocks((rel))=(blkno) ) \
elog(ERROR, Block number out of range.); }
#define GET_TEXT(str_) \
DirectFunctionCall1(textin, CStringGetDatum(str_))
Datum
bufpage_get_raw_page(PG_FUNCTION_ARGS)
{
text *relname = PG_GETARG_TEXT_P(0);
uint32 blkno = PG_GETARG_UINT32(1);
Relation rel;
RangeVar *relrv;
bytea *raw_page;
char *raw_page_data;
Page bufpage;
Buffer buf;
relrv = makeRangeVarFromNameList(textToQualifiedNameList(relname));
rel = relation_openrv(relrv, AccessShareLock);
/* work on relation */
{
CHECK_RELATION_BLOCK_RANGE(rel, blkno);
buf = ReadBuffer(rel, blkno);
/* work on buffer */
{
bufpage = BufferGetPage(buf);
raw_page = (bytea *) palloc(BLCKSZ + VARHDRSZ);
SET_VARSIZE(raw_page, BLCKSZ + VARHDRSZ);
raw_page_data = VARDATA(raw_page);
LockBuffer(buf, BUFFER_LOCK_SHARE);
/* SnapshotEverything */
{
memcpy(raw_page_data, bufpage, BLCKSZ);
}
LockBuffer(buf, BUFFER_LOCK_UNLOCK);
}
ReleaseBuffer(buf);
}
relation_close(rel, AccessShareLock);
PG_RETURN_BYTEA_P(raw_page);
}
Datum
heap_raw_page_header_is_valid(PG_FUNCTION_ARGS)
{
bytea *raw_page = PG_GETARG_BYTEA_P(0);
bool result;
validate_raw_page(raw_page);
result = PageHeaderIsValid((PageHeader)VARDATA(raw_page));
PG_RETURN_BOOL(result);
}
static void
validate_raw_page(bytea *raw_page)
{
if ((VARSIZE(raw_page) - VARHDRSZ) != BLCKSZ)
elog(ERROR,Invalid raw_page: data length %d does not match BLCKSZ,
VARSIZE(raw_page) - VARHDRSZ);
}
struct user_args
{
TupleDesc tupd;
Page page;
uint16 offset;
};
Datum
Re: [PATCHES] Heap page diagnostic/test functions (WIP)
Simon Riggs [EMAIL PROTECTED] writes: WIP patch for diagnostic/test functions for heap pages. (Linked to discussion thread on -hackers HOT - Whats Next?) --- no security checks; surely these must be superuser-only. --- relation_open will succeed on things that don't have storage; better use heap_open (and check it's not a view). --- most of the validation functions are quite pointless as bufmgr will refuse to load a page with bad header data. Specifically designed to allow test cases to be written that prove that HOT works, Exactly what will these allow that you can't do with inspection of ctid etc? (I suspect your answer will be can't see infomask, but I'd rather expose that as a new system column than invent functions like these.) I'm pretty dubious of the premise anyway --- to get results sufficiently constant that the current regression test comparison mechanism works for them, I think you'll have to constrain the test conditions so much that the test will prove little or nothing. 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] Heap page diagnostic/test functions (WIP)
On Mon, 2007-03-05 at 14:31 -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: WIP patch for diagnostic/test functions for heap pages. (Linked to discussion thread on -hackers HOT - Whats Next?) --- no security checks; surely these must be superuser-only. OK thanks --- relation_open will succeed on things that don't have storage; better use heap_open (and check it's not a view). and again --- most of the validation functions are quite pointless as bufmgr will refuse to load a page with bad header data. and again Specifically designed to allow test cases to be written that prove that HOT works, Exactly what will these allow that you can't do with inspection of ctid etc? (I suspect your answer will be can't see infomask, but I'd rather expose that as a new system column than invent functions like these.) Interesting idea, but aren't they keywords? How many system columns would we need to represent each of the info flags? The other thing was the ability to see headers of dead tuples as well so as to understand what is on the page in total, not just the visible portion of it. With HOT, recently dead tuples can still play an important part of the data access path, so being able to see them might explain many things. Is there a way to run a query in SnapshotAll? I'll happily code it as functions or system cols or any other way, as long as we can see everything there is to see. I'm pretty dubious of the premise anyway --- to get results sufficiently constant that the current regression test comparison mechanism works for them, I think you'll have to constrain the test conditions so much that the test will prove little or nothing. Well, I agree these would be more basic tests. But people might still break them. Thinking was really to provide a tutorial to how things work. Some more complex multi-session tests have already been written, based upon analysis of all of the paths taken through HeapTupleSatisfiesX. Those require the multi-session psql patch to be enabled. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Heap page diagnostic/test functions (WIP)
Simon Riggs [EMAIL PROTECTED] writes: On Mon, 2007-03-05 at 14:31 -0500, Tom Lane wrote: Exactly what will these allow that you can't do with inspection of ctid etc? (I suspect your answer will be can't see infomask, but I'd rather expose that as a new system column than invent functions like these.) Interesting idea, but aren't they keywords? How many system columns would we need to represent each of the info flags? Just one; I was imagining just returning the whole bitmask. See http://archives.postgresql.org/pgsql-hackers/2005-02/msg00636.php The other thing was the ability to see headers of dead tuples as well so as to understand what is on the page in total, not just the visible portion of it. Ah, that's a good point. 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] [HACKERS] Aggressive freezing in lazy-vacuum
Tom Lane wrote: ITAGAKI Takahiro [EMAIL PROTECTED] writes: This is a stand-alone patch for aggressive freezing. I'll propose to use OldestXmin instead of FreezeLimit as the freeze threshold in the circumstances below: I think it's a really bad idea to freeze that aggressively under any circumstances except being told to (ie, VACUUM FREEZE). When you freeze, you lose history information that might be needed later --- for forensic purposes if nothing else. You need to show a fairly amazing performance gain to justify that, and I don't think you can. There could be a GUC vacuum_freeze_limit, and the actual FreezeLimit would be calculated as GetOldestXmin() - vacuum_freeze_limit The default for vacuum_freeze_limit would be MaxTransactionId/2, just as it is now. greetings, Florian Pflug ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Aggressive freezing in lazy-vacuum
Florian G. Pflug wrote: There could be a GUC vacuum_freeze_limit, and the actual FreezeLimit would be calculated as GetOldestXmin() - vacuum_freeze_limit We already have that. It's called vacuum_freeze_min_age, and the default is 100 million transactions. IIRC we added it late in the 8.2 release cycle when we changed the clog truncation point to depend on freeze limit. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] Aggressive freezing in lazy-vacuum
Heikki Linnakangas wrote: Florian G. Pflug wrote: There could be a GUC vacuum_freeze_limit, and the actual FreezeLimit would be calculated as GetOldestXmin() - vacuum_freeze_limit We already have that. It's called vacuum_freeze_min_age, and the default is 100 million transactions. IIRC we added it late in the 8.2 release cycle when we changed the clog truncation point to depend on freeze limit. Ok, that explains why I didn't find it when I checked the source - I checked the 8.1 sources by accident ;-) Anyway, thanks for pointing that out ;-) greetings, Florian Pflug ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] xml2 contrib patch supporting default XML namespaces
Attatched you'll find a patch that I've been kicking around for a while that I'd like to propose for inclusion in 8.3. I attempted to submit this through the original xml2 author (as far back as the 7.4 days) but got no response. It's really fairly trivial, but I will be using the features it provides in production soon, so I'd like to see it applied against the contrib xml2 module. The patch adds support for default XML namespaces in xml2 by providing a mechanism for supplying a prefix to a named namespace URI. It then wraps the namespace-capable functions in backward-compatible equivalents so that old code will not break. I have patched README.xml2, pgxml.sql.in and xpath.c against CVS HEAD as of about 1 hour ago. I have code that uses both the old non-namespace-capable functions and the new functions, and all function as intended in my environment. Please let me know if there is any more I can/need-to do to help this patch along! -- Mike Rylander [EMAIL PROTECTED] GPLS -- PINES Development Database Developer http://open-ils.org xml2-namespaces.patch Description: Binary data ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] [CORE] GPL Source and Copyright Questions
OK, with no feedback on this, I have removed the copied comments from geo_ops.c, reorganized a little, and removed the GPL copyright notice. Patch attached as unified diff so you can see the line changes easier. Should this be backpatched to 8.2.X? --- Bruce Momjian wrote: I did some research on this item. I downloaded the source code to WN from: http://hopf.math.northwestern.edu/index.html I could only find the most recent version. wn-2.4.7. I then looked at its image.c file: http://momjian.us/expire/image.c I looked at the last two functions in the file and compared it to what we have in CVS, particularly the version of the code when it was first added to CVS: http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/geo_ops.c?rev=1.13;content-type=text%2Fplain Again, look at the last two functions in the file. You will see similarities and differences. Many of the variable names are the same, and there is an identical comment block. The algorithm used is very similar as well, but the style and formatting is different. I have updated the code comment in CVS to mention the web site, GPL license, and article describing the algorithm. Not sure where to go from here. --- bruce wrote: Tom Lane wrote: [ redirecting to -hackers, as I see no need for this to be a core issue ] Charles Comiskey [EMAIL PROTECTED] writes: Hello, I've recently looked through the PostgreSQL code and a couple of questions surfaced. I was hoping someone here may be able to answer them. Two have links to possible GPL sources and the third is just a contribution question. item #1: Does the geo_ops.c file contain GPL code? Embedded within the geo_ops.c file is a John Franks copyright statement referring to wn/image.c file from WN Server 1.15.1. WN Server appears to have been under the GPL license since 0.94 and continues to be offered under the GPL license today. John's letter to Linux Journal seems to only point the user to his WN Server distribution vs granting any specific license. The comment is: /* poly_contain_pt() * Test to see if the point is inside the polygon. * Code adapted from integer-based routines in * Wn: A Server for the HTTP * File: wn/image.c * Version 1.15.1 * Copyright (C) 1995 by John Franks * (code offered for use by J. Franks in Linux Journal letter.) */ That term adapted from isn't something Thomas would idly type, I think. I bet it means he looked at John Franks' code and used it as a base for our code. I am not concerned. Questions: 1) Is any John Franks code really in this file? 2) Did John provide a separate license for PostgreSQL to license it under the BSD license? This code seems to have been inserted by Tom Lockhart on 1997-07-29 (geo_ops.c rev 1.13). Tom, any info on the copyright status? References: - 1994 e-mail with GPL reference to WN Server v0.94: http://1997.webhistory.org/www.lists/www-talk.1994q4/1080.html - 1995 e-mail from John with GPL license text reference: http://1997.webhistory.org/www.lists/www-talk.1995q1/0482.html - WN Server url today: http://hopf.math.northwestern.edu/ - Link to Linux Journal article: http://www.linuxjournal.com/article/2197 -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: geo_ops.c === RCS file: /cvsroot/pgsql/src/backend/utils/adt/geo_ops.c,v retrieving revision 1.95 retrieving revision 1.96 diff -u -r1.95 -r1.96 --- geo_ops.c 27 Feb 2007 23:48:08 - 1.95 +++ geo_ops.c 5 Mar 2007 23:29:14 - 1.96 @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/utils/adt/geo_ops.c,v 1.95 2007/02/27 23:48:08 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/utils/adt/geo_ops.c,v 1.96 2007/03/05 23:29:14 momjian Exp $ * *- */ @@ -5063,128 +5063,126 @@ ***/ /* - * Test to see if the point is inside the polygon. - * Code adapted from integer-based routines in WN: A Server for the HTTP + * Test to see if the point is inside the
[PATCHES] Re: [HACKERS] [COMMITTERS] pgsql: Add GUC temp_tablespaces to provide a default location for
OK, patch reverted. Authors, would you please resubmit with fixes?
Thanks.
---
Tom Lane wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Add GUC temp_tablespaces to provide a default location for temporary
objects.
Jaime Casanova
I hadn't looked at this patch before, but now that I have, it is
rather broken.
In the first place, it makes no provision for RemovePgTempFiles() to
clean up leftover temp files that are in non-default places.
In the second place, it's a serious violation of what little modularity
and layering we have for fd.c to be calling into commands/tablespace.c.
This is not merely cosmetic but has real consequences: one being that
it's now unsafe to call OpenTemporaryFile outside a transaction.
Please revert until the submitter can come up with a better-designed
patch.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/config.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/config.sgml,v
retrieving revision 1.104
retrieving revision 1.105
diff -c -r1.104 -r1.105
*** doc/src/sgml/config.sgml 20 Jan 2007 21:30:26 - 1.104
--- doc/src/sgml/config.sgml 25 Jan 2007 04:35:10 - 1.105
***
*** 3398,3403
--- 3398,3432
/listitem
/varlistentry
+ varlistentry id=guc-temp-tablespaces xreflabel=temp_tablespaces
+ termvarnametemp_tablespaces/varname (typestring/type)/term
+ indexterm
+primaryvarnametemp_tablespaces/ configuration parameter/primary
+ /indexterm
+ indextermprimarytablespace/secondarytemp//
+ listitem
+para
+ This variable specifies tablespaces in which to create temp
+ objects (temp tables and indexes on temp tables) when a
+ commandCREATE/ command does not explicitly specify a tablespace
+ and temp files when necessary (eg. for sorting operations).
+/para
+
+para
+ The value is either a list of names of tablespaces, or an empty
+ string to specify using the default tablespace of the current database.
+ If the value does not match the name of any existing tablespace,
+ productnamePostgreSQL/ will automatically use the default
+ tablespace of the current database.
+/para
+
+para
+ For more information on tablespaces,
+ see xref linkend=manage-ag-tablespaces.
+/para
+ /listitem
+ /varlistentry
+
varlistentry id=guc-check-function-bodies xreflabel=check_function_bodies
termvarnamecheck_function_bodies/varname (typeboolean/type)/term
indexterm
Index: src/backend/commands/indexcmds.c
===
RCS file: /cvsroot/pgsql/src/backend/commands/indexcmds.c,v
retrieving revision 1.153
retrieving revision 1.154
diff -c -r1.153 -r1.154
*** src/backend/commands/indexcmds.c 20 Jan 2007 23:13:01 - 1.153
--- src/backend/commands/indexcmds.c 25 Jan 2007 04:35:10 - 1.154
***
*** 209,215
}
else
{
! tablespaceId = GetDefaultTablespace();
/* note InvalidOid is OK in this case */
}
--- 209,221
}
else
{
! /*
! * if the target table is temporary then use a temp_tablespace
! */
! if (!rel-rd_istemp)
! tablespaceId = GetDefaultTablespace();
! else
! tablespaceId = GetTempTablespace();
/* note InvalidOid is OK in this case */
}
Index: src/backend/commands/tablecmds.c
===
RCS file: /cvsroot/pgsql/src/backend/commands/tablecmds.c,v
retrieving revision 1.211
retrieving revision 1.212
diff -c -r1.211 -r1.212
*** src/backend/commands/tablecmds.c 25 Jan 2007 04:17:45 - 1.211
--- src/backend/commands/tablecmds.c 25 Jan 2007 04:35:10 - 1.212
***
*** 334,339
--- 334,343
errmsg(tablespace \%s\ does not exist,
stmt-tablespacename)));
}
+ else if (stmt-relation-istemp)
+ {
+ tablespaceId = GetTempTablespace();
+ }
else
{
tablespaceId = GetDefaultTablespace();
Index: src/backend/commands/tablespace.c
===
RCS file: /cvsroot/pgsql/src/backend/commands/tablespace.c,v
retrieving revision 1.40
retrieving revision 1.41
diff -c -r1.40 -r1.41
*** src/backend/commands/tablespace.c 5 Jan 2007 22:19:26 - 1.40
--- src/backend/commands/tablespace.c 25 Jan 2007 04:35:10 - 1.41
***
***
Re: [PATCHES] Heap page diagnostic/test functions (WIP)
Simon Riggs wrote: I'll happily code it as functions or system cols or any other way, as long as we can see everything there is to see. With HOT, other useful information is about the line pointers. It would be cool to be able to print the redirection info, details about LP_DELETEd line pointers etc. Also, there are some flags in the t_infomask2 which HOT uses, so that information would be useful also. Thanks, Pavan EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am playing with this now ... sorry for delay ... - --On Wednesday, February 28, 2007 12:58:04 -0500 Tom Lane [EMAIL PROTECTED] wrote: Bruce Momjian [EMAIL PROTECTED] writes: Joshua D. Drake wrote: We should add this to the mailing list signup pages and the welcome pages to the lists. Yep, good idea. Marc? For -patches and -hackers, I agree. It seems a bit legalistic and off-putting for the general lists, though. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFF7NK+4QvfyHIvDvMRAgmcAJ9SFJPqi1awtlsSPHYMskH0qEXSdACfblCC qODCB1vxRHBNwKj95pIOun4= =Asm5 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
