Split up wal-logging items:

< * Allow control over which tables are WAL-logged [walcontrol]
> * Allow WAL logging to be turned off for a table, but the table
>   might be dropped or truncated during crash recovery [walcontrol]
<   commit.  To do this, only a single writer can modify the table, and
<   writes must happen only on new pages.  Readers can continue accessing
<   the table.  This would affect COPY, and perhaps INSERT/UPDATE too.
<   Another option is to avoid transaction logging entirely and truncate
<   or drop the table on crash recovery.  These should be implemented
<   using ALTER TABLE, e.g. ALTER TABLE PERSISTENCE [ DROP | TRUNCATE |
<   STABLE | DEFAULT ].  Tables using non-default logging should not use
<   referential integrity with default-logging tables, and tables using
<   stable logging probably can not have indexes.  One complexity is
<   the handling of indexes on TOAST tables.
>   commit.  This should be implemented using ALTER TABLE, e.g. ALTER
>   TABLE PERSISTENCE [ DROP | TRUNCATE | DEFAULT ].  Tables using
>   non-default logging should not use referential integrity with
>   default-logging tables.  A table without dirty buffers during a
>   crash could perhaps avoid the drop/truncate.
>
> * Allow WAL logging to be turned off for a table, but the table would
>   avoid being truncated/dropped [walcontrol]
>
>   To do this, only a single writer can modify the table, and writes
>   must happen only on new pages so the new pages can be removed during
>   crash recovery.  Readers can continue accessing the table.  Such
>   tables probably cannot have indexes.  One complexity is the handling
>   of indexes on TOAST tables.

0 files changed, 0 insertions, 0 deletions