Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Bruce Momjian <bruce@momjian.us>, adam@labkey.com, pgsql-bugs@lists.postgresql.org
Date: 2024-11-27T15:40:13Z
Lists: pgsql-bugs
Attachments
- v8-0001-fix-database-name-truncation.patch (text/plain)
On Fri, Nov 22, 2024 at 02:17:07PM -0600, Nathan Bossart wrote: > On Fri, Nov 22, 2024 at 03:07:46PM -0500, Tom Lane wrote: >> Nathan Bossart <nathandbossart@gmail.com> writes: >>> I think we'll also want to do something about MyProcPort->database_name >> >> Huh, isn't that getting filled from InitPostgres's out_dbname? > > I think ProcessStartupPacket() sets it. That's called by > BackendInitialize(), which is called before PostgresMain() (which is what > ultimately calls InitPostgres()). The truncation used to happen within > ProcessStartupPacket(), and it updated MyProcPort directly. Here's an attempt at dealing with this problem. I've just taught PostgresMain() to use out_dbname to update MyProcPort->database_name and the process title as needed. Of course, we still need to handle role names, too... That being said, I'm growing quite uneasy about the size of this hack, and I'm wondering if it would be better to leave it alone (perhaps with an update to the release notes) or just revert commit 562bee0 until we have a better way of dealing with multibyte characters in identifiers (e.g., tracking their encoding). I suspect there are similar problems in other places (e.g., pg_dumpall). -- nathan
Commits
-
Revert "Don't truncate database and user names in startup packets."
- d09fbf645ece 17.3 landed
- a0ff56e2d3ff 18.0 landed
-
Don't truncate database and user names in startup packets.
- 562bee0fc13d 17.0 cited
-
Truncate incoming username and database name to NAMEDATALEN-1 characters
- d18c1d1f5102 7.1.1 cited