Обсуждение: Peripatus: Can someone look?

Поиск
Список
Период
Сортировка

Peripatus: Can someone look?

От
Larry Rosenman
Дата:
My Buildfarm animal (peripatus) has been failing check since yesterday.  
Can someone look at it?


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106



Re: Peripatus: Can someone look?

От
Tom Lane
Дата:
Larry Rosenman <ler@lerctr.org> writes:
> My Buildfarm animal (peripatus) has been failing check since yesterday.
> Can someone look at it?

It's been doing this in parallel queries, in v11 and up:

2019-09-29 19:00:15.534 CDT [49513:1] ERROR:  could not open shared memory segment "/PostgreSQL.1225945786": Permission
denied
2019-09-29 19:00:15.535 CDT [48596:491] pg_regress/partition_prune ERROR:  parallel worker failed to initialize
2019-09-29 19:00:15.535 CDT [48596:492] pg_regress/partition_prune HINT:  More details may be available in the server
log.
2019-09-29 19:00:15.535 CDT [48596:493] pg_regress/partition_prune CONTEXT:  PL/pgSQL function
explain_parallel_append(text)line 5 at FOR over EXECUTE statement 
2019-09-29 19:00:15.535 CDT [48596:494] pg_regress/partition_prune STATEMENT:  select explain_parallel_append('select
avg(ab.a)from ab inner join lprt_a a on ab.a = a.a where a.a in(1, 0, 0)'); 
2019-09-29 19:00:15.535 CDT [48596:495] pg_regress/partition_prune WARNING:  could not remove shared memory segment
"/PostgreSQL.1225945786":Permission denied 

which looks like an external problem to me --- certainly, nothing
we changed yesterday would explain it.  Did you change anything
about the system configuration, or do a software update?

            regards, tom lane



Re: Peripatus: Can someone look?

От
Larry Rosenman
Дата:
On 10/01/2019 10:46 am, Tom Lane wrote:
> Larry Rosenman <ler@lerctr.org> writes:
>> My Buildfarm animal (peripatus) has been failing check since 
>> yesterday.
>> Can someone look at it?
> 
> It's been doing this in parallel queries, in v11 and up:
> 
> 2019-09-29 19:00:15.534 CDT [49513:1] ERROR:  could not open shared
> memory segment "/PostgreSQL.1225945786": Permission denied
> 2019-09-29 19:00:15.535 CDT [48596:491] pg_regress/partition_prune
> ERROR:  parallel worker failed to initialize
> 2019-09-29 19:00:15.535 CDT [48596:492] pg_regress/partition_prune
> HINT:  More details may be available in the server log.
> 2019-09-29 19:00:15.535 CDT [48596:493] pg_regress/partition_prune
> CONTEXT:  PL/pgSQL function explain_parallel_append(text) line 5 at
> FOR over EXECUTE statement
> 2019-09-29 19:00:15.535 CDT [48596:494] pg_regress/partition_prune
> STATEMENT:  select explain_parallel_append('select avg(ab.a) from ab
> inner join lprt_a a on ab.a = a.a where a.a in(1, 0, 0)');
> 2019-09-29 19:00:15.535 CDT [48596:495] pg_regress/partition_prune
> WARNING:  could not remove shared memory segment
> "/PostgreSQL.1225945786": Permission denied
> 
> which looks like an external problem to me --- certainly, nothing
> we changed yesterday would explain it.  Did you change anything
> about the system configuration, or do a software update?
> 
>             regards, tom lane

I did do an upgrade to a later SVN rev.

Let me reboot and see if that fixes anything.

(this is -CURRENT on FreeBSD, so it's always a moving target).


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106



Re: Peripatus: Can someone look?

От
Thomas Munro
Дата:
On Wed, Oct 2, 2019 at 4:49 AM Larry Rosenman <ler@lerctr.org> wrote:
> On 10/01/2019 10:46 am, Tom Lane wrote:
> > Larry Rosenman <ler@lerctr.org> writes:
> >> My Buildfarm animal (peripatus) has been failing check since
> >> yesterday.
> >> Can someone look at it?
> >
> > It's been doing this in parallel queries, in v11 and up:
> >
> > 2019-09-29 19:00:15.534 CDT [49513:1] ERROR:  could not open shared
> > memory segment "/PostgreSQL.1225945786": Permission denied
> > 2019-09-29 19:00:15.535 CDT [48596:491] pg_regress/partition_prune
> > ERROR:  parallel worker failed to initialize
> > 2019-09-29 19:00:15.535 CDT [48596:492] pg_regress/partition_prune
> > HINT:  More details may be available in the server log.
> > 2019-09-29 19:00:15.535 CDT [48596:493] pg_regress/partition_prune
> > CONTEXT:  PL/pgSQL function explain_parallel_append(text) line 5 at
> > FOR over EXECUTE statement
> > 2019-09-29 19:00:15.535 CDT [48596:494] pg_regress/partition_prune
> > STATEMENT:  select explain_parallel_append('select avg(ab.a) from ab
> > inner join lprt_a a on ab.a = a.a where a.a in(1, 0, 0)');
> > 2019-09-29 19:00:15.535 CDT [48596:495] pg_regress/partition_prune
> > WARNING:  could not remove shared memory segment
> > "/PostgreSQL.1225945786": Permission denied
> >
> > which looks like an external problem to me --- certainly, nothing
> > we changed yesterday would explain it.  Did you change anything
> > about the system configuration, or do a software update?
> >
> >                       regards, tom lane
>
> I did do an upgrade to a later SVN rev.
>
> Let me reboot and see if that fixes anything.
>
> (this is -CURRENT on FreeBSD, so it's always a moving target).

Hi Larry,

I'm seeing this on my FreeBSD 13 bleeding edge system too (built a
couple of days ago) and will see if I can find out what's up with
that.  The most obvious culprit is the stuff that just landed in the
kernel to support Linux-style memfd_create() and thereby changed
around some shm_open() related things.  Seems to be clearly not a
PostgreSQL problem.

Thanks,
Thomas



Re: Peripatus: Can someone look?

От
Larry Rosenman
Дата:
On 10/01/2019 8:33 pm, Thomas Munro wrote:
> On Wed, Oct 2, 2019 at 4:49 AM Larry Rosenman <ler@lerctr.org> wrote:
>> On 10/01/2019 10:46 am, Tom Lane wrote:
>> > Larry Rosenman <ler@lerctr.org> writes:
>> >> My Buildfarm animal (peripatus) has been failing check since
>> >> yesterday.
>> >> Can someone look at it?
>> >
>> > It's been doing this in parallel queries, in v11 and up:
>> >
>> > 2019-09-29 19:00:15.534 CDT [49513:1] ERROR:  could not open shared
>> > memory segment "/PostgreSQL.1225945786": Permission denied
>> > 2019-09-29 19:00:15.535 CDT [48596:491] pg_regress/partition_prune
>> > ERROR:  parallel worker failed to initialize
>> > 2019-09-29 19:00:15.535 CDT [48596:492] pg_regress/partition_prune
>> > HINT:  More details may be available in the server log.
>> > 2019-09-29 19:00:15.535 CDT [48596:493] pg_regress/partition_prune
>> > CONTEXT:  PL/pgSQL function explain_parallel_append(text) line 5 at
>> > FOR over EXECUTE statement
>> > 2019-09-29 19:00:15.535 CDT [48596:494] pg_regress/partition_prune
>> > STATEMENT:  select explain_parallel_append('select avg(ab.a) from ab
>> > inner join lprt_a a on ab.a = a.a where a.a in(1, 0, 0)');
>> > 2019-09-29 19:00:15.535 CDT [48596:495] pg_regress/partition_prune
>> > WARNING:  could not remove shared memory segment
>> > "/PostgreSQL.1225945786": Permission denied
>> >
>> > which looks like an external problem to me --- certainly, nothing
>> > we changed yesterday would explain it.  Did you change anything
>> > about the system configuration, or do a software update?
>> >
>> >                       regards, tom lane
>> 
>> I did do an upgrade to a later SVN rev.
>> 
>> Let me reboot and see if that fixes anything.
>> 
>> (this is -CURRENT on FreeBSD, so it's always a moving target).
> 
> Hi Larry,
> 
> I'm seeing this on my FreeBSD 13 bleeding edge system too (built a
> couple of days ago) and will see if I can find out what's up with
> that.  The most obvious culprit is the stuff that just landed in the
> kernel to support Linux-style memfd_create() and thereby changed
> around some shm_open() related things.  Seems to be clearly not a
> PostgreSQL problem.
> 
> Thanks,
> Thomas

Thanks, Thomas.

Here's my 2 SVN revs if that would help:
FreeBSD SVN rev:
r352600   -      -          1.69G 2019-09-22 13:13
r352873   NR     /          43.1G 2019-09-29 16:36


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106