Thread: [bugfix] sepgsql didn't follow the latest core API changes
This patch fixes a few portions on which sepgsql didn't follow the latest
core API changes.
1) Even though the prototype of ProcessUtility_hook was recently changed,
sepgsql side didn't follow this update, so it made build failed.
2) sepgsql internally uses GETSTRUCT() and HeapTupleGetOid() macro
these were moved to htup_details.h, so it needs an additional #include
for "access/htup_defails.h".
3) sepgsql internally used a bool typed variable named "abort".
I noticed it conflicts with ereport macro because it internally expanded to
ereport_domain that contains invocation of "abort()". So, it renamed this
variables to abort_on_violation.
#define ereport_domain(elevel, domain, rest) \
(errstart(elevel, __FILE__, __LINE__, PG_FUNCNAME_MACRO, domain) ? \
(errfinish rest) : (void) 0), \
((elevel) >= ERROR ? abort() : (void) 0)
This does not affect to v9.2, so please apply it on the master branch.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
Attachment
Excerpts from Kohei KaiGai's message of dom sep 02 15:53:22 -0300 2012: > This patch fixes a few portions on which sepgsql didn't follow the latest > core API changes. I think you should get a buildfarm animal installed that builds and tests sepgsql, to avoid this kind of problem in the future. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
2012/9/3 Alvaro Herrera <alvherre@2ndquadrant.com>: > Excerpts from Kohei KaiGai's message of dom sep 02 15:53:22 -0300 2012: >> This patch fixes a few portions on which sepgsql didn't follow the latest >> core API changes. > > I think you should get a buildfarm animal installed that builds and > tests sepgsql, to avoid this kind of problem in the future. > Thanks for your suggestion. I'm interested in. http://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto Does it test only build-correctness? Or, is it possible to include result of regression test for result to be alarmed? -- KaiGai Kohei <kaigai@kaigai.gr.jp>
Excerpts from Kohei KaiGai's message of mié sep 05 08:30:37 -0300 2012: > 2012/9/3 Alvaro Herrera <alvherre@2ndquadrant.com>: > > Excerpts from Kohei KaiGai's message of dom sep 02 15:53:22 -0300 2012: > >> This patch fixes a few portions on which sepgsql didn't follow the latest > >> core API changes. > > > > I think you should get a buildfarm animal installed that builds and > > tests sepgsql, to avoid this kind of problem in the future. > > > Thanks for your suggestion. I'm interested in. > > http://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto > > Does it test only build-correctness? Or, is it possible to include > result of regression test for result to be alarmed? Yes, regression test diffs are also reported and can cause failures. As far as I know, you can construct your own test steps, if you want to do something customized that's not present in regular BF animals. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 09/05/2012 09:11 AM, Alvaro Herrera wrote: > Excerpts from Kohei KaiGai's message of mié sep 05 08:30:37 -0300 2012: >> 2012/9/3 Alvaro Herrera <alvherre@2ndquadrant.com>: >>> Excerpts from Kohei KaiGai's message of dom sep 02 15:53:22 -0300 2012: >>>> This patch fixes a few portions on which sepgsql didn't follow the latest >>>> core API changes. >>> I think you should get a buildfarm animal installed that builds and >>> tests sepgsql, to avoid this kind of problem in the future. >>> >> Thanks for your suggestion. I'm interested in. >> >> http://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto >> >> Does it test only build-correctness? Or, is it possible to include >> result of regression test for result to be alarmed? > Yes, regression test diffs are also reported and can cause failures. > As far as I know, you can construct your own test steps, if you want to > do something customized that's not present in regular BF animals. Looking at SEPgsql testing is on my long TODO list. I'll have to set up a separate VM for it, as I don't habitually run SELinux. cheers andrew
On Sun, Sep 2, 2012 at 2:53 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: > This patch fixes a few portions on which sepgsql didn't follow the latest > core API changes. > > 1) Even though the prototype of ProcessUtility_hook was recently changed, > sepgsql side didn't follow this update, so it made build failed. > > 2) sepgsql internally uses GETSTRUCT() and HeapTupleGetOid() macro > these were moved to htup_details.h, so it needs an additional #include > for "access/htup_defails.h". > > 3) sepgsql internally used a bool typed variable named "abort". > I noticed it conflicts with ereport macro because it internally expanded to > ereport_domain that contains invocation of "abort()". So, it renamed this > variables to abort_on_violation. > > #define ereport_domain(elevel, domain, rest) \ > (errstart(elevel, __FILE__, __LINE__, PG_FUNCNAME_MACRO, domain) ? \ > (errfinish rest) : (void) 0), \ > ((elevel) >= ERROR ? abort() : (void) 0) > > This does not affect to v9.2, so please apply it on the master branch. I have committed this untested. It seems pretty mechanical and I assume that you tested it. Anyway, it's certainly broken without the patch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
2012/9/5 Andrew Dunstan <andrew@dunslane.net>: > > On 09/05/2012 09:11 AM, Alvaro Herrera wrote: >> >> Excerpts from Kohei KaiGai's message of mié sep 05 08:30:37 -0300 2012: >>> >>> 2012/9/3 Alvaro Herrera <alvherre@2ndquadrant.com>: >>>> >>>> Excerpts from Kohei KaiGai's message of dom sep 02 15:53:22 -0300 2012: >>>>> >>>>> This patch fixes a few portions on which sepgsql didn't follow the >>>>> latest >>>>> core API changes. >>>> >>>> I think you should get a buildfarm animal installed that builds and >>>> tests sepgsql, to avoid this kind of problem in the future. >>>> >>> Thanks for your suggestion. I'm interested in. >>> >>> http://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto >>> >>> Does it test only build-correctness? Or, is it possible to include >>> result of regression test for result to be alarmed? >> >> Yes, regression test diffs are also reported and can cause failures. >> As far as I know, you can construct your own test steps, if you want to >> do something customized that's not present in regular BF animals. > > Looking at SEPgsql testing is on my long TODO list. I'll have to set up a > separate VM for it, as I don't habitually run SELinux. > If you are available to provide a VM environment for sepgsql, let me help set up its build and regression test environment. As you may know, the regression test of sepgsql requires some additional configurations on operating system level, such as security policy load and so on. I expect we have to add something special stuff onto the buildfirm system. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
2012/9/5 Robert Haas <robertmhaas@gmail.com>: > On Sun, Sep 2, 2012 at 2:53 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: >> This patch fixes a few portions on which sepgsql didn't follow the latest >> core API changes. >> >> 1) Even though the prototype of ProcessUtility_hook was recently changed, >> sepgsql side didn't follow this update, so it made build failed. >> >> 2) sepgsql internally uses GETSTRUCT() and HeapTupleGetOid() macro >> these were moved to htup_details.h, so it needs an additional #include >> for "access/htup_defails.h". >> >> 3) sepgsql internally used a bool typed variable named "abort". >> I noticed it conflicts with ereport macro because it internally expanded to >> ereport_domain that contains invocation of "abort()". So, it renamed this >> variables to abort_on_violation. >> >> #define ereport_domain(elevel, domain, rest) \ >> (errstart(elevel, __FILE__, __LINE__, PG_FUNCNAME_MACRO, domain) ? \ >> (errfinish rest) : (void) 0), \ >> ((elevel) >= ERROR ? abort() : (void) 0) >> >> This does not affect to v9.2, so please apply it on the master branch. > > I have committed this untested. It seems pretty mechanical and I > assume that you tested it. Anyway, it's certainly broken without the > patch. > Thanks, I'd like to pay attention to core API changes more. I still have one other bug fix for v9.2 and master branch. Isn't it obvious to apply? http://archives.postgresql.org/message-id/CADyhKSVWKjCKY3cDeQG6qp7OczqsbJtT9cihk3HB7TkvcEDD+Q@mail.gmail.com -- KaiGai Kohei <kaigai@kaigai.gr.jp>
Kohei KaiGai wrote: > 2012/9/5 Andrew Dunstan <andrew@dunslane.net>: > > Looking at SEPgsql testing is on my long TODO list. I'll have to set up a > > separate VM for it, as I don't habitually run SELinux. > > > If you are available to provide a VM environment for sepgsql, let me help > set up its build and regression test environment. > > As you may know, the regression test of sepgsql requires some additional > configurations on operating system level, such as security policy load and > so on. I expect we have to add something special stuff onto the buildfirm > system. Did this go anywhere? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
2012/10/10 Alvaro Herrera <alvherre@2ndquadrant.com>: > Kohei KaiGai wrote: >> 2012/9/5 Andrew Dunstan <andrew@dunslane.net>: > >> > Looking at SEPgsql testing is on my long TODO list. I'll have to set up a >> > separate VM for it, as I don't habitually run SELinux. >> > >> If you are available to provide a VM environment for sepgsql, let me help >> set up its build and regression test environment. >> >> As you may know, the regression test of sepgsql requires some additional >> configurations on operating system level, such as security policy load and >> so on. I expect we have to add something special stuff onto the buildfirm >> system. > > Did this go anywhere? > Andrew offered a test environment, but I could not have enough time to set up it yet... Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
Kohei KaiGai wrote: > 2012/10/10 Alvaro Herrera <alvherre@2ndquadrant.com>: > > Kohei KaiGai wrote: > >> 2012/9/5 Andrew Dunstan <andrew@dunslane.net>: > > > >> > Looking at SEPgsql testing is on my long TODO list. I'll have to set up a > >> > separate VM for it, as I don't habitually run SELinux. > >> > > >> If you are available to provide a VM environment for sepgsql, let me help > >> set up its build and regression test environment. > >> > >> As you may know, the regression test of sepgsql requires some additional > >> configurations on operating system level, such as security policy load and > >> so on. I expect we have to add something special stuff onto the buildfirm > >> system. > > > > Did this go anywhere? > > > Andrew offered a test environment, but I could not have enough time to > set up it yet... I will snail-mail you a round tuit I have at home. I would feel more comfortable committing sepgsql stuff if we had it. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services