Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Bug]: Server crashes when a compressed table update performed with a filter on tableoid #6024

Closed
alexanderlaw opened this issue Aug 29, 2023 · 0 comments · Fixed by #6035
Closed

[Bug]: Server crashes when a compressed table update performed with a filter on tableoid #6024

alexanderlaw opened this issue Aug 29, 2023 · 0 comments · Fixed by #6035
Assignees
@sb230132
Labels
bug compression

Comments

@alexanderlaw
Copy link

What type of bug is this?

Crash

What subsystems and features are affected?

Compression

What happened?

When trying to update a row in a compressed table with a filter by the tableoid column, the server crashes due to inability to get compression information for that column.

TimescaleDB version affected

2.12.0-dev

PostgreSQL version used

15.3

What operating system did you use?

Ubuntu 22.04 x86_64

What installation method did you use?

Source

What platform did you run on?

On prem/Self-hosted

Relevant log output and stack trace

Core was generated by `postgres: law regression [local] UPDATE                                       '.
Program terminated with signal SIGSEGV, Segmentation fault.

warning: Section `.reg-xstate/550613' in core file too small.
#0  0x00007f4cdefffe66 in fill_predicate_context (ch=ch@entry=0x562d626b0a78, 
    predicates=predicates@entry=0x562d626b0698, filters=filters@entry=0x7ffedfc5aef8, 
    index_filters=index_filters@entry=0x7ffedfc5af00, 
    segmentby_predicates=segmentby_predicates@entry=0x7ffedfc5af08, is_null=is_null@entry=0x7ffedfc5af10)
    at .../timescaledb/tsl/src/compression/compression.c:2774
2774                                    if (COMPRESSIONCOL_IS_SEGMENT_BY(fd))
(gdb) bt
#0  0x00007f4cdefffe66 in fill_predicate_context (ch=ch@entry=0x562d626b0a78, 
    predicates=predicates@entry=0x562d626b0698, filters=filters@entry=0x7ffedfc5aef8, 
    index_filters=index_filters@entry=0x7ffedfc5af00, 
    segmentby_predicates=segmentby_predicates@entry=0x7ffedfc5af08, is_null=is_null@entry=0x7ffedfc5af10)
    at .../timescaledb/tsl/src/compression/compression.c:2774
#1  0x00007f4cdf00372e in decompress_batches_for_update_delete (chunk=chunk@entry=0x562d626b0a78, 
    predicates=predicates@entry=0x562d626b0698, estate=0x562d6272a7b8)
    at .../timescaledb/tsl/src/compression/compression.c:3198
#2  0x00007f4cdf003b8b in decompress_chunk_walker (ps=0x562d6272b9d0, relids=relids@entry=0x562d62976d18)
    at .../timescaledb/tsl/src/compression/compression.c:3351
#3  0x0000562d610177cb in planstate_tree_walker (planstate=planstate@entry=0x562d6272bc40, 
    walker=walker@entry=0x7f4cdf0039f1 <decompress_chunk_walker>, context=context@entry=0x562d62976d18)
    at nodeFuncs.c:4103
#4  0x00007f4cdf003a91 in decompress_chunk_walker (ps=0x562d6272bc40, relids=relids@entry=0x562d62976d18)
    at .../timescaledb/tsl/src/compression/compression.c:3377
#5  0x0000562d610177cb in planstate_tree_walker (planstate=planstate@entry=0x562d6272aee8, 
    walker=walker@entry=0x7f4cdf0039f1 <decompress_chunk_walker>, context=context@entry=0x562d62976d18)
    at nodeFuncs.c:4103
#6  0x00007f4cdf003a91 in decompress_chunk_walker (ps=0x562d6272aee8, relids=0x562d62976d18)
    at .../timescaledb/tsl/src/compression/compression.c:3377
#7  0x00007f4cdf00492b in decompress_target_segments (ps=<optimized out>)
    at .../timescaledb/tsl/src/compression/compression.c:3284
#8  0x00007f4cdf17668f in ExecModifyTable (cs_node=0x562d6272aa28, pstate=0x562d6272aee8)
    at .../timescaledb/src/nodes/hypertable_modify.c:787
#9  0x00007f4cdf176e97 in hypertable_modify_exec (node=<optimized out>)
    at .../timescaledb/src/nodes/hypertable_modify.c:182
#10 0x0000562d60fc209f in ExecCustomScan (pstate=0x562d6272aa28) at nodeCustom.c:115
#11 0x0000562d60fb01f2 in ExecProcNodeFirst (node=0x562d6272aa28) at execProcnode.c:464
#12 0x0000562d60fa9a77 in ExecProcNode (node=0x562d6272aa28)
    at ../../../src/include/executor/executor.h:262
#13 ExecutePlan (estate=estate@entry=0x562d6272a7b8, planstate=0x562d6272aa28, 
    use_parallel_mode=<optimized out>, operation=operation@entry=CMD_UPDATE, 
    sendTuples=sendTuples@entry=false, numberTuples=numberTuples@entry=0, 
    direction=ForwardScanDirection, dest=0x562d629c9c18, execute_once=true) at execMain.c:1636
