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,
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 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
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
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
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
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
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 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
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
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
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
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
"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
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 10
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
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 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 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 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
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 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
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
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 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
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?
27 matches
Mail list logo
