Re: Hot Standby remaining issues

Heikki Linnakangas wrote:
> Simon Riggs wrote:
>> @@ -654,10 +656,13 @@ LockAcquire(const LOCKTAG *locktag,
>> elog(PANIC, "lock table corrupted");
>> }
>> LWLockRelease(partitionLock);
>> - ereport(ERROR,
>> - (errcode(ERRCODE_OUT_OF_MEMORY),
>> - errmsg("out of shared memory"),
>> - errhint("You might need to increase max_locks_per_transaction.")));
>> + if (reportLockTableError)
>> + ereport(ERROR,
>> + (errcode(ERRCODE_OUT_OF_MEMORY),
>> + errmsg("out of shared memory"),
>> + errhint("You might need to increase max_locks_per_transaction.")));
>> + else
>> + return LOCKACQUIRE_NOT_AVAIL;
>> }
>> locallock->proclock = proclock;
>>
>
> That seems dangerous when dontWait==false.

Ah, I see now that you're only setting reportLockTableError just before
you call LockAcquire, and reset it afterwards. It's safe then, but it
should rather be another argument to the function, as how the global
variable is really being used.

The patch doesn't actually fix the issue it was supposed to fix. If a
read-only transaction holds a lot of locks, consuming so much lock space
that there's none left for the startup process to hold the lock it
wants, it will abort and bring down postmaster. The patch attempts to
kill any conflicting lockers, but those are handled fine already (if
there's any conflicting locks, LockAcquire will return
LOCKACQUIRE_NOT_AVAIL anyway). The problem is with non-conflicting locks
using up the lock space.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com