Horton
Menu

Thread

  1. [bugfix] sepgsql didn't follow the latest core API changes

    Kohei KaiGai <kaigai@kaigai.gr.jp> — 2012-09-02T18:53:22Z

    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>

  2. Re: [bugfix] sepgsql didn't follow the latest core API changes

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2012-09-03T13:15:06Z

    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

  3. Re: [bugfix] sepgsql didn't follow the latest core API changes

    Kohei KaiGai <kaigai@kaigai.gr.jp> — 2012-09-05T11:30:37Z

    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>

  4. Re: [bugfix] sepgsql didn't follow the latest core API changes

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2012-09-05T13:11:05Z

    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

  5. Re: [bugfix] sepgsql didn't follow the latest core API changes

    Andrew Dunstan <andrew@dunslane.net> — 2012-09-05T13:49:09Z

    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

  6. Re: [bugfix] sepgsql didn't follow the latest core API changes

    Robert Haas <robertmhaas@gmail.com> — 2012-09-05T18:02:50Z

    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

  7. Re: [bugfix] sepgsql didn't follow the latest core API changes

    Kohei KaiGai <kaigai@kaigai.gr.jp> — 2012-09-05T20:25:37Z

    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>

  8. Re: [bugfix] sepgsql didn't follow the latest core API changes

    Kohei KaiGai <kaigai@kaigai.gr.jp> — 2012-09-05T20:35:03Z

    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>

  9. Re: [bugfix] sepgsql didn't follow the latest core API changes

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2012-10-10T15:44:47Z

    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

  10. Re: [bugfix] sepgsql didn't follow the latest core API changes

    Kohei KaiGai <kaigai@kaigai.gr.jp> — 2012-10-10T16:09:56Z

    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>

  11. Re: [bugfix] sepgsql didn't follow the latest core API changes

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2012-10-10T16:18:29Z

    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