Summary
A documented PostgreSQL 17 role-membership operation terminated the backend with signal 11 on two consecutive official Supabase Postgres images. Both attempts used isolated temporary storage, no published port, no network, and synthetic roles.
Exact runtime identities
| Image tag |
Repository digest |
PostgreSQL evidence |
Platform evidence |
Outcome |
public.ecr.aws/supabase/postgres:17.6.1.140 |
public.ecr.aws/supabase/postgres@sha256:6501843661b1f8ff97e85c02de33edc0ee2e2693888ad596ee86222f02dc8ecc |
major 17, preflight-verified; 17.6.1.140 is the image tag version |
linux/arm64 is inferred from the same local host/runtime architecture; a per-run platform line was not retained |
backend terminated by signal 11 |
public.ecr.aws/supabase/postgres:17.6.1.141 |
public.ecr.aws/supabase/postgres@sha256:ba10e934f0a59990379f78ab9ed93926f1c291dd61a12fe4026f4202f1b89770 |
major 17, preflight-verified; 17.6.1.141 is the image tag version |
linux/arm64, directly captured before SQL |
backend terminated by signal 11 |
The .140 platform value is deliberately labelled as an inference, not independent per-image evidence.
The retained evidence did not capture the exact output of SELECT version(). Accordingly, this report does not present 17.6.1 as an upstream server-version string; it reports verified PostgreSQL major 17 and keeps the complete Supabase image versions in their tags.
Synthetic role topology
The failing statement ran with this bounded topology:
- The image bootstrap administrator established a login-capable, non-superuser,
NOINHERIT, CREATEROLE executor.
- The executor created a non-login, non-superuser, non-
CREATEROLE, NOINHERIT owner.
- PostgreSQL 17 had already recorded its automatic creator membership for the
(owner, executor) pair under the image bootstrap administrator.
- The crashing connection authenticated directly as the executor, so
session_user and current_user were both the synthetic executor; this was not a SET ROLE context. That session requested a second edge for the same pair with the executor as explicit grantor.
Only the two synthetic roles participated in the tested operation.
Minimal failing statement
GRANT synthetic_owner TO CURRENT_USER
WITH ADMIN FALSE, INHERIT FALSE, SET TRUE
GRANTED BY CURRENT_USER;
Expected result
The statement should return normally and record a second membership edge whose role is the synthetic owner, member and grantor are the synthetic executor, and options are ADMIN FALSE, INHERIT FALSE, SET TRUE. The existing automatic creator edge should remain unchanged.
Observed result
On both exact images, PostgreSQL 17 terminated the executing backend with signal 11 at the GRANT. The client observed an unexpected end of connection, the in-flight transaction aborted, and the server recovered to accept connections. No successful role switch, revoke, or positive second run followed the crash.
On .140, the equivalent statement without the explicit GRANTED BY clause was also tried once and terminated the backend with signal 11. This is corroborating evidence; the cross-image comparison above uses the unchanged explicit-grantor statement.
Privacy-bounded server log
server process ... was terminated by signal 11: Segmentation fault
terminating any other active server processes
database system was interrupted
database system is ready to accept connections
Questions
- Is this role-membership crash a known Supabase Postgres issue?
- What is the first exact Supabase Postgres image that contains a fix?
- Which stable Supabase CLI release selects that image?
- Is the fixed runtime available or eligible for hosted projects?
- What additional privacy-bounded diagnostics would be required for triage? Any diagnostic rerun would require separate approval.
Reviewed artifact hashes
- Report:
e2130dc770edf21548d1964468446c1cd8f877f531850fe3e468d3d3be128cc8
- Minimal SQL:
bb9ef3993642b53e052533c7e09413e25589d7dd1f6b9ff8323cb802c0e838b1
- Bounded log:
f9f8d06b053dfc26b2147755c8aabbb959a86d8cbbd885614d8eae9fbef7078f
Summary
A documented PostgreSQL 17 role-membership operation terminated the backend with signal 11 on two consecutive official Supabase Postgres images. Both attempts used isolated temporary storage, no published port, no network, and synthetic roles.
Exact runtime identities
public.ecr.aws/supabase/postgres:17.6.1.140public.ecr.aws/supabase/postgres@sha256:6501843661b1f8ff97e85c02de33edc0ee2e2693888ad596ee86222f02dc8ecc17, preflight-verified;17.6.1.140is the image tag versionlinux/arm64is inferred from the same local host/runtime architecture; a per-run platform line was not retainedpublic.ecr.aws/supabase/postgres:17.6.1.141public.ecr.aws/supabase/postgres@sha256:ba10e934f0a59990379f78ab9ed93926f1c291dd61a12fe4026f4202f1b8977017, preflight-verified;17.6.1.141is the image tag versionlinux/arm64, directly captured before SQLThe
.140platform value is deliberately labelled as an inference, not independent per-image evidence.The retained evidence did not capture the exact output of
SELECT version(). Accordingly, this report does not present17.6.1as an upstream server-version string; it reports verified PostgreSQL major17and keeps the complete Supabase image versions in their tags.Synthetic role topology
The failing statement ran with this bounded topology:
NOINHERIT,CREATEROLEexecutor.CREATEROLE,NOINHERITowner.(owner, executor)pair under the image bootstrap administrator.session_userandcurrent_userwere both the synthetic executor; this was not aSET ROLEcontext. That session requested a second edge for the same pair with the executor as explicit grantor.Only the two synthetic roles participated in the tested operation.
Minimal failing statement
Expected result
The statement should return normally and record a second membership edge whose role is the synthetic owner, member and grantor are the synthetic executor, and options are
ADMIN FALSE,INHERIT FALSE,SET TRUE. The existing automatic creator edge should remain unchanged.Observed result
On both exact images, PostgreSQL 17 terminated the executing backend with signal 11 at the
GRANT. The client observed an unexpected end of connection, the in-flight transaction aborted, and the server recovered to accept connections. No successful role switch, revoke, or positive second run followed the crash.On
.140, the equivalent statement without the explicitGRANTED BYclause was also tried once and terminated the backend with signal 11. This is corroborating evidence; the cross-image comparison above uses the unchanged explicit-grantor statement.Privacy-bounded server log
Questions
Reviewed artifact hashes
e2130dc770edf21548d1964468446c1cd8f877f531850fe3e468d3d3be128cc8bb9ef3993642b53e052533c7e09413e25589d7dd1f6b9ff8323cb802c0e838b1f9f8d06b053dfc26b2147755c8aabbb959a86d8cbbd885614d8eae9fbef7078f