On Mon, Dec 31, 2012 at 1:38 AM, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>wrote:
> On Sun, Dec 30, 2012 at 12:38 AM, Stephen Frost <sfrost(at)snowman(dot)net>
> > * Pavan Deolasee (pavan(dot)deolasee(at)gmail(dot)com) wrote:
> >> On Fri, Sep 7, 2012 at 6:06 PM, Kevin Grittner
> >> > 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.
> >> >
> >> If we agree, should we change that now ?
> > This is on the next commitfest, so I figure it deserves some comment.
> > For my part- I tend to agree that we should have it always use a read
> > only transaction. Perhaps we should update the pg_dump documentation to
> > mention this as well though? Pavan, do you want to put together an
> > actual patch?
> I'd posted actual patch on this thread, but probably linked wrong
> message-id in the commitfest page. Will check and correct. Regarding
> pg_dump's documentation, I don't have strong views on that. Whether
> pg_dump runs as a read-only transaction or not is entirely internal to
> its implementation, but then if we make this change, it might be worth
> telling users that they can trust that pg_dump will not make any
> changes to their database and hence a safe operation to carry out.
I have updated the commitfest submission to link to the correct patch email.
I initially thought that this patch deserves accompanying documentation
because pg_dump's serializable transaction may error out because of a
conflict. But the following line in the docs  confirms otherwise:
"read-only transactions will never have serialization conflicts"
So no doc patch necessary :)
In response to
pgsql-hackers by date
|Next:||From: Andrew Dunstan||Date: 2013-01-09 01:40:44|
|Subject: Re: proposal: Set effective_cache_size to greater of .conf
|Previous:||From: Tom Lane||Date: 2013-01-09 01:08:36|
|Subject: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers|