Horton

Thread

Commits

  1. Ensure we have a snapshot when updating various system catalogs.

  1. BUG #18309: TOASTed entry in pg_subscription provokes an assertion failure

    The Post Office <noreply@postgresql.org> — 2024-01-24T12:00:01Z

    The following bug has been logged on the website:

Bug reference:      18309
Logged by:          Alexander Lakhin
Email address:      exclusion@gmail.com
PostgreSQL version: 16.1
Operating system:   Ubuntu 22.04
Description:        

When a pg_subscription entry contains a TOASTed field, e.g., subconninfo,
several operations with the subscription trigger an assertion failure.

For example, with the following modification of test 029_on_error.pl:
-my $publisher_connstr = $node_publisher->connstr . ' dbname=postgres';
+my $publisher_connstr = $node_publisher->connstr . ' dbname=postgres
password=' . join('', map {chr(65 + rand 26)} (1 .. 10000));

I get an assertion failure with the stack:
...
#5  0x0000556d7c9d1cd7 in ExceptionalCondition
(conditionName=conditionName@entry=0x556d7ca356e0
"HaveRegisteredOrActiveSnapshot()", fileName=fileName@entry=0x556d7ca353e6
"toast_internals.c", lineNumber=lineNumber@entry=670)
    at assert.c:66
#6  0x0000556d7c48827d in init_toast_snapshot (...) at
toast_internals.c:670
#7  0x0000556d7c488331 in toast_delete_datum (...) at
toast_internals.c:429
#8  0x0000556d7c5283fa in toast_tuple_cleanup (...) at toast_helper.c:309
#9  0x0000556d7c4e06c4 in heap_toast_insert_or_update (...) at
heaptoast.c:333
#10 0x0000556d7c4d3a8a in heap_update (...) at heapam.c:3613
#11 0x0000556d7c4d44e9 in simple_heap_update (...) at heapam.c:4071
#12 0x0000556d7c57c0a8 in CatalogTupleUpdate (...) at indexing.c:322
#13 0x0000556d7c59d4a5 in DisableSubscription (...) at
pg_subscription.c:196
#14 0x0000556d7c812c76 in DisableSubscriptionAndExit () at worker.c:4748
#15 0x0000556d7c812e1c in start_table_sync (...) at worker.c:4386
#16 0x0000556d7c818176 in ApplyWorkerMain (...) at worker.c:4564
#17 0x0000556d7c7da7fa in StartBackgroundWorker () at bgworker.c:861
...

After this failure elimination (with PushActiveSnapshot()/
PopActiveSnapshot() inside DisableSubscriptionAndExit()), the same test
produces another one:
...
#5  0x0000555a203f1ce9 in ExceptionalCondition
(conditionName=conditionName@entry=0x555a204556e0
"HaveRegisteredOrActiveSnapshot()", fileName=fileName@entry=0x555a204553e6
"toast_internals.c", lineNumber=lineNumber@entry=670)
    at assert.c:66
#6  0x0000555a1fea827d in init_toast_snapshot (...) at
toast_internals.c:670
#7  0x0000555a1fea8331 in toast_delete_datum (...) at
toast_internals.c:429
#8  0x0000555a1ff483fa in toast_tuple_cleanup (...) at toast_helper.c:309
#9  0x0000555a1ff006c4 in heap_toast_insert_or_update (...) at
heaptoast.c:333
#10 0x0000555a1fef3a8a in heap_update (...) at heapam.c:3613
#11 0x0000555a1fef44e9 in simple_heap_update (...) at heapam.c:4071
#12 0x0000555a1ff9c0a8 in CatalogTupleUpdate (...) at indexing.c:322
#13 0x0000555a20231331 in UpdateTwoPhaseState (...) at tablesync.c:1669
#14 0x0000555a202383d3 in ApplyWorkerMain (...) at worker.c:4694
#15 0x0000555a201fa7fa in StartBackgroundWorker () at bgworker.c:861
...

