On Sun, Mar 15, 2015 at 2:27 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2015-03-12 15:52:02 +0100, Andres Freund wrote:
/*
* Override any inconsistent requests. Not that this is a change
* of behaviour in 9.5; prior to this we simply ignored a request
*
Hi,
On 2015-03-15 17:59:39 +0200, Itai wrote:
Thanks for the quick response!! :)
But I don't get it... isn't:
if (SRF_IS_FIRSTCALL()){
}
the iterator one time
initialization block where I setup the data to be iterated
upon?
Can you please elaborate on how should I fix this? I'm
On 2014-12-08 02:18:11 +0100, Petr Jelinek wrote:
On 08/12/14 02:06, Petr Jelinek wrote:
On 08/12/14 02:03, Michael Paquier wrote:
On Mon, Dec 8, 2014 at 9:59 AM, Petr Jelinek p...@2ndquadrant.com
wrote:
Ok this patch does that, along with the rename to
recovery_target_action and
addition
On 2015-03-15 14:51:46 +0100, Magnus Hagander wrote:
On Sun, Mar 15, 2015 at 2:27 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2015-03-12 15:52:02 +0100, Andres Freund wrote:
/*
* Override any inconsistent requests. Not that this is a change
* of behaviour
Pavel Stehule pavel.steh...@gmail.com writes:
other variant, I hope better than previous. We can introduce new long
option --strict. With this active option, every pattern specified by -t
option have to have identifies exactly only one table. It can be used for
any other should to exists
Hi
I'm attempting to program a simple SRF function but it constantly crashes
(details and code below).
Any idea why?
Thanks!
-Itai
-
Environment
-
Ubunto: 14.04.2
Itai it...@outlook.com writes:
I'm attempting to program a simple SRF function but it constantly crashes
(details and code below).
Any idea why?
Looks like you're pallocing some stuff in the calling context (ie, a
short-lived context) during the first execution and expecting it to
still be
On 15/03/15 14:51, Magnus Hagander wrote:
On Sun, Mar 15, 2015 at 2:27 PM, Andres Freund and...@2ndquadrant.com
mailto:and...@2ndquadrant.com wrote:
On 2015-03-12 15:52:02 +0100, Andres Freund wrote:
/*
* Override any inconsistent requests. Not that this is a
On 2015-03-02 18:45:18 +0100, Andres Freund wrote:
On 2015-03-02 19:23:56 +0200, Heikki Linnakangas wrote:
Pass the prepared XID as yet another argument to XactEmitCommitRecord, and
have XactEmitCommitRecord emit the xl_xact_commit_prepared part of the
record too. It might even make sense
Thanks for the quick response!! :)
But I don't get it... isn't:
if (SRF_IS_FIRSTCALL()){
}
the iterator one time
initialization block where I setup the data to be iterated
upon?
Can you please elaborate on how should I fix this? I'm probably missing
something basic...
Date: Sun, 15 Mar 2015
Hi,
On 2015-03-03 11:04:30 -0800, Josh Berkus wrote:
Attached is version D, which incorporates the above two changes, but NOT
a general unit comment cleanup of postgresql.conf, which needs to be an
entirely different patch.
Pushed!
Greetings,
Andres Freund
--
Andres Freund
Hi,
On 2014-12-08 02:18:11 +0100, Petr Jelinek wrote:
...except for the removal of pause_at_recovery_target it seems, so I
attached just that
Pushed.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training
Hi,
On 2015-03-15 17:40:11 +0200, Itai wrote:
I'm attempting to program a simple SRF function but it constantly crashes
(details and code below).
Any idea why?
if (SRF_IS_FIRSTCALL())
{
length = 4000;
base_num = 120300;
list = (NumberList *)palloc(sizeof(NumberList));
Fantastic! That solved this problem.
However I still get a crash if I change:
is_even to bool num-is_even = ((base_num + i) % 2 == 0) ? true : false;
retvals[1] = BoolGetDatum(list-pp_numbers[call_cntr]-is_even); CREATE OR
REPLACE FUNCTION pg_srf(OUT value integer, OUT is_even bit)
On Sun, Mar 15, 2015 at 3:16 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2015-03-15 14:51:46 +0100, Magnus Hagander wrote:
On Sun, Mar 15, 2015 at 2:27 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2015-03-12 15:52:02 +0100, Andres Freund wrote:
/*
*
On 2015-03-12 15:52:02 +0100, Andres Freund wrote:
/*
* Override any inconsistent requests. Not that this is a change
* of behaviour in 9.5; prior to this we simply ignored a request
* to pause if hot_standby = off, which was surprising behaviour.
*/
On 2015-03-15 16:30:16 +0100, Andres Freund wrote:
The attached patch does pretty much what you suggested above and tries
to address all the point previously made. I plan to push this fairly
soon; unless somebody has further input.
Pushed, after fixing two typos in decode.c I introduced while
Sun, 15 Mar 2015 11:22:01 +0100 (CET)
Hello Tomas,
attached is a patch implementing merging of pgbench logs. These logs are
written by each thread, so with N threads you get N files with names
pgbench_log.PID
pgbench_log.PID.1
...
pgbench_log.PID.N
Before analyzing these logs,
On Thu, Mar 12, 2015 at 11:21:37AM -0400, Robert Haas wrote:
On Thu, Feb 19, 2015 at 1:19 AM, Noah Misch n...@leadboat.com wrote:
Rereading my previous message, I failed to make the bottom line clear: I
recommend marking eqsel etc. PROPARALLEL_UNSAFE but *not* checking an
estimator's
On Sun, Mar 15, 2015 at 1:58 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm getting rather tired of reading these warning messages in OS X builds:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
file: libpgport.a(dirmod.o) has no symbols
On 15/03/2015 04:34, Andreas Karlsson wrote:
On 03/15/2015 04:25 AM, Andreas Karlsson wrote:
Nice. You will also want to apply the attached patch which fixes support
for the --no-tablespaces flag.
Just realized that --no-tablespaces need to be fixed for pg_restore too.
Indeed, after taking
Firstly, the fact that pgbench produces one file per thread is awkward.
I agree, but I think it is due to the multi process thread emulation: if
you have real threads, you can do a simple fprintf, possibly with some
mutex, and you're done. There is really nothing to do to implement this
Thanks Tom.
Assuming the SRF had a parameter, would this be a correct approach
(considering the iterative model) to bail-out early?
if (SRF_IS_FIRSTCALL())
{
int i;
if (get_call_result_type(fcinfo, NULL, funcctx-tuple_desc) !=
TYPEFUNC_COMPOSITE)
{
Buildfarm member brolga seems unhappy with my commit 91f4a5a that
restricted port/dirmod.c to being built only on Windows. Evidently
we need to build it when $PORTNAME = cygwin as well, which is fine;
but I'm a bit astonished that none of the other stuff inserted in the
# Win32 support stanza
On 14/03/15 04:17, Andreas Karlsson wrote:
On 03/13/2015 10:22 PM, Peter Geoghegan wrote:
On Thu, Mar 12, 2015 at 6:23 PM, Andreas Karlsson andr...@proxel.se
wrote:
/*
* Integer data types use Numeric accumulators to share code and
avoid risk
* of overflow. To speed up aggregation 128-bit
On 15.3.2015 11:22, Fabien COELHO wrote:
I've looked at the patch. Although I think that such a feature is
somehow desirable... I have two issues with it: ISTM that
(1) it does not belong to pgbench as such
(2) even if, the implementation is not right
About (1):
I think that this
Hi,
On 2015-03-15 14:03:08 -0400, Tom Lane wrote:
Buildfarm member brolga seems unhappy with my commit 91f4a5a that
restricted port/dirmod.c to being built only on Windows. Evidently
we need to build it when $PORTNAME = cygwin as well, which is fine;
but I'm a bit astonished that none of the
On 15 March 2015 at 14:16, Andres Freund and...@2ndquadrant.com wrote:
Personally I think we just should change the default to 'shutdown' for
all cases. That makes documentation and behaviour less surprising. And
makes experimenting less dangerous, since you can just start again.
We need to
On 2015-03-15 20:10:49 +, Simon Riggs wrote:
On 15 March 2015 at 14:16, Andres Freund and...@2ndquadrant.com wrote:
Personally I think we just should change the default to 'shutdown' for
all cases. That makes documentation and behaviour less surprising. And
makes experimenting less
On 2015/03/13 11:46, Etsuro Fujita wrote:
BTW, what do you think about opening/locking foreign tables selected for
update at InitPlan, which the original patch does? As I mentioned in
[1], ISTM that ExecOpenScanRelation called from ExecInitForeignScan is
assuming that.
[1]
On 15.3.2015 20:35, Fabien COELHO wrote:
Firstly, the fact that pgbench produces one file per thread is awkward.
I agree, but I think it is due to the multi process thread emulation: if
you have real threads, you can do a simple fprintf, possibly with some
mutex, and you're done. There is
On 03/15/2015 09:47 PM, Petr Jelinek wrote:
It's almost the same thing as you wrote but the 128 bit and 64 bit
optimizations are put on the same level of optimized routines.
But this is nitpicking at this point, I am happy with the patch as it
stands right now.
Do you think it is ready for
On Mon, Mar 16, 2015 at 7:38 AM, Andres Freund wrote:
On 2015-03-15 20:10:49 +, Simon Riggs wrote:
On 15 March 2015 at 14:16, Andres Freund wrote:
Personally I think we just should change the default to 'shutdown' for
all cases. That makes documentation and behaviour less surprising.
On 03/15/2015 02:12 PM, Andres Freund wrote:
Hi,
On 2015-03-15 14:03:08 -0400, Tom Lane wrote:
Buildfarm member brolga seems unhappy with my commit 91f4a5a that
restricted port/dirmod.c to being built only on Windows. Evidently
we need to build it when $PORTNAME = cygwin as well, which is
On 03/14/2015 06:04 PM, Tom Lane wrote:
Given the rather hostile response I got to
http://www.postgresql.org/message-id/4146.1425872...@sss.pgh.pa.us
I was not planning to bring this topic up again until 9.6 development
starts. However, as I said in that thread, this work is getting done now
Would a parameter to auto terminate long running transactions be a better
solution? Terminating the long running transaction would allow for the normal
vacuuming process to cleanup the deleted records thus avoiding database bloat
without introducing new semantics to Postgres's MVCC. I would
On 16/03/15 13:04, Rui DeSousa wrote:
Would a parameter to auto terminate long running transactions be a better
solution? Terminating the long running transaction would allow for the normal
vacuuming process to cleanup the deleted records thus avoiding database bloat
without introducing new
On Wed, Mar 11, 2015 at 2:23 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 03/11/2015 05:01 AM, Amit Kapila wrote:
Can't that happen if the source database (new-master) haven't
received all of the data from target database (old-master) at the
time of promotion?
If yes, then source
38 matches
Mail list logo
