Please take it as a very naive and basic approach :-)
What could go wrong here?
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 36863df..57a50b5 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -5169,9 +5169,9 @@ getTables(Archive *fout, DumpOptions *dopt, int
*numTables) * Read-lock target tables to make sure they aren't DROPPED or altered * in schema before we
getaround 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
- * alterations to parent tables.
+ * Note that we don't explicitly lock neither parents nor 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
relationstoo, not only * plain tables, but the backend doesn't presently allow that.
@@ -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); }
On Fri, Oct 16, 2015 at 5:06 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Oct 15, 2015 at 9:13 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> OTOH, now that the catalog is MVCC capable, do we even still need to lock
>> the objects for a schema-only dump?
>
> Yes. The MVCC snapshots used for catalog reads are stable only for
> the duration of one particular catalog read. We're not using the
> transaction snapshot.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
