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 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
- * 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 relations too, 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 <robertmh...@gmail.com> wrote:
> On Thu, Oct 15, 2015 at 9:13 PM, Jim Nasby <jim.na...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
