From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | CharSyam <charsyam(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS][PATCH] adding simple sock check for windows |
Date: | 2018-03-31 18:03:38 |
Message-ID: | 23870.1522519418@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
... Oh, just to make things even more fun, PQsocket() returns int, not
pgsocket; see its header comment. Therefore, that test is correctly
coded as-is (though it's still useless), and the real problem is that
ParallelSlot.sock ought to be declared int not pgsocket. If you look
around at our other places that read PQsocket() and use its result in
select() masks, they uniformly use int variables, and I think they're
right.
Actually, the more I look at this code, the more problems I'm finding.
The wait-for-a-free-connection code is just broken on its face, because
it supposes it can retry select() waits without reinitializing the
FD_SET. The loop in vacuum_one_database() uses "conn" to call
prepare_vacuum_command() without any thought as to whether that is a
free connection --- which, typically, it isn't. It looks to me like
libpq silently copes with this silliness, just waiting for the active
command to finish and then doing what it's told, but the net result
is that supposedly-concurrent vacuums get serialized.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2018-03-31 18:27:14 | Re: [HACKERS] A design for amcheck heapam verification |
Previous Message | Tomas Vondra | 2018-03-31 17:56:56 | Re: some last patches breaks plan cache |