Re: [PATCHES] Automatic adjustment of bgwriter_lru_maxpages
Greg Smith wrote: I realized recently the task I should take on here is to run some more experiments with the latest code and pass along suggested techniques for producing/identifying the kind of problem conditions I've run into in the past; then we can see if other people can reproduce them. I got a new 8-core server I need to thrash anyway and will try and do just that starting tomorrow. Yes, please do that. I can't imagine a situation where a tunable maximum would help, but you've clearly spent a lot more time experimenting with it than me. I have noticed that on a heavily (over)loaded system with fully saturated I/O, bgwriter doesn't make any difference because all the backends need to wait for writes anyway. But it doesn't hurt either. -- 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] [DOCS] Autovacuum and XID wraparound
Neil Conway wrote: On Mon, 2007-14-05 at 16:22 -0400, Bruce Momjian wrote: I agree with Tom. I don't think the current behavior is a major issue for users for it to be mentioned more than it already is Are you really suggesting that we shouldn't modify config.sgml to note that autovacuum = off does not actually imply that the autovacuum daemon is disabled? ISTM that plainly violates the principle of least surprise -- it is almost the definition of what an entry in config.sgml *should* include. I agree, the note should be added there (but it should be a short one and refer the reader someplace else for more complete details). Was there a doc patch proposed already? I seem to have missed it. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] updated SORT/LIMIT patch
Tom Lane [EMAIL PROTECTED] writes: [ greps a bit... ] It looks like the only way that you could expose the bug in the current state of the system would be if the sort/limit with the outer parameter were the inside of a nestloop join in the subplan. nodeNestloop would set EXEC_FLAG_REWIND, causing nodeSort to set randomAccess, allowing ExecReScanSort to suppose that it could rewind the sort. I finally managed to trigger this case and found that the checks don't actually work: postgres=# SELECT (SELECT n FROM (VALUES (1)) AS x, (SELECT n FROM generate_series(1,10) AS n ORDER BY n LIMIT 1 OFFSET s-1) AS y) AS z FROM generate_series(1,10) AS s; ERROR: retrieved too many tuples in a bounded sort What's going on is that nodeLimit.c only invokes recompute_limit when the first tuple is actually generated. It has a comment saying (We can't do this any earlier, because parameters from upper nodes may not be set until now.) So the checks are still comparing the previous bound against the boundDone. Attached is a small patch which fixes this case. It also makes the check slightly more liberal -- we don't need to resort if the previous sort was unbounded or the bound was greater than or equal to the new bound. There is one bit I'm not too sure of. We may or may not end up requesting tuples from our child node. If we do we have to ReScan it but by then we don't have the exprCtx passed to the ReScan call. I just made it call ReScan always even if we later decide we can just rewind the tuplesort, is that ok? Also, I left a comment that it would be nice if we could peek at the tuplesort's boundUsed and state to avoid resorting unnecessarily. Currently it pretty much always resorts unless you construct a bizarre query like the above to force the randomAccess flag to be true. Most of the time tuplesort is going to sort in memory anyways even if random access isn't requested and resorting is pointless. I think it would be worthwhile adding a method to tuplesort to ask whether random access is possible and how many tuples were actually kept. Then nodeSort could ask it those values instead of just remembering what values were requested. sortlimit-fix-v2.diff.gz Description: Binary data -- Gregory Stark 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] [DOCS] Autovacuum and XID wraparound
On Tue, 2007-15-05 at 09:07 -0400, Alvaro Herrera wrote: I agree, the note should be added there (but it should be a short one and refer the reader someplace else for more complete details). I've applied the attached patch to HEAD and REL8_2_STABLE. -Neil Index: doc/src/sgml/config.sgml === RCS file: /home/neilc/postgres/cvs_root/pgsql/doc/src/sgml/config.sgml,v retrieving revision 1.122 diff -c -p -r1.122 config.sgml *** doc/src/sgml/config.sgml 20 Apr 2007 02:37:37 - 1.122 --- doc/src/sgml/config.sgml 15 May 2007 15:04:35 - *** SELECT * FROM parent WHERE key = 2400; *** 3172,3177 --- 3172,3183 This parameter can only be set in the filenamepostgresql.conf/ file or on the server command line. /para +para + Note that even when this parameter is disabled, the system + will periodically launch autovacuum processes in order to + prevent transaction ID wraparound. See xref + linkend=vacuum-for-wraparound for more information. +/para /listitem /varlistentry ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Doc and comment patch for packed varlena
Patch applied. Thanks. --- Gregory Stark wrote: Caught someone using PG_DETOAST_PACKED and VARDATA_ANY on a structure that required alignment so I guess some more prominent warnings are in order. I also added a paragraph to the User-Defined Types chapter on using these macros since it seems like they're a hit. [ Attachment, skipping... ] -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(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. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [DOCS] Autovacuum and XID wraparound
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I suppose it would be pretty trivial to set the relfrozenxid to
RecentXmin or something during TRUNCATE.
I had the idea we were doing that already --- at least I'm pretty sure I
remember it being discussed. But I see it's not being done in HEAD.
Patch to do it attached. I am thinking we can do something similar in
CLUSTER as well.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Index: src/backend/catalog/index.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/catalog/index.c,v
retrieving revision 1.282
diff -c -p -r1.282 index.c
*** src/backend/catalog/index.c 29 Mar 2007 00:15:37 - 1.282
--- src/backend/catalog/index.c 15 May 2007 22:06:12 -
*** index_update_stats(Relation rel, bool ha
*** 1188,1196
* setNewRelfilenode - assign a new relfilenode value to the relation
*
* Caller must already hold exclusive lock on the relation.
*/
void
! setNewRelfilenode(Relation relation)
{
Oid newrelfilenode;
RelFileNode newrnode;
--- 1188,1199
* setNewRelfilenode - assign a new relfilenode value to the relation
*
* Caller must already hold exclusive lock on the relation.
+ *
+ * The relation is marked with relfrozenxid=freezeXid (InvalidTransactionId
+ * must be passed for indexes)
*/
void
! setNewRelfilenode(Relation relation, TransactionId freezeXid)
{
Oid newrelfilenode;
RelFileNode newrnode;
*** setNewRelfilenode(Relation relation)
*** 1204,1209
--- 1207,1216
relation-rd_rel-relkind == RELKIND_INDEX);
/* Can't change for shared tables or indexes */
Assert(!relation-rd_rel-relisshared);
+ /* Indexes must have Invalid frozenxid; other relations must not */
+ Assert((relation-rd_rel-relkind == RELKIND_INDEX
+ freezeXid == InvalidTransactionId) ||
+ TransactionIdIsNormal(freezeXid));
/* Allocate a new relfilenode */
newrelfilenode = GetNewRelFileNode(relation-rd_rel-reltablespace,
*** setNewRelfilenode(Relation relation)
*** 1241,1246
--- 1248,1254
rd_rel-relfilenode = newrelfilenode;
rd_rel-relpages = 0; /* it's empty until further notice */
rd_rel-reltuples = 0;
+ rd_rel-relfrozenxid = freezeXid;
simple_heap_update(pg_class, tuple-t_self, tuple);
CatalogUpdateIndexes(pg_class, tuple);
*** reindex_index(Oid indexId)
*** 1957,1963
/*
* We'll build a new physical relation for the index.
*/
! setNewRelfilenode(iRel);
}
/* Initialize the index and rebuild */
--- 1965,1971
/*
* We'll build a new physical relation for the index.
*/
! setNewRelfilenode(iRel, InvalidTransactionId);
}
/* Initialize the index and rebuild */
Index: src/backend/commands/tablecmds.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/commands/tablecmds.c,v
retrieving revision 1.223
diff -c -p -r1.223 tablecmds.c
*** src/backend/commands/tablecmds.c 14 May 2007 20:24:41 - 1.223
--- src/backend/commands/tablecmds.c 15 May 2007 22:08:33 -
*** ExecuteTruncate(TruncateStmt *stmt)
*** 616,622
* the relfilenode value. The old storage file is scheduled for
* deletion at commit.
*/
! setNewRelfilenode(rel);
heap_relid = RelationGetRelid(rel);
toast_relid = rel-rd_rel-reltoastrelid;
--- 616,622
* the relfilenode value. The old storage file is scheduled for
* deletion at commit.
*/
! setNewRelfilenode(rel, RecentXmin);
heap_relid = RelationGetRelid(rel);
toast_relid = rel-rd_rel-reltoastrelid;
*** ExecuteTruncate(TruncateStmt *stmt)
*** 629,635
if (OidIsValid(toast_relid))
{
rel = relation_open(toast_relid, AccessExclusiveLock);
! setNewRelfilenode(rel);
heap_close(rel, NoLock);
}
--- 629,635
if (OidIsValid(toast_relid))
{
rel = relation_open(toast_relid, AccessExclusiveLock);
! setNewRelfilenode(rel, RecentXmin);
heap_close(rel, NoLock);
}
Index: src/include/catalog/index.h
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/include/catalog/index.h,v
retrieving revision 1.73
diff -c -p -r1.73 index.h
*** src/include/catalog/index.h 9 Jan 2007 02:14:15 - 1.73
--- src/include/catalog/index.h 15 May 2007 21:59:31 -
*** extern void FormIndexDatum(IndexInfo *in
*** 53,59
Datum *values,
bool *isnull);
! extern void setNewRelfilenode(Relation relation);
extern void index_build(Relation heapRelation,
Relation indexRelation,
--- 53,59
Datum *values,
bool *isnull);
! extern void setNewRelfilenode(Relation relation, TransactionId
Re: [PATCHES] Maintaining cluster order on insert
Ah, thanks! I had forgotten about it as well. Bruce Momjian wrote: [ Sorry I found this one only found recently.] Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Heikki Linnakangas wrote: While thinking about index-organized-tables and similar ideas, it occurred to me that there's some low-hanging-fruit: maintaining cluster order on inserts by trying to place new heap tuples close to other similar tuples. That involves asking the index am where on the heap the new tuple should go, and trying to insert it there before using the FSM. Using the new fillfactor parameter makes it more likely that there's room on the page. We don't worry about the order within the page. The API I'm thinking of introduces a new optional index am function, amsuggestblock (suggestions for a better name are welcome). It gets the same parameters as aminsert, and returns the heap block number that would be optimal place to put the new tuple. It's be called from ExecInsert before inserting the heap tuple, and the suggestion is passed on to heap_insert and RelationGetBufferForTuple. I wrote a little patch to implement this for btree, attached. This could be optimized by changing the existing aminsert API, because as it is, an insert will have to descend the btree twice. Once in amsuggestblock and then in aminsert. amsuggestblock could keep the right index page pinned so aminsert could locate it quicker. But I wanted to keep this simple for now. Another improvement might be to allow amsuggestblock to return a list of suggestions, but that makes it more expensive to insert if there isn't room in the suggested pages, since heap_insert will have to try them all before giving up. Comments regarding the general idea or the patch? There should probably be a index option to turn the feature on and off. You'll want to turn it off when you first load a table, and turn it on after CLUSTER to keep it clustered. Since there's been discussion on keeping the TODO list more up-to-date, I hereby officially claim the Automatically maintain clustering on a table TODO item :). Feel free to bombard me with requests for status reports. And just to be clear, I'm not trying to sneak this into 8.2 anymore, this is 8.3 stuff. I won't be implementing a background daemon described on the TODO item, since that would essentially be an online version of CLUSTER. Which sure would be nice, but that's a different story. - Heikki -- Heikki Linnakangas 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: [PATCHES] Automatic adjustment of bgwriter_lru_maxpages
Moving to -performance. On Mon, May 14, 2007 at 09:55:16PM -0700, daveg wrote: Apologies for asking this on the wrong list, but it is at least the right thread. What is the current thinking on bg_writer setttings for systems such as 4 core Opteron with 16GB or 32GB of memory and heavy batch workloads? It depends greatly on how much of your data tends to stay 'pinned' in shared_buffers between checkpoints. In a case where the same data tends to stay resident you're going to need to depend on the 'all' scan to decrease the impact of checkpoints (though the load distributed checkpoint patch will change that greatly). Other than that tuning bgwriter boils down to your IO capability as well as how often you're checkpointing. -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(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] [DOCS] Autovacuum and XID wraparound
On Tue, May 15, 2007 at 06:13:47PM -0400, Alvaro Herrera wrote: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: I suppose it would be pretty trivial to set the relfrozenxid to RecentXmin or something during TRUNCATE. I had the idea we were doing that already --- at least I'm pretty sure I remember it being discussed. But I see it's not being done in HEAD. Patch to do it attached. I am thinking we can do something similar in CLUSTER as well. Actually, it already happens for CLUSTER because cluster calls heap_create_with_catalog, which calls AddNewRelationTuple. See backend/catalog/heap.c line 716. -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [DOCS] OS/X startup scripts
On Tue, May 15, 2007 at 03:35:45PM +1200, Mark Kirkwood wrote: Alvaro Herrera wrote: Mark Kirkwood wrote: Alvaro Herrera wrote: Except that it also includes diffs for generated files, which tend to be huge. To work around that you need to create a list of files to exclude, and the whole thing (which was cumbersome already) starts to get unmanageable. $ make maintainer-clean before the diff, which clears all those out. Yeah, but then if you make a mistake with the patch and have to build again to retest, you have to wait the whole thing to compile, which can be annoying. True - depends on the speed of your machine as to how annoying this really is... (I'm using a PIII 1.26 GHz... takes 5 min with -O2 - good excuse for a coffee etc). However, as David brought up previously it is probably worth mentioning several of the various CVS work-arounds in the docs, so people at least get a good survey of the options - they can then choose whichever suits their needs best. +1... BTW, is there some trick to getting cvs diff to ignore files that aren't in the repo? -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Maintaining cluster order on insert
What about adding the ability to ask the FSM for a page that's near a given page? That way if you did have to go to the FSM you could at least try and insert close to the page you originally wanted. On Tue, May 15, 2007 at 11:26:51PM +0100, Heikki Linnakangas wrote: Ah, thanks! I had forgotten about it as well. Bruce Momjian wrote: [ Sorry I found this one only found recently.] Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Heikki Linnakangas wrote: While thinking about index-organized-tables and similar ideas, it occurred to me that there's some low-hanging-fruit: maintaining cluster order on inserts by trying to place new heap tuples close to other similar tuples. That involves asking the index am where on the heap the new tuple should go, and trying to insert it there before using the FSM. Using the new fillfactor parameter makes it more likely that there's room on the page. We don't worry about the order within the page. The API I'm thinking of introduces a new optional index am function, amsuggestblock (suggestions for a better name are welcome). It gets the same parameters as aminsert, and returns the heap block number that would be optimal place to put the new tuple. It's be called from ExecInsert before inserting the heap tuple, and the suggestion is passed on to heap_insert and RelationGetBufferForTuple. I wrote a little patch to implement this for btree, attached. This could be optimized by changing the existing aminsert API, because as it is, an insert will have to descend the btree twice. Once in amsuggestblock and then in aminsert. amsuggestblock could keep the right index page pinned so aminsert could locate it quicker. But I wanted to keep this simple for now. Another improvement might be to allow amsuggestblock to return a list of suggestions, but that makes it more expensive to insert if there isn't room in the suggested pages, since heap_insert will have to try them all before giving up. Comments regarding the general idea or the patch? There should probably be a index option to turn the feature on and off. You'll want to turn it off when you first load a table, and turn it on after CLUSTER to keep it clustered. Since there's been discussion on keeping the TODO list more up-to-date, I hereby officially claim the Automatically maintain clustering on a table TODO item :). Feel free to bombard me with requests for status reports. And just to be clear, I'm not trying to sneak this into 8.2 anymore, this is 8.3 stuff. I won't be implementing a background daemon described on the TODO item, since that would essentially be an online version of CLUSTER. Which sure would be nice, but that's a different story. - Heikki -- Heikki Linnakangas 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 -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [DOCS] Autovacuum and XID wraparound
Jim C. Nasby wrote:
On Tue, May 15, 2007 at 06:13:47PM -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I suppose it would be pretty trivial to set the relfrozenxid to
RecentXmin or something during TRUNCATE.
I had the idea we were doing that already --- at least I'm pretty sure I
remember it being discussed. But I see it's not being done in HEAD.
Patch to do it attached. I am thinking we can do something similar in
CLUSTER as well.
Actually, it already happens for CLUSTER because cluster calls
heap_create_with_catalog, which calls AddNewRelationTuple. See
backend/catalog/heap.c line 716.
Right, but that heap is dropped later, and only the relfilenode remains,
because they are swapped.
In any case the change is a very small patch, which I attach but I
haven't tested. This only works if the new rewriteheap stuff actually
changes Xids to follow OldestXmin, i.e. all tuples that have older
Xmin/Xmax are frozen (or marked with the current Xid). Heikki, can you
confirm that this is the case?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Index: src/backend/commands/cluster.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/commands/cluster.c,v
retrieving revision 1.159
diff -c -p -r1.159 cluster.c
*** src/backend/commands/cluster.c 8 Apr 2007 01:26:28 - 1.159
--- src/backend/commands/cluster.c 15 May 2007 22:55:22 -
*** typedef struct
*** 54,60
static void cluster_rel(RelToCluster *rv, bool recheck);
static void rebuild_relation(Relation OldHeap, Oid indexOid);
! static void copy_heap_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex);
static List *get_tables_to_cluster(MemoryContext cluster_context);
--- 54,60
static void cluster_rel(RelToCluster *rv, bool recheck);
static void rebuild_relation(Relation OldHeap, Oid indexOid);
! static TransactionId copy_heap_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex);
static List *get_tables_to_cluster(MemoryContext cluster_context);
*** rebuild_relation(Relation OldHeap, Oid i
*** 512,517
--- 512,518
Oid tableSpace = OldHeap-rd_rel-reltablespace;
Oid OIDNewHeap;
char NewHeapName[NAMEDATALEN];
+ TransactionId frozenXid;
ObjectAddress object;
/* Mark the correct index as clustered */
*** rebuild_relation(Relation OldHeap, Oid i
*** 538,548
/*
* Copy the heap data into the new table in the desired order.
*/
! copy_heap_data(OIDNewHeap, tableOid, indexOid);
/* To make the new heap's data visible (probably not needed?). */
CommandCounterIncrement();
/* Swap the physical files of the old and new heaps. */
swap_relation_files(tableOid, OIDNewHeap);
--- 539,556
/*
* Copy the heap data into the new table in the desired order.
*/
! frozenXid = copy_heap_data(OIDNewHeap, tableOid, indexOid);
/* To make the new heap's data visible (probably not needed?). */
CommandCounterIncrement();
+ /*
+ * update the relation's freeze Xid. We don't need to change the
+ * actual tuple on disk, because swap_relation_files will do it for
+ * us.
+ */
+ OldHeap-rd_rel-relfrozenxid = frozenXid;
+
/* Swap the physical files of the old and new heaps. */
swap_relation_files(tableOid, OIDNewHeap);
*** make_new_heap(Oid OIDOldHeap, const char
*** 640,648
}
/*
! * Do the physical copying of heap data.
*/
! static void
copy_heap_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex)
{
Relation NewHeap,
--- 648,657
}
/*
! * Do the physical copying of heap data. Returns the transaction ID used as
! * cutoff point.
*/
! static TransactionId
copy_heap_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex)
{
Relation NewHeap,
*** copy_heap_data(Oid OIDNewHeap, Oid OIDOl
*** 809,814
--- 818,825
index_close(OldIndex, NoLock);
heap_close(OldHeap, NoLock);
heap_close(NewHeap, NoLock);
+
+ return OldestXmin;
}
/*
---(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] actualised forgotten Magnus's patch for plpgsql MOVE statement
Pavel Stehule wrote: I would argue that we should likewise not allow them in plpgsql's MOVE, although this is more of a judgment call than is the case for FETCH. I just don't think it's a good idea to provide two redundant ways to do the same thing, when we might want to make one of the ways mean something else later. There's no upside and there might be a downside. It's question. There are lot of links to FETCH in doc, and we support from FETCH direction only subset. It needs at least notice in documentation. When I testeid MOVE I found an form MOVE FORWARD 10 ... more natural than MOVE RELATIVE 10 and if we support MOVE FORWARD ... then is logic support MOVE FORWARD n , else FORWARD, BACKWARD are nonstandard and MOVE statement too. Do we have a patch to make this consistent? -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://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
Re: [PATCHES] [DOCS] Autovacuum and XID wraparound
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: I had the idea we were doing that already --- at least I'm pretty sure I remember it being discussed. But I see it's not being done in HEAD. Patch to do it attached. I am thinking we can do something similar in CLUSTER as well. Umm ... you'd have to be a lot more conservative in CLUSTER now that it's MVCC-safe. I don't say that CLUSTER can't push up relfrozenxid, but there's something wrong if CLUSTER and TRUNCATE are trying to push it up the same amount. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
