|
|
|
|
@ -81,6 +81,8 @@ |
|
|
|
|
clients"</I> when trying to connect?<BR> |
|
|
|
|
<A href="#3.9">3.9</A>) What are the <I>pg_sorttempNNN.NN</I> |
|
|
|
|
files in my database directory?<BR> |
|
|
|
|
<A href="#3.10">3.10</A>) Why do I need to do a dump and restore |
|
|
|
|
to upgrade PostgreSQL?<BR> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<H2 align="center">Operational Questions</H2> |
|
|
|
|
@ -776,6 +778,26 @@ |
|
|
|
|
not if a backend crashes during a sort. If you have no backends |
|
|
|
|
running at the time, it is safe to delete the pg_tempNNN.NN |
|
|
|
|
files.</P> |
|
|
|
|
|
|
|
|
|
<H4><A name="3.10">3.10</A>) Why do I need to do a dump and restore |
|
|
|
|
to upgrade PostgreSQL?</H4> |
|
|
|
|
|
|
|
|
|
<P>The PostgreSQL team tries very heard to maintain compatability across |
|
|
|
|
minor releases. So upgrading from 7.2 to 7.2.1 does not require a dump a |
|
|
|
|
restore. However, new features are continuously being adding and |
|
|
|
|
sometimes this requires new fields to be added to system tables. |
|
|
|
|
|
|
|
|
|
<P>These changes may be across many tables and so maintaining backward |
|
|
|
|
compatability would be quite difficult. Thus, restoring from a dump is |
|
|
|
|
required to make everything work. |
|
|
|
|
|
|
|
|
|
<P>Note that the actual on-disk file format does not change very often, |
|
|
|
|
a feature the pg_upgrade script uses quite successfully. There the dump |
|
|
|
|
is used create the necessary information in the system tables. The data |
|
|
|
|
files are then just copied across. This method is not as guarenteed as |
|
|
|
|
the dump/restore method but when it works it can make upgrades very |
|
|
|
|
efficient. |
|
|
|
|
|
|
|
|
|
<HR> |
|
|
|
|
|
|
|
|
|
<H2 align="center">Operational Questions</H2> |
|
|
|
|
|