Thank you for the explanation. We shall try the latest PostgreSQL 9.6.6
version.
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
We encounter one problem that PostgreSQL walsender process doesn't exist
after "pg_ctl stop -m fast".
Uses PostgreSQL 9.6.2
Steps:
1)active postgres server is up;
2)standby postgres intance take pg_basebackup
3)usin command "pg_ctl stop -W -m fast -D /mnt/db/DBTestPostgres/db_data" to
stop active
Yeah, I figured out the point(logic). The precondition is should not have any
connections accept while recovering. It is clear to me now. Thank you very
much.
static TransactionId
btree_xlog_delete_get_latestRemovedXid(xl_btree_delete *xlrec)
{
..
if (*CountDBBackends(InvalidOid)* == 0
Thank you the comments.
We found the panic happened when adding one of our patch.
static int
ProcessStartupPacket(Port *port, bool SSLdone)
{
..
/*
* If we're going to reject the connection due to database state, say so
* now instead of wasting cycles on an authentic
is there possibility btree_redo with XLOG_BTREE_DELETE info done between
standby_redo and the end of backup? I have PostgreSQL 9.3.14 which have
some patches to use and easy to happen.
//checkpoint
[26005-59251d35.6595-712522] 2017-05-24 05:42:22.343 GMT < > DEBUG: 0:
recovery snapshots are