#14 0x0000562d60fa9bdd in standard_ExecutorRun (queryDesc=0x562d62897358, 
    direction=ForwardScanDirection, count=0, execute_once=execute_once@entry=true) at execMain.c:363
#15 0x0000562d60fa9cad in ExecutorRun (queryDesc=queryDesc@entry=0x562d62897358, 
    direction=direction@entry=ForwardScanDirection, count=count@entry=0, 
    execute_once=execute_once@entry=true) at execMain.c:307
#16 0x0000562d611268e7 in ProcessQuery (plan=plan@entry=0x562d629784c0, 
    sourceText=0x562d625e44e8 "UPDATE t SET b = 2 WHERE tableoid = 0;", params=0x0, queryEnv=0x0, 
    dest=dest@entry=0x562d629c9c18, qc=qc@entry=0x7ffedfc5b5c0) at pquery.c:160
#17 0x0000562d61127294 in PortalRunMulti (portal=portal@entry=0x562d626574e8, 
    isTopLevel=isTopLevel@entry=true, setHoldSnapshot=setHoldSnapshot@entry=false, 
    dest=dest@entry=0x562d629c9c18, altdest=altdest@entry=0x562d629c9c18, qc=qc@entry=0x7ffedfc5b5c0)
    at pquery.c:1277
#18 0x0000562d6112769d in PortalRun (portal=portal@entry=0x562d626574e8, 
    count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true, 
    run_once=run_once@entry=true, dest=dest@entry=0x562d629c9c18, altdest=altdest@entry=0x562d629c9c18, 
    qc=0x7ffedfc5b5c0) at pquery.c:791
#19 0x0000562d61123d43 in exec_simple_query (
    query_string=query_string@entry=0x562d625e44e8 "UPDATE t SET b = 2 WHERE tableoid = 0;")
    at postgres.c:1250
#20 0x0000562d61125bca in PostgresMain (dbname=<optimized out>, username=<optimized out>)
    at postgres.c:4598
#21 0x0000562d6109d690 in BackendRun (port=port@entry=0x562d6260aab0) at postmaster.c:4511
#22 0x0000562d610a0414 in BackendStartup (port=port@entry=0x562d6260aab0) at postmaster.c:4239
#23 0x0000562d610a064d in ServerLoop () at postmaster.c:1806
#24 0x0000562d610a1a02 in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x562d6254cc70)
    at postmaster.c:1478
#25 0x0000562d60fff10c in main (argc=3, argv=0x562d6254cc70) at main.c:202
(gdb) print fd
$1 = (FormData_hypertable_compression *) 0x0

How can we reproduce the bug?

CREATE EXTENSION timescaledb;

CREATE TABLE t(a integer, b integer);
SELECT create_hypertable('t', 'a', chunk_time_interval=> 10);
INSERT INTO t values(1, 2);
ALTER TABLE t SET (timescaledb.compress);
SELECT compress_chunk(show_chunks('t'));

UPDATE t SET b = 2 WHERE tableoid = 0;
@lkshminarayanan lkshminarayanan self-assigned this Aug 30, 2023
sb230132 added a commit to sb230132/timescaledb that referenced this issue Sep 1, 2023
@sb230132
Fix server crash on UPDATE of compressed chunk
efb9c59 
UPDATE query with system attributes in WHERE clause causes
server to crash. This patch fixes this issue by checking for
system attributes and handle cases only for segmentby attributes
in fill_predicate_context().

Fixes timescale#6024
@sb230132 sb230132 mentioned this issue Sep 1, 2023
Merged
sb230132 added a commit to sb230132/timescaledb that referenced this issue Sep 1, 2023
@sb230132
Fix server crash on UPDATE of compressed chunk
dd09e23 
UPDATE query with system attributes in WHERE clause causes
server to crash. This patch fixes this issue by checking for
system attributes and handle cases only for segmentby attributes
in fill_predicate_context().

Fixes timescale#6024
sb230132 added a commit to sb230132/timescaledb that referenced this issue Sep 1, 2023
@sb230132
Fix server crash on UPDATE of compressed chunk
1ee12cf 
UPDATE query with system attributes in WHERE clause causes
server to crash. This patch fixes this issue by checking for
system attributes and handle cases only for segmentby attributes
in fill_predicate_context().

Fixes timescale#6024
sb230132 added a commit to sb230132/timescaledb that referenced this issue Sep 2, 2023
@sb230132
Fix server crash on UPDATE of compressed chunk
6fc3a9b 
UPDATE query with system attributes in WHERE clause causes
server to crash. This patch fixes this issue by checking for
system attributes and handle cases only for segmentby attributes
in fill_predicate_context().

Fixes timescale#6024
sb230132 added a commit that referenced this issue Sep 4, 2023
@sb230132
Fix server crash on UPDATE of compressed chunk
e66a400 
UPDATE query with system attributes in WHERE clause causes
server to crash. This patch fixes this issue by checking for
system attributes and handle cases only for segmentby attributes
in fill_predicate_context().

Fixes #6024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sb230132 sb230132

Labels
bug compression
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix server crash on UPDATE of compressed chunk sb230132/timescaledb
3 participants
@lkshminarayanan @sb230132 @alexanderlaw