Point in time recovery: archiving WAL files - Mailing list pgsql-hackers

From Marc Munro
Subject Point in time recovery: archiving WAL files
Date
Msg-id 1014856808.19487.2.camel@bloodnok.com
Whole thread Raw
List 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 by date:

Previous
From: Marc Munro
Date:
Subject: Point in time recovery: recreating relation files
Next
From: "Christopher Kings-Lynne"
Date:
Subject: Arch (was RE: Refactoring of command.c )