Subject: Re: Getting server crash after running sqlsmith

From: tushar <[email-masked]>
Date: Tue, 23 May 2017 11:16:29 +0530

On 03/29/2017 12:06 AM, Tom Lane wrote:
> Hm ... I don't see a crash here, but I wonder whether you have parameters
> set that would cause this query to be run as a parallel query?  Because
> pg_rotate_logfile() is marked as parallel-safe in pg_proc, which seems
> probably insane.
Well, I am able to see a crash .  Enable "logging_collector=on" in 
postgresql.conf file / restart the server and fire below sql query - 5 
or 6 times

select
           80 as c0,
           pg_catalog.pg_backend_pid() as c1,
           68 as c2,
           subq_1.c0 as c3,
           subq_1.c0 as c4
         from
           (select
                 ref_0.specific_schema as c0
               from
                 information_schema.role_routine_grants as ref_0,
                 lateral (select
                       ref_0.grantor as c0,
                       50 as c1
                     from
                       information_schema.routines as ref_1
                     where (63 = 86)
                       or (pg_catalog.pg_advisory_lock(
                           cast(ref_1.result_cast_datetime_precision as 
integer),
                           cast(pg_catalog.bttidcmp(
                             cast(null as tid),
                             cast(null as tid)) as integer)) is NULL)
                     limit 143) as subq_0
               where pg_catalog.pg_rotate_logfile() is NULL) as subq_1
         where 50 <> 45;

-- 
regards,tushar
EnterpriseDB  https://www.enterprisedb.com/
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list ([email-masked])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

---

From: Robert Haas <[email-masked]>
Date: Tue, 23 May 2017 08:55:58 -0400

On Tue, May 23, 2017 at 1:46 AM, tushar <[email-masked]> wrote:
> postgresql.conf file / restart the server and fire below sql query - 5 or 6
> times

Just out of curiosity, what happens if you try it with the attached patch?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

---

From: tushar <[email-masked]>
Date: Tue, 23 May 2017 18:37:40 +0530

> Just out of curiosity, what happens if you try it with the attached patch?
Thanks, issue seems to be fixed after applying your patch.

---

From: Tom Lane <[email-masked]>
Date: Tue, 23 May 2017 09:45:14 -0400

> Just out of curiosity, what happens if you try it with the attached patch?

Surely that's pretty unsafe?

			regards, tom lane

---

From: Robert Haas <[email-masked]>
Date: Tue, 23 May 2017 19:45:43 -0400

> Surely that's pretty unsafe?

Yes.  I was just curious to see whether it would work.  I think what
we need to do is teach pqsignal() to block all of the necessary
signals using sa_mask and then remove all of the explicit
blocking/unblocking logic from the signal handlers themselves.  IIUC,
the point of sa_mask is precisely that you want the operating system
to handle the save/restore of the signal mask rather than doing it
yourself in the handler, precisely because doing it in the handler
creates windows at the beginning and end of the handler where the mask
may not be what you want.

In the case of Linux and MacOS, at least, the default behavior (unless
SA_NODEFER is set) is to automatically block the signal currently
being handled, so there's likely no way to blow out the stack during
the brief window before PG_SETMASK(&BlockSig) is called.  You could
receive some *other* signal during that window, but then that one
would blocked too, so I don't think you can stack up more frames this
way than the number of distinct signal handlers you have.  However,
the window at the end of the function - after PG_SETMASK(&UnBlockSig)
has been invoked - can recurse arbitrarily deep.  At that point we've
unblocked the signal we're currently handling, so we're playing with
fire.