On Mon, Oct 16, 2023 at 6:36 AM Alexander Korotkov wrote:
>
> > On Mon, Oct 16, 2023 at 02:47:03AM +0300, Alexander Korotkov wrote:
> > > The attached revision fixes test failures spotted by
> > > commitfest.cputube.org. Also, perl scripts passed perltidy.
>
> You are very fast and sharp eye!
>
Hi, Alexander!
On Mon, Feb 5, 2024 at 7:00 PM Alexander Lakhin wrote:
> 05.02.2024 02:51, Alexander Korotkov wrote:
>
> > Usage of heap_inplace_update() seems appropriate for me here. It
> > avoids trouble with both TOAST and row-level locks. Alexander, could
> > you please recheck this fixes
Hello Alexander,
05.02.2024 02:51, Alexander Korotkov wrote:
Usage of heap_inplace_update() seems appropriate for me here. It
avoids trouble with both TOAST and row-level locks. Alexander, could
you please recheck this fixes the problem.
I've re-tested the last problematic scenario and can
On Tue, Jan 23, 2024 at 11:52 PM Alexander Korotkov
wrote:
> On Tue, Jan 23, 2024 at 8:00 PM Alexander Lakhin wrote:
> > Please look at the following query, which triggers an assertion failure on
> > updating the field dathasloginevt for an entry in pg_database:
> > SELECT format('CREATE
On Tue, Jan 23, 2024 at 8:00 PM Alexander Lakhin wrote:
> Please look at the following query, which triggers an assertion failure on
> updating the field dathasloginevt for an entry in pg_database:
> SELECT format('CREATE DATABASE db1 LOCALE_PROVIDER icu ICU_LOCALE en ENCODING
> utf8
> ICU_RULES
Hello Alexander and Daniel,
Please look at the following query, which triggers an assertion failure on
updating the field dathasloginevt for an entry in pg_database:
SELECT format('CREATE DATABASE db1 LOCALE_PROVIDER icu ICU_LOCALE en ENCODING
utf8
ICU_RULES ''' || repeat(' ', 20) || '''
On Mon, Jan 15, 2024 at 11:29 AM Daniel Gustafsson wrote:
> > On 13 Jan 2024, at 17:00, Alexander Lakhin wrote:
>
> > I suspected that this failure was caused by autovacuum, and I've managed to
> > reproduce it without Valgrind or slowing down a machine.
>
> This might be due to the fact that
> On 13 Jan 2024, at 17:00, Alexander Lakhin wrote:
> I suspected that this failure was caused by autovacuum, and I've managed to
> reproduce it without Valgrind or slowing down a machine.
This might be due to the fact that the cleanup codepath to remove the flag when
there is no login event
> On 13 Jan 2024, at 17:00, Alexander Lakhin wrote:
> DROP EVENT TRIGGER olt;
> SELECT dathasloginevt FROM pg_database WHERE datname= current_database();
> dathasloginevt
>
> t
> (1 row)
>
> Although after reconnection (\c, as done in the event_trigger_login test),
> this
Hi, Alexander!
On Sat, Jan 13, 2024 at 6:00 PM Alexander Lakhin wrote:
> I've discovered one more instability in the event_trigger_login test.
> Please look for example at case [1]:
> ok 213 + event_trigger 28946 ms
> not ok 214 - event_trigger_login
Hello Alexander,
I've discovered one more instability in the event_trigger_login test.
Please look for example at case [1]:
ok 213 + event_trigger 28946 ms
not ok 214 - event_trigger_login 6430 ms
ok 215 - fast_default
Alexander Korotkov writes:
> On Sun, Oct 29, 2023 at 6:16 PM Tom Lane wrote:
>> It looks to me that what happened here is that the backend completed the
>> authentication handshake, and then the login trigger caused a FATAL exit,
>> and after than the connected psql session tried to send "SELECT
On Sun, Oct 29, 2023 at 6:16 PM Tom Lane wrote:
> Mikhail Gribkov writes:
> > Just for a more complete picture of the final state here.
> > I have posted the described fix (for avoiding race condition in the tests)
> > separately:
> > https://commitfest.postgresql.org/45/4616/
>
> It turns out
Mikhail Gribkov writes:
> Just for a more complete picture of the final state here.
> I have posted the described fix (for avoiding race condition in the tests)
> separately:
> https://commitfest.postgresql.org/45/4616/
It turns out that the TAP test for this feature (006_login_trigger.pl)
also
Hi Alexander,
>> Thank you for catching it. Please, post this.
Just for a more complete picture of the final state here.
I have posted the described fix (for avoiding race condition in the tests)
separately:
https://commitfest.postgresql.org/45/4616/
--
best regards,
Mikhail A. Gribkov
Hi Alexander,
Sorry for my long offline and thanks for the activity. So should we close
the patch on the commitfest page now?
By the way I had one more issue with the login trigger tests (quite a rare
one though). A race condition may occur on some systems, when oidjoins test
starts a moment
Hi, Mikhail.
On Wed, Oct 18, 2023 at 1:30 PM Mikhail Gribkov wrote:
> Sorry for my long offline and thanks for the activity. So should we close the
> patch on the commitfest page now?
I have just done this.
> By the way I had one more issue with the login trigger tests (quite a rare
> one
On Mon, Oct 16, 2023 at 4:00 AM Michael Paquier wrote:
> On Mon, Oct 16, 2023 at 02:47:03AM +0300, Alexander Korotkov wrote:
> > The attached revision fixes test failures spotted by
> > commitfest.cputube.org. Also, perl scripts passed perltidy.
>
> Still you've missed a few things. At quick
On Mon, Oct 16, 2023 at 02:47:03AM +0300, Alexander Korotkov wrote:
> The attached revision fixes test failures spotted by
> commitfest.cputube.org. Also, perl scripts passed perltidy.
Still you've missed a few things. At quick glance:
- The code indentation was off a bit in event_trigger.c.
-
On Sat, Oct 14, 2023 at 2:10 AM Alexander Korotkov wrote:
> On Fri, Oct 13, 2023 at 11:26 AM Alexander Korotkov
> wrote:
> > On Fri, Oct 13, 2023 at 4:18 AM Robert Haas wrote:
> > > On Thu, Oct 12, 2023 at 6:54 PM Alexander Korotkov
> > > wrote:
> > > > On Thu, Oct 12, 2023 at 8:35 PM Robert
On Fri, Oct 13, 2023 at 11:26 AM Alexander Korotkov
wrote:
> On Fri, Oct 13, 2023 at 4:18 AM Robert Haas wrote:
> > On Thu, Oct 12, 2023 at 6:54 PM Alexander Korotkov
> > wrote:
> > > On Thu, Oct 12, 2023 at 8:35 PM Robert Haas wrote:
> >
> > > > Doesn't that mean that if you create the first
On Fri, Oct 13, 2023 at 4:18 AM Robert Haas wrote:
> On Thu, Oct 12, 2023 at 6:54 PM Alexander Korotkov
> wrote:
> > On Thu, Oct 12, 2023 at 8:35 PM Robert Haas wrote:
>
> > > Doesn't that mean that if you create the first login trigger in a
> > > database and leave the transaction open,
On Thu, Oct 12, 2023 at 6:54 PM Alexander Korotkov wrote:
> On Thu, Oct 12, 2023 at 8:35 PM Robert Haas wrote:
> > Doesn't that mean that if you create the first login trigger in a
> > database and leave the transaction open, nobody can connect to that
> > database until the transaction ends?
>
On Thu, Oct 12, 2023 at 8:35 PM Robert Haas wrote:
> On Tue, Oct 10, 2023 at 3:43 PM Alexander Korotkov
> wrote:
> > Yep, in v43 it worked that way. One transaction has to wait for
> > another finishing update of pg_database tuple, then fails. This is
> > obviously ridiculous. Since
On Tue, Oct 10, 2023 at 3:43 PM Alexander Korotkov wrote:
> Yep, in v43 it worked that way. One transaction has to wait for
> another finishing update of pg_database tuple, then fails. This is
> obviously ridiculous. Since overlapping setters of flag will have to
> wait anyway, I changed lock
Hi, Robert!
Thank you for your feedback.
On Tue, Oct 10, 2023 at 5:51 PM Robert Haas wrote:
>
> On Mon, Oct 9, 2023 at 10:11 AM Alexander Korotkov
> wrote:
> > * Hold lock during setting of pg_database.dathasloginevt flag (v32
> > version actually didn't prevent race condition).
>
> So ...
Hi!
Thank you for the review.
On Tue, Oct 10, 2023 at 7:37 PM Andres Freund wrote:
> On 2023-10-10 08:18:46 +0300, Alexander Korotkov wrote:
> > @@ -968,7 +969,7 @@ createdb(ParseState *pstate, const CreatedbStmt *stmt)
> >
> > if (!get_db_info(dbtemplate, ShareLock,
> >
Hi,
On 2023-10-10 08:18:46 +0300, Alexander Korotkov wrote:
> @@ -968,7 +969,7 @@ createdb(ParseState *pstate, const CreatedbStmt *stmt)
>
> if (!get_db_info(dbtemplate, ShareLock,
>_dboid, _owner, _encoding,
> -
On Mon, Oct 9, 2023 at 10:11 AM Alexander Korotkov wrote:
> * Hold lock during setting of pg_database.dathasloginevt flag (v32
> version actually didn't prevent race condition).
So ... how does getting this flag set actually work? And how does
clearing it work?
In the case of row-level
On Mon, Oct 9, 2023 at 11:58 PM Andres Freund wrote:
> On 2023-10-09 17:11:25 +0300, Alexander Korotkov wrote:
> > This version should be good and has no overhead. Any thoughts?
>
> I think you forgot to attach the patch?
That's it!
--
Regards,
Alexander Korotkov
On 2023-10-09 17:11:25 +0300, Alexander Korotkov wrote:
> This version should be good and has no overhead. Any thoughts?
I think you forgot to attach the patch?
Hi!
On Tue, Oct 3, 2023 at 8:35 PM Alexander Korotkov wrote:
> Thank you for the interesting ideas. I'd like to try to revive the
> version with the flag in pg_database. Will use other ideas as backup
> if no success.
I've revived the patch version with pg_database.dathasloginevt flag.
I took
Hi, Robert!
On Tue, Oct 3, 2023 at 5:21 PM Robert Haas wrote:
> On Tue, Oct 3, 2023 at 9:43 AM Daniel Gustafsson wrote:
> > That's exactly what happens, the patch is using BuildEventTriggerCache() to
> > build the hash for EVT which is then checked for login triggers. This is
> > clearly the
On Tue, Oct 3, 2023 at 9:43 AM Daniel Gustafsson wrote:
> That's exactly what happens, the patch is using BuildEventTriggerCache() to
> build the hash for EVT which is then checked for login triggers. This is
> clearly the bottleneck and there needs to be a fast-path. There used to be a
> cache
> On 2 Oct 2023, at 20:10, Robert Haas wrote:
>
> Sorry to have gone dark on this for a long time after having been
> asked for my input back in March. I'm not having a great time trying
> to keep up with email, and the threads getting split up makes it a lot
> worse for me.
Not a problem,
Sorry to have gone dark on this for a long time after having been
asked for my input back in March. I'm not having a great time trying
to keep up with email, and the threads getting split up makes it a lot
worse for me.
On Fri, Sep 29, 2023 at 6:15 AM Daniel Gustafsson wrote:
> Running the same
On Fri, Sep 29, 2023 at 1:15 PM Daniel Gustafsson wrote:
> > On 28 Sep 2023, at 23:50, Alexander Korotkov wrote:
>
> > I don't think I can reproduce the performance regression pointed out
> > by Pavel Stehule [1].
>
> > I can't confirm the measurable overhead.
>
>
> Running the same pgbench
> On 28 Sep 2023, at 23:50, Alexander Korotkov wrote:
> I don't think I can reproduce the performance regression pointed out
> by Pavel Stehule [1].
> I can't confirm the measurable overhead.
Running the same pgbench command on my laptop looking at the average connection
times, and the
Hi, Daniel!
On Mon, Sep 25, 2023 at 3:42 PM Daniel Gustafsson wrote:
> > On 25 Sep 2023, at 11:13, Alexander Korotkov wrote:
>
> > I'd like to do a short summary of
> > design issues on this thread.
>
> Thanks for summarizing this long thread!
>
> > the patch for the GUC option to disable
> >
> On 25 Sep 2023, at 11:13, Alexander Korotkov wrote:
> I'd like to do a short summary of
> design issues on this thread.
Thanks for summarizing this long thread!
> the patch for the GUC option to disable
> all event triggers resides in a separate thread [4]. Apparently that
> patch should be
Hi!
On Wed, Jun 14, 2023 at 10:49 PM Mikhail Gribkov wrote:
> The attached v40 patch is a fresh rebase on master branch to actualize the
> state before the upcoming commitfest.
> Nothing has changed beyond rebasing.
>
> And just for convenience, here is a link to the exact message of the thread
Hi hackers,
The attached v40 patch is a fresh rebase on master branch to actualize the
state before the upcoming commitfest.
Nothing has changed beyond rebasing.
And just for convenience, here is a link to the exact message of the thread
describing the current approach:
> On 22 Mar 2023, at 18:54, Robert Haas wrote:
> Basically, I think 0001 is a good idea -- I'm much more nervous about
> 0002. I think we should get 0001 polished up and committed.
Correct me if I'm wrong, but I believe you commented on v27-0001 of the login
event trigger patch series? Sorry
On Tue, Mar 15, 2022 at 4:52 PM Daniel Gustafsson wrote:
> Yeah, that was the previously posted v25 from the author (who adopted it from
> the original author). I took the liberty to quickly poke at the review
> comments you had left as well as the ones that I had found to try and progress
> the
Hi Gregory,
Thanks for the note. The problem was that the patch was not aware of
yesterday Tom Lane's changes in the test.
It's fixed now: the attached v39 patch contains the updated version along
with the freshest rebase on master branch.
--
best regards,
Mikhail A. Gribkov
e-mail:
It looks like the patch is failing a test by not dumping
login_event_trigger_func? I'm guessing there's a race condition in the
test but I don't know. I also don't see the tmp_test_jI6t output file
being preserved in the artifacts anywhere :(
> On 6 Mar 2023, at 23:10, Andres Freund wrote:
>
> Hi,
>
> On 2023-03-06 15:55:01 -0500, Gregory Stark (as CFM) wrote:
>> It looks like Daniel Gustafsson, Andres, and Tom have all weighed in
>> on this patch with at least a neutral comment (+-0 from Andres :)
>>
>> It looks like the main
Hi,
On 2023-03-06 15:55:01 -0500, Gregory Stark (as CFM) wrote:
> It looks like Daniel Gustafsson, Andres, and Tom have all weighed in
> on this patch with at least a neutral comment (+-0 from Andres :)
>
> It looks like the main concern was breaking physical replicas and that
> there was
> On 6 Mar 2023, at 21:55, Gregory Stark (as CFM) wrote:
>
> It looks like Daniel Gustafsson, Andres, and Tom have all weighed in
> on this patch with at least a neutral comment (+-0 from Andres :)
I think the concept of a login event trigger has merits, even though it's kind
of a niche use
It looks like Daniel Gustafsson, Andres, and Tom have all weighed in
on this patch with at least a neutral comment (+-0 from Andres :)
It looks like the main concern was breaking physical replicas and that
there was consensus that as long as single-user mode worked that it
was ok?
So maybe it's
Hi hackers,
The attached v38 patch is a fresh rebase on master branch.
Nothing has changed beyond rebasing.
And just for convenience, here is a link to the exact message of the thread
describing the current approach:
pá 20. 1. 2023 v 19:46 odesílatel Mikhail Gribkov
napsal:
> Hi Pavel,
>
> On Mon, Jan 16, 2023 at 9:10 AM Pavel Stehule
> wrote:
>
>>
>>
>> ne 15. 1. 2023 v 7:32 odesílatel Pavel Stehule
>> napsal:
>>
>>> Hi
>>>
>>>
On Thu, Jan 12, 2023 at 9:51 AM Pavel Stehule
wrote:
>
Hi Pavel,
On Mon, Jan 16, 2023 at 9:10 AM Pavel Stehule
wrote:
>
>
> ne 15. 1. 2023 v 7:32 odesílatel Pavel Stehule
> napsal:
>
>> Hi
>>
>>
>>> On Thu, Jan 12, 2023 at 9:51 AM Pavel Stehule
>>> wrote:
>>>
Hi
I checked this patch and it looks well. All tests passed. Together
ne 15. 1. 2023 v 7:32 odesílatel Pavel Stehule
napsal:
> Hi
>
>
>> On Thu, Jan 12, 2023 at 9:51 AM Pavel Stehule
>> wrote:
>>
>>> Hi
>>>
>>> I checked this patch and it looks well. All tests passed. Together with
>>> https://commitfest.postgresql.org/41/4013/ it can be a good feature.
>>>
>>> I
Hi
so 14. 1. 2023 v 22:56 odesílatel Mikhail Gribkov
napsal:
> Hi Pavel,
>
> Thanks for pointing out the tests. I completely agree that using an
> exception inside on-login trigger should be tested. It cannot be done via
> regular *.sql/*.out regress tests, thus I have added another perl test
Hi Pavel,
Thanks for pointing out the tests. I completely agree that using an
exception inside on-login trigger should be tested. It cannot be done via
regular *.sql/*.out regress tests, thus I have added another perl test to
authentication group doing this.
Attached v36 patch contains this test
Hi
po 19. 12. 2022 v 10:40 odesílatel Mikhail Gribkov
napsal:
> Hi Ted,
>
> > bq. in to the system
> > 'in to' -> into
> > bq. Any bugs in a trigger procedure
> > Any bugs -> Any bug
>
> Thanks! Fixed typos in the attached v35.
>
> > + if (event == EVT_Login)
> > +
On Mon, Dec 19, 2022 at 1:40 AM Mikhail Gribkov wrote:
> Hi Ted,
>
> > bq. in to the system
> > 'in to' -> into
> > bq. Any bugs in a trigger procedure
> > Any bugs -> Any bug
>
> Thanks! Fixed typos in the attached v35.
>
> > + if (event == EVT_Login)
> > +
Hi Ted,
> bq. in to the system
> 'in to' -> into
> bq. Any bugs in a trigger procedure
> Any bugs -> Any bug
Thanks! Fixed typos in the attached v35.
> + if (event == EVT_Login)
> + dbgtag = CMDTAG_LOGIN;
> + else
> +
On Sat, Dec 17, 2022 at 3:46 AM Mikhail Gribkov wrote:
> Hi Nikita,
>
> > Mikhail, I've checked the patch and previous discussion,
> > the condition mentioned earlier is still actual:
>
> Thanks for pointing this out! My bad, I forgot to fix the documentation
> example.
> Attached v34 has this
Hi Nikita,
> Mikhail, I've checked the patch and previous discussion,
> the condition mentioned earlier is still actual:
Thanks for pointing this out! My bad, I forgot to fix the documentation
example.
Attached v34 has this issue fixed, as well as a couple other problems with
the example code.
Hi,
Mikhail, I've checked the patch and previous discussion,
the condition mentioned earlier is still actual:
>The example trigger from the documentation
+DECLARE
+ hour integer = EXTRACT('hour' FROM current_time);
+ rec boolean;
+BEGIN
+-- 1. Forbid logging in between 2AM and 4AM.
+IF
Hi hackers,
Attached v33 is a new rebase of the flagless version of the patch. As
there were no objections at first glance, I’ll try to post it to the
upcoming commitfest, thus the brief recap of all the patch details is below.
v33-On_client_login_event_trigger
The patch introduces a trigger on
Hi hackers,
Since the original authors, as Daniel said, seems to have retired from the
patch, I have allowed myself to continue the patch polishing.
Attached v32 includes fresh rebase and the following fixes:
- Copying dathasloginevt flag during DB creation from template;
- Restoring
2022年11月4日(金) 5:23 Daniel Gustafsson :
>
> > On 20 Sep 2022, at 16:10, Daniel Gustafsson wrote:
>
> > Since the original authors seems to have retired from the patch
> > (I've only rebased it to try and help) I am inclined to mark it as returned
> > with feedback.
>
> Doing so now since no
> On 20 Sep 2022, at 16:10, Daniel Gustafsson wrote:
> Since the original authors seems to have retired from the patch
> (I've only rebased it to try and help) I am inclined to mark it as returned
> with feedback.
Doing so now since no updates have been posted for quite some time and holes
have
On 20.09.2022 17:10, Daniel Gustafsson wrote:
On 20 Sep 2022, at 15:43, Sergey Shinderuk wrote:
There is a race around setting and clearing of dathasloginevt.
Thanks for the report! The whole dathasloginevt mechanism is IMO too clunky
and unelegant to go ahead with, I wouldn't be surprised
> On 20 Sep 2022, at 15:43, Sergey Shinderuk wrote:
>
> On 02.09.2022 18:36, Daniel Gustafsson wrote:
>> This had bitrotted a fair bit, attached is a rebase along with (mostly)
>> documentation fixes. 0001 adds a generic GUC for ignoring event triggers and
>> 0002 adds the login event with
On 02.09.2022 18:36, Daniel Gustafsson wrote:
This had bitrotted a fair bit, attached is a rebase along with (mostly)
documentation fixes. 0001 adds a generic GUC for ignoring event triggers and
0002 adds the login event with event trigger support, and hooks it up to the
GUC such that broken
On Fri, Sep 2, 2022 at 8:37 AM Daniel Gustafsson wrote:
> This had bitrotted a fair bit, attached is a rebase along with (mostly)
> documentation fixes. 0001 adds a generic GUC for ignoring event triggers
> and
> 0002 adds the login event with event trigger support, and hooks it up to
> the
>
This had bitrotted a fair bit, attached is a rebase along with (mostly)
documentation fixes. 0001 adds a generic GUC for ignoring event triggers and
0002 adds the login event with event trigger support, and hooks it up to the
GUC such that broken triggers wont require single-user mode. Moving
> On 1 Apr 2022, at 09:16, a.soko...@postgrespro.ru wrote:
> Please fix a typo in doc/src/sgml/event-trigger.sgml: "precvent"
Will do. With that fixed I think this is ready and unless I find something on
another read through and test pass I hope to be able to push this before the CF
closes
Daniel Gustafsson писал 2022-03-30 16:48:
On 30 Mar 2022, at 13:21, Ivan Panchenko wrote:
Maybe side-effects is a bit too general? Emitting a log message,
rejecting a
login, setting some GUCs, etc are all side-effects too.
Something like this:
I've reworded the docs close to what you
> On 29 Mar 2022, at 00:40, Tom Lane wrote:
>
> Andres Freund writes:
>> On 2022-03-28 23:27:56 +0200, Daniel Gustafsson wrote:
>>> Do you think this potential foot-gun is scary enough to reject this patch?
>>> There are lots of creative ways to cause Nagios alerts from ones database,
>>> but
> On 30 Mar 2022, at 13:21, Ivan Panchenko wrote:
> Maybe side-effects is a bit too general? Emitting a log message, rejecting a
> login, setting some GUCs, etc are all side-effects too.
> Something like this:
I've reworded the docs close to what you suggested here.
> Also, please fix a typo in
Hi,
>Tue, March 29, 2022, 0:31 +03:00 from Andres Freund :
>
>Hi,
>
>On 2022-03-28 23:27:56 +0200, Daniel Gustafsson wrote:
>> > On 28 Mar 2022, at 19:10, Andres Freund < and...@anarazel.de > wrote:
>> > On 2022-03-28 15:57:37 +0300, a.soko...@postgrespro.ru wrote:
>>
>> >> + data
Andres Freund writes:
> On 2022-03-28 23:27:56 +0200, Daniel Gustafsson wrote:
>> Do you think this potential foot-gun is scary enough to reject this patch?
>> There are lots of creative ways to cause Nagios alerts from ones database,
>> but
>> this has the potential to do so with a small bug in
> On 28 Mar 2022, at 23:31, Andres Freund wrote:
>
> Hi,
>
> On 2022-03-28 23:27:56 +0200, Daniel Gustafsson wrote:
>>> On 28 Mar 2022, at 19:10, Andres Freund wrote:
>>> On 2022-03-28 15:57:37 +0300, a.soko...@postgrespro.ru wrote:
>>
+data initialization. It is vital that any event
Hi,
On 2022-03-28 23:27:56 +0200, Daniel Gustafsson wrote:
> > On 28 Mar 2022, at 19:10, Andres Freund wrote:
> > On 2022-03-28 15:57:37 +0300, a.soko...@postgrespro.ru wrote:
>
> >> +data initialization. It is vital that any event trigger using the
> >> +login event checks whether or
> On 28 Mar 2022, at 19:10, Andres Freund wrote:
> On 2022-03-28 15:57:37 +0300, a.soko...@postgrespro.ru wrote:
>> +data initialization. It is vital that any event trigger using the
>> +login event checks whether or not the database is in
>> +recovery.
>>
>> Does any trigger really
Hi,
On 2022-03-28 15:57:37 +0300, a.soko...@postgrespro.ru wrote:
> +data initialization. It is vital that any event trigger using the
> +login event checks whether or not the database is in
> +recovery.
>
> Does any trigger really have to contain a pg_is_in_recovery() call?
Not
Daniel Gustafsson писал 2022-03-22 11:43:
On 22 Mar 2022, at 04:48, Andres Freund wrote:
docs fail to build:
https://cirrus-ci.com/task/5556234047717376?logs=docs_build#L349
Ugh, that one was on me and not the original author. Fixed.
+data initialization. It is vital that any event
> On 22 Mar 2022, at 04:48, Andres Freund wrote:
> docs fail to build:
> https://cirrus-ci.com/task/5556234047717376?logs=docs_build#L349
Ugh, that one was on me and not the original author. Fixed.
--
Daniel Gustafsson https://vmware.com/
Hi,
On 2022-03-18 17:03:39 +0100, Daniel Gustafsson wrote:
> > On 18 Mar 2022, at 08:24, a.soko...@postgrespro.ru wrote:
>
> > - auth_extra => [ '--create-role', 'repl_role' ]);
> > + auth_extra => [ '--create-role', 'repl_role,regress_user' ]);
>
> Looking at the test
> On 18 Mar 2022, at 08:24, a.soko...@postgrespro.ru wrote:
> - auth_extra => [ '--create-role', 'repl_role' ]);
> + auth_extra => [ '--create-role', 'repl_role,regress_user' ]);
Looking at the test in question it's not entirely clear to me what the original
author really
Daniel Gustafsson писал 2022-03-15 23:52:
Yeah, that was the previously posted v25 from the author (who adopted
it from
the original author). I took the liberty to quickly poke at the review
comments you had left as well as the ones that I had found to try and
progress
the patch. 0001
> On 14 Mar 2022, at 17:10, Andres Freund wrote:
>
> Hi,
>
> On 2022-03-14 14:47:09 +0100, Daniel Gustafsson wrote:
>>> On 14 Mar 2022, at 01:08, Andres Freund wrote:
>>
>>> I was thinking that the way to use it would be to specify it as a client
>>> option. Like PGOPTIONS='-c
Hi,
On 2022-03-14 14:47:09 +0100, Daniel Gustafsson wrote:
> > On 14 Mar 2022, at 01:08, Andres Freund wrote:
>
> > I was thinking that the way to use it would be to specify it as a client
> > option. Like PGOPTIONS='-c ignore_event_trigger=login' psql.
>
> Attached is a quick PoC/sketch of
> On 14 Mar 2022, at 01:08, Andres Freund wrote:
> I was thinking that the way to use it would be to specify it as a client
> option. Like PGOPTIONS='-c ignore_event_trigger=login' psql.
Attached is a quick PoC/sketch of such a patch, where 0001 adds a guc, 0002 is
the previously posted v25
On Sun, Mar 13, 2022 at 7:34 PM Andres Freund wrote:
> IMO the other types of event triggers make it a heck of a lot harder to get
> yourself into a situation that you can't get out of...
In particular, unless something has changed since I committed this
stuff originally, there's no existing
> On 14 Mar 2022, at 00:33, Andres Freund wrote:
> We already have GUCs like row_security, so it doesn't seem insane to add one
> that disables login event triggers. What is the danger that you see?
My fear is that GUCs like that end up as permanent fixtures in scripts etc
after having been
On 2022-03-13 20:35:44 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I was thinking that the way to use it would be to specify it as a client
> > option. Like PGOPTIONS='-c ignore_event_trigger=login' psql.
>
> Ugh ... that would allow people (at least superusers) to bypass
> the login
Andres Freund writes:
> I was thinking that the way to use it would be to specify it as a client
> option. Like PGOPTIONS='-c ignore_event_trigger=login' psql.
Ugh ... that would allow people (at least superusers) to bypass
the login trigger at will, which seems to me to break a lot of
the
Hi,
On 2022-03-13 19:57:08 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-03-13 23:31:03 +0100, Daniel Gustafsson wrote:
> >> Something like a '-c ignore_event_trigger=' GUC perhaps?
>
> > Did you mean login instead of event?
>
> > Something like it would work for me. It probably
Andres Freund writes:
> On 2022-03-13 23:31:03 +0100, Daniel Gustafsson wrote:
>> Something like a '-c ignore_event_trigger=' GUC perhaps?
> Did you mean login instead of event?
> Something like it would work for me. It probably should be
> GUC_DISALLOW_IN_FILE?
Why? Inserting such a setting
Hi,
On 2022-03-13 23:31:03 +0100, Daniel Gustafsson wrote:
> > On 12 Mar 2022, at 03:46, Andres Freund wrote:
>
> >> +
> >> + The login event occurs when a user logs in to the
> >> + system.
> >> + Any bugs in a trigger procedure for this event may prevent successful
> >> +
> On 12 Mar 2022, at 03:46, Andres Freund wrote:
>> +
>> + The login event occurs when a user logs in to the
>> + system.
>> + Any bugs in a trigger procedure for this event may prevent successful
>> + login to the system. Such bugs may be fixed after first restarting the
>> +
Hi,
On 2022-02-15 21:07:15 +1100, Greg Nancarrow wrote:
> Subject: [PATCH v25] Add a new "login" event and login event trigger support.
>
> The login event occurs when a user logs in to the system.
I think this needs a HUGE warning in the docs about most event triggers
needing to check
On Tue, Feb 15, 2022 at 5:07 AM Greg Nancarrow wrote:
> I've attached a re-based version (no functional changes from the
> previous) to fix cfbot failures.
I tried this:
rhaas=# create function on_login_proc() returns event_trigger as
$$begin perform pg_sleep(1000); end$$ language plpgsql;
> On 15 Feb 2022, at 11:07, Greg Nancarrow wrote:
> I've attached a re-based version (no functional changes from the
> previous) to fix cfbot failures.
Thanks for adopting this patch, I took another look at it today and have some
comments.
+This flag is used internally by PostgreSQL
1 - 100 of 186 matches
Mail list logo
