On 18/11/19 9:56 μ.μ., Dave Hughes wrote:
Hello,
I'm using PostgreSQL 10.5 on Linux (RHEL). I'm new to administering PostgreSQL and recently installed pgaudit. I believe I have it installed correctly and wanted to start playing with it to see
how exactly it works.
So while walking through a
On Mon, 18 Nov 2019 at 22:24, Peter J. Holzer wrote:
>
> On 2019-11-18 12:24:40 +, Geoff Winkless wrote:
> > On Mon, 18 Nov 2019 at 11:46, Michael Paquier wrote:
> > > On Mon, Nov 18, 2019 at 10:27:24AM +0100, Josef Šimánek wrote:
> > > > This is clear once you understand what does it mean. I
Thanks for the response! I realized I didn't have the default logging
turned on. I needed to edit the postgresql.conf file to enable
log_destination = 'csvlog' and logging_collector = on. Once I did that I
can now see the audit file.
On Tue, Nov 19, 2019 at 4:31 AM Achilleas Mantzios <
ach...@m
Hello,
I'm using PostgreSQL 10.5 on Linux (RHEL). I recently installed pgAudit
and was trying to configure it to capture DLL statements.
1) The first thing I tried was to edit the postgresql.conf file directly.
I didn't see any commented out default entries to edit, so near where I
have the entri
Hello Dave,
What I can see is you missed to include pgAudit extension in
shared_preload_libraries parameter (*shared_preload_libraries='pgaudit'*).
Thanks
Rajni
On Wed, Nov 20, 2019 at 7:39 AM Dave Hughes wrote:
> Hello,
> I'm using PostgreSQL 10.5 on Linux (RHEL). I recently installed pgAudit
Hello,
What is the best way to dump/restore the entire database except couple of
largest tables, what is the best way to do it on PostgreSQL 9.4.1 on
x86_64-unknown-linux-gnu?
Thank you
On 11/19/19 4:06 PM, Julie Nishimura wrote:
Hello,
What is the best way to dump/restore the entire database except couple
of largest tables, what is the best way to do it on PostgreSQL 9.4.1 on
x86_64-unknown-linux-gnu?
https://www.postgresql.org/docs/11/app-pgdump.html
-T table
--exclude-ta
I am presently running on a Ubuntu 18.04 instance, and as you know
Debian/Ubuntu have upgraded to version 12. i have not completed the
upgrade yet, so I am in the situation of still having a version 11 server,
attaching from vversion 12 psql.
I was troubleshooting something a few minutes ago, a
On 11/19/19 4:32 PM, stan wrote:
I am presently running on a Ubuntu 18.04 instance, and as you know
Debian/Ubuntu have upgraded to version 12. i have not completed the
upgrade yet, so I am in the situation of still having a version 11 server,
attaching from vversion 12 psql.
I was troubleshoot
On Tue, Nov 19, 2019 at 11:37:04AM +, Geoff Winkless wrote:
> It's bad enough that you have the inconsistency that REINDEX VERBOSE
> requires parentheses while the more recent REINDEX CONCURRENTLY does
> not (presumably to match the syntax of CREATE INDEX CONCURRENTLY),
> without insisting that
On Wed, Oct 30, 2019 at 12:13 AM Thomas Munro wrote:
> On Tue, Oct 29, 2019 at 9:23 PM ZhenHua Cai wrote:
> > No, it doesn't call any in-core code.
>
> I wondered if this could be coming from the new code in
> src/port/pg_p{read,write}.c. ERROR_HANDLE_EOF is a documented
> GetLastError() return
Hello,
I am doing a query to fetch about 1000 records in one time. But the query
seems very slow, like "mission impossible".
I am very confident that these records should be fit into
my shared_buffers settings(20G), and my query is totally on my index,
which is this big:(19M x 100 partitio
12 matches
Mail list logo
