On Sat, Jan 2, 2016 at 12:28 PM, Noah Misch <n...@leadboat.com> wrote:
> On Sat, Oct 31, 2015 at 10:14:18AM +0100, Simon Riggs wrote:
>> I agree with Filip that this is a bug. pg_dump clearly doesn't work
>> correctly with inheritance.
>>
>> If I run this command
>>
>>   pg_dump -t tab1
>>
>> then I get a dump of "tab1".  No data is included from tables that inherit
>> tab1 because COPY refers only to the target table.
>>
>> Why should that action cause a lock to be taken on another table that
>> inherits from tab1?
>>
>> It seems clear that the user is requesting an action ONLY on tab1, so we
>> should use LOCK TABLE tab1 ONLY;
>
> +1

Hm. Looking one extra time at that, the patch upthread should as well
do the same for the parallel mode introduced in 9.3 as data is always
bumped using FROM ONLY. See for example the attached..
-- 
Michael
diff --git a/src/bin/pg_dump/parallel.c b/src/bin/pg_dump/parallel.c
index ff823e5..25d18ba 100644
--- a/src/bin/pg_dump/parallel.c
+++ b/src/bin/pg_dump/parallel.c
@@ -834,8 +834,12 @@ lockTableNoWait(ArchiveHandle *AH, TocEntry *te)
 							PQgetvalue(res, 0, 0),
 							PQgetvalue(res, 0, 1));
 
-	appendPQExpBuffer(query, "LOCK TABLE %s IN ACCESS SHARE MODE NOWAIT",
-					  qualId);
+	if (AHX->remoteVersion >= 80400)
+		appendPQExpBuffer(query, "LOCK TABLE ONLY %s IN ACCESS SHARE MODE NOWAIT",
+						  qualId);
+	else
+		appendPQExpBuffer(query, "LOCK TABLE %s IN ACCESS SHARE MODE NOWAIT",
+						  qualId);
 	PQclear(res);
 
 	res = PQexec(AH->connection, query->data);
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 36863df..755046f 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -5169,8 +5169,8 @@ getTables(Archive *fout, DumpOptions *dopt, int *numTables)
 		 * Read-lock target tables to make sure they aren't DROPPED or altered
 		 * in schema before we get around to dumping them.
 		 *
-		 * Note that we don't explicitly lock parents of the target tables; we
-		 * assume our lock on the child is enough to prevent schema
+		 * Note that we don't explicitly lock parents or children of the target
+		 * tables; we assume our lock on the child is enough to prevent schema
 		 * alterations to parent tables.
 		 *
 		 * NOTE: it'd be kinda nice to lock other relations too, not only
@@ -5179,11 +5179,18 @@ getTables(Archive *fout, DumpOptions *dopt, int *numTables)
 		if (tblinfo[i].dobj.dump && tblinfo[i].relkind == RELKIND_RELATION)
 		{
 			resetPQExpBuffer(query);
-			appendPQExpBuffer(query,
-							  "LOCK TABLE %s IN ACCESS SHARE MODE",
-							  fmtQualifiedId(fout->remoteVersion,
-										tblinfo[i].dobj.namespace->dobj.name,
-											 tblinfo[i].dobj.name));
+			if (fout->remoteVersion >= 80400)
+				appendPQExpBuffer(query,
+								  "LOCK TABLE ONLY %s IN ACCESS SHARE MODE",
+								  fmtQualifiedId(fout->remoteVersion,
+											tblinfo[i].dobj.namespace->dobj.name,
+												 tblinfo[i].dobj.name));
+			else
+				appendPQExpBuffer(query,
+								  "LOCK TABLE %s IN ACCESS SHARE MODE",
+								  fmtQualifiedId(fout->remoteVersion,
+											tblinfo[i].dobj.namespace->dobj.name,
+												 tblinfo[i].dobj.name));
 			ExecuteSqlStatement(fout, query->data);
 		}
 
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to