Re: pg_dump transaction's read-only mode

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <pavan(dot)deolasee(at)gmail(dot)com>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump transaction's read-only mode
Date: 2012-09-07 12:36:33
Message-ID: 5049A4010200002500049FC1@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavan Deolasee wrote:
> I'm looking at the following code in pg_dump.c
>
> /*
> * Start transaction-snapshot mode transaction to dump
> * consistent data.
> */
> ExecuteSqlStatement(fout, "BEGIN");
> if (fout->remoteVersion >= 90100)
> {
> if (serializable_deferrable)
> ExecuteSqlStatement(fout,
> "SET TRANSACTION ISOLATION LEVEL "
> "SERIALIZABLE, READ ONLY, DEFERRABLE");
> else
> ExecuteSqlStatement(fout,
> "SET TRANSACTION ISOLATION LEVEL "
> "REPEATABLE READ");
> }
> else
> ExecuteSqlStatement(fout,
> "SET TRANSACTION ISOLATION LEVEL SERIALIZABLE");
>
> Is there a reason why we do not the RR transaction as READ ONLY
> above ? I understand that unlike in the case of SERIALIZABLE
> transaction, it may not have any performance impact. But isn't it a
> good practice anyways to guard against any unintended database
> modification while taking a dump or a safe guard against any future
> optimizations for read-only transactions ? More so because RR seems
> to the default for pg_dump

That makes sense to me. The reason I didn't make that change when I
added the serializable special case to pg_dump was that it seemed
like a separate question; I didn't want to complicate an already big
patch with unnecessary changes to non-serializable transactions.

-Kevin

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2012-09-07 12:49:17 Re: txid failed epoch increment, again, aka 6291
Previous Message Pavan Deolasee 2012-09-07 09:19:32 Re: BUG #7521: Cannot disable WAL log while using pg_dump