On Wed, Apr 16, 2025 at 03:53:53PM -0400, Ron Johnson wrote:
> On Wed, Apr 16, 2025 at 3:42 PM Nico Williams wrote:
> > I would care about what happened. To know what happened I'd have to see
> > either only audit logs for committed transactions, or also see the
> > COMMIT and ROLLBACK statements
On Wed, 2025-04-16 at 17:06 +0200, Dominique Devienne wrote:
> So in a way, you guys are saying one should never REVOKE CONNECT ON
> DATABASE FROM PUBLIC?
No, not at all.
> All my DBs are not PUBLIC-accessible.
> And inside my DBs, I try to revoke everything from PUBLIC
> (USAGE ON TYPES, EXECUTE
On Wed, Apr 16, 2025 at 3:42 PM Nico Williams wrote:
> On Wed, Apr 16, 2025 at 02:43:59PM -0400, Ron Johnson wrote:
> > You'll have to bring that up with the PgAudit maintainer. Note, though,
> > that the purpose of PgAudit is not "recreate the database from audit
> logs";
> > it's "what Auditor
On Wed, Apr 16, 2025 at 02:43:59PM -0400, Ron Johnson wrote:
> You'll have to bring that up with the PgAudit maintainer. Note, though,
> that the purpose of PgAudit is not "recreate the database from audit logs";
> it's "what Auditors care about". In my experience, auditors do not care
> about CO
On 4/16/25 09:25, Anton Shepelev wrote:
Adrian Klaver:
Anton Shepelev:
This shows a setting of 'on' not the 'off' you mention in
the first paragraph.
I beg pardon. Having no immediate access to the system in
question, I confess to having mocked up those results from
an analogous query on
On Wed, Apr 16, 2025 at 3:15 PM Achilleas Mantzios <
a.mantz...@cloud.gatewaynet.com> wrote:
> On 16/4/25 21:43, Ron Johnson wrote:
>
>
> You'll have to bring that up with the PgAudit maintainer. Note, though,
> that the purpose of PgAudit is not "recreate the database from audit logs";
> it's "w
On 16/4/25 21:43, Ron Johnson wrote:
You'll have to bring that up with the PgAudit maintainer. Note,
though, that the purpose of PgAudit is not "recreate the database from
audit logs"; it's "what Auditors care about". In my experience,
auditors do not care about COMMIT and ROLLBACK statement
On Tue, Apr 15, 2025 at 05:28:40PM +0200, Karsten Hilbert wrote:
> Am Tue, Apr 15, 2025 at 11:26:35AM -0400 schrieb Osmel Brito-Bigott:
>
> > I'm not collecting emails in the survey
>
> Don't get me wrong, I am not questioning your good faith or intent.
Agreed. The email said:
The surv
You'll have to bring that up with the PgAudit maintainer. Note, though,
that the purpose of PgAudit is not "recreate the database from audit logs";
it's "what Auditors care about". In my experience, auditors do not care
about COMMIT and ROLLBACK statements.
On Wed, Apr 16, 2025 at 1:35 PM Achill
On 16/4/25 15:36, Ron Johnson wrote:
pgaudit is statement-level, not transaction-level; that's its nature.
This is the same as log_statement.
ok, but log_statement prints ROLLBACKs/COMMITs, but pgaudit not.
On Wed, Apr 16, 2025 at 5:10 AM Achilleas Mantzios - cloud
wrote:
On 4/15/2
"David G. Johnston" writes:
> But feel free to work out a design and add it to the ToDo list for the v4
> protocol. The use case seems reasonable and doable (on the basis of the
> replication protocol works).
No, the replication protocol isn't a precedent. Physical replication
needn't connect t
On Wed, Apr 16, 2025 at 8:07 AM Dominique Devienne
wrote:
> On Wed, Apr 16, 2025 at 4:39 PM Tom Lane wrote:
> > Laurenz Albe writes:
> > > On Wed, 2025-04-16 at 10:09 +0200, Dominique Devienne wrote:
>
> So in a way, you guys are saying one should never REVOKE CONNECT ON
> DATABASE FROM PUBLIC?
On 4/16/25 02:27, Anton Shepelev wrote:
Hello, all.
I have a Postgres sever with the 'track_counts' setting
stuck in 'off'. I cannot seem to enable it with either of
a. ALTER SYSTEM,
b. ALTER DATABASE,
c. ALTER USER,
d. or plain SET.
pg_settings shows:
name| track_counts
On Wed, Apr 16, 2025 at 4:39 PM Tom Lane wrote:
> Laurenz Albe writes:
> > On Wed, 2025-04-16 at 10:09 +0200, Dominique Devienne wrote:
So in a way, you guys are saying one should never REVOKE CONNECT ON
DATABASE FROM PUBLIC?
All my DBs are not PUBLIC-accessible.
And inside my DBs, I try to rev
> On 16 Apr 2025, at 16:53, Tom Lane wrote:
>
> Anton Shepelev writes:
>> pg_settings shows:
>
>> name| track_counts
>> setting | on
>> source | override
>
>> What does 'override' mean in the 'source' column? How can I
>> find where in the system this setting is overridden?
>
> I am
Anton Shepelev writes:
> pg_settings shows:
> name| track_counts
> setting | on
> source | override
> What does 'override' mean in the 'source' column? How can I
> find where in the system this setting is overridden?
I am fairly certain that there is nothing in core Postgres that
wo
Laurenz Albe writes:
> On Wed, 2025-04-16 at 10:09 +0200, Dominique Devienne wrote:
>> Authentication is cluster-wide, not DB specific, so I'd welcome a way to
>> connect
>> to the cluster, not a specific DB, and introspect shared-objects,
>> including databases
>> I'm allowed to connect to, whic
pgaudit is statement-level, not transaction-level; that's its nature. This
is the same as log_statement.
On Wed, Apr 16, 2025 at 5:10 AM Achilleas Mantzios - cloud <
a.mantz...@cloud.gatewaynet.com> wrote:
> On 4/15/25 12:14, KENAN ÇİFTÇİ wrote:
>
> Hi,
>
> You can use pgaudit and pgauditlogtofi
On Wed, 2025-04-16 at 10:09 +0200, Dominique Devienne wrote:
> On Wed, Apr 16, 2025 at 9:32 AM Laurenz Albe wrote:
> > On Tue, 2025-04-15 at 17:24 -0700, Adrian Klaver wrote:
> > But then you fortunately cannot drop all databases, because you cannot
> > drop the database you are connected to.
> >
Hello, all.
I have a Postgres sever with the 'track_counts' setting
stuck in 'off'. I cannot seem to enable it with either of
a. ALTER SYSTEM,
b. ALTER DATABASE,
c. ALTER USER,
d. or plain SET.
pg_settings shows:
name| track_counts
setting | on
source | override
What does 'o
On 4/15/25 12:14, KENAN ÇİFTÇİ wrote:
Hi,
You can use pgaudit and pgauditlogtofile extension
(https://github.com/fmbiete/pgauditlogtofile) together to write audit
logs in a separate file.
One issue we have with pgaudit is that it prints AUDIT records even if
the xaction gets rollbacked, how
On Wed, Apr 16, 2025 at 9:32 AM Laurenz Albe wrote:
> On Tue, 2025-04-15 at 17:24 -0700, Adrian Klaver wrote:
> But then you fortunately cannot drop all databases, because you cannot
> drop the database you are connected to.
>
> Still, a cluster that is missing "postgres" will give beginners troub
On Tue, 2025-04-15 at 17:24 -0700, Adrian Klaver wrote:
> I know I can use --template=template with createdb, but that still means
> there has to be a database existing in the initial cluster to use as a
> template. You can't get around that fact.
Right.
But then you fortunately cannot drop all
23 matches
Mail list logo
