[PATCHES] fix vpath doc builds
At present, trying to build the documentation from outside the source tree (i.e. a "vpath build") fails. This patch fixes that. Two changes were required: - in a vpath build, make sure that we look in the appropriate directory in the build tree, not just the source tree (some SGML files are auto-generated and aren't found otherwise, causing the build to fail) - in a vpath build, copy over 'stylesheet.css' from the source tree into the build tree. The generated HTML references "stylesheet.css", so this makes that work properly. -Neil Index: doc/src/sgml/Makefile === RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/Makefile,v retrieving revision 1.60 diff -c -r1.60 Makefile *** doc/src/sgml/Makefile 29 Nov 2003 19:51:36 - 1.60 --- doc/src/sgml/Makefile 10 Dec 2003 21:34:31 - *** *** 22,27 --- 22,34 endif SGMLINCLUDE = -D $(srcdir) + # If this is a vpath build, some generated SGML will be in the build + # tree, so we need to make sure we look there as well as in the + # source tree + ifeq ($(vpath_build), yes) + SGMLINCLUDE += -D . + endif + ifndef NSGMLS NSGMLS = nsgmls endif *** *** 80,85 --- 87,95 html: postgres.sgml $(ALLSGML) stylesheet.dsl @rm -f *.html $(JADE) $(JADEFLAGS) $(SGMLINCLUDE) $(CATALOG) -d stylesheet.dsl -i output-html -t sgml $< + ifeq ($(vpath_build), yes) + @cp $(srcdir)/stylesheet.css . + endif COLLATEINDEX := LC_ALL=C $(PERL) $(COLLATEINDEX) -f -g ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[PATCHES] improvements to SGML
This patch makes some editorial improvements to the bug reporting guidelines and the LOCK reference page. -Neil Index: doc/src/sgml/problems.sgml === RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/problems.sgml,v retrieving revision 2.16 diff -c -r2.16 problems.sgml *** doc/src/sgml/problems.sgml 29 Nov 2003 19:51:37 - 2.16 --- doc/src/sgml/problems.sgml 10 Dec 2003 21:00:25 - *** *** 18,24 The following suggestions are intended to assist you in forming bug reports that can be handled in an effective fashion. No one is required to follow ! them but it tends to be to everyone's advantage. --- 18,24 The following suggestions are intended to assist you in forming bug reports that can be handled in an effective fashion. No one is required to follow ! them but doing so tends to be to everyone's advantage. *** *** 204,220 ! Any command line options and other start-up options, including concerned ! environment variables or configuration files that you changed from the ! default. Again, be exact. If you are using a prepackaged ! distribution that starts the database server at boot time, you should try ! to find out how that is done. ! Anything you did at all differently from the installation instructions. --- 204,222 ! Any command line options and other start-up options, including ! any relevant environment variables or configuration files that ! you changed from the default. Again, please provide exact ! information. If you are using a prepackaged distribution that ! starts the database server at boot time, you should try to find ! out how that is done. ! Anything you did at all differently from the installation ! instructions. *** *** 234,242 ! If your version is older than &version; we will almost certainly tell ! you to upgrade. There are tons ! of bug fixes in each new release, that is why we make new releases. --- 236,249 ! If your version is older than &version; we will almost certainly ! tell you to upgrade. There are many bug fixes and improvements ! in each new release, so it is quite possible that a bug you have ! encountered in an older release of PostgreSQL ! has already been fixed. We can only provide limited support for ! sites using older releases of PostgreSQL; if you require more ! than we can provide, consider acquiring a commercial support ! contract. *** *** 244,255 ! Platform information. This includes the kernel name and version, C library, ! processor, memory information. In most cases it is sufficient to report ! the vendor and version, but do not assume everyone knows what exactly ! Debian contains or that everyone runs on Pentiums. If ! you have installation problems then information about compilers, make, ! etc. is also necessary. --- 251,264 ! Platform information. This includes the kernel name and version, ! C library, processor, memory information, and so on. In most ! cases it is sufficient to report the vendor and version, but do ! not assume everyone knows what exactly Debian ! contains or that everyone runs on Pentiums. If you have ! installation problems then information about the toolchain on ! your machine (compiler, make, and so ! on) is also necessary. *** *** 269,275 !When writing a bug report, please choose non-confusing terminology. The software package in total is called PostgreSQL, sometimes Postgres for short. If you are specifically talking about the backend server, mention that, do not --- 278,284 !When writing a bug report, please avoid confusing terminology. The software package in total is called PostgreSQL, sometimes Postgres for short. If you are specifically talking about the backend server, mention that, do not Index: doc/src/sgml/ref/lock.sgml === RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/lock.sgml,v retrieving revision 1.39 diff -c -r1.39 lock.sgml *** doc/src/sgml/ref/lock.sgml 29 Nov 2003 19:51:39 - 1.39 --- doc/src/sgml/ref/lock.sgml 10 Dec 2003 21:15:56 - *** *** 108,116 ! The command LOCK a, b; is equivalent to ! LOCK a; LOCK b;. The tables are locked one-by-one in ! the order specified in the LOCK c
[PATCHES] bufmgr code cleanup (revised)
I posted some bufmgr cleanup a few weeks ago, but it conflicted with
some concurrent changes Jan was making to the bufmgr. Here's an
updated version of the patch -- it should apply cleanly to CVS
HEAD and passes the regression tests.
This patch makes the following changes:
- remove the UnlockAndReleaseBuffer() and UnlockAndWriteBuffer()
macros, and replace uses of them with calls to the appropriate
functions.
- remove a bunch of #ifdef BMTRACE code: it is ugly & broken
(i.e. it doesn't compile)
- make BufferReplace() return a bool, not an int
- cleanup some logic in bufmgr.c; should be functionality
equivalent to the previous code, just cleaner now
- remove the BM_PRIVATE flag as it is unused
- improve a few comments, etc.
-Neil
Index: src/backend/access/heap/heapam.c
===
RCS file: /var/lib/cvs/pgsql-server/src/backend/access/heap/heapam.c,v
retrieving revision 1.158
diff -c -r1.158 heapam.c
*** src/backend/access/heap/heapam.c 29 Nov 2003 19:51:40 - 1.158
--- src/backend/access/heap/heapam.c 10 Dec 2003 22:34:31 -
***
*** 2110,2116
if (XLByteLE(lsn, PageGetLSN(page)))
{
! UnlockAndReleaseBuffer(buffer);
return;
}
--- 2110,2117
if (XLByteLE(lsn, PageGetLSN(page)))
{
! LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
! ReleaseBuffer(buffer);
return;
}
***
*** 2135,2141
PageSetLSN(page, lsn);
PageSetSUI(page, ThisStartUpID); /* prev sui */
! UnlockAndWriteBuffer(buffer);
}
static void
--- 2136,2143
PageSetLSN(page, lsn);
PageSetSUI(page, ThisStartUpID); /* prev sui */
! LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
! WriteBuffer(buffer);
}
static void
***
*** 2170,2176
{
if (XLByteLE(lsn, PageGetLSN(page))) /* changes are applied */
{
! UnlockAndReleaseBuffer(buffer);
return;
}
}
--- 2172,2179
{
if (XLByteLE(lsn, PageGetLSN(page))) /* changes are applied */
{
! LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
! ReleaseBuffer(buffer);
return;
}
}
***
*** 2199,2205
htup->t_ctid = xlrec->target.tid;
PageSetLSN(page, lsn);
PageSetSUI(page, ThisStartUpID);
! UnlockAndWriteBuffer(buffer);
return;
}
--- 2202,2209
htup->t_ctid = xlrec->target.tid;
PageSetLSN(page, lsn);
PageSetSUI(page, ThisStartUpID);
! LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
! WriteBuffer(buffer);
return;
}
***
*** 2249,2255
if (XLByteLE(lsn, PageGetLSN(page))) /* changes are applied */
{
! UnlockAndReleaseBuffer(buffer);
return;
}
--- 2253,2260
if (XLByteLE(lsn, PageGetLSN(page))) /* changes are applied */
{
! LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
! ReleaseBuffer(buffer);
return;
}
***
*** 2282,2288
elog(PANIC, "heap_insert_redo: failed to add tuple");
PageSetLSN(page, lsn);
PageSetSUI(page, ThisStartUpID); /* prev sui */
! UnlockAndWriteBuffer(buffer);
return;
}
--- 2287,2294
elog(PANIC, "heap_insert_redo: failed to add tuple");
PageSetLSN(page, lsn);
PageSetSUI(page, ThisStartUpID); /* prev sui */
! LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
! WriteBuffer(buffer);
return;
}
***
*** 2332,2338
{
if (XLByteLE(lsn, PageGetLSN(page))) /* changes are applied */
{
! UnlockAndReleaseBuffer(buffer);
if (samepage)
return;
goto newt;
--- 2338,2345
{
if (XLByteLE(lsn, PageGetLSN(page))) /* changes are applied */
{
! LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
! ReleaseBuffer(buffer);
if (samepage)
return;
goto newt;
***
*** 2378,2384
goto newsame;
PageSetLSN(page, lsn);
PageSetSUI(page, ThisStartUpID);
! UnlockAndWriteBuffer(buffer);
goto newt;
}
--- 2385,2392
goto newsame;
PageSetLSN(page, lsn);
PageSetSUI(page, ThisStartUpID);
! LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
! WriteBuffer(buffer);
goto newt;
}
***
*** 2421,2427
if (XLByteLE(lsn, PageGetLSN(page))) /* changes are applied */
{
! UnlockAndReleaseBuffer(buffer);
return;
}
--- 2429,2436
if (XLByteLE(lsn, PageGetLSN(page))) /* changes are applied */
{
! LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
! ReleaseBuffer(buffer);
return;
}
***
*** 2474,2480
elog(PANIC, "heap_update_redo: failed to add tuple");
PageSetLSN(page, lsn);
PageSetSUI(page, ThisStartUpID); /* prev sui */
! UnlockAndWriteBuffer(buffer);
return;
}
--- 2483,2490
elog(PANIC, "heap_update_redo: failed to add tuple");
PageSetLSN(page, lsn);
PageSetSUI(page, ThisStartUpID); /* prev sui */
! LockBuffer(buffer, BUFFER_LOCK_UNLOC
[PATCHES] improve routine vacuuming docs
This patch makes some improvements and adds some details to the documentation on routine database maintenance activities. Any comments on the new text would be appreciated. I decided not to mention the FSM -- I haven't seen any reports that users have had to tweak FSM settings in 7.4, and it is probably better not to get into implementation details unless there's a good reason for it. But if anyone thinks otherwise, please speak up. I also corrected a bunch of instances of SGML usage. One of these days I'll get around to writing a style guide for the PostgreSQL SGML docs... -Neil Index: doc/src/sgml/maintenance.sgml === RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/maintenance.sgml,v retrieving revision 1.29 diff -c -r1.29 maintenance.sgml *** doc/src/sgml/maintenance.sgml 29 Nov 2003 19:51:37 - 1.29 --- doc/src/sgml/maintenance.sgml 11 Dec 2003 04:26:14 - *** *** 87,93 of VACUUM can run in parallel with normal database operations (selects, inserts, updates, deletes, but not changes to table definitions). Routine vacuuming is therefore not nearly as intrusive as it was in prior !releases, and it's not as critical to try to schedule it at low-usage times of day. --- 87,93 of VACUUM can run in parallel with normal database operations (selects, inserts, updates, deletes, but not changes to table definitions). Routine vacuuming is therefore not nearly as intrusive as it was in prior !releases, and it is not as critical to try to schedule it at low-usage times of day. *** *** 115,121 Clearly, a table that receives frequent updates or deletes will need to be vacuumed more often than tables that are seldom updated. It may be useful to set up periodic cron tasks that ! vacuum only selected tables, skipping tables that are known not to change often. This is only likely to be helpful if you have both large heavily-updated tables and large seldom-updated tables --- the extra cost of vacuuming a small table isn't enough to be worth --- 115,121 Clearly, a table that receives frequent updates or deletes will need to be vacuumed more often than tables that are seldom updated. It may be useful to set up periodic cron tasks that ! VACUUM only selected tables, skipping tables that are known not to change often. This is only likely to be helpful if you have both large heavily-updated tables and large seldom-updated tables --- the extra cost of vacuuming a small table isn't enough to be worth *** *** 123,161 ! The standard form of VACUUM is best used with the goal of ! maintaining a fairly level steady-state usage of disk space. The standard ! form finds old row versions and makes their space available for re-use within ! the table, but it does not try very hard to shorten the table file and ! return disk space to the operating system. If you need to return disk ! space to the operating system you can use VACUUM FULL --- ! but what's the point of releasing disk space that will only have to be ! allocated again soon? Moderately frequent standard VACUUM runs ! are a better approach than infrequent VACUUM FULL runs for ! maintaining heavily-updated tables. Recommended practice for most sites is to schedule a database-wide ! VACUUM once a day at a low-usage time of day, supplemented ! by more frequent vacuuming of heavily-updated tables if necessary. ! (If you have multiple databases in a cluster, don't forget to ! vacuum each one; the program vacuumdb may be helpful.) ! Use plain VACUUM, not VACUUM FULL, for routine ! vacuuming for space recovery. ! VACUUM FULL is recommended for cases where you know you have ! deleted the majority of rows in a table, so that the steady-state size ! of the table can be shrunk substantially with VACUUM FULL's ! more aggressive approach. ! If you have a table whose contents are deleted completely every so often, ! consider doing it with TRUNCATE rather than using ! DELETE followed by VACUUM. --- 123,191 ! There are two variants of the VACUUM ! command. The first form, known as lazy vacuum or ! just VACUUM, marks expired data in tables and ! indexes for future reuse; it does not attempt ! to reclaim the space used by this expired data ! immediately. Therefore, the table file is not shortened, and any ! unused space in the file is not returned to the operating ! system. This variant of VACUUM can be run ! concurrently with normal database operations. ! ! ! ! The second form is the VACUUM FULL ! command. This uses a more aggressive algorithm for reclaiming the ! space consumed
