On Fri, Jan 24, 2020 at 4:58 PM Mahendra Singh Thalor
wrote:
>
> On Thu, 23 Jan 2020 at 15:32, Mahendra Singh Thalor
> wrote:
> >
> > On Wed, 22 Jan 2020 at 12:48, Masahiko Sawada
> > wrote:
> > >
> > > Attached the updated version patch.
> >
> > Thanks Sawada-san for the re-based patch.
> >
>
On Fri, Jan 24, 2020 at 9:37 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > LGTM. I have combined them into the single patch. What do we think
> > about backpatching this?
>
> No objection to the patch for HEAD, but it does not seem like
> back-patch material: it is not fixing a bug.
>
Okay,
On Wed, Dec 11, 2019 at 2:07 AM Ibrar Ahmed wrote:
> You are checking file->dirty twice, first before calling the function and
> within the function too. Same for the Assert. For example.
True. Thanks for the review. Before I post a new version, any
opinions on whether to back-patch, and
On Sat, Jan 25, 2020 at 3:39 PM Melanie Plageman
wrote:
> So, I think from a code review perspective the code in the patches
> LGTM.
> As for the EXPLAIN ANALYZE tests--I don't see that many of them in
> regress, so maybe that's because they aren't normally very useful. In
> this case, it would
Thanks for the thorough review. I obviously missed some critical
issues. I recognized some of the other maintainability problems, but
did not have a sense of how to best avoid them, being unfamiliar with
the code.
For what it's worth, this version makes sense to me.
So, I think from a code review perspective the code in the patches
LGTM.
As for the EXPLAIN ANALYZE tests--I don't see that many of them in
regress, so maybe that's because they aren't normally very useful. In
this case, it would only be to protect against regressions in printing
the leader
On Wed, Jan 22, 2020 at 3:06 PM Alvaro Herrera
wrote:
> My own inclination is that Andrew's implementation, being more general
> in nature, would be the better one to have in the codebase; but we don't
> have a complete patch yet. Can we reach some compromise such as if
> Andrew's patch is not
Maciek Sakrejda writes:
> Okay. Does not getting as many workers as it asks for include
> sometimes getting zero, completely changing the actual output?
Yup :-(. We could possibly avoid that by running the explain
test by itself rather than in a parallel group, but I don't
especially want to
On Fri, Jan 24, 2020 at 5:01 PM Jeff Davis wrote:
> Unfortunately, I'm seeing some bad behavior (at least in some cases)
> with logtape.c, where it's spending a lot of time qsorting the list of
> free blocks. Adam, did you also see this during your perf tests? It
> seems to be worst with lower
Okay. Does not getting as many workers as it asks for include
sometimes getting zero, completely changing the actual output? If so,
I'll submit a new version of the patch removing all tests--I was
hoping to improve coverage, but I guess this is not the way to start.
If not, can we keep the json
On Thu, Jan 23, 2020 at 2:47 AM Amit Kapila wrote:
>
> On Sun, Jan 19, 2020 at 2:23 PM Richard Guo wrote:
> >
> > I realized that there are two patches in this thread that are
> > implemented according to different methods, which causes confusion.
> >
>
> Both the idea seems to be different. Is
On Thu, Jan 23, 2020 at 9:38 AM Rui DeSousa wrote:
> On Jan 22, 2020, at 2:19 PM, Tom Lane wrote:
>> It's certainly possible that to see any benefit you need stress
>> levels above what I can manage on the small box I've got these
>> OSes on. Still, it'd be nice if a performance patch could
On 1/24/20, 1:32 PM, "Bossart, Nathan" wrote:
>>> I chose to disallow disabling both *_RELATION_CLEANUP options
>>> together, as this would essentially cause the VACUUM command to take
>>> no action.
>>
>> My first reaction is why? Agreed that it is a bit crazy to combine
>> both options, but if
On 1/21/20, 1:39 PM, "Vik Fearing" wrote:
> On 21/01/2020 22:21, Bossart, Nathan wrote:
>> I've attached a patch for a couple of new options for VACUUM:
>> MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP. The motive
>> behind these options is to allow table owners to easily vacuum only
>>
On Fri, Jan 24, 2020 at 6:55 AM Justin Pryzby wrote:
>
> On Wed, Nov 13, 2019 at 11:39:04AM +0100, Julien Rouhaud wrote:
> > (moved to -hackers)
> >
> > On Tue, Nov 12, 2019 at 9:55 PM Andres Freund wrote:
> > >
> > > This last point is more oriented towards other PG developers: I wonder
> > >
Hi,
There are 3 tiny improvements to xlog.c code:
1. At function StartupXLOG (line 6370), the second test if
(ArchiveRecoveryRequested) is redundant and can secure removed.
2. At function StartupXLOG (line 7254) the var switchedTLI already been
tested before and the second test can secure
Hi,
Currently pg_stat_bgwriter.buffers_backend is pretty useless to gauge
whether backends are doing writes they shouldn't do. That's because it
counts things that are either unavoidably or unlikely doable by other
parts of the system (checkpointer, bgwriter).
In particular extending the file
> On Jan 24, 2020, at 10:43 AM, Robert Haas wrote:
>
> Since 0001-0003 have been reviewed by multiple people and nobody's
> objected, I have committed those.
I think 0004-0005 have been reviewed and accepted by both me and Andrew, if I
understood him correctly:
> I've reviewed these
pá 24. 1. 2020 v 14:17 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 24.01.2020 15:15, Pavel Stehule wrote:
>
> You will see a effect of DDL in current session (where you did the
> change), all other sessions should to live without any any change do
> reconnect or
Thanks for reviewing
On Wed, Jan 22, 2020 at 05:37:06PM +0900, Masahiko Sawada wrote:
> I'm not sure it's worth to have patches separately but I could apply
The later patches expanded on the initial scope, and to my understanding the
1st callback is desirable but the others are maybe still at
On 2020-Jan-24, Peter Eisentraut wrote:
> I'm not fond of the base64 idea btw., because it seems to sort of penalize
> using non-ASCII characters by making the result completely not human
> readable. Something along the lines of MIME would be better in that way.
> There are existing solutions to
On Thu, Jan 23, 2020 at 1:05 PM Mark Dilger
wrote:
> Ok, I finished merging with Robert’s patches. The attached follow his
> numbering, with my patches intended to by applied after his.
I think it'd be a good idea to move the pg_wchar.h stuff into a new
thread. This thread is getting a bit
Hi Nikita,
This patch seems inactive / stuck in "waiting on author" since November.
It's marked as bugfix, so it'd be good to get it committed instead of
just punting it to the next CF.
I did a quick review, and I came mostly with the same two complaints as
Alexander ...
On Wed, Jul 17, 2019
On 2020-01-24 18:56, Robert Haas wrote:
On Fri, Jan 24, 2020 at 9:48 AM Tom Lane wrote:
Alvaro Herrera writes:
I prefer the encoding scheme myself. I don't see the point of the
error.
Yeah, if we don't want to skip such files, then storing them using
a base64-encoded name (with a
> On Jan 24, 2020, at 10:03 AM, Alvaro Herrera wrote:
>
> The other is Mark's point about "expected file pattern", which seems a
> slippery slope to me. If the pattern is /^[a-zA-Z0-9_.]*$/ then I'm
> okay with it (maybe add a few other punctuation chars); as you say no
> sane extension
On 2020-Jan-24, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2020-Jan-24, Mark Dilger wrote:
> >> I would expect, therefore, that we only back up files which match our
> >> expected file name pattern and ignore (perhaps with a warning)
> >> everything else.
>
> > That risks missing files
On 2020-01-24 18:25, Juan José Santamaría Flecha wrote:
To illustrate the issue, it does not work as expected:
postgres=# select lower(to_char(now(),'TMMONTH'));
lower
ιανουάριοσ
(1 row)
postgres=# select to_char(now(),'TMmonth');
to_char
ιανουάριος
(1 row)
On Fri, Jan 24, 2020 at 9:48 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > I prefer the encoding scheme myself. I don't see the point of the
> > error.
>
> Yeah, if we don't want to skip such files, then storing them using
> a base64-encoded name (with a different key than regular names)
>
Alvaro Herrera writes:
> On 2020-Jan-24, Mark Dilger wrote:
>> I would expect, therefore, that we only back up files which match our
>> expected file name pattern and ignore (perhaps with a warning)
>> everything else.
> That risks missing files placed in the datadir by extensions;
I agree that
On 2020-Jan-24, Mark Dilger wrote:
> I would expect, therefore, that we only back up files which match our
> expected file name pattern and ignore (perhaps with a warning)
> everything else.
That risks missing files placed in the datadir by extensions; see
discussion about pg_checksums using a
Alvaro Herrera writes:
> I prefer the encoding scheme myself. I don't see the point of the
> error.
Yeah, if we don't want to skip such files, then storing them using
a base64-encoded name (with a different key than regular names)
seems plausible. But I don't really see why we'd go to that
On 2020-Jan-24, David Steele wrote:
> On 1/24/20 10:00 AM, Alvaro Herrera wrote:
> > Maybe we can get away with *ignoring* such files, perhaps after emitting
> > a warning.
>
> I'd prefer an an error (or base64 encoding) rather than just skipping a
> file. The latter sounds scary.
Well, if
Maciek Sakrejda writes:
> Great, thank you. I noticed in the CF patch tester app, the build
> fails on Windows [1]. Investigating, I realized I had failed to fully
> strip volatile EXPLAIN info (namely buffers) in TEXT mode due to a
> bad regexp_replace.
You haven't gone nearly far enough in
hi there
I am a database developer with 10+ years industry experience. I want to
make contribution to Postgres and look for some work items to start with.
Looking at the TODO list, I am not sure what to start with? Any suggestions?
Thanks,
Xiang
On Fri, Jan 24, 2020 at 5:46 PM Tom Lane wrote:
> Peter Eisentraut writes:
> > Looking through the patch quickly, if you want to get Unicode-fancy,
> > doing a case-insensitive comparison by running lower-case on both
> > strings is also wrong in corner cases. All the Greek month names end in
> On Jan 24, 2020, at 8:36 AM, David Steele wrote:
>
>> I don't entirely follow why we're discussing this at all, if the
>> requirement is backing up a PG data directory. There are not, and
>> are never likely to be, any legitimate files with non-ASCII names
>> in that context. Why can't we
On 1/24/20 10:00 AM, Alvaro Herrera wrote:
On 2020-Jan-24, David Steele wrote:
It might be nice to have a strict mode where non-ASCII/UTF8 characters will
error instead, but that can be added on later.
"your backup failed because you have a file we don't like" is not great
behavior. IIRC we
Great, thank you. I noticed in the CF patch tester app, the build
fails on Windows [1]. Investigating, I realized I had failed to fully
strip volatile EXPLAIN info (namely buffers) in TEXT mode due to a
bad regexp_replace. I've fixed this in the attached patch (which I
also rebased against current
On 2020-Jan-24, David Steele wrote:
> It might be nice to have a strict mode where non-ASCII/UTF8 characters will
> error instead, but that can be added on later.
"your backup failed because you have a file we don't like" is not great
behavior. IIRC we already fail when a file is owned by root
Peter Eisentraut writes:
> Looking through the patch quickly, if you want to get Unicode-fancy,
> doing a case-insensitive comparison by running lower-case on both
> strings is also wrong in corner cases. All the Greek month names end in
> sigma, so I suspect that this patch might not work
On 2020-01-24 17:22, Tom Lane wrote:
Alvaro Herrera writes:
But that's a different POV. The input to this function could come from
arbitrary user input from any application whatsoever. So the only
reason we can get away with that is because the example regression case
Juan José added (which
On 1/24/20 9:27 AM, Tom Lane wrote:
Peter Eisentraut writes:
On 2020-01-23 18:04, Robert Haas wrote:
Now, you might say "well, why don't we just do an encoding
conversion?", but we can't. When the filesystem tells us what the file
names are, it does not tell us what encoding the person who
On 1/23/20 11:05 AM, Robert Haas wrote:
> On Thu, Jan 23, 2020 at 12:49 PM Bruce Momjian wrote:
>> Another idea is to use base64 for all non-ASCII file names, so we don't
>> need to check if the file name is valid UTF8 before outputting --- we
>> just need to check for non-ASCII, which is much
Peter Eisentraut writes:
> On 2020-01-23 18:04, Robert Haas wrote:
>> Now, you might say "well, why don't we just do an encoding
>> conversion?", but we can't. When the filesystem tells us what the file
>> names are, it does not tell us what encoding the person who created
>> those files had in
Alvaro Herrera writes:
> But that's a different POV. The input to this function could come from
> arbitrary user input from any application whatsoever. So the only
> reason we can get away with that is because the example regression case
> Juan José added (which uses non-normals) does not
On 2020-Jan-24, Peter Eisentraut wrote:
> When you interact with glibc locale functions, you essentially have to
> assume that everything is in NFC. When using ICU locale functions (which we
> don't here, but just for the sake of argument), then I would expect that ICU
> does appropriate
On 1/23/20 7:09 AM, Christoph Berg wrote:
> Re: David Steele 2020-01-21
<95349047-31dd-c7dc-df17-b488c2d34...@pgmasters.net>
>> Yes -- at least Ubuntu < 18.04 does not install pkg-config for
libxml2. I
>> have not checked Debian yet, but I imagine < 8 will have the same issue.
>
> That is not
Amit Kapila writes:
> LGTM. I have combined them into the single patch. What do we think
> about backpatching this?
No objection to the patch for HEAD, but it does not seem like
back-patch material: it is not fixing a bug.
regards, tom lane
On 2020-01-24 12:44, Alvaro Herrera wrote:
On 2020-Jan-24, Juan José Santamaría Flecha wrote:
There is an open patch that will make the normalization functionality user
visible [1]. So, if a user can call to_date(normalize('01 ŞUB 2010'), 'DD
TMMON ') I would vote to drop the normalization
Peter Eisentraut writes:
> On 2020-01-23 23:11, Tom Lane wrote:
>> I happened to notice this comment in the logic in
>> ATAddForeignKeyConstraint that tries to decide if it can skip
>> revalidating a foreign-key constraint after a DDL change:
>> * Since we require that all collations share
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
writes:
> On Thu, Jan 23, 2020 at 11:00 PM Tom Lane wrote:
>> * It's not exactly apparent to me why this code should be concerned
>> about non-normalized characters when noplace else in the backend is.
> There is an open patch that will make
On 2020-01-23 18:04, Robert Haas wrote:
Now, you might say "well, why don't we just do an encoding
conversion?", but we can't. When the filesystem tells us what the file
names are, it does not tell us what encoding the person who created
those files had in mind. We don't know that they had*any*
On Fri, Jan 24, 2020 at 6:47 AM Alvaro Herrera wrote:
> On 2020-Jan-22, Tatsuro Yamada wrote:
> > P.S.
> > Next up is progress reporting for query execution?!
>
> Actually, I think it's ALTER TABLE.
+1. Existing infrastructure might be enough to cover ALTER TABLE's
needs, whereas we will very
> On Jan 23, 2020, at 4:27 PM, Andrew Dunstan
> wrote:
>
> On Fri, Jan 24, 2020 at 7:35 AM Mark Dilger
> wrote:
>>
>>
>>> On Jan 22, 2020, at 7:00 PM, Mark Dilger
>>> wrote:
>>>
>>> I have this done in my local repo to the point that I can build frontend
>>> tools against the json
Hello again.
Andres, Peter, thanks for your comments.
Some of issues your mentioned (reporting feedback to the another
cascade standby, processing queries after restart and newer xid
already reported) could be fixed in provided design, but your
intention to have "independent correctness
On 24.01.2020 15:15, Pavel Stehule wrote:
You will see a effect of DDL in current session (where you did the
change), all other sessions should to live without any any change do
reconnect or to RESET connect
Why? I found this requirement quit unnatural and contradicting to the
behavior of
On 24/01/2020 10:06, Takashi Menjo wrote:
I propose "non-volatile WAL buffer," a proof-of-concept new feature. It
enables WAL records to be durable without output to WAL segment files by
residing on persistent memory (PMEM) instead of DRAM. It improves database
performance by reducing copies
Last time improvement to restricted_token.c
regards,
Ranier Vilela
restricted_token_leaks.patch
Description: Binary data
Em sex., 24 de jan. de 2020 às 04:13, Michael Paquier
escreveu:
> On Wed, Jan 22, 2020 at 05:51:51PM -0300, Ranier Vilela wrote:
> > After review the patches and build all and run regress checks for each
> > patch, those are the ones that don't break.
>
> There is some progress. You should be
pá 24. 1. 2020 v 10:43 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 24.01.2020 12:09, Pavel Stehule wrote:
>
>
>
> pá 24. 1. 2020 v 9:39 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> napsal:
>
>>
>>
>> On 23.01.2020 23:47, Robert Haas wrote:
>> > On
On 2020/01/24 17:08, Fujii Masao wrote:
On 2020/01/24 16:56, Julien Rouhaud wrote:
On Fri, Jan 24, 2020 at 8:20 AM Fujii Masao
wrote:
On 2020/01/24 15:38, Arthur Zakirov wrote:
On 2020/01/24 14:56, Michael Paquier wrote:
On Fri, Jan 24, 2020 at 01:28:29PM +0900, Arthur Zakirov wrote:
On 2020-Jan-24, Juan José Santamaría Flecha wrote:
> There is an open patch that will make the normalization functionality user
> visible [1]. So, if a user can call to_date(normalize('01 ŞUB 2010'), 'DD
> TMMON ') I would vote to drop the normalization logic inside this patch
> altogether.
On Thu, 23 Jan 2020 at 15:32, Mahendra Singh Thalor wrote:
>
> On Wed, 22 Jan 2020 at 12:48, Masahiko Sawada
> wrote:
> >
> > On Wed, 22 Jan 2020 at 11:23, Amit Kapila wrote:
> > >
> > > On Wed, Jan 22, 2020 at 7:14 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > Thank you for updating the
On 2020-01-20 16:43, Tom Lane wrote:
Peter Eisentraut writes:
On 2020-01-15 01:37, Tom Lane wrote:
This patch is making src/tools/pginclude/headerscheck unhappy:
./src/include/common/unicode_combining_table.h:3: error: array type has
incomplete element type
Hmm, this file is only meant to
> On 17 Jan 2020, at 03:38, Michael Paquier wrote:
>
> On Fri, Jan 17, 2020 at 10:09:54AM +0900, Michael Paquier wrote:
>> Could you please rebase and fix the remaining pieces of the patch?
>
> And while I remember, you may want to add checks for incorrect bounds
> when validating the values in
Hello,
+1 on the idea.
By quickly looking at the patch, I notice that there are no tests.
Is it possible to emulate somthing without the actual hardware, at least
for testing purposes?
--
Fabien.
On 2020-01-24 01:21, Thomas Munro wrote:
On Fri, Jan 24, 2020 at 11:12 AM Tom Lane wrote:
I happened to notice this comment in the logic in
ATAddForeignKeyConstraint that tries to decide if it can skip
revalidating a foreign-key constraint after a DDL change:
* Since we require
On 2020-01-23 23:11, Tom Lane wrote:
I happened to notice this comment in the logic in
ATAddForeignKeyConstraint that tries to decide if it can skip
revalidating a foreign-key constraint after a DDL change:
* Since we require that all collations share the same notion of
On 2019-12-21 09:01, Thomas Munro wrote:
I think this problem goes away if we commit the per-object collation
version patch set[1]. It drops the collversion column, and Julien's
recent versions handle pg_upgrade quite well, as long as a collation
by the same name exists in the target cluster.
On Thu, Jan 23, 2020 at 11:00 PM Tom Lane wrote:
Thank you for your time looking into this.
Here's a v7 patch, rebased over my recent hacking, and addressing
> most of the complaints I raised in <31691.1579648...@sss.pgh.pa.us>.
> However, I've got some new complaints now that I've looked
On 24.01.2020 12:09, Pavel Stehule wrote:
pá 24. 1. 2020 v 9:39 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 23.01.2020 23:47, Robert Haas wrote:
> On Sat, Jan 11, 2020 at 8:51 PM Tomas Vondra
> mailto:tomas.von...@2ndquadrant.com>> wrote:
## Sergiu Velescu (sergiu.vele...@endava.com):
> OnLogin/Logout.
> I want to log/audit each attempt to login (successful and/or not).
log_connections/log_disconnections
> Who/how long was logged in DB (who logged in out of business hours
> (maybe deny access)).
Use PAM authentication.
> Set
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
I've reviewed and verified this patch and IMHO, this is
pá 24. 1. 2020 v 10:08 odesílatel Sergiu Velescu
napsal:
> Hi,
>
>
>
> Could you please elaborate – what do you mean by “…you can do almost all
> things today by C extensions…” – does these extensions already exists or I
> have to develop it?
>
> If these extensions exists and developed by
pá 24. 1. 2020 v 9:39 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 23.01.2020 23:47, Robert Haas wrote:
> > On Sat, Jan 11, 2020 at 8:51 PM Tomas Vondra
> > wrote:
> >> I proposed just ignoring those new indexes because it seems much simpler
> >> than alternative
Hi,
Could you please elaborate – what do you mean by “…you can do almost all things
today by C extensions…” – does these extensions already exists or I have to
develop it?
If these extensions exists and developed by somebody else (not in PG core) then
nobody will install it where sensitive
Dear hackers,
I propose "non-volatile WAL buffer," a proof-of-concept new feature. It
enables WAL records to be durable without output to WAL segment files by
residing on persistent memory (PMEM) instead of DRAM. It improves database
performance by reducing copies of WAL and shortening the time
Hi,
Yes, please find below few examples.
OnLogin/Logout.
I want to log/audit each attempt to login (successful and/or not).
Who/how long was logged in DB (who logged in out of business hours (maybe deny
access)).
Set session variable based on username (or maybe IP address) - for example
DATE
On Thu, Jan 23, 2020 at 4:31 PM Amit Langote wrote:
> Now, the chances of such a big overhaul of how UPDATEs of inheritance
> trees are handled getting into PG 13 seem pretty thin even if I post
> the patch in few days, so perhaps it would make sense to get this
> patch in so that we can give
On 2019-12-20 01:30, Vik Fearing wrote:
On 16/12/2019 22:13, Tom Lane wrote:
That being the case, I'm not in favor of using up SQL syntax space for it
if we don't have to.
Do I understand correctly that you are advocating *against* using
standard SQL syntax for a feature that is defined by
On 23.01.2020 23:47, Robert Haas wrote:
On Sat, Jan 11, 2020 at 8:51 PM Tomas Vondra
wrote:
I proposed just ignoring those new indexes because it seems much simpler
than alternative solutions that I can think of, and it's not like those
other solutions don't have other issues.
+1.
For
On 2019-12-16 22:13, Tom Lane wrote:
Hm. Given that this involves a function-taking-and-returning-internal,
I think it's fairly silly to claim that it is implementing a SQL-standard
feature, or even a subset or related feature. Nor do I see a pathway
whereby this might end in a feature you
On 23.01.2020 19:28, 曾文旌(义从) wrote:
I'm trying to improve this part of the implementation in
global_temporary_table_v7-pg13.patch
Please check my patch and give me feedback.
Thanks
Wenjing
Below is my short review of the patch:
+ /*
+ * For global temp table only
+ * use
On 2019-12-16 19:53, Peter Eisentraut wrote:
SQL:2016 has a feature called polymorphic table functions (PTF) that
addresses this. The full PTF feature is much larger, so I just carved
out this particular piece of functionality. Here is a link to some
related information:
On 2020/01/24 16:56, Julien Rouhaud wrote:
On Fri, Jan 24, 2020 at 8:20 AM Fujii Masao wrote:
On 2020/01/24 15:38, Arthur Zakirov wrote:
On 2020/01/24 14:56, Michael Paquier wrote:
On Fri, Jan 24, 2020 at 01:28:29PM +0900, Arthur Zakirov wrote:
It is compiled and passes the tests. There
pá 24. 1. 2020 v 8:55 odesílatel Sergiu Velescu
napsal:
> Hi,
>
>
>
> Yes, please find below few examples.
>
>
>
> OnLogin/Logout.
>
> I want to log/audit each attempt to login (successful and/or not).
>
> Who/how long was logged in DB (who logged in out of business hours (maybe
> deny access)).
86 matches
Mail list logo
