Horton

Thread

Commits

  1. Check for interrupts and stack overflow in TParserGet().

  2. Doc: Clarify the behavior of triggers/rules in a logical subscriber.

  1. BUG #17995: Segmentation fault caused by UPDATE statement

    The Post Office <noreply@postgresql.org> — 2023-06-24T18:33:27Z

    The following bug has been logged on the website:

Bug reference:      17995
Logged by:          Zuming Jiang
Email address:      zuming.jiang@inf.ethz.ch
PostgreSQL version: 16beta1
Operating system:   Ubuntu 20.04
Description:        

My fuzzer finds a bug in Postgres, which crashes Postgres. This bug can be
reproduced even after applying the fixing patches for
https://www.postgresql.org/message-id/flat/b2bd02dff61af15e3526293e2771f874cf2a3be7.camel@cybertec.at

--- Test case ---
create table t1 (pkey int4, c7 float8, c8 text, c9 float8);
insert into t1 (pkey, c7, c8, c9) values (96000, 0.0, '3n@', -79.14);
update t1 set c7 = t1.c9 / t1.c7 where 'a' @@ repeat(t1.c8, t1.pkey);
---

--- Expected behavior ---
Postgres does not crash.

--- Actual behavior ---
Postgres crashes.

--- Server log ---
2023-06-24 18:27:12.606 UTC [36] LOG:  server process (PID 3917180) was
terminated by signal 11: Segmentation fault
2023-06-24 18:27:12.606 UTC [36] DETAIL:  Failed process was running: update
t1 set c7 = t1.c9 / t1.c7 where 'a' @@ repeat(t1.c8, t1.pkey)
2023-06-24 18:27:12.606 UTC [36] LOG:  terminating any other active server
processes
2023-06-24 18:27:12.607 UTC [36] LOG:  all server processes terminated;
reinitializing
2023-06-24 18:27:12.658 UTC [3917181] LOG:  database system was interrupted;
last known up at 2023-06-24 18:27:11 UTC
2023-06-24 18:27:22.848 UTC [3917181] LOG:  database system was not properly
shut down; automatic recovery in progress
---

--- Postgres version ---
Github commit: f5c446e3367527f9db1506d7c38d2f56e20950b6
Version: PostgreSQL 16beta1 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
9.4.0-1ubuntu1~20.04.1) 9.4.0, 64-bit

--- Platform information ---
Platform: Ubuntu 20.04
Kernel: Linux 5.4.0-147-generic

  2. Re: BUG #17995: Segmentation fault caused by UPDATE statement

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-06-24T19:51:59Z

    PG Bug reporting form <noreply@postgresql.org> writes:
> --- Test case ---
> create table t1 (pkey int4, c7 float8, c8 text, c9 float8);
> insert into t1 (pkey, c7, c8, c9) values (96000, 0.0, '3n@', -79.14);
> update t1 set c7 = t1.c9 / t1.c7 where 'a' @@ repeat(t1.c8, t1.pkey);

