On 24/01/2017 16:14, Tom Lane wrote:
Achilleas Mantzios <achill@matrix.gatewaynet.com> writes:
On 24/01/2017 15:29, Tom Lane wrote:
The larger issue here is that you're confusing the function of an archive area with that of the active WAL directory. The server will prune what is in the active WAL directory and does not want your
help. In an archive directory, I'd expect the files to have monotonic timestamps corresponding to the times you copied them over to the archive, so you could rely on the timestamp sequence there.
I would be silly to mess around with pg_xlog. I was talking about the
archive directory. *There* is where I noticed the inconsistencies.
If you copied the files to the archive directory when the server told you
they were ready, it should be impossible for them to have non-sequential
timestamps. I'm wondering if you tried to short-circuit that, perhaps
by hard-linking them instead of copying. That won't work at all, since
the server will reuse (overwrite) the files once it thinks you've
copied them.
I provided the archive_command in the 1st post. The copy is against another host (called sma in the command) :
archive_command = '
/usr/bin/scp %p sma:/smadb/pgsql/pitr/%f'
I didn't do any scp by hand. My suspicion is that PostreSQL (before recycling them) just flushed via the archive command those files which were created before PITR was setup, i.e. before the server was restarted to begin WAL archiving. The timestamps observed on the sequence of files make me believe so.
First thing this morning, by seeing that, made me skeptical of whether the obvious assumption on the monotonicity between filenames/tiemstamps is valid. However for the last 7 hours (after the last file with the *oldish* filenames was written) I have not witnessed anything weird.
regards, tom lane
--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt