postgres
postgres copied to clipboard
supabase
pgbouncer connection speed regression
I suspect this was due to something done towards the fastboot changes in #141 . Initial connection to pgbouncer takes a substantially longer period, and has errors in the logs:
May 11 14:11:55 db-XXX pgbouncer[1095]: S-0xaaaaf77db2b0: postgres/[email protected]:5432 new connection to server (from 127.0.0.1:50612)
May 11 14:11:55 db-XXX pgbouncer[1095]: C-0xaaaaf77c2c10: postgres/[email protected]:54319 login attempt: db=postgres user=supabase_admin tls=TLSv1.3/TLS_AES_256_GCM_SHA384
May 11 14:12:01 db-XXX pgbouncer[1095]: C-0xaaaaf77c2c10: postgres/[email protected]:54320 login attempt: db=postgres user=supabase_admin tls=TLSv1.3/TLS_AES_256_GCM_SHA384
May 11 14:12:01 db-XXX pgbouncer[1095]: sbuf_connect failed: Address family not supported by protocol
May 11 14:12:01 db-XXX pgbouncer[1095]: S-0xaaaaf77db4e0: postgres/supabase_admin@[::1]:5432 closing because: connect failed (age=0s)
vs a connection to an older, non-fastboot instance:
May 11 14:12:33 db-XXX pgbouncer[1418]: C-0xaaaafa3d74d0: (nodb)/(nouser)@58.182.5.215:54332 registered new auto-database: db=postgres
May 11 14:12:33 db-XXX pgbouncer[1418]: S-0xaaaafa4357a0: postgres/[email protected]:5432 new connection to server (from 127.0.0.1:60092)
May 11 14:12:33 db-XXX pgbouncer[1418]: C-0xaaaafa3d74d0: postgres/[email protected]:54332 login attempt: db=postgres user=supabase_admin tls=TLSv1.3/TLS_AES_256_GCM_SHA384
May 11 14:12:37 db-XXX pgbouncer[1418]: C-0xaaaafa3d74d0: postgres/[email protected]:54334 login attempt: db=postgres user=supabase_admin tls=TLSv1.3/TLS_AES_256_GCM_SHA384
May 11 14:12:44 db-XXX pgbouncer[1418]: C-0xaaaafa3d74d0: postgres/[email protected]:54335 login attempt: db=postgres user=supabase_admin tls=TLSv1.3/TLS_AES_256_GCM_SHA384
May 11 14:12:44 db-XXX pgbouncer[1418]: S-0xaaaafa4359d0: postgres/[email protected]:5432 new connection to server (from 127.0.0.1:60094)
Deleting the IPv6 entry for localhost from /etc/hosts resolves the issue. I'm not sure why pgbouncer started trying to use ipv6 now, though.
I'm quite sure, IPv6 was disabled on fastboot-ami.
$ cat /sys/module/ipv6/parameters/disable
1
Do you have proj-ref for older ami? I want to check whether it has IPv6 enabled and /etc/hosts entries.
Reg your solution to delete /etc/hosts IPv6 entry: Should we just create /etc/hosts with only 127.0.0.1 localhost entry by modifying init script? or need to re-create the ami for this change? what is the recommended approach?
related: https://fritshoogland.wordpress.com/2021/04/09/pgbouncer-and-slow-server-pool-increase/
That's basically it-the older AMIs don't disable IPv6, so having that entry in /etc/hosts doesn't present a problem. We should definitely fix the AMI; in the interim, if you want to get a patch out sooner, using init-scripts is fine.
We'll also want to fix this in existing fastboot-based projects.
okay, I think IPv6 got disabled because it created issue with some package (may be vector - I can't re-collect exact the reason, atm). Need to verify that before enabling IPv6.
Lets use init-scripts for a quick patch for new launches and then fix the ami image after verifying IPv6 doesn't create new issues.
Hi everyone. Experimenting with supabase and pgbouncer today. The connection using pgbouncer and port 6543 is significantly slower. Is there anything we need to update in supabase to solve the issue? What is the recommended approach?
Hello @msevestre , We resolved issues related to IPV6 few months ago. Are you still facing this issue?
