* Simon Riggs (simon@2ndQuadrant.com) wrote:
> On 7 May 2016 at 16:21, Stephen Frost <sfrost@snowman.net> wrote:
> > * Simon Riggs (simon@2ndQuadrant.com) wrote:
> > > On 7 May 2016 at 16:14, Stephen Frost <sfrost@snowman.net> wrote:
> > > > > If we don't lock it then we will have a inconsistent dump that will
> > fail
> > > > > later, if dumped while an object is being dropped.
> > > > > Do we want an inconsistent dump?
> > > >
> > > > The dump won't be inconsistent, as Tom pointed out. The catalog tables
> > > > are read using a repeatable read transaction, which will be consistent.
> > >
> > > The scan is consistent, yes, but the results would not be.
> >
> > I'm not following- the results are entirely dependent on the scan, so if
> > the scan is consistent, how could the results not be?
> >
>
> Objects would no longer exist because of concurrent DROPs.
A concurrent DROP wouldn't actually produce different results than it
did before, except that the DROP would be allowed to proceed, rather
than block behind the dump. In both cases, the dump would include that
table.
> You agreed before, why did you change?
I realized that Tom was right that we are just reading from the tables
using regular SELECTs in these cases and therefore the repeatable-read
transaction semantics would be used.
There are cases where that doesn't work, as discussed up-thread and in
the comments, but those are cases where we are using server-side
functions that use SysCache and don't respect the repeatable-read
transaction.
Thanks!
Stephen