On Thu, Nov 20, 2014 at 4:45 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> How about a frontend process having created a relation that then starts
> a parallel query. Then the frontend process ERRORs out and, in the
> course of that, does smgrDoPendingDeletes(). Which will delete the new
> relation. Boom. The background process might just be accessing it. If
> you think thats harmless, think e.g. what'd happen with heap cleanup
> records generated in the background process. They'd not replay.
I spent some time thinking about this case. I don't think this is
really principally a locking issue; I think it it's really a timing
issue around transaction abort. I believe that, if we wanted to be
able to write any tuples at all from within a parallel worker, there
are certain phases of transaction abort processing that would need to
happen only once we're sure that all of the backends involved have
done their local abort processing. smgrDoPendingDeletes() is one, but
I think we have pretty much the same problem with
RecordTransactionAbort() and ProcArrayEndTransaction(). Without some
synchronization, it would be possible for a parallel backend to stamp
a tuple with an XID after the abort record is already written, or
after the transaction has already been removed from the ProcArray.
Are we prepared to view that sort of thing as harmless?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
