Hello, I tried to look at the patch #1 and #2 at first, but I shall rest of portion later.
* basic checks All the patches (not only #1, #2) can be applied without any problem towards the latest master branch. Its build was succeeded with Werror. Regression test works fine on the core and contrib/test_shm_mq. * on-dsm-detach-v2.patch It reminded me the hook registration/invocation mechanism on apache/httpd. It defines five levels for invocation order (REALLY_FIRST, FIRST, MIDDLE, LAST, REALLY_LAST), but these are alias of integer values, in other words, they are just kicks the hook in order to the priority value associated with a function pointer. These flexibility may make sense. We may want to control the order to release resources more fine grained in the future. For example, isn't it a problem if we have only two levels when a stuff in a queue needs to be released earlier than the queue itself? I'm not 100% certain on this suggestion because on_shmen_exit is a hook that does not host so much callbacks, thus extension may implement their own way on the SHMEM_EXIT_EARLY or SHMEM_EXIT_LATE stage of course. * shm-toc-v1.patch >From my experience, it makes sense to put a magic number on the tail of toc segment to detect shared-memory usage overrun. It helps to find bugs bug hard to find because of concurrent jobs. Probably, shm_toc_freespace() is a point to put assertion. How many entries is shm_toc_lookup() assumed to chain? It assumes a liner search from the head of shm_toc segment, and it is prerequisite for lock-less reference, isn't it? Does it make a problem if shm_toc host many entries, like 100 or 1000? Or, it is not an expected usage? #3 and #4 should be looked later... Thanks, 2013/11/8 Robert Haas <robertmh...@gmail.com>: > On Wed, Nov 6, 2013 at 9:48 AM, Peter Eisentraut <pete...@gmx.net> wrote: >> This patch needs to be rebased. > > Thanks. You didn't mention which of the four needed rebasing, but it > seems that it's just the first one. New version of just that patch > attached; please use the prior versions of the remaining three. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
