Am I missing something about the output of pg_stop_backup()?
От | Ben |
---|---|
Тема | Am I missing something about the output of pg_stop_backup()? |
Дата | |
Msg-id | Pine.LNX.4.64.0707101222170.27105@localhost.localdomain обсуждение исходный текст |
Ответы |
Re: Am I missing something about the output of pg_stop_backup()?
Re: Am I missing something about the output ofpg_stop_backup()? |
Список | pgsql-general |
So, I'm working on a script that does PITR and basing it off the one here: http://archives.postgresql.org/pgsql-admin/2006-03/msg00337.php (BTW, thanks for posting that, Rajesh.) My frustration comes from the output format of pg_stop_backup(). Specifically, it outputs a string like this: 550/E788D70 ...which I then need to tokenize in order to find which archived wal files I'll need to keep as part of the backup. For instance, that output above will result in a WAL file named like so: 00000001000005500000000E.00788D70.backup That's easy enough to parse when using fixed positions, but sometimes pg_stop_backup won't always give me a string with the same number of characters. In fact, I suspect the output can be up to 23 characters (including the /) if I've commided enough transactions.... and that's before the first 1 in the WAL filename presumably increments past 1. At which point, I'm not sure what I'd see. "2/ABC/12345678"? I guess my questions boil down to: 1. Why not delimit the tokens it's obviously trying to represent with a delimiter, instead of just mashing the second two tokens together? 2. Why use / to delimit the first two tokens? That's unhelpfully the character usually used for pattern matching, and so needs to be escaped. 3. Am I missing an obvious way to map this function output to the generated WAL filname? 4. Actually.... why doesn't pg_stop_backup() just output the WAL filename that was used?
В списке pgsql-general по дате отправления: