Обсуждение: Could not open file pg_xlog/000000010....
Hello, my name is Viktor, I am from Ukraine. I work under ArchLinux. I have installed Postgresql 8.4.4 and I can't run it. Report log: Oct 12 17:53:25 localhost postgres[26997]: [1748-1] LOG: database system was shut down at 2010-10-12 17:43:07 EEST Oct 12 17:53:25 localhost postgres[26997]: [1749-1] DEBUG: checkpoint record is at 0/7000020 Oct 12 17:53:25 localhost postgres[26997]: [1750-1] DEBUG: redo record is at 0/7000020; shutdown TRUE Oct 12 17:53:25 localhost postgres[26997]: [1751-1] DEBUG: next transaction ID: 0/3162; next OID: 17842 Oct 12 17:53:25 localhost postgres[26997]: [1752-1] DEBUG: next MultiXactId: 1; next MultiXactOffset: 0 Oct 12 17:53:25 localhost postgres[26997]: [1753-1] PANIC: could not open file "pg_xlog/000000010000000000000007" (log file 0, segment 7): ???????????? ???????? Oct 12 17:53:25 localhost postgres[26995]: [1748-1] DEBUG: reaping dead processes Oct 12 17:53:25 localhost postgres[26995]: [1749-1] LOG: startup process (PID 26997) was terminated by signal 6: Aborted Oct 12 17:53:25 localhost postgres[26995]: [1750-1] LOG: aborting startup due to startup process failure Oct 12 17:53:25 localhost postgres[26995]: [1751-1] DEBUG: shmem_exit(1): 3 callbacks to make Oct 12 17:53:25 localhost postgres[26995]: [1752-1] DEBUG: proc_exit(1): 3 callbacks to make Oct 12 17:53:25 localhost postgres[26995]: [1753-1] DEBUG: exit(1) Oct 12 17:53:25 localhost postgres[26995]: [1754-1] DEBUG: shmem_exit(-1): 0 callbacks to make Oct 12 17:53:25 localhost postgres[26995]: [1755-1] DEBUG: proc_exit(-1): 0 callbacks to make I hadn't this problem under previous version Postgresql 8.4.3. I tried pg_resetxlog -f /var/lib/postgres/data, but it didn't resolve this problem. I tried reinit database but result is the same.
El 12/10/2010 13:26, Victor escribió: > Hello, my name is Viktor, I am from Ukraine. > > I work under ArchLinux. > I have installed Postgresql 8.4.4 and I can't run it. > > Report log: > > Oct 12 17:53:25 localhost postgres[26997]: [1748-1] LOG: database > system was shut down at 2010-10-12 17:43:07 EEST > Oct 12 17:53:25 localhost postgres[26997]: [1749-1] DEBUG: checkpoint > record is at 0/7000020 > Oct 12 17:53:25 localhost postgres[26997]: [1750-1] DEBUG: redo > record is at 0/7000020; shutdown TRUE > Oct 12 17:53:25 localhost postgres[26997]: [1751-1] DEBUG: next > transaction ID: 0/3162; next OID: 17842 > Oct 12 17:53:25 localhost postgres[26997]: [1752-1] DEBUG: next > MultiXactId: 1; next MultiXactOffset: 0 > Oct 12 17:53:25 localhost postgres[26997]: [1753-1] PANIC: could not > open file "pg_xlog/000000010000000000000007" (log file 0, segment 7): > ???????????? ???????? > Oct 12 17:53:25 localhost postgres[26995]: [1748-1] DEBUG: reaping > dead processes > Oct 12 17:53:25 localhost postgres[26995]: [1749-1] LOG: startup > process (PID 26997) was terminated by signal 6: Aborted > Oct 12 17:53:25 localhost postgres[26995]: [1750-1] LOG: aborting > startup due to startup process failure > Oct 12 17:53:25 localhost postgres[26995]: [1751-1] DEBUG: > shmem_exit(1): 3 callbacks to make > Oct 12 17:53:25 localhost postgres[26995]: [1752-1] DEBUG: > proc_exit(1): 3 callbacks to make > Oct 12 17:53:25 localhost postgres[26995]: [1753-1] DEBUG: exit(1) > Oct 12 17:53:25 localhost postgres[26995]: [1754-1] DEBUG: > shmem_exit(-1): 0 callbacks to make > Oct 12 17:53:25 localhost postgres[26995]: [1755-1] DEBUG: > proc_exit(-1): 0 callbacks to make > > I hadn't this problem under previous version Postgresql 8.4.3. > I tried pg_resetxlog -f /var/lib/postgres/data, but it didn't resolve > this problem. > I tried reinit database but result is the same. hi, you upgrade from 8.4.3 to 8.4.4, do you have the file in $pgdate/pg_xlog/000000010000000000000007, assuming pgdata in /var/lib/pgsql/data. the database try to redo some transaction but don't have the log file. have any backup prior upgrade?. the logfile number is to small, this is not a production database, no? Fernando Rodriguez
Victor <only-victor@mail.ru> writes:
> Oct 12 17:53:25 localhost postgres[26997]: [1753-1] PANIC: could not
> open file "pg_xlog/000000010000000000000007" (log file 0, segment
> 7): ???????????? ????????
Hm, where's the rest of that error message? You should certainly not
have gotten just question-marks there.
> I hadn't this problem under previous version Postgresql 8.4.3.
I think you have a bad build of Postgres --- there's certainly a problem
in the error reporting, which is a pretty well-exercised part of the
code, and that leads to the idea that there are other problems. Maybe
you used a buggy compiler or some such. Did you build it exactly
the same way as you did 8.4.3, and with the same tools? Does it pass
the regression tests?
regards, tom lane
problem with glibc strerror messages translation (was: Could not open file pg_xlog/000000010....)
От
Sergey Burladyan
Дата:
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Victor <only-victor@mail.ru> writes:
> > Oct 12 17:53:25 localhost postgres[26997]: [1753-1] PANIC: could not
> > open file "pg_xlog/000000010000000000000007" (log file 0, segment
> > 7): ???????????? ????????
>
> Hm, where's the rest of that error message? You should certainly not
> have gotten just question-marks there.
IMHO you can receive question-marks here if lc_messages in postgresql.conf
do not match with locale from environment at server start, for example:
correctly translated and displayed:
$ LANG=ru_RU.UTF-8 ../bin/postgres -D d -k`pwd`/s
2010-10-13 05:34:39 MSD 14796 4cb50caf.39cc FATAL: XX000: could not create shared memory segment: Недопустимый
аргумент
incorrect, question-marks only:
$ LANG=C ../bin/postgres -D d -k`pwd`/s
2010-10-13 05:34:54 MSD 14798 4cb50cbd.39ce FATAL: XX000: could not create shared memory segment: ????????????
????????
error message received from function strerror(). It use gettext (in glibc) for messages translation.
man gettext say this:
In both cases, the functions also use the LC_CTYPE locale facet in order to
convert the translated message from the translator's codeset to the current
locale's codeset, unless overridden by a prior call to the
bind_textdomain_codeset function.
but when postgres starting, it set LC_CTYPE to current locale (I used gdb for monitoring):
$ LANG=C gdb --args ../bin/postgres -D d -k`pwd`/s
(gdb) break setlocale
Breakpoint 1 at 0x453118
(gdb) commands
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>p {"LC_CTYPE ", "LC_NUMERIC ", "LC_TIME ", "LC_COLLATE ", "LC_MONETARY ",
"LC_MESSAGES ", "LC_ALL ", "LC_PAPER ", "LC_NAME ", "LC_ADDRESS ", "LC_TELEPHONE
", "LC_MEASUREMENT ", "LC_IDENTIFICATION"}[category]
>c
>end
(gdb) set pagination off
(gdb) r
Starting program: /home/seb/inst/pg-dev/bin/postgres -D d -k/home/seb/inst/pg-dev/var/s
Breakpoint 1, *__GI_setlocale (category=3, locale=0x7ff627 "") at setlocale.c:199
199 setlocale.c: No such file or directory.
in setlocale.c
$1 = "LC_COLLATE "
Breakpoint 1, *__GI_setlocale (category=0, locale=0x7ff627 "") at setlocale.c:199
199 in setlocale.c
$2 = "LC_CTYPE "
Breakpoint 1, *__GI_setlocale (category=5, locale=0x7ff627 "") at setlocale.c:199
199 in setlocale.c
$3 = "LC_MESSAGES "
. . .
Breakpoint 1, *__GI_setlocale (category=5, locale=0xb31e10 "ru_RU.UTF-8") at setlocale.c:199
199 in setlocale.c
$29 = "LC_MESSAGES "
so, if current environment do not match with lc_messages in postgresql.conf
- glibc cannot translate error message.
simple test program in attachment
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <locale.h>
#include <libintl.h>
/*
* http://sourceware.org/git/?p=glibc.git;a=blob;f=string/_strerror.c
* http://sourceware.org/git/?p=glibc.git;a=blob;f=include/libintl.h
*
* man gettext
*
* In both cases, the functions also use the LC_CTYPE locale facet in order to
* convert the translated message from the translator's codeset to the current
* locale's codeset, unless overridden by a prior call to the
* bind_textdomain_codeset function.
*
*/
int main()
{
printf("LC_MESSAGES: %s\n", setlocale(LC_MESSAGES, "ru_RU.UTF-8"));
/* postgres do this at starting */
printf("LC_CTYPE: %s\n", setlocale(LC_CTYPE, ""));
/* can be fixed like this, but _libc_intl_domainname is private :( */
//printf("bind_textdomain_codeset: %s\n", bind_textdomain_codeset(/*_libc_intl_domainname*/"libc", "UTF-8"));
printf("msg: %s\n", strerror(22));
return 0;
}
correct:
$ ./a.out
LC_MESSAGES: ru_RU.UTF-8
LC_CTYPE: ru_RU.UTF-8
msg: Недопустимый аргумент
incorrect:
$ LANG=C ./a.out
LC_MESSAGES: ru_RU.UTF-8
LC_CTYPE: C
msg: ???????????? ????????
--
Sergey Burladyan
2010/10/13 Sergey Burladyan <eshkinkot@gmail.com>: > Tom Lane <tgl@sss.pgh.pa.us> writes: > >> Victor <only-victor@mail.ru> writes: >> > Oct 12 17:53:25 localhost postgres[26997]: [1753-1] PANIC: =9Acould not >> > open file "pg_xlog/000000010000000000000007" (log file 0, segment >> > 7): ???????????? ???????? >> >> Hm, where's the rest of that error message? =9AYou should certainly not >> have gotten just question-marks there. > > IMHO you can receive question-marks here if lc_messages in postgresql.conf > do not match with locale from environment at server start, for example: > > correctly translated and displayed: > $ LANG=3Dru_RU.UTF-8 ../bin/postgres -D d -k`pwd`/s > 2010-10-13 05:34:39 MSD 14796 4cb50caf.39cc FATAL: =9AXX000: could not cr= eate shared memory segment: =EE=C5=C4=CF=D0=D5=D3=D4=C9=CD=D9=CA =C1=D2=C7= =D5=CD=C5=CE=D4 > > incorrect, question-marks only: > $ LANG=3DC ../bin/postgres -D d -k`pwd`/s > 2010-10-13 05:34:54 MSD 14798 4cb50cbd.39ce FATAL: =9AXX000: could not cr= eate shared memory segment: ???????????? ???????? This seems like it might be a bug. Can we fix it by initializing... something... a bit more thoroughly than we presently do? --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 10/16/2010 08:58 PM, Robert Haas wrote: > 2010/10/13 Sergey Burladyan<eshkinkot@gmail.com>: >> IMHO you can receive question-marks here if lc_messages in postgresql.conf >> do not match with locale from environment at server start, for example: >> >> correctly translated and displayed: >> $ LANG=ru_RU.UTF-8 ../bin/postgres -D d -k`pwd`/s >> 2010-10-13 05:34:39 MSD 14796 4cb50caf.39cc FATAL: XX000: could not create shared memory segment: îÅÄÏÐÕÓÔÉÍÙÊ ÁÒÇÕÍÅÎÔ >> >> incorrect, question-marks only: >> $ LANG=C ../bin/postgres -D d -k`pwd`/s >> 2010-10-13 05:34:54 MSD 14798 4cb50cbd.39ce FATAL: XX000: could not create shared memory segment: ???????????? ???????? > > This seems like it might be a bug. Can we fix it by initializing... > something... a bit more thoroughly than we presently do? There was a previous discussion about this re logs that mixed the shift-JIS and UTF-8 encodings on a Japanese language machine. It came up under "BUG #5661: The character encoding in logfile is confusing". I've CC'd the reporter of that bug in on this discussion, as it appears to be pertinent. Tom didn't seem to like any of the options I raised as possible solutions to the mixed encoding issue, and the discussion petered out with things being left at the (IMO broken) status quo. See: http://www.mail-archive.com/pgsql-bugs@postgresql.org/msg28047.html http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg159818.html http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg159872.html -- Craig Ringer