Point in time recovery: archiving WAL files

Поиск
Список
Период
Сортировка
От Marc Munro
Тема Point in time recovery: archiving WAL files
Дата
Msg-id 1014856808.19487.2.camel@bloodnok.com
обсуждение исходный текст
Список pgsql-hackers
We need to archive WAL files and I am unsure of the right approach. 
What is the right way to do this without completely blocking the backend
that gets the task?

I can see a number of options but lack the depth of PosgreSQL knowledge
to be able to choose between them.  No doubt some of you will see other
options.

1) Just let the backend get on with it.  This will effectively stop the user's session while the copy occurs. 
Bad idea.

2) Have the backend spawn a child process to do this.  Will the backend wait for it's child before closing down?  Will
aborting the backend kill the archiving child?  This just seems wrong to
me.

3) Have the backend spawn a disconnected (nohup) process.  This seems dangerous to me but I can't put my finger on
why.

4) Have the backend tell the postmaster to archive the file.  The
postmaster will spawn a dedicated process to make it happen.  I think I like this but I don't know how to do it yet.

5) Have a dedicated archiver process.  Have backends tell it to get on
with the job.  This is Oracle's approach.  I see no real benefit over option 4
except that we don't have to keep spawning new processes.  On a personal
level I want to be different from Oracle.

6) I have completely missed the point about backends  Please be gentle.

Any and all feedback welcomed.  Thanks.


-- 
Marc        marc@bloodnok.com


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

Предыдущее
От: Marc Munro
Дата:
Сообщение: Point in time recovery: recreating relation files
Следующее
От: "Christopher Kings-Lynne"
Дата:
Сообщение: Arch (was RE: Refactoring of command.c )