2010/1/16 Tom Lane t...@sss.pgh.pa.us:
Magnus Hagander mag...@hagander.net 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
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
2010/1/14 Greg Smith g...@2ndquadrant.com:
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
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:
Peter Eisentraut pete...@gmx.net 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
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,
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
2010/1/16 Robert Haas robertmh...@gmail.com:
On Thu, Jan 14, 2010 at 8:46 PM, Robert Haas robertmh...@gmail.com 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
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
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
2010/1/17 Peter Eisentraut pete...@gmx.net:
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
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
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 system -
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
2010/1/17 Peter Eisentraut pete...@gmx.net:
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
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 file. This
Peter Eisentraut pete...@gmx.net 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
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.
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:
Magnus Hagander mag...@hagander.net writes:
2010/1/17 Peter Eisentraut pete...@gmx.net:
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
2010/1/17 Tom Lane t...@sss.pgh.pa.us:
Magnus Hagander mag...@hagander.net writes:
2010/1/17 Peter Eisentraut pete...@gmx.net:
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.
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
On Sun, Jan 17, 2010 at 4:07 PM, James William Pye li...@jwp.name 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
Peter Eisentraut pete...@gmx.net 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
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
Jeff Davis pg...@j-davis.com 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
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 :
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,
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
Tatsuo Ishii is...@postgresql.org 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
Tatsuo Ishii is...@postgresql.org 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
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
automatically
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 = NULL).
David E. Wheeler da...@kineticode.com 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
Tatsuo Ishii is...@postgresql.org 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
2010/1/13 Teodor Sigaev teo...@sigaev.ru:
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
Greg Stark gsst...@mit.edu 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
On Sat, Jan 16, 2010 at 05:39, Robert Haas robertmh...@gmail.com wrote:
First, thanks for the review. Detailed comments/questions below.
On Fri, Jan 15, 2010 at 12:52 AM, Alex Hunsaker bada...@gmail.com wrote:
On Sun, Jan 10, 2010 at 12:27, Robert Haas robertmh...@gmail.com wrote:
I am not
On Sun, Jan 17, 2010 at 8:53 AM, Josh Berkus j...@agliodbs.com 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
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. Report
Tatsuo Ishii is...@postgresql.org 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
Magnus Hagander mag...@hagander.net 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
On Sun, Jan 17, 2010 at 3:19 PM, Peter Eisentraut pete...@gmx.net 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
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
On Sat, Jan 16, 2010 at 3:16 PM, Fujii Masao masao.fu...@gmail.com 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.
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
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 timestamp as
48 matches
Mail list logo
