Re: pg_dump LOCK TABLE ONLY question

From: Filip Rembiałkowski <filip(dot)rembialkowski(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: pg_dump LOCK TABLE ONLY question
Date: 2015-10-30 22:06:32
Message-ID: CAP_rwwkpY86Hr=REoYExY5GhM2QzuiN5Ns7a-hJ_zQuHShjZdQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Oct 15, 2015 at 9:13 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-10-30 23:16:31 Re: ALTER ... OWNER TO ... vs. ALTER DEFAULT PRIVILEGES
Previous Message Merlin Moncure 2015-10-30 21:20:14 Request: pg_cancel_backend variant that handles 'idle in transaction' sessions