On Mon, Jul 25, 2016 at 2:38 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Michael Paquier wrote: > Yeah, thanks, pushed. However this doesn't explain all the failures we see:
I missed those ones, thanks for the reminder. > 1) In > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamster&dt=2016-07-14%2016%3A00%3A06 > we see the pg_basebackup test failing. I suppose that failure is also > because of slowness, though of course this patch won't fix it. That's from 010_pg_basebackup... And I am not sure what's behind that. Could it be possible to add --verbose to the commands of pg_basebackup? We may be able to catch the problem if it shows up again. > 2) In > http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=hamster&dt=2016-06-29%2016%3A00%3A06&stg=recovery-check > we see a completely different failure: > > error running SQL: 'psql:<stdin>:1: ERROR: relation "tab_int" does not exist > LINE 1: SELECT count(*) FROM tab_int > ^' > while running 'psql -XAtq -d port=52824 host=/tmp/or2xHglniM dbname=postgres > -f - -v ON_ERROR_STOP=1' at > /home/buildfarm/data/buildroot/HEAD/pgsql.build/src/test/recovery/../../../src/test/perl/PostgresNode.pm > line 1166. > > Do we have an explanation for this one? Ah, yes, and that's a stupid mistake. We had better use replay_location instead of write_location. There is a risk that records have not been replayed yet even if they have been written on the standby, so it is possible that the query looking at tab_int may not see this relation. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
