Simon Riggs wrote:
> On Sun, 2010-01-17 at 22:57 +0200, Heikki Linnakangas wrote:
>>> It would be good if there was a keepalive WAL record with a
>> timestamp on it generated every N seconds while in streaming mode.
>>
>> Yeah, that would help. In streaming replication we could also send
>> such ti
Hi,
When I configured a cascaded standby (i.e, made the additional
standby server connect to the standby), I got the following
errors, and a cascaded standby didn't start replication.
ERROR: timeline 0 of the primary does not match recovery target timeline 1
I didn't care about that case so f
On Sat, Jan 16, 2010 at 3:16 PM, Fujii Masao wrote:
>> Attached is an updated patch, doing the above. Am I missing anything?
>
> Thanks a lot! Your change seems to be OK.
We'll need to do some more work after the following patch
has been committed.
http://archives.postgresql.org/pgsql-hackers/201
Hi,
Since I had tweaked wal-skipping logic for SR before,
there were two additional changes about that;
http://archives.postgresql.org/pgsql-committers/2009-11/msg00018.php
http://archives.postgresql.org/pgsql-committers/2009-12/msg00167.php
The attached patch deals with those changes.
Also I fo
On Sun, Jan 17, 2010 at 3:19 PM, Peter Eisentraut wrote:
> There is something slightly funny about the regression test output.
> When it starts a parallel group, it prints something like
>
> parallel group (14 tests): select_views portals_p2 rules foreign_key
> cluster dependency guc bitmapops co
Magnus Hagander writes:
> Which shows one potentially big problem - since we're calling select()
> from inside libpq, it's not calling our "signal emulation layer
> compatible select()". This means that at this point, walreceiver is
> not interruptible.
Ugh.
> Which also shows itself if I shut d
Tatsuo Ishii writes:
> Thanks. I confirmed the problem goes away. BTW, are we going to back
> patch to 8.2 or before?
That code isn't there before 8.3.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
> Log Message:
> ---
> Fix portalmem.c to avoid keeping a dangling pointer to a cached plan list
> after it's released its reference count for the cached plan. There are
> code paths that might try to examine the plan list before noticing that
> the portal is already in aborted state. Rep
On Sun, Jan 17, 2010 at 8:53 AM, Josh Berkus wrote:
> * amount of *time* since last successful archive (this would be a good
> trigger for alerts)
> * number of failed archive attempts
> * number of archive files awaiting processing (presumably monitored by
> the slave)
> * last archive file proce
On Sat, Jan 16, 2010 at 05:39, Robert Haas wrote:
> First, thanks for the review. Detailed comments/questions below.
>
> On Fri, Jan 15, 2010 at 12:52 AM, Alex Hunsaker wrote:
>> On Sun, Jan 10, 2010 at 12:27, Robert Haas wrote:
>>> I am not very happy with ATPrepSetOptions(). I basically just
Greg Stark writes:
> The only thing that jumps out at me from the code itself is the use of
> rand() and srand() which seems unacceptable.
Yeah, (1) rand isn't a good random number generator and (2) fooling with
the main random number sequence is user-unfriendly. If you need a
private source of
2010/1/13 Teodor Sigaev :
>> This is pretty darn slick. I haven't looked at the code yet, but the
>
> It's just a prototype and/or proof of concept
The only thing that jumps out at me from the code itself is the use of
rand() and srand() which seems unacceptable. At the very least the
srand(attno
Tatsuo Ishii writes:
> The patch addresses the original issue. The reason why you didn't see
> crash was just you were lucky, I believe. I'm sure that your
> exec_execute_message looks into already-freed-memory.
[ shrug... ] If it did, it would have crashed, because I invariably
build with --ca
"David E. Wheeler" writes:
> On Jan 17, 2010, at 3:47 PM, Tom Lane wrote:
>>> create type y as (c char, n int);
>>> select ('a', NULL)::y = ('a', NULL)::y; -- TRUE
>>> select ('a', NULL) = ('a', NULL); -- NULL
>> The latter gets simplified to ('a' = 'a') AND (NULL = NULL).
>> The former doesn't
On Jan 17, 2010, at 3:47 PM, Tom Lane wrote:
>> create type y as (c char, n int);
>> select ('a', NULL)::y = ('a', NULL)::y; -- TRUE
>> select ('a', NULL) = ('a', NULL); -- NULL
>
>> I would expect those to evaluate to the same thing.
>
> The latter gets simplified to ('a' = 'a') AND (NULL =
Magnus Hagander wrote:
the Git repository is missing parts of two non-recent commits.
> We've seen this happen before.
That seems like kind of a blasé attitude toward something upon which
some people rely.
When we (at Wisconsin State Courts) were using CVS and had scripts to
automatic
> Tatsuo Ishii writes:
> > While ago, I reported a problem regarding exec_execute_message crash
> > in transaction abort state if sync message issued right after parse,
> > bind and execute message (which is normal if used with pgpool). After
> > further investigation, I concluded that there's a s
Tatsuo Ishii writes:
> While ago, I reported a problem regarding exec_execute_message crash
> in transaction abort state if sync message issued right after parse,
> bind and execute message (which is normal if used with pgpool). After
> further investigation, I concluded that there's a serious pro
Hi,
While ago, I reported a problem regarding exec_execute_message crash
in transaction abort state if sync message issued right after parse,
bind and execute message (which is normal if used with pgpool). After
further investigation, I concluded that there's a serious problem with
unnamed portal
On Sun, 2010-01-17 at 18:47 -0500, Tom Lane wrote:
> The former might be closer to the spec's expectations but I'm not
> totally sure about it.
I suppose that people using NULLs should expect the unexpected ;)
I don't have strong feelings about it, I just wanted to raise the issue.
Regards,
Magnus Hagander wrote:
Maybe this should be "Unrecognized reset target: %s", target, and also
a errhint() saying which targets are allowed. Thoughts?
That seems reasonable. The other thing I realized is that I forgot to
add the new function to the right place in doc/src/sgml/func.sgml :
Jeff Davis writes:
> create type y as (c char, n int);
> select ('a', NULL)::y = ('a', NULL)::y; -- TRUE
> select ('a', NULL) = ('a', NULL); -- NULL
> I would expect those to evaluate to the same thing.
The latter gets simplified to ('a' = 'a') AND (NULL = NULL).
The former doesn't --- it
I wrote:
> This is not actually going to work nicely in cases such as the number of
> parallel tests being limited by max_connections.
Er, no, I take that back: I was thinking that the status() function
included checking of the output file, but it only prints the test name.
Still, I'm not convinc
Peter Eisentraut writes:
> I have found an Autoconf macro that checks whether the compiler properly
> supports C99 inline semantics. This would allow us to replace the
> __GNUC__ conditional with HAVE_C99_INLINE, in this case. Interestingly,
> however, this check results in GCC <=4.2 *not* suppo
On Sun, Jan 17, 2010 at 4:07 PM, James William Pye wrote:
> The effect of this is that every time the FUNCTION is called from PG, the
> import statements are ran, a new class object, UrlOpener, is created, and a
> new function object, translate, is created. Granted, a minor amount of
> overhead
create type y as (c char, n int);
select ('a', NULL)::y = ('a', NULL)::y; -- TRUE
select ('a', NULL) = ('a', NULL); -- NULL
I would expect those to evaluate to the same thing.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
2010/1/17 Tom Lane :
> Magnus Hagander writes:
>> 2010/1/17 Peter Eisentraut :
>>> Maybe I'm hallucinating and someone could check this in their
>>> environment, but it appears to me that the Git repository is missing
>>> parts of two non-recent commits. See attached patch.
>
>> Not having looked
On Sun, 2010-01-17 at 22:57 +0200, Heikki Linnakangas wrote:
>
> > It would be good if there was a keepalive WAL record with a
> timestamp on it generated every N seconds while in streaming mode.
>
> Yeah, that would help. In streaming replication we could also send
> such timestamp as a separate
Magnus Hagander writes:
> 2010/1/17 Peter Eisentraut :
>> Maybe I'm hallucinating and someone could check this in their
>> environment, but it appears to me that the Git repository is missing
>> parts of two non-recent commits. See attached patch.
> Not having looked at the repo in detail, but I
On Jan 14, 2010, at 7:08 PM, Greg Smith wrote:
> So more targeted examples like you're considering now would help.
Here's the first example. This covers an advantage of function modules.
This is a conversion of a plpythonu function published to the wiki:
http://wiki.postgresql.org/wiki/Google_T
On Jan 14, 2010, at 7:08 PM, Greg Smith wrote:
> So more targeted examples like you're considering now would help.
So far, I have three specific examples in mind:
The first will illustrate the advantages of function modules wrt setup code in
the module body. Primarily this is about convenience.
Peter Eisentraut writes:
> I propose to adjust the behavior so that the "parallel group" line
> prints the test names before/as the tests are started, and then the
> subsequent lines print the results after the tests finish, as is
> currently the case.
This is not actually going to work nicely in
Simon Riggs wrote:
> On Fri, 2010-01-15 at 20:50 +0200, Heikki Linnakangas wrote:
>
>>> So in either case, when we are waiting for new input we reset the timer
>>> as soon as new WAL is received. The resolution/accuracy of standby_delay
>>> will be no more than the time taken to replay a single fi
2010/1/17 Peter Eisentraut :
> On sön, 2010-01-17 at 20:50 +0100, Magnus Hagander wrote:
>> As for fixing it, I guess we can try the
>> rewind-to-commit-before-this-and-rerun. That'll break people who have
>> branched after, but last time it seemed that most peoples git clients
>> would clean that
On sön, 2010-01-17 at 20:50 +0100, Magnus Hagander wrote:
> As for fixing it, I guess we can try the
> rewind-to-commit-before-this-and-rerun. That'll break people who have
> branched after, but last time it seemed that most peoples git clients
> would clean that up automatically. Which commits are
Magnus Hagander wrote:
> Which shows one potentially big problem - since we're calling select()
> from inside libpq, it's not calling our "signal emulation layer
> compatible select()". This means that at this point, walreceiver is
> not interruptible. Which also shows itself if I shut down the sys
There is something slightly funny about the regression test output.
When it starts a parallel group, it prints something like
parallel group (14 tests): select_views portals_p2 rules foreign_key
cluster dependency guc bitmapops combocid tsearch tsdicts foreign_data
window xmlmap
One would think
2010/1/17 Peter Eisentraut :
> Maybe I'm hallucinating and someone could check this in their
> environment, but it appears to me that the Git repository is missing
> parts of two non-recent commits. See attached patch.
Not having looked at the repo in detail, but I bet this happened
because the g
On ons, 2009-12-16 at 10:49 -0500, Tom Lane wrote:
> I think you're way overthinking this. Where we started was just
> a proposal to try to expand the set of inline-ing compilers beyond
> "gcc only". I don't see why we need to do anything but that. The
> code is fine as-is except for the control
Maybe I'm hallucinating and someone could check this in their
environment, but it appears to me that the Git repository is missing
parts of two non-recent commits. See attached patch.
diff -I '\$\(PostgreSQL\|OpenBSD\|FreeBSD\|NetBSD\|KAME\)' -x CVS -x .git -ur /home/peter/devel/postgresql/cvs/pg8
2010/1/16 Robert Haas :
> On Thu, Jan 14, 2010 at 8:46 PM, Robert Haas wrote:
>> I have yet to fully review the code but on a quick glance it looks
>> reasonable.
>
> On further review, it looks less reasonable. :-(
>
> The new PQescapeIdentConn function is basically a cut-up version of
> PQesca
I want to do something about the open item discussed in this thread:
http://archives.postgresql.org/message-id/2009081446.ga25...@depesz.com
The right way to handle that, IMO, is to create pg_constraint rows for
triggers created via CREATE CONSTRAINT TRIGGER. Then,
AfterTriggerSetState can in
Hi,
here's a review of the patch:
It applies with offsets, but worked fine for me. It works as advertised,
and I believe it is a solid step forward from the current situation.
As far as the coding goes, the PG_TRY/CATCH in xml_xmlpathobjtoxmltype
seems unnecessary in the XPATH_BOOLEAN branch, as
Peter Eisentraut writes:
> read.c: In function ânodeReadâ:
> read.c:370:3: warning: case value â101â not in enumerated type
> âNodeTagâ
> This can be fixed by changing
> switch (type)
> to
> switch ((int) type)
No objection from here. We don't attempt to cover all possib
Only these few:
read.c: In function ‘nodeRead’:
read.c:370:3: warning: case value ‘101’ not in enumerated type
‘NodeTag’
read.c:300:3: warning: case value ‘102’ not in enumerated type
‘NodeTag’
read.c:294:3: warning: case value ‘103’ not in enumerated type
‘NodeTag’
read.c:374:3: warni
2010/1/14 Greg Smith :
> Itagaki Takahiro wrote:
>>
>> To be honest, I have a plan to add performance statistics counters to
>> postgres. It is not bgwriter's counters, but cluster-level. I'd like
>> to use your infrastructure in my work, too :)
>>
>
> Attached patch provides just that. It still wo
I'm trying to figure out why streaming replication doesn't work on
win32. Here is what I have so far: It starts up fine, and outputs:
LOG: starting archive recovery
LOG: standby_mode = 'on'
LOG: primary_conninfo = 'host=localhost port=5432'
LOG: starting streaming recovery at 0/200
After t
2010/1/16 Tom Lane :
> Magnus Hagander writes:
>> I was going to test the walreceiver stuff, but it turns out that basic
>> archive recovery appears to be broken in HEAD. From what I can tell,
>> it's related to Hot Standby code.
>
> I've committed a fix that makes it work in EXEC_BACKEND case on
48 matches
Mail list logo
