Hi
Here is an initial version of an auditing extension for Postgres to
generate log output suitable for compiling a comprehensive audit trail
of database operations.
Why auditing?
Various laws and regulations (HIPAA, PCI DSS, EU Data Protection
Directive etc.) as well as internal business requ
On 02 May 2014 10:00, Amit Longote Wrote:
> > I
> > s the following behavior perceived fix-worthy?
> >
> >
> > -- note the
> > '
> > 1's
> > in the output
> > s
> >
> > po
> > stgres=# CREATE TABLE test AS SELECT;
> > SELECT 1
> >
> > postgres=# insert into test select;
> > INSERT 0 1
> >
>
> Or
On Fri, May 2, 2014 at 2:06 PM, Michael Paquier
wrote:
> Not that I know of. I am not sure that enforcing query rewrite on the
> server side is a good idea at this may trap your applications and have
> them face unexpected behaviors.
Note as well that there is a hook *before* the rewriter and *aft
On Fri, May 2, 2014 at 1:37 PM, Rajmohan C wrote:
> Hi,
>
>I want to know is there a way to use a hook to modify the input query
> before Postgresql parses and builds the parse tree for the query.
Not that I know of. I am not sure that enforcing query rewrite on the
server side is a good idea
On Fri, May 2, 2014 at 10:07 AM, Rajmohan C wrote:
> Hi,
>
>I want to know is there a way to use a hook to modify the input query
> before Postgresql parses and builds the parse tree for the query.
>
Uh...the rewriter?
--
Regards,
Atri
*l'apprenant*
Hi,
I want to know is there a way to use a hook to modify the input query
before Postgresql parses and builds the parse tree for the query.
On Fri, May 2, 2014 at 12:57 PM, Amit Langote wrote:
> I
> s the following behavior perceived fix-worthy?
>
>
> -- note the
> '
> 1's
> in the output
> s
>
> po
> stgres=# CREATE TABLE test AS SELECT;
> SELECT 1
>
> postgres=# insert into test select;
> INSERT 0 1
>
Or maybe, it just means 1 'nu
Hi,
I
s the following behavior perceived fix-worthy?
-- note the
'
1's
in the output
s
po
stgres=# CREATE TABLE test AS SELECT;
SELECT 1
postgres=# insert into test select;
INSERT 0 1
My guess why this happens is because changes made in the commit in
$SUBJECT only pertain to fixi
Noah Misch writes:
> On Thu, May 01, 2014 at 08:44:46PM -0400, Tom Lane wrote:
>> You're only considering one aspect of the problem. Yeah, you might not
>> get duplicated output unless system() prints something before exec(),
>> but we would also like to have causality: that is, whatever we sent
Peter Eisentraut writes:
> I have been working on making the DocBook XML output valid. The first
> part was bb4eefe7bf518e42c73797ea37b033a5d8a8e70a, I now have the rest
> ready, but I'll spare you the mostly mechanical 200kB patch for now. In
> addition, I'd like to add the attached patch with
I have been working on making the DocBook XML output valid. The first
part was bb4eefe7bf518e42c73797ea37b033a5d8a8e70a, I now have the rest
ready, but I'll spare you the mostly mechanical 200kB patch for now. In
addition, I'd like to add the attached patch with an xmllint call to
make sure thing
Alvaro Herrera writes:
> Tom Lane wrote:
>> The patch is certainly too invasive to consider back-patching into
>> 9.3, though.
> I feel unsure about this. I agree the patch is quite invasive. Leaving
> 9.3 in a broken state seems problematic. In particular I'm not sure
> what would Debian do a
Tom Lane wrote:
> I wrote:
> > How about we change common/relpath.[hc] to export a single version of
> > relpath() that takes its arguments as separate plain OIDs, and then
> > make the other versions wrappers that are only declared in some
> > backend header? The wrappers could possibly be macros
On Thu, May 01, 2014 at 08:44:46PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Thu, May 01, 2014 at 05:59:08PM -0400, Tom Lane wrote:
> >> However ... after looking around I notice that fflush(NULL) is already
> >> being used in parallel pg_dump and pg_upgrade; and at least in the latter
>
Noah Misch writes:
> On Thu, May 01, 2014 at 05:59:08PM -0400, Tom Lane wrote:
>> However ... after looking around I notice that fflush(NULL) is already
>> being used in parallel pg_dump and pg_upgrade; and at least in the latter
>> case I'm afraid to change that because it looks like there are pr
On Thu, May 01, 2014 at 05:59:08PM -0400, Tom Lane wrote:
> I wrote:
> > Noah Misch writes:
> >> Modern systems have other fflush(NULL) problems:
>
> >> http://www.nntp.perl.org/group/perl.perl5.porters/2013/09/msg207692.html
> >> http://perl5.git.perl.org/metaconfig.git/blob/master:/U/perl/fflus
On Thu, May 1, 2014 at 5:59 PM, Tom Lane wrote:
> I wrote:
>> Noah Misch writes:
>>> On Thu, May 01, 2014 at 12:13:28PM -0400, Tom Lane wrote:
Is there any reason not to change this to just fflush(NULL)? We dropped
support for SunOS 4.1 quite some time ago ...
>
>>> Modern systems have
Andres Freund writes:
> There's another problematic case:
> http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=olinguito&dt=2014-05-01%2021%3A22%3A43&stg=config
> /usr/local/lib/libxml2.so.14.0: warning: strcpy() is almost always misused,
> please use strlcpy()
> /usr/local/lib/libxml2
I wrote:
> Noah Misch writes:
>> On Thu, May 01, 2014 at 12:13:28PM -0400, Tom Lane wrote:
>>> Is there any reason not to change this to just fflush(NULL)? We dropped
>>> support for SunOS 4.1 quite some time ago ...
>> Modern systems have other fflush(NULL) problems:
>> http://www.nntp.perl.or
On 2014-05-01 16:17:17 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Patch attached.
>
> Committed with minor comment-smithing.
Thanks.
There's another problematic case:
http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=olinguito&dt=2014-05-01%2021%3A22%3A43&stg=config
configur
Andres Freund writes:
> Patch attached.
Committed with minor comment-smithing.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I wrote:
> I believe I understand what's going on here, and it's not quite as
> exciting as it first appears. The issue is that we are failing to
> honor the "toasting goes only one level deep" rule in the specific
> case of arrays of composite type. So while it's definitely a nasty
> bug, it aff
Noah Misch writes:
> On Thu, May 01, 2014 at 12:13:28PM -0400, Tom Lane wrote:
>> Is there any reason not to change this to just fflush(NULL)? We dropped
>> support for SunOS 4.1 quite some time ago ...
> Modern systems have other fflush(NULL) problems:
> http://www.nntp.perl.org/group/perl.per
On 2014-05-01 10:10:46 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I still think we really need to fix this. I have three possible
> > solutions:
>
> > a) Add an external file (in the source tree) that's included in the
> >configure test.
> > b) Have a compiler specific override and sp
On Thu, May 01, 2014 at 12:13:28PM -0400, Tom Lane wrote:
> fork_process.c quoth:
>
> /*
> * Flush stdio channels just before fork, to avoid double-output problems.
> * Ideally we'd use fflush(NULL) here, but there are still a few non-ANSI
> * stdio libraries out there (like Sun
fork_process.c quoth:
/*
* Flush stdio channels just before fork, to avoid double-output problems.
* Ideally we'd use fflush(NULL) here, but there are still a few non-ANSI
* stdio libraries out there (like SunOS 4.1.x) that coredump if we do.
* Presently stdout and stderr a
On Thu, May 1, 2014 at 12:33:51PM +1200, Gavin Flower wrote:
> On 01/05/14 12:04, Bruce Momjian wrote:
> >On Thu, May 1, 2014 at 08:27:49AM +1200, Gavin Flower wrote:
> >>On 01/05/14 02:51, Bruce Momjian wrote:
> >>>The table of contents for pg_restore -l shows the time the archive was
> >>>made
Kevin Grittner wrote:
> each connection caused to be held in cache the last page at each
> level of the index.
Apologies for ambiguous terminology there.
To be clear: the most recently accessed page at each level of the index.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise P
Jim Nasby wrote:
> In our case this could maybe be handled by simply not
> incrementing counts when there's no eviction... but I'm more a
> fan of separate polls/clocks, because that means you can do
> things like a LFU for active and an LRU for inactive.
I have hesitated to mention some benchma
Le 01/05/2014 04:56, Robert Haas a écrit :
> On Tue, Apr 29, 2014 at 5:39 AM, Thomas Reiss wrote:
>> You can find attached a small patch to fix the pg_replication_slots
>> documentation. The slot_type and plugin are not in the appropriate
>> order, slot_name and plugin have a wrong type and xmin a
On 2014-05-01 10:10:46 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I still think we really need to fix this. I have three possible
> > solutions:
>
> > a) Add an external file (in the source tree) that's included in the
> >configure test.
> > b) Have a compiler specific override and sp
Andres Freund writes:
> I still think we really need to fix this. I have three possible
> solutions:
> a) Add an external file (in the source tree) that's included in the
>configure test.
> b) Have a compiler specific override and specify USE_INLINE there.
> c) Drop the requirement of quiet i
Andres Freund writes:
> On 2014-05-01 13:55:46 +0100, Greg Stark wrote:
>> Is there some use case for that I'm not seeing?
> Can be useful if different opclasses are used for the individual
> columns. Other than that I am not seing much use.
Yeah. This is more plausible for the advanced index t
On Fri, Sep 13, 2013 at 5:31 PM, Robert Haas wrote:
> On Thu, Sep 12, 2013 at 11:33 AM, Magnus Hagander wrote:
>> Well, undocumented and OpenSSL tend to go hand in hand a lot. Or,
>> well, it might be documented, but not in a useful way. I wouldn't
>> count on it.
>
> The OpenSSL code is some of
Hi,
On 2014-04-03 12:47:00 +0200, Andres Freund wrote:
> The current quiet inline test doesn't work for clang. As e.g. evidenced in
> http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=gull&dt=2014-04-03%2007%3A49%3A26&stg=configure
> configure thinks it's not quiet.
>
> Which means tha
=?UTF-8?Q?Filip_Rembia=C5=82kowski?= writes:
> I was (as a long time Pg user) dead sure that psql really sometimes
> cares about the number of plus signs that you add to meta-command
No, it never has done so AFAIK.
> Can't we have higher levels of "verbosiness"?
I think that for most commands,
Hi,
On 2014-05-01 13:55:46 +0100, Greg Stark wrote:
> Is there some use case for that I'm not seeing?
>
> postgres=***# create index tti on
> tt(i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i);
> CREATE INDEX
> Time: 15.891 ms
Can be useful if different opclasses are used for th
Is there some use case for that I'm not seeing?
postgres=***# create index tti on
tt(i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i);
CREATE INDEX
Time: 15.891 ms
postgres=***# commit;
COMMIT
Time: 11.191 ms
postgres=# \d tt
Table "public.tt"
++-+-
38 matches
Mail list logo
