Thread

Commits

  1. Add GUC variables for stat tracking and timeout as PGDLLIMPORT

  1. pg13 PGDLLIMPORT list

    legrand legrand <legrand_legrand@hotmail.com> — 2020-01-17T22:07:48Z

    Hello,
    would it be possible to add PGDLLIMPORT to permit to build following
    extensions on windows
    
    pg_stat_sql_plans:
    src/include/pgstat.h
    extern PGDLLIMPORT bool pgstat_track_activities;
    
    pg_background:
    src/include/storage/proc.h
    extern PGDLLIMPORT int	StatementTimeout;
    
    Thanks in advance
    Regards
    PAscal
    
    
    
    --
    Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
    
    
    
    
  2. Re: pg13 PGDLLIMPORT list

    Michael Paquier <michael@paquier.xyz> — 2020-01-18T02:26:10Z

    On Fri, Jan 17, 2020 at 03:07:48PM -0700, legrand legrand wrote:
    > Would it be possible to add PGDLLIMPORT to permit to build following
    > extensions on windows
    > 
    > pg_stat_sql_plans:
    > src/include/pgstat.h
    > extern PGDLLIMPORT bool pgstat_track_activities;
    > 
    > pg_background:
    > src/include/storage/proc.h
    > extern PGDLLIMPORT int	StatementTimeout;
    
    No objections from me to add both to what's imported.  Do you have a 
    specific use-case in mind for an extension on Windows?  Just
    wondering..
    --
    Michael
    
  3. Re: pg13 PGDLLIMPORT list

    Amit Kapila <amit.kapila16@gmail.com> — 2020-01-18T07:04:14Z

    On Sat, Jan 18, 2020 at 7:56 AM Michael Paquier <michael@paquier.xyz> wrote:
    >
    > On Fri, Jan 17, 2020 at 03:07:48PM -0700, legrand legrand wrote:
    > > Would it be possible to add PGDLLIMPORT to permit to build following
    > > extensions on windows
    > >
    > > pg_stat_sql_plans:
    > > src/include/pgstat.h
    > > extern PGDLLIMPORT bool pgstat_track_activities;
    > >
    > > pg_background:
    > > src/include/storage/proc.h
    > > extern PGDLLIMPORT int        StatementTimeout;
    >
    > No objections from me to add both to what's imported.
    >
    
    +1 for adding PGDLLIMPORT to these variables.  In the past, we have
    added it on the request of some extension authors, so I don't see any
    problem doing this time as well.
    
    -- 
    With Regards,
    Amit Kapila.
    EnterpriseDB: http://www.enterprisedb.com
    
    
    
    
  4. Re: pg13 PGDLLIMPORT list

    Julien Rouhaud <rjuju123@gmail.com> — 2020-01-18T07:19:19Z

    On Sat, 18 Jan 2020, 09:04 Amit Kapila <amit.kapila16@gmail.com wrote:
    
    > On Sat, Jan 18, 2020 at 7:56 AM Michael Paquier <michael@paquier.xyz>
    > wrote:
    > >
    > > On Fri, Jan 17, 2020 at 03:07:48PM -0700, legrand legrand wrote:
    > > > Would it be possible to add PGDLLIMPORT to permit to build following
    > > > extensions on windows
    > > >
    > > > pg_stat_sql_plans:
    > > > src/include/pgstat.h
    > > > extern PGDLLIMPORT bool pgstat_track_activities;
    > > >
    > > > pg_background:
    > > > src/include/storage/proc.h
    > > > extern PGDLLIMPORT int        StatementTimeout;
    > >
    > > No objections from me to add both to what's imported.
    > >
    >
    > +1 for adding PGDLLIMPORT to these variables.  In the past, we have
    > added it on the request of some extension authors, so I don't see any
    > problem doing this time as well.
    >
    
    +1 too
    
    >
    
  5. Re: pg13 PGDLLIMPORT list

    legrand legrand <legrand_legrand@hotmail.com> — 2020-01-18T09:32:49Z

    Michael Paquier-2 wrote
    > On Fri, Jan 17, 2020 at 03:07:48PM -0700, legrand legrand wrote:
    > [...]
    > 
    > No objections from me to add both to what's imported.  Do you have a 
    > specific use-case in mind for an extension on Windows?  Just
    > wondering..
    > --
    > Michael
    > 
    > signature.asc (849 bytes)
    > &lt;https://www.postgresql-archive.org/attachment/6119761/0/signature.asc&gt;
    
    No specific use-case, just the need to test features (IVM, push agg to base
    relations and joins, ...)
    on a professional laptop in windows 10 for a nomad app that collects
    performance metrics on Oracle 
    databases.
    
    Regards
    PAscal
    
    
    
    --
    Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
    
    
    
    
  6. Re: pg13 PGDLLIMPORT list

    Michael Paquier <michael@paquier.xyz> — 2020-01-18T09:48:18Z

    On Sat, Jan 18, 2020 at 02:32:49AM -0700, legrand legrand wrote:
    > No specific use-case, just the need to test features (IVM, push agg to base
    > relations and joins, ...)
    > on a professional laptop in windows 10 for a nomad app that collects
    > performance metrics on Oracle 
    > databases.
    
    That pretty much is a use-case, at least to me :)
    --
    Michael
    
  7. Re: pg13 PGDLLIMPORT list

    Michael Paquier <michael@paquier.xyz> — 2020-01-18T09:49:12Z

    On Sat, Jan 18, 2020 at 09:19:19AM +0200, Julien Rouhaud wrote:
    > On Sat, 18 Jan 2020, 09:04 Amit Kapila <amit.kapila16@gmail.com wrote:
    >> +1 for adding PGDLLIMPORT to these variables.  In the past, we have
    >> added it on the request of some extension authors, so I don't see any
    >> problem doing this time as well.
    >>
    > 
    > +1 too
    
    Thanks.  If there are no objections, I would like to actually
    back-patch that.
    --
    Michael
    
  8. Re: pg13 PGDLLIMPORT list

    Amit Kapila <amit.kapila16@gmail.com> — 2020-01-21T03:04:05Z

    On Sat, Jan 18, 2020 at 3:19 PM Michael Paquier <michael@paquier.xyz> wrote:
    >
    > On Sat, Jan 18, 2020 at 09:19:19AM +0200, Julien Rouhaud wrote:
    > > On Sat, 18 Jan 2020, 09:04 Amit Kapila <amit.kapila16@gmail.com wrote:
    > >> +1 for adding PGDLLIMPORT to these variables.  In the past, we have
    > >> added it on the request of some extension authors, so I don't see any
    > >> problem doing this time as well.
    > >>
    > >
    > > +1 too
    >
    > Thanks.  If there are no objections, I would like to actually
    > back-patch that.
    >
    
    As such no objection, but I am not sure if the other person need it on
    back branches as well.  Are you planning to commit this, or if you
    want I can take care of it?
    
    -- 
    With Regards,
    Amit Kapila.
    EnterpriseDB: http://www.enterprisedb.com
    
    
    
    
  9. Re: pg13 PGDLLIMPORT list

    Michael Paquier <michael@paquier.xyz> — 2020-01-21T04:49:21Z

    On Tue, Jan 21, 2020 at 08:34:05AM +0530, Amit Kapila wrote:
    > As such no objection, but I am not sure if the other person need it on
    > back branches as well.  Are you planning to commit this, or if you
    > want I can take care of it?
    
    Thanks for the reminder.  Done now.  I have also switched the
    surrounding parameters while on it to not be inconsistent.
    --
    Michael
    
  10. Re: pg13 PGDLLIMPORT list

    Craig Ringer <craig@2ndquadrant.com> — 2020-01-21T07:07:31Z

    On Tue, 21 Jan 2020 at 12:49, Michael Paquier <michael@paquier.xyz> wrote:
    >
    > On Tue, Jan 21, 2020 at 08:34:05AM +0530, Amit Kapila wrote:
    > > As such no objection, but I am not sure if the other person need it on
    > > back branches as well.  Are you planning to commit this, or if you
    > > want I can take care of it?
    >
    > Thanks for the reminder.  Done now.  I have also switched the
    > surrounding parameters while on it to not be inconsistent.
    
    While speaking of PGDLLIMPORT, I wrote a quick check target in the
    makefiles for some extensions I work on. It identified the following
    symbols as used by the extensions but not exported:
    
    XactLastRecEnd (xlog.h)
    criticalSharedRelcachesBuilt   (relcache.h)
    hot_standby_feedback   (walreceiver.h)
    pgstat_track_activities  (pgstat.h)
    WalRcv  (walreceiver.h)
    wal_receiver_status_interval (walreceiver.h)
    wal_retrieve_retry_interval (walreceiver.h)
    
    Of those, XactLastRecEnd is by far the most important.
    
    Failure to export pgstat_track_activities is a bug IMO, since it's
    exported by inline functions pgstat_report_wait_start() and
    pgstat_report_wait_end() in pgstat.h
    
    criticalSharedRelcachesBuilt is useful in extensions that may do genam
    systable_beginscan() etc in functions called both early in startup and
    later on.
    
    hot_standby_feedback can be worked around by reading the GUC via the
    config options interface. But IMO all GUC symbols should be
    PGDLLEXPORTed, especially since we lack an interface for extensions to
    read arbitrary GUC values w/o formatting to string then parsing the
    string.
    
    wal_receiver_status_interval and wal_retrieve_retry_interval are not
    that important, but again they're GUCs.
    
    Being able to see WalRcv is very useful when running extension code on
    a streaming physical replica, where you want to make decisions based
    on what's actually replicated.
    
    Anyone object to exporting these?
    
    
    -- 
     Craig Ringer                   http://www.2ndQuadrant.com/
     2ndQuadrant - PostgreSQL Solutions for the Enterprise