Re: [HACKERS] pg_dump -j against standbys

2016-05-26 Thread Magnus Hagander
On Thu, May 26, 2016 at 5:57 PM, Tom Lane wrote: > Magnus Hagander writes: > > Here's an updated patch based on this,and the other feedback. > > Looks sane in a quick once-over, but I haven't tested it. > > I've run some tests and it looks good. Will apply. Thanks for the quick look! -- Mag

Re: [HACKERS] pg_dump -j against standbys

2016-05-26 Thread Tom Lane
Magnus Hagander writes: > Here's an updated patch based on this,and the other feedback. Looks sane in a quick once-over, but I haven't tested it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscriptio

Re: [HACKERS] pg_dump -j against standbys

2016-05-26 Thread Magnus Hagander
On Wed, May 25, 2016 at 4:21 PM, Tom Lane wrote: > Magnus Hagander writes: > >> Also, why didn't you keep using ExecuteSqlQueryForSingleRow()? > > > The reason I did that is that ExecuteSqlQueryForSingleRow() is a static > > method in pg_dump.c. I was planning to go back and review that, and > >

Re: [HACKERS] pg_dump -j against standbys

2016-05-25 Thread Tom Lane
Magnus Hagander writes: >> Also, why didn't you keep using ExecuteSqlQueryForSingleRow()? > The reason I did that is that ExecuteSqlQueryForSingleRow() is a static > method in pg_dump.c. I was planning to go back and review that, and > consider moving it, but I forgot it :S > I think the clean t

Re: [HACKERS] pg_dump -j against standbys

2016-05-25 Thread Marko Tiikkaja
On 25/05/16 15:59, Magnus Hagander wrote: On Tue, May 24, 2016 at 5:39 PM, Tom Lane wrote: This patch will cause pg_dump to fail entirely against pre-9.0 servers. You need to execute the test conditionally. Ugh. can I blame coding while too jetlagged? You could try blaming Magnus. Oh, wai

Re: [HACKERS] pg_dump -j against standbys

2016-05-25 Thread Magnus Hagander
On Tue, May 24, 2016 at 5:39 PM, Tom Lane wrote: > Magnus Hagander writes: > > I think the cleanest way to do it is to just track if it's a standby in > the > > AH struct as written. > > > Comments? > > This patch will cause pg_dump to fail entirely against pre-9.0 servers. > You need to execute

Re: [HACKERS] pg_dump -j against standbys

2016-05-24 Thread Michael Paquier
On Tue, May 24, 2016 at 7:02 AM, Jim Nasby wrote: > On 5/24/16 6:27 AM, Magnus Hagander wrote: >> >> pg_dump: Synchronized snapshots are not supported on standby servers. > > > Would it be that much harder to support this use case, perhaps by having the > replica request the snapshot from the mast

Re: [HACKERS] pg_dump -j against standbys

2016-05-24 Thread Tom Lane
Magnus Hagander writes: > I think the cleanest way to do it is to just track if it's a standby in the > AH struct as written. > Comments? This patch will cause pg_dump to fail entirely against pre-9.0 servers. You need to execute the test conditionally. Also, in view of that, this test -

Re: [HACKERS] pg_dump -j against standbys

2016-05-24 Thread Jim Nasby
On 5/24/16 6:27 AM, Magnus Hagander wrote: pg_dump: Synchronized snapshots are not supported on standby servers. Would it be that much harder to support this use case, perhaps by having the replica request the snapshot from the master on the client's behalf? It certainly doesn't surprise me t

[HACKERS] pg_dump -j against standbys

2016-05-24 Thread Magnus Hagander
pg_dump -j against a standby server returns a pretty bad error message when pointed at a standby node: pg_dump: [archiver (db)] query failed: ERROR: cannot assign TransactionIds during recovery pg_dump: [archiver (db)] query was: SELECT pg_export_snapshot() That looks quite scary to the user, a