Thread: Could not open file pg_xlog/000000010....

Could not open file pg_xlog/000000010....

From
Victor
Date:
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.

Re: Could not open file pg_xlog/000000010....

From
Rodriguez Fernando
Date:
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

Re: Could not open file pg_xlog/000000010....

From
Tom Lane
Date:
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
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

Re: problem with glibc strerror messages translation

From
Craig Ringer
Date:
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