Frank Wittig wrote:
24 Hex digits means 24^16 unique file names. Assuming your server saves
a WAL file each second (you should review your config it it does) it
takes (24^16)/(60*60*24*365)=3.84214066×10^14 years to reach the upper
bound.
(..) It has to be 16^24.
But pg does forge filename
Greg Smith wrote:
On Wed, 13 Jun 2007, Johannes Konert wrote:
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.
This should never happen
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
g about related to
http://www.postgresql.org/docs/8.2/interactive/continuous-archiving.html.
Sorry, if that did not came out clearly enough.
On Wed, 13 Jun 2007, Johannes Konert wrote:
Because I do not want to rely on creation-date,
No, you want to rely on creation date, because then this pro
Hi pgsql-list-members,
I currently write a small script that deletes outdated xlog-files from
my backup-location.
Because I do not want to rely on creation-date, I found it usable to use
the result of
ln | sort -g -r
Thus the newest WAL xlog-file is on top and I can delete all not needed
files
Oliver Elphick wrote:
You could run the backup as postgres and pipe the output to another
program owned by the other user and with suid set in its permissions.
The suid means that the receiving program would have access where you
don't want postgres to go.
Thanks Oliver,
that was a good hint. Su
Joshua D. Drake wrote:
Johannes Konert wrote:
But that is not my point. The question is where I can change the
enforced chmod 700 postgresql always wants me to set.
You can't.
You can however change the postgresql.conf to put look for files
somewhere besides $PGDATA and thus you would be
Ragnar wrote:
are you planning a filesystem-level backup?
are you aware that you cannot just backup the postgres data directories
fro under a running server, and expect the
backup to be usable?
gnari
As war as I understood the docu of psql 8.2.4
(http://www.postgresql.org/docs/8.2/intera
use sudo in your backup scenario, or run you backup as postgres
Thanks for your quick reply.
Unfortunaltelly runing backup via sudo is not an option due to sercurity
issues and using postgres-user is not feasable because other data as
well is backuped where postgres-user should not have ac
Hi postgresql-listmembers,
for a backup-scenario I need to have access to the pgdata-directory as a
different shell-user, but postgresqul refuses to start if chmod is not
700 on the directory.
Is there a way to prevent postgres to check the data-dirs chmod 700 on
startup (and while running) ?
10 matches
Mail list logo
