Dear Euler, > Hayato already mentioned one of the solution in a previous email [2]. > AFAICS we can use any solution that creates a WAL record. I tested the > following options:
Yes, my point was that we should add an arbitrary record after the recovery_target_lsn. > (a) temporary replication slot: requires an additional replication slot. > small payload. it is extremely slow in comparison with the other > options. > (b) logical message: can be consumed by logical replication when/if it > is supported some day. big payload. fast. > (c) snapshot of running txn: small payload. fast. > (d) named restore point: biggest payload. fast. Another PoV is whether they trigger the flush of the generated WAL record. You've tested pg_logical_emit_message() with flush=false, but this meant that the WAL does not flush so that the wait_for_end_recovery() waits a time. IIUC, it may wait 15 seconds, which is the time duration bgwriter works. If flush is set to true, the execution time will be longer. pg_create_restore_point() also does not flush the generated record so that it may be problematic. Moreover, the name of the restore point might be a conflict that users will use. Overall, I could agree to use pg_log_standby_snapshot(). This flushes the WAL asynchronously but ensures the timing is not so delayed. Best regards, Hayato Kuroda FUJITSU LIMITED
