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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
