Read the workflow at .github/workflows/llm-fuzzer.yaml. You are running in that
workflow. PostgreSQL with TimescaleDB is already built and installed, with
AddressSanitizer enabled. The build environment is functional, use it to rebuild
with debug logging as needed.

Find bugs in the TimescaleDB code modified in this change set. Only consider the
bugs that manifest in a way that is handled by the current oracle at
.github/workflows/llm-fuzzer/oracle/${ORACLE_NAME}/verify.sh.
This run focuses on these classes of bugs specifically, so do not chase
different classes. Stop after one reproducible bug.

Determine whether you are testing a PR or a commit on a branch. Focus on the
changes in that change set. Do not explore unrelated git history or old commits.

Only use public SQL APIs (CREATE, ALTER, SELECT, INSERT, etc. and documented
timescaledb functions). Do not directly modify internal catalog tables
(_timescaledb_catalog.*, _timescaledb_internal.*) -- corrupting internal state
is not a useful bug. The goal is to find inputs that break the code through its
public interface.

When done, generate a self-contained ~/llm-fuzzer-repro.sql that reproduces the
error when the subsequent workflow step replays it against a fresh server. The
reproducer must follow the admissibility rules stated by the oracle, and not
work around any of the checks performed by the oracle. The mechanical checks are
incomplete and can have false positives. Not only must the repro pass the
checks, but you must also follow the rules stated by the oracle to decide
admissibility.

If no bug in the target class is reproducible, or if you are unable to construct
a repro that follows the admissibility rules, do not create the reproducer file.
In this case, you may report the important findings in a message.

Some details about the GitHub Actions event that triggered this workflow:
what=${EVENT_WHAT}
branch=${EVENT_BRANCH}
base=${EVENT_BASE}
event=${EVENT_NAME}
sha=${SHA}
