On Tue, Jan 26, 2016 at 6:53 PM, Dmitriy Sarafannikov
<dimon99901@mail.ru> wrote:
> I found that transInvalInfo == NULL
>
> (gdb) print transInvalInfo
> $1 = (TransInvalidationInfo *) 0x0
>
> Apparently, he crashes on this row
> *RelcacheInitFileInval = transInvalInfo->RelcacheInitFileInval;
>
> in REL9_5_STABLE branch i see check if transInvalInfo == NULL
>
> /* Quick exit if we haven't done anything with invalidation messages. */
> if (transInvalInfo == NULL)
> {
> *RelcacheInitFileInval = false;
> *msgs = NULL;
> return 0;
> }
>
> but in REL9_4_STABLE this check is absent
Yes, this check comes from 6cb4afff. In the case of a transaction
commit I am failing to see immediately why transInvalInfo would be
NULL, it is initialized by AtStart_Inval() when starting a
transaction. transInvalInfo becomes NULL only in AtEOXact_Inval()
after the transaction commit is recorded so the code involved looks
correct to me.
> #4 0x00007f6ecc6ad4d6 in ProcessCatchupEvent () at
> /build/postgresql-9.4-MZhK6O/postgresql-9.4-9.4.5/build/../src/backend/storage/ipc/sinval.c:338
> notify_enabled = 1 '\001'
> __func__ = "ProcessCatchupEvent"
> #5 0x00007f6ecc6ad815 in EnableCatchupInterrupt () at
> /build/postgresql-9.4-MZhK6O/postgresql-9.4-9.4.5/build/../src/backend/storage/ipc/sinval.c:273
This is telling that this process is running a cache invalidation
signal outside a transaction block. The only logical explanation that
I see here is that the transaction state of CurrentTransactionState is
not set to TBLOCK_DEFAULT, making transInvalInfo to not be
initialized, but we are sure that it is initialized via
IsTransactionOrTransactionBlock and CurrentTransactionState is set
per-backend. What kind of commands have you run in parallel for this
to happen?
If there is a bug, that's an interesting problem.
--
Michael
