On Thu, Nov 26, 2009 at 4:55 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
In current SR, since a backup history file is not replicated,
the standby always starts an archive recovery without a backup
history file, and a wrong minRecoveryPoint might be
Fujii Masao wrote:
On Thu, Nov 26, 2009 at 4:55 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
In current SR, since a backup history file is not replicated,
the standby always starts an archive recovery without a backup
history file, and a wrong
On Thu, Nov 26, 2009 at 5:17 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Yeah, that needs to be addressed regardless of HS, because you can
otherwise start up (= fail over to) the standby too early, before the
minimum recovery point has been reached.
Okey, I address that
When using the service parameter in a libpq connection (e.g., psql
service=foo), and the service name is not defined in pg_service.conf,
then the setting is silently ignored and the connection proceeds with
whatever other settings and defaults apply. That does not look very
robust. Shouldn't
On Wed, Nov 25, 2009 at 11:34:35PM -0500, Tom Lane wrote:
Roger Leigh rle...@codelibre.net writes:
The following patch adds in an nl_langinfo(CODESET) check in
addition to the existing client encoding check.
I think the consensus is pretty clear that we should just set the
default
On Thu, Nov 26, 2009 at 2:28 AM, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2009-11-25 at 22:15 +0100, Magnus Hagander wrote:
On Wed, Nov 25, 2009 at 22:07, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2009-11-25 at 16:27 +0100, Magnus Hagander wrote:
Attached is a patch which adds a
Robert Haas wrote:
On Thu, Nov 26, 2009 at 2:28 AM, Peter Eisentraut pete...@gmx.net wrote:
In the installation instructions chapter, there is a section Getting
the Source, which could warrant a link or reference to the appropriate
instructions on the web site.
I have to say I'm not really
On Thu, Nov 26, 2009 at 12:29, Robert Haas robertmh...@gmail.com wrote:
On Thu, Nov 26, 2009 at 2:28 AM, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2009-11-25 at 22:15 +0100, Magnus Hagander wrote:
On Wed, Nov 25, 2009 at 22:07, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2009-11-25
On Thu, Nov 26, 2009 at 6:44 AM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Nov 26, 2009 at 12:29, Robert Haas robertmh...@gmail.com wrote:
On Thu, Nov 26, 2009 at 2:28 AM, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2009-11-25 at 22:15 +0100, Magnus Hagander wrote:
On Wed, Nov 25,
On Wed, Nov 25, 2009 at 10:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
ISTM restricting the name to ASCII-only is the most reasonable tradeoff.
Of course, as a speaker of English I may be a bit biased here --- but
doing nothing about the issue doesn't seem acceptable.
OK - something like this?
Oleg Bartunov o...@sai.msu.su writes:
On Wed, 25 Nov 2009, Tom Lane wrote:
I think you altered the wrong function. The function underlying
point @ box is on_pb() not pt_contained_box ... in fact, I don't
even see a function named that.
sorry, I forgot to say, that I created operator
Unless
On Mon, Nov 16, 2009 at 11:58:04AM +0100, Boszormenyi Zoltan wrote:
I have rebased the ECPG patches to current CVS.
This mail contains the dynamic cursorname,
the fine-grained split-up was re-united as per
Alvaro's comment.
Rest of it committed to HEAD.
Thanks for your work.
Michael
--
Dave Page dp...@pgadmin.org writes:
OK - something like this? Should keep non-printable/control characters
out of logs too...
Personally I'd use guc_strdup and then modify the string in-place,
but that's just a matter of taste I guess. Otherwise it seems
reasonable.
On Thu, November 26, 2009 2:22 am, Jeff Davis wrote:
On Thu, 2009-11-26 at 00:35 -0500, Andrew Dunstan wrote:
On Wed, November 25, 2009 3:56 pm, Jeff Davis wrote:
I worry that we're getting further away from the original problem.
Let's
allow functions to get the bytes of data from a COPY,
On Thu, November 26, 2009 2:22 am, Jeff Davis wrote:
On Thu, 2009-11-26 at 00:35 -0500, Andrew Dunstan wrote:
On Wed, November 25, 2009 3:56 pm, Jeff Davis wrote:
I worry that we're getting further away from the original problem.
Let's
allow functions to get the bytes of data from a COPY,
Hannu Krosing wrote:
After triggers can't change tuple, thus cant change routing.
An after trigger can always issue an update of the tuple but that should
be trapped by the regular mechanism that will deal with updates (when we
have it available).
Also the description omits the execution of
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Robert Haas wrote:
I have to say I'm not really impressed by the idea of removing things
from our documentation and replacing them with pages on the wiki. The
documentation is better-written and easier to navigate.
I agree in
2009/11/26 Jeff Davis pg...@j-davis.com:
On Thu, 2009-11-26 at 05:01 +0100, Pavel Stehule wrote:
It working like:
1. EXECUTE SELECT 0 FROM generate_series(1,...);
2. STORE RESULT TO TABLE zero;
3. EXECUTE SELECT 1/i FROM zero;
4. STORE RESULT TO TABLE tmp;
Problem is in seq execution.
Updated application name patch, including a GUC assign hook to clean
the application name of any unsafe characters, per discussion.
Regards, Dave
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
appname-v4.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list
On Thu, Nov 26, 2009 at 16:38, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Robert Haas wrote:
I have to say I'm not really impressed by the idea of removing things
from our documentation and replacing them with pages on the wiki. The
I wrote a hackish little script that checks if all rules in ecpg.addons are
indeed used to create the precompiler's parser to catch renamed symbol and
similar changes. Now I wonder whether this should be added to the build
process. If it is, the buildfarm will catch every such change, not just the
Magnus Hagander mag...@hagander.net writes:
I assume you are fine with the addition of some info about git, but
what about the removal of those two chapters suggested?
I agree that we needn't try to cover material that's in the CVS manual.
As somebody mentioned upthread, a sentence or two about
Michael Meskes mes...@postgresql.org writes:
I wrote a hackish little script that checks if all rules in ecpg.addons are
indeed used to create the precompiler's parser to catch renamed symbol and
similar changes. Now I wonder whether this should be added to the build
process. If it is, the
Hi!
Contrib module is reworked as a patch for current GiST. Now GiST supports
KNN-search, the query looks like
SELECT * FROM point_tbl ORDER BY f1 - '0,1';
or
SELECT * FROM point_tbl WHERE f1 @ '(-10,-10),(10,10)':: box ORDER BY f1 -
'0,1';
Plans are:
EXPLAIN (COSTS OFF)
SELECT * FROM
explain select col1 from s order by abs(col1 - 5) limit 10;
is the one-dimensional equivalent of the type of query you're proposing
Exactly, it's already done in next version of patch :)
and that doesn't work either until you put an index on abs(col1 - 5),
then it just works, but only for k
BTW, it's possible to add this feature to plain btree by changing
traversal algorithm, but I'm fill enough power to do it.
Sorry, I'm NOT fill enough power to do it.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
BTW, it's possible to add this feature to plain btree by changing
traversal algorithm, but I'm fill enough power to do it.
Sorry, I'm NOT fill enough power to do it.
%-), I'm NOT FEEL enough power to do it.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
pete...@gmx.net (Peter Eisentraut) writes:
On ons, 2009-11-25 at 16:27 +0100, Magnus Hagander wrote:
Attached is a patch which adds a chapter to git in our documentation,
around where we have several chapters about cvs today. It also removes
a few very out of date comments about cvs
I think
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
Attached is the latest version of the patch.
I started to look at this patch and soon noted that a very substantial
fraction of the delta had to do with getting rid of dependencies on
estate-es_result_relation_info. It seemed to me that if we
Michael Meskes írta:
On Mon, Nov 16, 2009 at 11:58:04AM +0100, Boszormenyi Zoltan wrote:
I have rebased the ECPG patches to current CVS.
This mail contains the dynamic cursorname,
the fine-grained split-up was re-united as per
Alvaro's comment.
Rest of it committed to HEAD.
Tom Lane wrote:
What this misses is EvalPlanQual, which can require
initialization of a new plan tree during execution.
Agh. You're right, I missed that.
When I realized this, my first thought was that we might as well drop
all the proposed changes that involve avoiding use of
On Thu, 26 Nov 2009, Tom Lane wrote:
Oleg Bartunov o...@sai.msu.su writes:
On Wed, 25 Nov 2009, Tom Lane wrote:
I think you altered the wrong function. The function underlying
point @ box is on_pb() not pt_contained_box ... in fact, I don't
even see a function named that.
sorry, I forgot
The following commit to release-8.5.sgml:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=e043393bcc7ed484c3e3cd6a1ce4c63651ab46be
broke the documentation (no end tag). Wouldn't the buildfarm notice
this, or does it not build the docs?
Regards,
Jeff Davis
--
Sent via
Hi Hackers,
I've familiarized myself a little with the architecture of postgresql,
largely because it's interesting. There's one thing I can't quite
figure out though, and it seems that there's no better group of people
in the world to ask about it.
At the lower levels in PG, reading from the
Jeff Davis pg...@j-davis.com writes:
The following commit to release-8.5.sgml:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=e043393bcc7ed484c3e3cd6a1ce4c63651ab46be
broke the documentation (no end tag).
Ooops, my fault.
Wouldn't the buildfarm notice
this, or does it not
On Thu, Nov 26, 2009 at 4:33 AM, Jeff Davis pg...@j-davis.com wrote:
Thanks, I applied it. The only significant thing I changed was that I
did not inline the index_elem because it made it fairly hard to read.
Instead, I renamed it exclude_elem to make it a little more
meaningful, which I
On Thu, 2009-11-26 at 16:31 -0500, Robert Haas wrote:
On Thu, Nov 26, 2009 at 4:33 AM, Jeff Davis pg...@j-davis.com wrote:
Thanks, I applied it. The only significant thing I changed was that I
did not inline the index_elem because it made it fairly hard to read.
Instead, I renamed it
Dan Eloff wrote:
At the lower levels in PG, reading from the disk into cache, and
writing from the cache to the disk is always done in pages.
Why does PG work this way? Is it any slower to write whole pages
rather than just the region of the page that changed? Conversely, is
it faster? From
On Thu, Nov 26, 2009 at 4:14 PM, Dan Eloff dan.el...@gmail.com wrote:
Hi Hackers,
I've familiarized myself a little with the architecture of postgresql,
largely because it's interesting. There's one thing I can't quite
figure out though, and it seems that there's no better group of people
in
On Thu, Nov 26, 2009 at 10:11:12AM -0500, Andrew Dunstan wrote:
On Thu, November 26, 2009 2:22 am, Jeff Davis wrote:
On Thu, 2009-11-26 at 00:35 -0500, Andrew Dunstan wrote:
On Wed, November 25, 2009 3:56 pm, Jeff Davis wrote:
I worry that we're getting further away from the original
On Thu, Nov 26, 2009 at 6:13 PM, David Fetter da...@fetter.org wrote:
It'd be nice to make this available to the next revision of DBI-Link
and it'll be pretty handy for our SQL/MED whenever that happens.
Okay, so this thread sort of wandered into how we could refactor other
elements of COPY.
On Thu, Nov 26, 2009 at 4:25 PM, Robert Haas robertmh...@gmail.com wrote:
Current version of patch is attached. I've revised it to use the
reloptions stuff, but I don't think it's committable as-is because it
currently thinks that extracting options from a pg_tablespace tuple is
a cheap
Peter Eisentraut wrote:
When using the service parameter in a libpq connection (e.g., psql
service=foo), and the service name is not defined in pg_service.conf,
then the setting is silently ignored and the connection proceeds with
whatever other settings and defaults apply. That does not look
On tor, 2009-11-26 at 10:57 +0200, Peter Eisentraut wrote:
When using the service parameter in a libpq connection (e.g., psql
service=foo), and the service name is not defined in pg_service.conf,
then the setting is silently ignored and the connection proceeds with
whatever other settings and
44 matches
Mail list logo
