Hi, A quick update here.
> As it stands now, FLUSH_LOCK_CONFLICT and FLUSH_PARTIAL require the same > action (keep pending, retry later), but at least it is explicit why we > are retrying. This also forces extension authors to choose the correct > return value rather than blindly returning true/false. > > Does this match what you had in mind? To keep this thread better organized, I moved the mid-transaction flush discussion to its own thread [1]. Also, a week ago e65c331b8fbf8c9 was committed which added pgstat_prep_pending_from_entry_ref(). This allows extensions to have fine grained control over entry creation by allowing separate steps for lookup, creation and pending setup of an entry. This is vital for for the work being done for pg_stat_statements. [2] is still needed but I can proceed with the work even with the pg_stat_statements work for now since it's a transparent change to the extension; giving an extension the ability to have a dedicated dshash/dsa. But, nevertheless, I do believe this will be needed for proper management/accounting for the stats created by a custom kind. [1] https://www.postgresql.org/message-id/CAA5RZ0u84eMFeFWMaEo0D84ed3jF_RY0%3DRWD8tDwQWsNsU1qvA%40mail.gmail.com [2] https://www.postgresql.org/message-id/CAA5RZ0supQBxSkh=CWB39=j+cl3hhclpki3tcbk0b1r4fes...@mail.gmail.com -- Sami Imseih Amazon Web Services (AWS)