Hmm, I don't think this is about the UPDATE per se, it's about
not having a stack depth check in TParserGet() :-(

			regards, tom lane

  3. Re: BUG #17995: Segmentation fault caused by UPDATE statement

    Willian Colognesi <willian_colognesi@trimble.com> — 2023-06-24T20:48:09Z

    A time ago I had a problem with segmentation fault, and it was solved
disabling jit.


On Sat, Jun 24, 2023, 16:52 Tom Lane <tgl@sss.pgh.pa.us> wrote:

> PG Bug reporting form <noreply@postgresql.org> writes:
> > --- Test case ---
> > create table t1 (pkey int4, c7 float8, c8 text, c9 float8);
> > insert into t1 (pkey, c7, c8, c9) values (96000, 0.0, '3n@', -79.14);
> > update t1 set c7 = t1.c9 / t1.c7 where 'a' @@ repeat(t1.c8, t1.pkey);
>
> Hmm, I don't think this is about the UPDATE per se, it's about
> not having a stack depth check in TParserGet() :-(
>
>                         regards, tom lane
>
>
>

  4. Re: BUG #17995: Segmentation fault caused by UPDATE statement

    Alexander Law <exclusion@gmail.com> — 2023-06-25T03:00:00Z

    Hello,

24.06.2023 22:51, Tom Lane wrote:
> Hmm, I don't think this is about the UPDATE per se, it's about
> not having a stack depth check in TParserGet() :-(

BTW, there is a commitfest entry to eliminate a bunch of other stack
overflow hazards (may be the fuzzer can find some of them too):
https://commitfest.postgresql.org/43/4239/

(It looks like this issue was not discovered there because TParserGet()
doesn't call itself directly.)

Best regards,
Alexander

  5. Re: BUG #17995: Segmentation fault caused by UPDATE statement

    Michael Paquier <michael@paquier.xyz> — 2023-06-26T04:21:47Z

    On Sun, Jun 25, 2023 at 06:00:00AM +0300, Alexander Lakhin wrote:
> BTW, there is a commitfest entry to eliminate a bunch of other stack
> overflow hazards (may be the fuzzer can find some of them too):
> https://commitfest.postgresql.org/43/4239/

Thanks for the pointer, I'll double-check that.  Some of the locations
of stack depth checks proposed involve performance-sensitive code
paths, though, like mcxt.c :/
--
Michael

  6. Re: BUG #17995: Segmentation fault caused by UPDATE statement

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-06-26T04:27:08Z

    Michael Paquier <michael@paquier.xyz> writes:
> On Sun, Jun 25, 2023 at 06:00:00AM +0300, Alexander Lakhin wrote:
>> BTW, there is a commitfest entry to eliminate a bunch of other stack
>> overflow hazards (may be the fuzzer can find some of them too):
>> https://commitfest.postgresql.org/43/4239/

> Thanks for the pointer, I'll double-check that.  Some of the locations
> of stack depth checks proposed involve performance-sensitive code
> paths, though, like mcxt.c :/

I hadn't looked at the patch yet, but ... mcxt.c?  How is that recursive?
Even if there is some path that recurses through that, wouldn't the
check be better placed in a less-hot part of the loop?

			regards, tom lane

  7. Re: BUG #17995: Segmentation fault caused by UPDATE statement

    Michael Paquier <michael@paquier.xyz> — 2023-06-26T04:56:42Z

    On Mon, Jun 26, 2023 at 12:27:08AM -0400, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> Thanks for the pointer, I'll double-check that.  Some of the locations
>> of stack depth checks proposed involve performance-sensitive code
>> paths, though, like mcxt.c :/
> 
> I hadn't looked at the patch yet, but ... mcxt.c?  How is that recursive?
> Even if there is some path that recurses through that, wouldn't the
> check be better placed in a less-hot part of the loop?

Yeah, that's my impression.  I'll switch to the other thread after
looking more in details.
--
Michael

  8. Re: BUG #17995: Segmentation fault caused by UPDATE statement

    Alexander Law <exclusion@gmail.com> — 2023-06-26T05:00:01Z

    26.06.2023 07:27, Tom Lane wrote:
> I hadn't looked at the patch yet, but ... mcxt.c?  How is that recursive?
> Even if there is some path that recurses through that, wouldn't the
> check be better placed in a less-hot part of the loop?

In that thread Egor Chindyaskin showed proofs for stack overflow in all the
functions, that the fixes were proposed for. For example:
#MemoryContextStatsInternal
(n=1000000; printf "BEGIN;"; for ((i=1;i<=$n;i++)); do printf "SAVEPOINT s$i;"; done; printf "SELECT 
pg_log_backend_memory_contexts(pg_backend_pid())") | psql >/dev/null

Though maybe for some of those functions less-hot places could be found to
check the stack.

Best regards,
Alexander