On Fri, Dec 20, 2019 at 11:33:02AM -0300, Alvaro Herrera wrote:
> Fair enough.
And done:
https://commitfest.postgresql.org/25/2251/
Sorry for the late reply.
--
Michael
signature.asc
Description: PGP signature
On 2019-Dec-20, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Dec-20, Michael Paquier wrote:
> >> The patch has been committed once as of e788bd9, then reverted as of
> >> 9555cc8 because it had a couple of fundamental issues and many people
> >> were not happy with it.
>
> > Hmm, should
Alvaro Herrera writes:
> On 2019-Dec-20, Michael Paquier wrote:
>> The patch has been committed once as of e788bd9, then reverted as of
>> 9555cc8 because it had a couple of fundamental issues and many people
>> were not happy with it.
> Hmm, should we mark the commitfest entry as rejected then?
On 2019-Dec-20, Michael Paquier wrote:
> On Fri, Dec 20, 2019 at 02:45:26AM +, tsunakawa.ta...@fujitsu.com wrote:
> > I've got interested in this. What's the current status of this
> > patch? The CF entry shows it was committed.
> >
> > But I understood not, because the relevant code doesn't
On Fri, Dec 20, 2019 at 02:45:26AM +, tsunakawa.ta...@fujitsu.com wrote:
> I've got interested in this. What's the current status of this
> patch? The CF entry shows it was committed.
>
> But I understood not, because the relevant code doesn't appear in
> HEAD, and Git log shows that it was r
From: Michael Paquier
> Adding extra custom logging information, or plug that information
> elsewhere than Postgres. I have use cases for that when it comes to
> store external telemetry data or audit things for events happening
> specifically in Postgres.
>
> Well, hook authors can do a lot of
On Thu, Oct 3, 2019 at 11:09 AM Andres Freund wrote:
>
>
> I think what would need to be designed is something more like
> RegisterXactCallback():
>
> /*
> * start- and end-of-transaction callbacks for dynamically loaded modules
> */
> typedef enum
> {
> XACT_EVENT_COMMIT,
>
Hi,
On 2019-10-03 11:19:58 -0300, Fabrízio de Royes Mello wrote:
> On Thu, Oct 3, 2019 at 1:35 AM Andres Freund wrote:
> >
> > [...]
> >
> > In this state I think this patch should be flat out rejected.
> >
>
> Ok.
>
> > I'm seriously baffled at how this stuff is being pursued aggressively,
> >
On Thu, Oct 3, 2019 at 1:35 AM Andres Freund wrote:
>
> [...]
>
> In this state I think this patch should be flat out rejected.
>
Ok.
> I'm seriously baffled at how this stuff is being pursued aggressively,
> quite apparently without any serious design considerations. I mean this
> stuff had to
Hi,
On 2019-10-03 13:20:09 +0900, Michael Paquier wrote:
> On Wed, Oct 02, 2019 at 09:09:53PM -0700, Andres Freund wrote:
> > I have *SERIOUS* problems with performing additional writing
> > transactions in case of a FATAL. Something might have thrown that for a
> > reason, and just carrying on ex
On Wed, Oct 02, 2019 at 09:09:53PM -0700, Andres Freund wrote:
> On 2019-10-03 11:03:39 +0900, Michael Paquier wrote:
>> The idea here is to have a hook which can be triggered at the start of
>> a process which can be externally triggered, which I guess is normal
>> even for WAL senders not connect
Hi,
On 2019-10-03 11:03:39 +0900, Michael Paquier wrote:
> On Wed, Oct 02, 2019 at 10:23:54AM -0700, Andres Freund wrote:
> > - the startup hook isn't actually guaranteed to be able to write
> > anything, we might be in hot-standby
>
> Right.
>
> > - the startup hook doesn't just run in normal
On Wed, Oct 02, 2019 at 10:23:54AM -0700, Andres Freund wrote:
> - the startup hook isn't actually guaranteed to be able to write
> anything, we might be in hot-standby
Right.
> - the startup hook doesn't just run in normal sessions, it also runs in
> walsenders, including ones not connected
On Wed, Oct 02, 2019 at 01:51:43PM -0400, Tom Lane wrote:
> Thus, we can't run any shutdown hooks before this one, if indeed we
> consider it to be a shutdown hook at all.
>
> A possible fix is to do it as the first action in proc_exit, but that will
> fall foul of Andres' points about not wanting
Andres Freund writes:
> On 2019-10-02 23:52:31 +0900, Fujii Masao wrote:
>> Regarding session end hook, you can do the almost same thing as that hook
>> by calling on_shmem_exit(), before_shmem_exit() or on_proc_exit() in
>> other hook like session start hook. This approach also has the same issue
Hi,
Moving the discussion of the issues leading to this being reverted back
to -hackers:
On 2019-10-02 23:52:31 +0900, Fujii Masao wrote:
> On Wed, Oct 2, 2019 at 10:08 PM Alvaro Herrera
> wrote:
> >
> > On 2019-Oct-02, Michael Paquier wrote:
> >
> > > On Wed, Oct 02, 2019 at 01:27:50PM +0900,
On Mon, Sep 30, 2019 at 02:46:42PM -0300, Fabrízio de Royes Mello wrote:
> Makes sense to me. I become a reviewer and run all tests (make check &&
> make check-world) and everything is ok. Changed status to "ready for
> commiter".
Thanks. There was an extra problem in the module hidden in the log
On Sun, Sep 29, 2019 at 10:29 PM Michael Paquier
wrote:
>
> This code path can only be taken by normal backends, so that would
> apply, still I don't actually see why we should limit us here on the
> backend side. If for a reason or another those two code paths begin
> to be taken by a backend wi
On Sat, Sep 28, 2019 at 10:43:36AM -0300, Fabrízio de Royes Mello wrote:
> I poked a little with the patch and everything is ok. Your check for normal
> backend on test_session_hooks is much simpler than I did before:
>
> +/* just consider normal backends */
> +if (MyBackendId == InvalidBa
On Fri, Sep 27, 2019 at 4:26 PM legrand legrand
wrote:
>
> OK I confirm:
> - "client backend" appears at session start and end hook,
> - "autovacuum worker" and "pg_background" only appears at session end hook
> (backend_start can be retreived from pg_stat_activity),
> - "parallel workers" are n
Michael Paquier-2 wrote
> On Thu, Sep 26, 2019 at 09:57:57AM -0700, legrand legrand wrote:
>> Does that mean that all processes seen in pg_stat_activity like
>> - autovacuum launcher
>> - logical replication launcher
>> - background writer
>> - checkpointer
>> - walwriter
>> ...
>> - Parallel work
On Fri, Sep 27, 2019 at 12:54 AM Michael Paquier wrote:
>
> On Thu, Sep 26, 2019 at 09:57:57AM -0700, legrand legrand wrote:
> > Does that mean that all processes seen in pg_stat_activity like
> > - autovacuum launcher
> > - logical replication launcher
> > - background writer
> > - checkpointer
>
On Thu, Sep 26, 2019 at 09:57:57AM -0700, legrand legrand wrote:
> Does that mean that all processes seen in pg_stat_activity like
> - autovacuum launcher
> - logical replication launcher
> - background writer
> - checkpointer
> - walwriter
> ...
> - Parallel worker
> are available with that hook
Hello,
Thank you for the work done on this subject.
After starting to play with it, I have a question and a remark:
> - previous hook calls were only called for normal backends, which was
> incorrect as we define the backend so as we apply no backend-related
> filtering for the hook.
Does that
24 matches
Mail list logo
