Re: pg_dump transaction's read-only mode - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: pg_dump transaction's read-only mode
Date
Msg-id 5049A4010200002500049FC1@gw.wicourts.gov
Whole thread Raw
In response to pg_dump transaction's read-only mode  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Responses Re: pg_dump transaction's read-only mode  (Pavan Deolasee <pavan.deolasee@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Daniel Farina
Date:
Subject: Re: txid failed epoch increment, again, aka 6291
Next
From: Noah Misch
Date:
Subject: Re: txid failed epoch increment, again, aka 6291