On Sat, Nov 16, 2024 at 12:49:05PM +0100, Torsten Förtsch wrote: > Thanks. Here is an updated version of the patch including documentation.
+ <para> + If used together with <option>--if-not-exists</option> and if a + permanent slot by the requested name exists, that slot is used instead + of creating a new one. That permanent slot is then not automatically + removed when the connection is dropped. + </para> I'm wondering if this is the best behavior to have. Wouldn't it be simpler to just error out if combining --temporary-slot and --if-not-exists altogether? For example, this part of the documentation is not true if --if-not-exists bumps on an existing temporary slot, no? Another thing that is confusing is the fact of always requiring --create-slot when using the new option. Here is a simpler idea: if using --temporary-slot, imply that --create-slot is set then use a slot name based on the PID of the remote connection, like pg_basebackup (see call of PQbackendPID() in pg_basebackup.c). If --create-slot and --temporary-slot are both specified, error. My point is, do we actually need to care about the name of the slot for monitoring purposes as we know this is a slot that's going to be thrown away on disconnect? Probably not, so we could just use a pg_recvlogical_%u. Enforcing a permanent slot if --slot is set may not be the best thing to do, so I'd make things simpler and issue an error if attempting to use --slot and --temporary-slot in this case. This makes for less cases to think about when creating the slot once the connection to the remote is done. + the slot will be recreated first. If at that time another slot by the + same name exists, creation will fail. And concurrency issues like this one are very unlikely going to happen once you do that. -- Michael
signature.asc
Description: PGP signature
