On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote:
> Andres Freund 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?
On Fri, 2012-08-24 at 10:08 -0400, Tom Lane wrote:
> Heikki Linnakangas 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_upg
Andres Freund 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
--
Sent via pgsql-hack
On Wed, Aug 22, 2012 at 5:31 PM, Alvaro Herrera
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 EvalPlanQual obtains Fo
On Wed, Aug 22, 2012 at 12:59 PM, Jeff Davis 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 CHECK constraint
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 ta
On Saturday, August 25, 2012 12:15:00 AM Alex Hunsaker wrote:
> On Fri, Aug 24, 2012 at 4:10 PM, Andres Freund
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
On Fri, Aug 24, 2012 at 4:10 PM, Andres Freund 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 pqsignal(SIGFPE, Fl
On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote:
> Andres Freund 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. No
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.
>
> $
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 writes:
> >>> ./pod/perl581delta.pod:
> >>> At startup Perl blocks the SIGFPE signal away since there isn't much
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 10
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.
"Kevin Grittner" writes:
> Tom Lane 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 change the GUC permanently. (I thi
On 08/24/2012 10:58 AM, Andres Freund wrote:
On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote:
Andres Freund 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
program
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 e
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".
--
Ál
Bruce Momjian 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 might be candid
On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote:
> Andres Freund 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. No
Andres Freund 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 routine, whatever
On Fri, Aug 24, 2012 at 10:08:58AM -0400, Tom Lane wrote:
> Heikki Linnakangas 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
Magnus Hagander writes:
> On Fri, Aug 24, 2012 at 1:06 AM, Andrew Dunstan 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 specifically, these areas can be
> quite
Heikki Linnakangas 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: function might
>> be possible
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 no
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 e
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 co
On Fri, Aug 24, 2012 at 1:06 AM, Andrew Dunstan wrote:
>
> On 08/23/2012 02:44 PM, Andrew Dunstan wrote:
>>
>>
>> On 08/23/2012 01:58 PM, Tom Lane wrote:
>>>
>>> Andrew Dunstan writes:
On 08/23/2012 12:40 AM, Tom Lane wrote:
>
> Anybody who wants to fix it is surely welcome to,
27 matches
Mail list logo
