On Tue, 11 Aug 2009, Mike wrote:
Have any tool authors stepped up and committed resources to utilizing
this feature in the near term?
Even before the easier to read format was available, there were already
multiple EXPLAIN analysis tools floating around, some of them web-based
like you're
On Tue, 11 Aug 2009, Dimitri Fontaine wrote:
We should somehow provide a default archive and restore command integrated
into the main product, so that it's as easy as turning it 'on' in the
configuration for users to have something trustworthy: PostgreSQL will keep
past logs into a
I'm trying to add all the box op point operators. The C routines are
written and working as advertised. The manuals description of the
RESTRICT and JOIN clauses of CREATE OPERATOR don't seem too clear. Are
these samples correct, or am I totally off base here?
CREATE OPERATOR (
LEFTARG=
Hi,
Josh Berkus j...@agliodbs.com writes:
Will do. Teaching myself RST now
I've been doing a lot of RST editing before, and found it pretty
straightforward. Except for default table handling, where ascii-art
maintenance is a pain, or you have to use extended tools, like emacs
table mode
within source code, build options there is:
- Reserve the shared memory region during backend startup on Windows,
so that memory allocated by starting third party DLLs doesn't end up
conflicting with it. Hopefully this solves the long-time issue with
could not reattach to shared memory
But when I see a big red button, I just press it to see what happens.
Ugly hacks are useful to know how fast the thing can go ; then the
interesting part is to reimplement it cleanly, trying to reach the
same performance...
Right -- now that you've shown a 6x speedup increase, it is clear
Here is a proposal to integrate contrib/dblink and SQL/MED (foreign
data wrapper).
Dblink manages connections and transactions by itself at the moment,
but there are some benefits to split database connectors into FDW.
Dblink will uses those multiple connectors. For example, we will be
able to
Is there a reason why the function manager allows calling trigger functions
outside of triggers and forces the PLs to catch this case themselves? Is
there a case where calling trigger functions directly is useful?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Itagaki Takahiro wrote:
Present dblink is a thin wrapper of libpq, but some of my customers
want automatic transaction managements. Remote transactions are
committed with 2PC when the local transaction is committed.
To achieve it, I think we need on-commit trigger is needed,
but it is hard to
On Wed, Aug 12, 2009 at 07:13:44PM +0200, Boszormenyi Zoltan wrote:
a customer of us complained a behavioural difference
...
The attached patch implements this. The only downside
is that now DECLARE CURSOR cannot appear outside
of a function, a change in test/preproc/variable.pgc reflects
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
However I'm guessing that what actually happens is that heap_update is
returning HeapTupleSelfUpdated instead, which the code states as
/* nothing to do */.
Yeah.
I imagine this is so because of some old fiddling to get
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
I imagine this is so because of some old fiddling to get semantics just
right for obscure corner cases, but it feels wrong nevertheless.
I suspect it was reluctance to use the EvalPlanQual semantics (which
are pretty bogus
On Tue, Aug 11, 2009 at 4:31 AM, Peter Eisentrautpete...@gmx.net wrote:
On Tuesday 11 August 2009 08:28:24 Jaime Casanova wrote:
try to build the docs to see how to properly test this and seems like
you have to teach contrib.sgml and bookindex.sgml about
dict-unaccent... and when i did that i
Dimitri Fontaine wrote:
Hi,
Josh Berkus j...@agliodbs.com writes:
Will do. Teaching myself RST now
I've been doing a lot of RST editing before, and found it pretty
straightforward. Except for default table handling, where ascii-art
maintenance is a pain, or you have to use
On Tue, Aug 11, 2009 at 9:56 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Given that the anum.h stuff is gone, vastly might be an
overstatement. I'm pretty surprised to find out that people don't
like the idea of having dependencies be correct from anywhere
Itagaki Takahiro wrote:
Also new two interfaces will be introduced:
interface Connection/* represents PGconn */
{
voiddisconnect(self);
Cursor *open(self, query, fetchsize); /* for SELECT */
int64 exec(self, query);/* for UPDATE,
On Thursday 13 August 2009 17:07:38 Alvaro Herrera wrote:
I wonder if this format can be converted to SGML DocBook automatically.
Yes, that's why I used it.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Massa, Harald Armin c...@ghum.de writes:
within source code, build options there is:
- Reserve the shared memory region during backend startup on Windows,
so that memory allocated by starting third party DLLs doesn't end up
conflicting with it. Hopefully this solves the long-time issue
Peter Eisentraut pete...@gmx.net writes:
Is there a reason why the function manager allows calling trigger functions
outside of triggers and forces the PLs to catch this case themselves? Is
there a case where calling trigger functions directly is useful?
I think it's a matter of not wanting
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Indeed, and it fails to get rid of all the dull declarations :-(.
Right. I don't think we're going to move forward if we only accept
giant steps at a time, and we simultaneously reject patches that are too
intrusive.
I'm
Peter,
how to write accented characters in sgml ? Is't not allowed to write them
as is ?
Oleg
On Tue, 11 Aug 2009, Peter Eisentraut wrote:
On Tuesday 11 August 2009 08:28:24 Jaime Casanova wrote:
try to build the docs to see how to properly test this and seems like
you have to teach
Paul Matthews p...@netspace.net.au writes:
I'm trying to add all the box op point operators. The C routines are
written and working as advertised. The manuals description of the
RESTRICT and JOIN clauses of CREATE OPERATOR don't seem too clear. Are
these samples correct, or am I totally off
Tom Lane wrote:
In any case, it is not the function of the alpha release notes to
discuss changes in earlier release branches. The reason the commit
log points out the back-patch is to make it easier to extract the
information when we prepare release notes for the back-branch updates.
Hmm,
Oleg Bartunov wrote:
Peter,
how to write accented characters in sgml ? Is't not allowed to write
them as is ?
aacute; for á, etc. You can't use characters that aren't in Latin-1 I think.
Writing them literally is not allowed.
--
Alvaro Herrera
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
In any case, it is not the function of the alpha release notes to
discuss changes in earlier release branches. The reason the commit
log points out the back-patch is to make it easier to extract the
information when we prepare
Robert Haas robertmh...@gmail.com wrote:
*scratches head*
I don't really know how you COULD pick a safe default location.
Presumably any location that's in the default postgresql.conf file
would be under $PGDATA, which kind of defeats the purpose of the
whole thing. In other words,
Michael Meskes írta:
On Wed, Aug 12, 2009 at 07:13:44PM +0200, Boszormenyi Zoltan wrote:
a customer of us complained a behavioural difference
...
The attached patch implements this. The only downside
is that now DECLARE CURSOR cannot appear outside
of a function, a change in
2009/8/8 Alvaro Herrera alvhe...@commandprompt.com:
Олег Царев escribió:
Hello all!
If no one objecte (all agree, in other say) i continue work on patch -
particulary, i want support second strategy (tuple store instead of
hash-table) for save order of source (more cheap solution in case with
2009/8/13 Hitoshi Harada umi.tan...@gmail.com:
2009/8/8 Alvaro Herrera alvhe...@commandprompt.com:
Олег Царев escribió:
Hello all!
If no one objecte (all agree, in other say) i continue work on patch -
particulary, i want support second strategy (tuple store instead of
hash-table) for save
2009/8/13 Hitoshi Harada umi.tan...@gmail.com:
2009/8/8 Alvaro Herrera alvhe...@commandprompt.com:
Олег Царев escribió:
Hello all!
If no one objecte (all agree, in other say) i continue work on patch -
particulary, i want support second strategy (tuple store instead of
hash-table) for save
2009/8/14 Олег Царев zabiva...@gmail.com:
All rights, exclude
Because GROUP BY we have today is a subset of GROUPING SETS by
definition, I suppose we'll refactor nodeAgg.c so that it is allowed
to take multiple group definitions. And we must support both of
HashAgg and GroupAgg. For HashAgg,
2009/8/13 Олег Царев zabiva...@gmail.com:
2009/8/13 Hitoshi Harada umi.tan...@gmail.com:
2009/8/8 Alvaro Herrera alvhe...@commandprompt.com:
Олег Царев escribió:
Hello all!
If no one objecte (all agree, in other say) i continue work on patch -
particulary, i want support second strategy
All,
The other reason is what I think Greg Smith was mentioning --
simplifying the process of grabbing a usable PITR backup for novice
users. That seems like it has merit.
While we're at this, can we add xlog_location as a file-location GUC?
It seems inconsistent that we're still requiring
On 8/13/09 7:03 AM, Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
I imagine this is so because of some old fiddling to get semantics just
right for obscure corner cases, but it feels wrong nevertheless.
I suspect it was reluctance to use the
Josh Berkus j...@agliodbs.com writes:
While we're at this, can we add xlog_location as a file-location GUC?
That was proposed and rejected quite a long time ago. We don't *want*
people to be able to just change a GUC and have their xlog go
somewhere else, because of the foot-gun potential. You
In the previous mails I made a mistake, writing MTuples/s instead of
MDatums/s, sorry about that. It is the number of rows x columns. The
title was wrong, but the data was right.
I've been doing some tests on COPY FROM ... BINARY.
- inlines in various pg_get* etc
- a faster buffer handling
Tom,
That was proposed and rejected quite a long time ago. We don't *want*
people to be able to just change a GUC and have their xlog go
somewhere else, because of the foot-gun potential. You need to be sure
that the existing WAL files get moved over when you do something like
that, and
Josh Berkus j...@agliodbs.com writes:
That was proposed and rejected quite a long time ago. We don't *want*
people to be able to just change a GUC and have their xlog go
somewhere else, because of the foot-gun potential. You need to be sure
that the existing WAL files get moved over when you
2009/8/14 Pavel Stehule pavel.steh...@gmail.com:
I prefered using CTE, because this way was the most short to small
bugs less prototype - with full functionality.
You could make it by query rewriting, but as you say the best cleanest
way is total refactoring of existing nodeAgg. How easy to
Now admittedly it's not hard to screw yourself with a careless manual
move of xlog, either. But at least the database didn't hand you a knob
that invites clueless frobbing.
So really rather than a GUC we should have a utility for moving the xlog.
--
Josh Berkus
PostgreSQL Experts Inc.
Josh Berkus j...@agliodbs.com writes:
Now admittedly it's not hard to screw yourself with a careless manual
move of xlog, either. But at least the database didn't hand you a knob
that invites clueless frobbing.
So really rather than a GUC we should have a utility for moving the xlog.
Yeah,
2009/8/13 Hitoshi Harada umi.tan...@gmail.com:
2009/8/14 Pavel Stehule pavel.steh...@gmail.com:
I prefered using CTE, because this way was the most short to small
bugs less prototype - with full functionality.
You could make it by query rewriting, but as you say the best cleanest
way is
On Thu, Aug 13, 2009 at 02:01:19PM +0300, Heikki Linnakangas wrote:
Itagaki Takahiro wrote:
Present dblink is a thin wrapper of libpq, but some of my customers
want automatic transaction managements. Remote transactions are
committed with 2PC when the local transaction is committed.
To
On Thursday 13 August 2009 18:07:51 Alvaro Herrera wrote:
Oleg Bartunov wrote:
Peter,
how to write accented characters in sgml ? Is't not allowed to write
them as is ?
aacute; for á, etc. You can't use characters that aren't in Latin-1 I
think. Writing them literally is not allowed.
Yeah, that would work. Although it would probably take as much verbiage
to document the utility as it does to document how to do it manually.
Yes, but it would *feel* less hackish to sysadmins and DBAs, and make
them more confident about moving the xlogs.
Getting it to work on windows will
Josh Berkus wrote:
Yeah, that would work. Although it would probably take as much verbiage
to document the utility as it does to document how to do it manually.
Yes, but it would *feel* less hackish to sysadmins and DBAs, and make
them more confident about moving the xlogs.
Getting it
Peter Eisentraut wrote:
On Thursday 13 August 2009 18:07:51 Alvaro Herrera wrote:
Oleg Bartunov wrote:
Peter,
how to write accented characters in sgml ? Is't not allowed to write
them as is ?
aacute; for ?, etc. You can't use characters that aren't in Latin-1 I
think. Writing
Tom Lane wrote:
Massa, Harald Armin c...@ghum.de writes:
within source code, build options there is:
- Reserve the shared memory region during backend startup on Windows,
so that memory allocated by starting third party DLLs doesn't end up
conflicting with it. Hopefully this solves
On Thu, Aug 13, 2009 at 1:49 PM, Josh Berkusj...@agliodbs.com wrote:
Yeah, that would work. Although it would probably take as much verbiage
to document the utility as it does to document how to do it manually.
Yes, but it would *feel* less hackish to sysadmins and DBAs, and make
them more
[ moving to -hackers ]
If this topic has been discussed previously, please point me to the
earlier threads.
Why aren't we more opportunistic about freezing tuples? For instance, if
we already have a dirty buffer in cache, we should be more aggressive
about freezing those tuples than freezing
I've been looking into what it would take to eliminate the flat file for
pg_auth info. The implication of doing that is that authentication has
to be postponed until inside InitPostgres(), where we can read the
actual system catalogs instead.
The easy way to do it would be to postpone
Jeff Davis wrote:
Why aren't we more opportunistic about freezing tuples? For instance, if
we already have a dirty buffer in cache, we should be more aggressive
about freezing those tuples than freezing tuples on disk.
The most widely cited reason is that you lose forensics data. Although
Alvaro Herrera alvhe...@commandprompt.com wrote:
Jeff Davis wrote:
Why aren't we more opportunistic about freezing tuples? For
instance, if we already have a dirty buffer in cache, we should be
more aggressive about freezing those tuples than freezing tuples on
disk.
The most widely
On Thu, 2009-08-13 at 17:58 -0400, Alvaro Herrera wrote:
The most widely cited reason is that you lose forensics data. Although
they are increasingly rare, there are still situations in which the heap
tuple machinery messes up and the xmin/xmax/etc fields of the tuple are
the best/only way to
On Thu, 2009-08-13 at 17:17 -0500, Kevin Grittner wrote:
It wouldn't surprise
me to find workloads where writing data three times (once for the
data, once for hint bits, and once to freeze the tid)
I'm not sure that we're limited to 3 times, here. I could be missing
something, but if you have
On Thu, Aug 13, 2009 at 5:33 PM, Jeff Davispg...@j-davis.com wrote:
Or, perhaps when the bgwriter is flushing dirty buffers, it can look for
opportunities to set hint bits or freeze tuples.
One of the tricky things here is that the time you are mostly likely
to want to do this is when you are
Why aren't we more opportunistic about freezing tuples? For instance, if
we already have a dirty buffer in cache, we should be more aggressive
about freezing those tuples than freezing tuples on disk.
The most widely cited reason is that you lose forensics data. Although
they are
Jeff Davis pg...@j-davis.com writes:
Let's say that we had a range like 50-100M, where if it's older than
100M, we freeze it, and if it's older than 50M we freeze it only if it's
on a dirty page. We would still have forensic evidence, but we could
make a range such that we avoid writing
On Thu, 2009-08-13 at 18:46 -0400, Tom Lane wrote:
Yeah, making the limit slushy would doubtless save some writes, with
not a lot of downside.
OK, then should we make this a TODO? I'll make an attempt at this.
And people who don't care about forensic evidence can set it to 0-100M.
Jeff Davis pg...@j-davis.com writes:
On Thu, 2009-08-13 at 18:46 -0400, Tom Lane wrote:
Everybody *thinks* they don't care about forensic evidence. Until they
need it.
We already allow setting vacuum_freeze_min_age to zero, so I don't see a
solution here other than documentation.
Yeah, we
Jeff, Tom,
Let's say that we had a range like 50-100M, where if it's older than
100M, we freeze it, and if it's older than 50M we freeze it only if it's
on a dirty page. We would still have forensic evidence, but we could
make a range such that we avoid writing multiple times.
Yeah, making
What are you envisioning exactly? If vacuum finds any reason to dirty
a page (or it's already dirty), then freeze everything on the page that's
got age some lower threshold?
I was envisioning, if the page is already dirty and in memory *for any
reason*, the freeze rows at below some
I love using postgresql, and have for a long time. I'm involved with
almost a hundred postgresql installs. But this is the first time I've
gotten into the code.
Renumbering networks happens often, and will happen more frequently as
IPv4 space runs low. The IP based restrictions in pg_hba.conf is
On Thu, 2009-08-13 at 19:05 -0400, Tom Lane wrote:
What are you envisioning exactly? If vacuum finds any reason to dirty
a page (or it's already dirty), then freeze everything on the page that's
got age some lower threshold?
Yes. There are two ways to do the threshold:
1. Constant fraction
On Thu, 2009-08-13 at 18:25 -0400, Robert Haas wrote:
On Thu, Aug 13, 2009 at 5:33 PM, Jeff Davispg...@j-davis.com wrote:
Or, perhaps when the bgwriter is flushing dirty buffers, it can look for
opportunities to set hint bits or freeze tuples.
One of the tricky things here is that the time
Josh Berkus j...@agliodbs.com writes:
What are you envisioning exactly? If vacuum finds any reason to dirty
a page (or it's already dirty), then freeze everything on the page that's
got age some lower threshold?
I was envisioning, if the page is already dirty and in memory *for any
On Fri, Aug 14, 2009 at 12:07 AM, Josh Berkusj...@agliodbs.com wrote:
freeze this table agressively if it's in memory, but wait a long time
to vaccuum if it's on disk
Waitasec, in memory?
There are two projects here:
1) Make vacuum when it's freezing tuples freeze every tuple lesser
age if
On Fri, Aug 14, 2009 at 12:21 AM, Tom Lanet...@sss.pgh.pa.us wrote:
I was envisioning, if the page is already dirty and in memory *for any
reason*, the freeze rows at below some threshold.
I believe we've had this discussion before. I do *NOT* want freezing
operations pushed into any random
Alvaro Herrera alvhe...@commandprompt.com wrote:
int64 exec(self, query);/* for UPDATE, INSERT, DELETE
*/
It's not good to return int64 in exec(), because it could have a
RETURNING clause. (So it also needs a fetchsize).
We should use open() for RETURNING query.
2009/8/14 Pavel Stehule pavel.steh...@gmail.com:
2009/8/13 Hitoshi Harada umi.tan...@gmail.com:
2009/8/14 Pavel Stehule pavel.steh...@gmail.com:
I prefered using CTE, because this way was the most short to small
bugs less prototype - with full functionality.
You could make it by query
2009/8/14 Hitoshi Harada umi.tan...@gmail.com:
2009/8/14 Pavel Stehule pavel.steh...@gmail.com:
2009/8/13 Hitoshi Harada umi.tan...@gmail.com:
2009/8/14 Pavel Stehule pavel.steh...@gmail.com:
I prefered using CTE, because this way was the most short to small
bugs less prototype - with full
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Quite aside from the requirement for on-commit trigger, how exactly
would you use 2PC with the remote database? When would you issue PREPARE
TRANSACTION, and when would COMMIT PREPARED? What if the local database
crashes in
The story so far ... The provide polygon@point routine does not work
correctly when the points are close to the boundary. So we implemented a
custom contains(poly,point) function. In order to stop all points being
checked against all polygons, a separate bounding box is maintained. So
the query
OK, we have the following patches remaining for CommitFest 2009-07...
(1) Named and mixed notation for PL. Tom left this one as Waiting on
Author because he didn't have much else left to work on, just in case
Pavel could rework it in time. I'll move it to Returned with Feedback
after tomorrow
The Wisconsin Benchmark in src/test/bench is broken, probably since 8.2.
Attached is a tested patch that fixes it. However, it might be better
to just remove src/test/bench. The benchmark is quite useless,
because it is single user test that runs in the stand
alone mode, and because it is
2009/8/14 Олег Царев zabiva...@gmail.com:
2009/8/14 Hitoshi Harada umi.tan...@gmail.com:
2009/8/14 Pavel Stehule pavel.steh...@gmail.com:
2009/8/13 Hitoshi Harada umi.tan...@gmail.com:
2009/8/14 Pavel Stehule pavel.steh...@gmail.com:
I prefered using CTE, because this way was the most short
2009/8/14 Robert Haas robertmh...@gmail.com:
OK, we have the following patches remaining for CommitFest 2009-07...
(1) Named and mixed notation for PL. Tom left this one as Waiting on
Author because he didn't have much else left to work on, just in case
Pavel could rework it in time. I'll
77 matches
Mail list logo
