From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | prakash(dot)ramakrishnan(dot)ap(at)nielsen(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #15401: pg_dump error |
Date: | 2018-09-25 16:45:23 |
Message-ID: | CAFiTN-sKqqN-31-2Xnz3G=PDokwv_CmygpcBahQ1RwZa-+7NdQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Sep 25, 2018 at 9:24 PM, PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
> The following bug has been logged on the website:
>
> Bug reference: 15401
> Logged by: prakash
> Email address: prakash(dot)ramakrishnan(dot)ap(at)nielsen(dot)com
> PostgreSQL version: 9.6.6
> Operating system: Red Hat Enterprise Linux Server release 7.4 (Maipo
> Description:
>
> Hi Team ,
>
> While am connecting the standby server to taking the backup getting below
> error.
>
> ==> pg_dump -h LHRRHENPPP002.enterprisenet.org -p 5432 -d AIUK01PR -U
> postgres -Fd -f /PGDATA/prakash_backup/AIUK01PR.sql
> Password:
> pg_dump: Dumping the contents of table "cmt_attributes" failed:
> PQgetResult() failed.
> pg_dump: Error message from server: ERROR: canceling statement due to
> conflict with recovery
> DETAIL: User was holding a relation lock for too long.
> pg_dump: The command was: COPY cmtroi_owner.cmt_attributes (id, cmt_id,
> user_id, insert_date, last_change_date, height, width, duration, dpi,
> filesize, codec) TO stdout;
>
Seems like the startup process on the standby need to lock the
relation in a conflicting mode which is already held by the pg_dump
process so it got cancelled due to recovery conflict.
I think you can change these parameters to control how long the
startup process will wait before cancelling the conflicting query.
#max_standby_archive_delay = 30s # max delay before canceling queries
# when reading WAL from archive;
# -1 allows indefinite delay
#max_standby_streaming_delay = 30s # max delay before canceling queries
# when reading streaming WAL;
# -1 allows indefinite delay
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-09-25 20:11:15 | Re: BUG #15160: planner overestimates number of rows in join when there are more than 200 rows coming from CTE |
Previous Message | PG Bug reporting form | 2018-09-25 15:54:41 | BUG #15401: pg_dump error |