Re: Strange Windows problem, lock_timeout test request

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Tom Lane wrote:
>> Another way that we perhaps should consider is to follow the example of
>> XLogInsert and use internally-threaded lists that are typically stored
>> in local arrays in the callers. I've never thought that way was
>> especially beautiful, but it does have the advantage of being an idiom
>> that's already in use in other low-level code.

> FWIW you could use an slist from ilist.c. It means each node would need
> a "next" pointer, but there's no separately allocated list cell.

Yeah, if the usage patterns were more complicated it'd be worth thinking
about that. Right now there's nothing more complex than this:

*************** ResolveRecoveryConflictWithBufferPin(voi
*** 428,435 ****
* Wake up at ltime, and check for deadlocks as well if we will be
* waiting longer than deadlock_timeout
*/
! enable_timeout_after(STANDBY_DEADLOCK_TIMEOUT, DeadlockTimeout);
! enable_timeout_at(STANDBY_TIMEOUT, ltime);
}

/* Wait to be signaled by UnpinBuffer() */
--- 428,442 ----
* Wake up at ltime, and check for deadlocks as well if we will be
* waiting longer than deadlock_timeout
*/
! EnableTimeoutParams timeouts[2];
!
! timeouts[0].id = STANDBY_TIMEOUT;
! timeouts[0].type = TMPARAM_AT;
! timeouts[0].fin_time = ltime;
! timeouts[1].id = STANDBY_DEADLOCK_TIMEOUT;
! timeouts[1].type = TMPARAM_AFTER;
! timeouts[1].delay_ms = DeadlockTimeout;
! enable_timeouts(timeouts, 2);
}

and you really can't improve that by complicating the data structure.

regards, tom lane