Robert Haas wrote:
> I suspect that this leads to bugs under concurrency, something to do
> with crosscheck_snapshot, but I couldn't say exactly what the problem
> is off the top of my head. My hope is that partitioning might be
> immune on the strength of knowing that any given tuple could only be
> present in one particular partition, but that might be wishful
> thinking.
Speaking of crosscheck_snapshot, I just noticed that the case of FKs
with repeatable read or serializable snapshot seems not to be covered by
tests at all, judging from the coverage report:
2635 : /*
2636 : * In READ COMMITTED mode, we just need to use an up-to-date regular
2637 : * snapshot, and we will see all rows that could be interesting. But in
2638 : * transaction-snapshot mode, we can't change the transaction snapshot. If
2639 : * the caller passes detectNewRows == false then it's okay to do the query
2640 : * with the transaction snapshot; otherwise we use a current snapshot, and
2641 : * tell the executor to error out if it finds any rows under the current
2642 : * snapshot that wouldn't be visible per the transaction snapshot. Note
2643 : * that SPI_execute_snapshot will register the snapshots, so we don't need
2644 : * to bother here.
2645 : */
2646 3026 : if (IsolationUsesXactSnapshot() && detectNewRows)
2647 : {
2648 0 : CommandCounterIncrement(); /* be sure all my own work is visible */
2649 0 : test_snapshot = GetLatestSnapshot();
2650 0 : crosscheck_snapshot = GetTransactionSnapshot();
2651 : }
2652 : else
2653 : {
2654 : /* the default SPI behavior is okay */
2655 3026 : test_snapshot = InvalidSnapshot;
2656 3026 : crosscheck_snapshot = InvalidSnapshot;
2657 : }
https://coverage.postgresql.org/src/backend/utils/adt/ri_triggers.c.gcov.html
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services