Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > Tom Lane escribió: >> I seem to recall that we've previously found that you have to write >> MAXALIGN(offsetof(shm_mq, mq_ring[0])) + MAXIMUM_ALIGNOF; >> to keep MSVC happy with a reference to an array member in offsetof.
> Hmm, this seems to contradict what's documented at the definition of > FLEXIBLE_ARRAY_MEMBER: Ah, I thought we had that issue documented somewhere, but failed to find this comment, or I'd have known that was backwards. The other possibility I was contemplating is that "export a const variable" doesn't actually work for some reason. We're not in the habit of doing that elsewhere, so I don't find that theory outlandish. Perhaps it could be fixed by adding PGDLLIMPORT to the extern, but on the whole I'd rather avoid the technique altogether. The least-unlike-other-Postgres-code approach would be to go ahead and export the struct so that the size computation could be provided as a #define in the same header. Robert stated a couple days ago that he didn't foresee much churn in this struct, so that doesn't seem unacceptable. Another possibility is to refactor so that testing an allocation request against shm_mq_minimum_size is the responsibility of storage/ipc/shm_mq.c, not some random code in a contrib module. It's not immediately apparent to me why it's good code modularization to have a contrib module responsible for checking sizes based on the sizeof a struct it's not supposed to have any access to. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers