On Wed, Dec 14, 2016 at 5:38 PM, Ashutosh Sharma <ashu.coe...@gmail.com> wrote: >> What I think you want to do is modify the flag events associated to >> the socket read/write event to be updated in WaitEventAdjustWin32(), > > Well, this does not work as the following if check does not allow the > FD_READ or FD_WRITE flags to be applied on the already existing socket > handle. We have already debugged and verified this. > > if (events == event->events && > (!(event->events & WL_LATCH_SET) || set->latch == latch)) > return; > >> which gets called in ModifyWaitEvent(). By the way, position 0 refers >> to a socket for FeBeWaitSet, but that's a mandatory thing when a list >> of events is created with AddWaitEventToSet. > > Yes, 0th position refers to event for socket and we will have to pass > 0 as an argument to get socket events from FeBeWaitSet. You may see > the usage of ModifyWaitEvent() in secure_read where we are passing the > hard coded value (0) to get the socket events from the FeBeWaitSet.
I have just read the patch, and hardcoding the array position for a socket event to 0 assumes that the socket event will be *always* the first one in the list. but that cannot be true all the time, any code that does not register the socket event as the first one in the list will likely break. -- Michael -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers