Robert Haas <robertmh...@gmail.com> writes:
> Thanks for digging into this. I failed to notice while reviewing that
> the way we were printing the message had changed a bit in the new
> code, and I just totally overlooked the existing locking hazards.
> Oops.
I pushed a patch to deal with this. I ended up simplifying the previous
commit considerably by getting rid of the commit-multiple-deletions-per-
transaction business. I do not think that this code will get exercised
enough, either in the field or in testing, to justify taking a risk of
additional bugs from that.
Also, another reason for not liking that is that it seems to increase the
risk of deadlock against an incoming session that's taking over the temp
schema belonging to a crashed session. The incoming backend would be
deleting the same tables in (probably) a different order, which is an
obvious deadlock hazard. I think it'd be mostly all right because the
autovac worker should lose deadlock fights, but the incoming session would
see a deadlock_timeout stall if not an error. So that's another reason to
commit immediately after each deletion.
I tested this by dint of turning RemoveTempRelationsCallback into a no-op,
so that things always acted as though sessions had crashed without
cleaning up their temp tables. The code survived quite a few regression
test cycles without visible problems, although I had to tweak rules.sql
to ignore temp views.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
