Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > Hi Karthik > > On 12/02/2025 12:34, Karthik Nayak wrote: >>> On 07/02/2025 07:34, Karthik Nayak wrote: >>>> Git's reference updates are traditionally atomic >>> >>> I'm nitpicking but the updates aren't actually atomic, if a transaction >>> updates two refs then it is possible for another process to see the one >>> ref pointing to the new value and the other pointing to the old value. >>> >> >> Good point. This is true in the case of the files backend, since updates >> involve locking individual files and during the commit phase, there is a >> possibility that one ref is updated while the other is yet to be >> (committing of the lock is not global but rather per ref file). >> >> However this is not the case with the reftable backend, there, updates >> are written to a new table and committed at the end after locking the >> table. So in the reftable backend, this is indeed atomic. > > Ah, interesting. That explains why batching updates is so much more > efficient when using the reftable backend. > >>>> This series introduces support for partial reference transactions, >>>> allowing individual reference updates to fail while letting others >>>> proceed. >>> >>> This sounds like it's abusing ref transactions to implement a >>> performance optimization. >> >> I understand where you're coming from. This is definitely a stray from >> the regular atomic behavior, that transactions promise. But I would say >> this is more of an exception handling for the regular transaction >> mechanism and AFAIK this is also something that some of the databases >> support (see EXCEPTION in PostgreSQL). >> >> Overall, we're adding an exception handling support to the existing >> transaction interface. > > My understanding of exception handling is that if an error occurs then > an error handler is called (reading [1] that seems to be what PostgreSQL > does as well). Is that what is being proposed here? I thought this > series added a flag to ignore errors rather than provide a way to handle > them. > That is correct, and while the current implementation is to ignore them. It does make way for building something like that in the future. > [1] > https://www.postgresql.org/docs/current/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING > >>> I wonder if it would be better to provide that >>> via a different interface than shares the same underling implementation >>> as transactions. That would make it clear to someone reading the code >>> that individual ref updates can fail without affecting the rest. Burying >>> that detail in a flag makes it rather easy to miss. >>> >> >> Thinking this out, having a different interface sound good, but I feel >> we'd end up with the same structure as currently presented in this >> series. Only other way is to really split the implementation to support >> partial transactions as a entity of its own. In that case, we'd end up >> with code duplication. >> >> Do you think you can expand a little more here? > > I was thinking of a function that took a list of refs to update and made > a best effort to update them, ignoring any updates that fail. > Yes, this is what we want too, but in the context of transactions. Without transactions, this is already possible to build albeit on the user side with some simple scripts. > My concern with adding a flag to ignore errors in the transaction api is > that a partial transaction is a contradiction in terms. I'm also > concerned that it seems to be ignoring all errors. I'd be happier if > there was someway for the caller to specify which errors to ignore or if > the caller could provide a callback to handle any errors. That way a > caller could ignore d/f conflicts but still cause the transaction to > fail if there was an i/o or could create a reference if it did not exist > but leave it unchanged if it did exist. > Yeah, I think this is also something that Patrick raised and something I will tackle in the next version of this patch series. The next version will skip all user oriented errors (errors which can be fixed by changing the user input), while still catch system errors (I/O , memory ...). I also see how this can be extended to allow users to nit-pick which errors they don't care about. But that is something I don't plan to tackle for now. > Best Wishes > > Phillip Thanks for your inputs!
Attachment:
signature.asc
Description: PGP signature
