Johannes Konert wrote:
But during the day I came out with an solution: I store the WAL-files
with the time-stamp of archiving in their file-name. Thus I can order
and delete them safely.
Your hint was the one, that helped me to find that solution - so
thanks for that, Greg.....and the others.
That solution has still a problem: It workes fine in case that the
WAL-naming restarts with 000000000000000000000001, because the attached
timestamp in name would still make it possible to identify the file as
being a newer one as FFFFFFFFFFFFFFFFFFFFFFFF, but there is still the
problem with shifts in time itself.
If someone corrects the servers computer-time/date to a date before
current time (e.g. set the clock two hours back), then the newer WAL
files will have an older timestamp and will be deleted by accident.
Thus now I increase the number of characters of the filename to infinite
and the last 24 characters are the WAL file name. Thus the archived
filenames ~always~ increase in naming and all backup files before the
last base backup can be safely identified not relying on computer
timestamps or with the risk of a restart in naming by postgresql.
I hope this solutions only border is the 255 character restriction of
file-name length....but if that one will be reached in future times I am
sure longer names are possible :)
Regards Johannes
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
