Re: Strange Windows problem, lock_timeout test request

Alvaro Herrera <alvherre@2ndquadrant.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
thandeadlock_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
thandeadlock_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