On 23.08.2012 23:07, Alvaro Herrera wrote:
One problem with this is that I get this warning:
/pgsql/source/HEAD/contrib/pg_upgrade/exec.c: In function ‘s_exec_prog’:
/pgsql/source/HEAD/contrib/pg_upgrade/exec.c:96:2: warning: function might be
possible candidate for ‘gnu_printf’ format
On Fri, Aug 24, 2012 at 1:06 AM, Andrew Dunstan and...@dunslane.net wrote:
On 08/23/2012 02:44 PM, Andrew Dunstan wrote:
On 08/23/2012 01:58 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 08/23/2012 12:40 AM, Tom Lane wrote:
Anybody who wants to fix it is surely
On Thu, Aug 23, 2012 at 11:15:06PM -0400, Peter Eisentraut wrote:
On Thu, 2012-08-23 at 17:05 -0400, Bruce Momjian wrote:
On Thu, Aug 23, 2012 at 02:17:44AM -0400, Peter Eisentraut wrote:
The script analyze_new_cluster.sh output by pg_upgrade contains several
sleep calls (see
On 08/24/2012 12:42 PM, Amit Kapila wrote:
Isn't what you are telling explained in Returning Cursors section on below
link:
http://www.postgresql.org/docs/9.1/static/plpgsql-cursors.html
Yes, but nowhere in:
http://www.postgresql.org/docs/current/static/sql-fetch.html
and IMO not clearly
From: Craig Ringer [mailto:ring...@ringerc.id.au]
Sent: Friday, August 24, 2012 6:59 PM
On 08/24/2012 12:42 PM, Amit Kapila wrote:
Isn't what you are telling explained in Returning Cursors section on
below
link:
http://www.postgresql.org/docs/9.1/static/plpgsql-cursors.html
Yes, but nowhere
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 23.08.2012 23:07, Alvaro Herrera wrote:
One problem with this is that I get this warning:
/pgsql/source/HEAD/contrib/pg_upgrade/exec.c: In function âs_exec_progâ:
/pgsql/source/HEAD/contrib/pg_upgrade/exec.c:96:2: warning:
Magnus Hagander mag...@hagander.net writes:
On Fri, Aug 24, 2012 at 1:06 AM, Andrew Dunstan and...@dunslane.net wrote:
TBH I'd rather stick with the less invasive approach of the original patch
at this stage, and see about refactoring for 9.3.
+1.
While I haven't looked at the code
On Fri, Aug 24, 2012 at 10:08:58AM -0400, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 23.08.2012 23:07, Alvaro Herrera wrote:
One problem with this is that I get this warning:
/pgsql/source/HEAD/contrib/pg_upgrade/exec.c: In function ‘s_exec_prog’:
Andres Freund and...@2ndquadrant.com writes:
./pod/perl581delta.pod:
At startup Perl blocks the SIGFPE signal away since there isn't much
Perl can do about it. Previously this blocking was in effect also for
programs executed from within Perl. Now Perl restores the original
SIGFPE handling
On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
./pod/perl581delta.pod:
At startup Perl blocks the SIGFPE signal away since there isn't much
Perl can do about it. Previously this blocking was in effect also for
programs executed from
Bruce Momjian br...@momjian.us writes:
It sounds like it is suggestioning to use more specific attribute
decoration. This might be relevant:
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
-Wmissing-format-attribute
Warn about function pointers that
Actually it seems better to just get rid of the extra varargs function
and just have a single exec_prog. The extra NULL argument is not
troublesome enough, it seems. Updated version attached.
Again, win32 testing would be welcome. Sadly, buildfarm does not run
pg_upgrade's make check.
--
On 20.08.2012 00:31, Alexander Korotkov wrote:
On Thu, Aug 16, 2012 at 4:40 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 15.08.2012 11:34, Alexander Korotkov wrote:
Ok, we've to decide if we need standard histogram. In some cases it can
be used for more accurate
On 08/24/2012 10:58 AM, Andres Freund wrote:
On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
./pod/perl581delta.pod:
At startup Perl blocks the SIGFPE signal away since there isn't much
Perl can do about it. Previously this blocking was in
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Lastly, I simplified the added code in InitPostgres down to just a
bare assignment to XactIsoLevel. It doesn't seem worthwhile to
add all the cycles involved in SetConfigOption(), when we have no
desire to
Hi,
attached is a patch that adds support for random sampling in pgbench, when
it's executed with -l flag. You can do for example this:
$ pgbench -l -T 120 -R 1 db
and then only 1% of transactions will be written into the log file. If you
omit the tag, all the transactions are written (i.e.
Hi,
this patch adds support for aggregation of info written into the log.
Instead of info about each transaction, a summary for time intervals (with
custom length) is written into the log. All you need to do is add -A
seconds, e.g.
$ pgbench -T 3600 -A 10 -l db
which will produce log with
On Friday, August 24, 2012 05:09:18 PM Andrew Dunstan wrote:
On 08/24/2012 10:58 AM, Andres Freund wrote:
On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
./pod/perl581delta.pod:
At startup Perl blocks the SIGFPE signal away since there
On 24 Srpen 2012, 23:25, Tomas Vondra wrote:
Hi,
this patch adds support for aggregation of info written into the log.
Instead of info about each transaction, a summary for time intervals (with
custom length) is written into the log. All you need to do is add -A
seconds, e.g.
$ pgbench
On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
./pod/perl581delta.pod:
At startup Perl blocks the SIGFPE signal away since there isn't much
Perl can do about it. Previously this blocking was in effect also for
programs executed from
On Fri, Aug 24, 2012 at 4:10 PM, Andres Freund and...@2ndquadrant.com wrote:
We probably should workaround that bug anyway given that its a pretty trivial
DOS using only a trusted language and it will take quite some time to push out
newer perl versions even if that bug gets fixed.
Doing a
On Saturday, August 25, 2012 12:15:00 AM Alex Hunsaker wrote:
On Fri, Aug 24, 2012 at 4:10 PM, Andres Freund and...@2ndquadrant.com
wrote:
We probably should workaround that bug anyway given that its a pretty
trivial DOS using only a trusted language and it will take quite some
time to
Hi,
attached is a patch that improves performance when dropping multiple
tables within a transaction. Instead of scanning the shared buffers for
each table separately, the patch removes this and evicts all the tables
in a single pass through shared buffers.
Our system creates a lot of working
On Wed, Aug 22, 2012 at 12:59 PM, Jeff Davis davis.jeff...@gmail.com wrote:
On Tue, 2012-08-21 at 10:41 -0400, Robert Haas wrote:
The thing to keep in mind here is that EVERY property of a foreign
table is subject to change at any arbitrary point in time, without our
knowledge. ... Why should
On Wed, Aug 22, 2012 at 5:31 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Patch v19 contains some tweaks. Most notably,
1. if an Xid requests a lock A, and then a lock B which is stronger than
A, then record only lock B and forget lock A. This is important for
performance, because
Andres Freund and...@2ndquadrant.com writes:
Doing a pqsignal(SIGFPE, FloatExceptionHandler) after PERL_SYS_INIT3 seems to
work. Is that acceptable?
Surely that's breaking perl's expectations, to more or less the same
degree they're breaking ours?
regards, tom lane
--
On Fri, 2012-08-24 at 10:08 -0400, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 23.08.2012 23:07, Alvaro Herrera wrote:
One problem with this is that I get this warning:
/pgsql/source/HEAD/contrib/pg_upgrade/exec.c: In function ‘s_exec_prog’:
On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Doing a pqsignal(SIGFPE, FloatExceptionHandler) after PERL_SYS_INIT3
seems to work. Is that acceptable?
Surely that's breaking perl's expectations, to more or less the same
degree they're
28 matches
Mail list logo