Thread

Commits

  1. Fix overridden callbacks in pg_rewind.

  1. [pg_rewind] use the passing callback instead of global function

    Junwang Zhao <zhjwpku@gmail.com> — 2023-04-26T01:51:13Z

    `local_traverse_files` and `libpq_traverse_files` both have a
    callback parameter but instead use the global process_source_file
    which is no good for function encapsulation.
    
    -- 
    Regards
    Junwang Zhao
    
  2. Re: [pg_rewind] use the passing callback instead of global function

    Richard Guo <guofenglinux@gmail.com> — 2023-04-26T08:33:39Z

    On Wed, Apr 26, 2023 at 9:51 AM Junwang Zhao <zhjwpku@gmail.com> wrote:
    
    > `local_traverse_files` and `libpq_traverse_files` both have a
    > callback parameter but instead use the global process_source_file
    > which is no good for function encapsulation.
    
    
    Nice catch.  This should be a typo introduced by 37d2ff38.
    
    While this patch is doing it correctly, I'm wondering that since both
    kinds of source server (libpq and local) are using the same function
    (i.e. process_source_file) to process source file list for
    traverse_files operations, do we really need to provide a callback?  Or
    will there be some kind of source server that may use different source
    file processing function?
    
    Thanks
    Richard
    
  3. Re: [pg_rewind] use the passing callback instead of global function

    Daniel Gustafsson <daniel@yesql.se> — 2023-04-26T08:48:16Z

    > On 26 Apr 2023, at 10:33, Richard Guo <guofenglinux@gmail.com> wrote:
    > 
    > On Wed, Apr 26, 2023 at 9:51 AM Junwang Zhao <zhjwpku@gmail.com <mailto:zhjwpku@gmail.com>> wrote:
    > `local_traverse_files` and `libpq_traverse_files` both have a
    > callback parameter but instead use the global process_source_file
    > which is no good for function encapsulation.
    > 
    > Nice catch.  This should be a typo introduced by 37d2ff38.
    
    Agreed, I'll look at applying this after some testing.
    
    > While this patch is doing it correctly, I'm wondering that since both
    > kinds of source server (libpq and local) are using the same function
    > (i.e. process_source_file) to process source file list for
    > traverse_files operations, do we really need to provide a callback?  Or
    > will there be some kind of source server that may use different source
    > file processing function?
    
    
    While there isn't one right now, removing the callback seems like imposing a
    restriction that the refactoring in 37d2ff38 aimed to avoid.
    
    --
    Daniel Gustafsson