On Thu, Jun 15, 2017 at 3:31 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> But surely the silent treatment should only apply to DSM_OP_CREATE? > > Oh ... scratch that, it *does* only apply to DSM_OP_CREATE. > > The lack of any other message before the 'could not map' failure must, > then, mean that dsm_attach() couldn't find an entry in shared memory > that it wanted to attach to. >
Yes, I also think so. > But how could that happen? > I could think of a couple of reasons due to which it can happen. (a) the value of segment handle passed by the master backend to worker backend somehow got messed up. (b) all other workers along with master backend exited before one of the workers try to attach. (c) the master backend has not actually created any dsm segment (like when max segments have reached) but still invoked some workers. (d) some corner case bug in dsm code due to which it can't attach to a valid segment handle. Now, of these, I have checked that (c) can't happen because we ensure that if the segment is not created than we make workers as zero. I think (b) shouldn't happen because we wait for all workers to exit before the query is finished. Now, I think (a) and (d) are slightly related and I have looked around in the relevant code but didn't find any obvious problem, however, it seems to me that it might be something which happens on Cygwin environment differently. For example, I think the value of seg->handle can be different from what we expect in dsm_create. Basically, random returns long and we are storing it in dsm_handle (uint32), so considering long is 8 bytes on Cygwin [1] and 4 bytes on Windows the value could wrap but even if that happens it is not clear how that can cause what we are seeing in this case. [1] - https://stackoverflow.com/questions/384502/what-is-the-bit-size-of-long-on-64-bit-windows -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
