On Fri, Aug 21, 2015 at 10:06:44AM -0400, Robert Haas wrote:
> On Tue, Aug 18, 2015 at 3:06 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> > On Tue, Aug 18, 2015 at 8:17 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> >> On Sat, Aug 15, 2015 at 6:47 PM, Noah Misch <noah@leadboat.com> wrote:
> >>> [1] That's not to say it must use the shmem lock structures and deadlock
> >>> detector.
> >>
> >> This footnote goes to my point.
> >> So, I agree that this scenario should be an error. What I don't agree
> >> with is the idea that it should be the deadlock detector's job to
> >> throw that error.
I couldn't gather from your earlier messages that this scenario should get an
error, so I'm glad to have that clarified.
> > Can you get away with only looking at tuples though? For example,
> > what about advisory locks? Table locks?
>
> Well, that's an interesting question. Can we get away with regarding
> those things as non-conflicting, as between the parent and child
> transactions?
For system lock types, no. While one could define advisory locks to work
differently, we should assume that today's advisory lockers have expectations
like those of system lockers. An autonomous transaction should not bypass any
lock that a transaction of another backend could not bypass.