After this failure elimination (with PushActiveSnapshot()/
PopActiveSnapshot() inside ApplyWorkerMain()), the same test produces
another one:
...
#5  0x00005567183a5cff in ExceptionalCondition
(conditionName=conditionName@entry=0x5567184096e0
"HaveRegisteredOrActiveSnapshot()", fileName=fileName@entry=0x5567184093e6
"toast_internals.c", lineNumber=lineNumber@entry=670)
    at assert.c:66
#6  0x0000556717e5c27d in init_toast_snapshot (...) at
toast_internals.c:670
#7  0x0000556717e5c331 in toast_delete_datum (...) at
toast_internals.c:429
#8  0x0000556717efc3fa in toast_tuple_cleanup (...) at toast_helper.c:309
#9  0x0000556717eb46c4 in heap_toast_insert_or_update (...) at
heaptoast.c:333
#10 0x0000556717ea7a8a in heap_update (...) at heapam.c:3613
#11 0x0000556717ea84e9 in simple_heap_update (...) at heapam.c:4071
#12 0x0000556717f500a8 in CatalogTupleUpdate (...) at indexing.c:322
#13 0x00005567181e7451 in clear_subscription_skip_lsn (...) at
worker.c:2274
#15 0x00005567181ea20e in apply_handle_commit (...) at worker.c:1040
#16 0x00005567181eacff in apply_dispatch (...) at worker.c:3305
#17 0x00005567181eb643 in LogicalRepApplyLoop (...) at worker.c:3603
#18 0x00005567181eba72 in start_apply (...) at worker.c:4419
#19 0x00005567181ec469 in ApplyWorkerMain (...) at worker.c:4720
#20 0x00005567181ae7fa in StartBackgroundWorker () at bgworker.c:861
...

Finally, after this failure elimination (with PushActiveSnapshot()/
PopActiveSnapshot() inside clear_subscription_skip_lsn()), this test
passes.

  2. Re: BUG #18309: TOASTed entry in pg_subscription provokes an assertion failure

    Daniel Gustafsson <daniel@yesql.se> — 2024-01-24T15:24:38Z

    > On 24 Jan 2024, at 13:00, PG Bug reporting form <noreply@postgresql.org> wrote:
> 
> The following bug has been logged on the website:
> 
> Bug reference:      18309
> Logged by:          Alexander Lakhin
> Email address:      exclusion@gmail.com
> PostgreSQL version: 16.1
> Operating system:   Ubuntu 22.04
> Description:        
> 
> When a pg_subscription entry contains a TOASTed field, e.g., subconninfo,
> several operations with the subscription trigger an assertion failure.
> 
> For example, with the following modification of test 029_on_error.pl:
> -my $publisher_connstr = $node_publisher->connstr . ' dbname=postgres';
> +my $publisher_connstr = $node_publisher->connstr . ' dbname=postgres
> password=' . join('', map {chr(65 + rand 26)} (1 .. 10000));
> 
> I get an assertion failure with the stack:

This seems like a variation of the issue reported in the login event trigger
thread at postgr.es/m/e2a0248e-5f32-af0c-9832-a90d303c2c61@gmail.com

--
Daniel Gustafsson

  3. Re: BUG #18309: TOASTed entry in pg_subscription provokes an assertion failure

    Alexander Law <exclusion@gmail.com> — 2024-01-24T16:00:00Z

    Hello Daniel,

24.01.2024 18:24, Daniel Gustafsson wrote:
> This seems like a variation of the issue reported in the login event trigger
> thread at postgr.es/m/e2a0248e-5f32-af0c-9832-a90d303c2c61@gmail.com

Yes, it has the same root cause, but maybe it should be fixed differently.
I had also reported:
https://www.postgresql.org/message-id/18127-fe54b6a667f29658%40postgresql.org
but I'm not sure that all of these issues should be fixed by a single commit.
(Given that there are 7c38ef2a5 and 54b208f90 already.)
Though maybe I'm wrong here.

Best regards,
Alexander