Re: NOLOGGING option, or ?

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: NOLOGGING option, or ?
Дата
Msg-id 1117627405.3844.950.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: NOLOGGING option, or ?  (Greg Stark <gsstark@mit.edu>)
Ответы Re: NOLOGGING option, or ?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
On Wed, 2005-06-01 at 04:44 -0400, Greg Stark wrote:
> Greg Stark <gsstark@MIT.EDU> writes:
> 
> > For CREATE TABLE AS in the non-PITR case you don't really need to WAL log the
> > records at all. If it fails in the middle you just drop the table. When it
> > completes you do a checkpoint before acknowledging the COMMIT.
> > 
> > I think this is already done for CREATE INDEX/REINDEX, also only in the
> > non-PITR case.
> 
> Sorry to followup to my own message, but it occurs to me that COPY could be
> made to automatically do this for the case of an empty destination table too.
> 
> I'm not sure if it should automatically check for an empty table or if there
> should be an option for the user to indicate he wants COPY to replace the
> current contents entirely. The latter might actually be more useful. .
> 
> But either way, you just WAL log a record indicating that the table should be
> entirely empty. Then you fill it up without logging anything. Do a checkpoint
> and then WAL log that the COPY is finished. If any failure occurs replay
> leaves it empty.
> 
> Again this sadly only works in the non-PITR case.

Yes, all of the above could work.

It would use essentially the same functionality that Manfred suggested
for handling truncated tables. Ignore the first LOAD DATA started
message until recovery completes, then truncate table if the LOAD DATA
complete message was not logged in wal.

Best Regards, Simon Riggs



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dawid Kuroczko
Дата:
Сообщение: Re: Tablespace-level Block Size Definitions
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: NOLOGGING option, or ?