On 04/11/2018 11:15 AM, Don Seiler wrote:
Let's say I have two DBs: main (9.6.6) and archive (10.2).
I have a table in main where I want to archive data older then 60 days.
For various reasons, the table is not partitioned, so for now we must use
DELETE. The destination table in the archive DB is partitioned with the
new Pg10 partitioning.
My initial plan was to have a stored procedure on the archive DB use
postgres_fdw to do an INSERT INTO / SELECT to select the data remotely and
insert into the local archive table. It would then issue a single DELETE
command to remotely remove the data from the main DB. However I found that
doing this resulted in the main DB calling thousands (perhaps millions if
it's one-per-row) of individual DELETE statements based on a ctid column.
Aside from WAL behavior concerns, it is flooding my postgresql server logs
since I log any DML.
On top of that, I'm told that a remote DELETE wouldn't be transactional,
so if I were to compare inserted rows vs deleted rows and found a
mismatch, I couldn't just rollback the DELETE. I plan to verify this with
a small test case later but for now I'll assume this to be true.
Right now I'm thinking of falling back to the far-less-elegant method of
dumping the data to a flat file via COPY, running psql to connect to the
archive DB remotely and running a COPY to load the data (or maybe
transferring the flat file to the archive DB to load it there, offloading
that part of the workload), then deleting the data from the main DB. I
could capture the rows dumped in a control table and compare the rows
deleted against that and then rollback the delete if necessary.
Like I said, not elegant, but I don't want to risk losing data that wasn't
successfully archived to the archive DB. I'm very interested to hear what
others might be doing for tasks like this.
It might not be elegant, but a COPY / DELETE / LOAD is granular, so you can
restart at any point.
Angular momentum makes the world go 'round.