On Fri, Apr 9, 2010 at 3:39 PM, Jaime Casanova
<jcasa...@systemguards.com.ec> wrote:
>
> but, my main concern is why it was asking for
> "000000010000000000000006"? is this normal? is this standby's way of
> saying i'm working but i have nothing to do?
> when that happens after a standby restart, is normal that i have to
> wait until the file is created before it can accept connections?
>

ok, i see this again in a new env. seems like this happen when i
shutdown standby and primary (in that order) after making some
WAL-logged action on the primary an then start again primary and
standby (in that order)... it doesn't occur always but it does occur
too often, still i'm not sure what is the key factor that triggers
this

standby waits for a file that doesn't exist to reach a consistent
state (last time i wait for an hour after i force a WAL-logged
action), here is an extract of the message on standby's log:
"""
postg...@casanova1:/usr/local/pgsql/9.0slave$ cat
data/pg_log/postgresql-2010-04-12_000947.log
LOG:  database system was interrupted while in recovery at log time
2010-04-11 20:44:09 GMT
HINT:  If this has occurred more than once some data might be
corrupted and you might need to choose an earlier recovery target.
LOG:  entering standby mode
LOG:  restored log file "000000010000000E00000014" from archive
LOG:  redo starts at E/14000088
LOG:  consistent recovery state reached at E/15000000
cp: no se puede efectuar `stat' sobre
«/usr/local/pgsql/wal_archive/000000010000000E00000015»: No existe el
fichero o el directorio
LOG:  unexpected pageaddr D/EE000000 in log file 14, segment 21, offset 0
cp: no se puede efectuar `stat' sobre
«/usr/local/pgsql/wal_archive/000000010000000E00000015»: No existe el
fichero o el directorio
LOG:  streaming replication successfully connected to primary

"""

another point, what happened with this:
http://archives.postgresql.org/message-id/1229549172.4793.105.ca...@ebony.2ndquadrant?
Obviously we still have the problem with hash indexes, and in that
thread Tom advice was just to document the issue and while that could
be fine at least we should be emitting better messages, consider this
one that i got on the standby server (where 4658650 is the oid of a
hash index):
"""
mic=# explain analyze select * from tt1 where col1 = 5000;
ERROR:  could not read block 0 in file "base/21958/4658650": read only
0 of 8192 bytes
"""

-- 
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to