On Tue, Dec 8, 2009 at 5:30 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > A couple of small issues spotted while reviewing the streaming > replication patch:
Thanks for the review! > - Because sentPtr is initialized to zeros, GetOldestWALSendPointer will > return zero before a just-launched WAL sender has sent its first > message. That can lead to WAL files that are still needed by another > standby to be deleted prematurely. Oops! I fixed that (in my git repository, see the bottom of this mail). > - If a WAL file is not found in the master for some reason, standby goes > into an infinite loop retrying it: > > ERROR: could not read xlog records: FATAL: could not open file > "pg_xlog/000000010000000000000000" (log file 0, segment 0): No such file > or directory http://archives.postgresql.org/pgsql-hackers/2009-09/msg01393.php >> walreceiver shouldn't die on connection error, just to be restarted by >> startup process. Can we add error handling a la bgwriter and have a >> retry loop within walreceiver? As the result of your current and previous comment, you mean that walreceiver should always retry connecting to the primary after a connection error occurs in PQgetXLogData/PQputXLogRecPtr, and exit after the other errors occur? Though I'm not sure whether we can determine the error type precisely. > - It's possible to shut down master, change max_wal_senders to 0, > restart and do an operation like CLUSTER which then skips WAL-logging. > Then shutdown, change max_wal_senders back to non-zero. All this while > the standby is running. Leads to a corrupt standby. I've regarded this case as a restriction. But, how do you think we should cope with it? 1. Restriction: only documentation is required? 2. Needs safe guard: - forbid the primary to perform such operations while the standby is running? - emit PANIC error on the standby if the primary which lost sync restarts? 3. Full solution: automatic resync mechanism is required? > I've also pushed a couple of small cosmetic changes to replication > branch at git://git.postgresql.org/git/users/heikki/postgres.git Your changes seem good. I pulled and merged your changes into my repository: git://git.postgresql.org/git/users/fujii/postgres.git branch: replication And, I pushed the capability of replication of a backup history file into the repository. > I'll continue reviewing... Thanks a lot! Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers