Thread: Re: [HACKERS] Getting server crash after running sqlsmith
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
asc0, 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_precisionas
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
On Tue, May 23, 2017 at 1:46 AM, tushar <tushar.ahuja@enterprisedb.com> wrote: > 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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
On 05/23/2017 06:25 PM, Robert Haas wrote: > Just out of curiosity, what happens if you try it with the attached patch? Thanks, issue seems to be fixed after applying your patch. -- regards,tushar EnterpriseDB https://www.enterprisedb.com/ The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> Just out of curiosity, what happens if you try it with the attached patch?
Surely that's pretty unsafe?
regards, tom lane
On Tue, May 23, 2017 at 9:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> Just out of curiosity, what happens if you try it with the attached patch? > > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company