2009/8/14 Itagaki Takahiro
>
> Heikki Linnakangas 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
2009/8/14 Robert Haas :
> 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 Returne
2009/8/14 Олег Царев :
> 2009/8/14 Hitoshi Harada :
>> 2009/8/14 Pavel Stehule :
>>> 2009/8/13 Hitoshi Harada :
2009/8/14 Pavel Stehule :
> I prefered using CTE, because this way was the most short to small
> bugs less prototype - with full functionality.
You could make it by
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 laugha
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 if
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 ha
Heikki Linnakangas 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 between - is the remote transaction le
2009/8/14 Hitoshi Harada :
> 2009/8/14 Pavel Stehule :
>> 2009/8/13 Hitoshi Harada :
>>> 2009/8/14 Pavel Stehule :
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
2009/8/14 Pavel Stehule :
> 2009/8/13 Hitoshi Harada :
>> 2009/8/14 Pavel Stehule :
>>> 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
Alvaro Herrera 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.
It is just same as p
On Fri, Aug 14, 2009 at 12:21 AM, Tom Lane 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 page access,
On Fri, Aug 14, 2009 at 12:07 AM, Josh Berkus 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 it finds any
Josh Berkus 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
> reason*, the fre
On Thu, 2009-08-13 at 18:25 -0400, Robert Haas wrote:
> On Thu, Aug 13, 2009 at 5:33 PM, Jeff Davis 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 mo
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 fract
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 o
> 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 thre
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.
>
> Yea
Jeff Davis 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 allow it.
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 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 multiple times.
Yea
>> 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
On Thu, Aug 13, 2009 at 5:33 PM, Jeff Davis 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 loading a lot of
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 hav
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
Alvaro Herrera 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 cited reason is th
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
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 authenticat
[ 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 tupl
On Thu, Aug 13, 2009 at 1:49 PM, 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
Tom Lane wrote:
> "Massa, Harald Armin" 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
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 ?
> >
> > á for ?, etc. You can't use characters that aren't in Latin-1 I
> >
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
> 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
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 ?
>
> á for á, etc. You can't use characters that aren't in Latin-1 I
> think. Writing them literally is not allow
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.
>
2009/8/13 Hitoshi Harada :
> 2009/8/14 Pavel Stehule :
>> 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. H
Josh Berkus 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, that would
> 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.
ww
2009/8/14 Pavel Stehule :
> 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 implement is
not convinci
Josh Berkus 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 do some
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,
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 handli
Josh Berkus 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 need to be sur
On 8/13/09 7:03 AM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Alvaro Herrera 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
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 requirin
2009/8/13 Олег Царев :
> 2009/8/13 Hitoshi Harada :
>> 2009/8/8 Alvaro Herrera :
>>> Олег Царев 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 or
2009/8/14 Олег Царев :
> 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, it is easie
2009/8/13 Hitoshi Harada :
> 2009/8/8 Alvaro Herrera :
>> Олег Царев 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 solut
2009/8/13 Hitoshi Harada :
> 2009/8/8 Alvaro Herrera :
>> Олег Царев 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 solut
2009/8/8 Alvaro Herrera :
> Олег Царев 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
>> grouping sets
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 t
Robert Haas 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, you're always going
Alvaro Herrera 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 release notes for
Oleg Bartunov wrote:
> Peter,
>
> how to write accented characters in sgml ? Is't not allowed to write
> them as is ?
á for á, etc. You can't use characters that aren't in Latin-1 I think.
Writing them literally is not allowed.
--
Alvaro Herrerahttp://www.Comman
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.
Hm
Paul Matthews 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 base here?
Well,
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 contrib
Alvaro Herrera 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 okay with small steps
Peter Eisentraut 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 to slow down
"Massa, Harald Armin" 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 with
>
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:
http://www.postgresql.org/mai
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 Tue, Aug 11, 2009 at 9:56 PM, Tom Lane wrote:
> Robert Haas 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 in the
>> tree. Even if I'm th
Dimitri Fontaine wrote:
>
> Hi,
>
> Josh Berkus 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 tool
On Tue, Aug 11, 2009 at 4:31 AM, 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 contrib.sgml and bookindex.sgml about
>> dict-unaccent... and when i did that i got this:
Tom Lane wrote:
> Alvaro Herrera 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 in their own way)
Tom Lane wrote:
Alvaro Herrera 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 semantics just
right for obscure
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
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 har
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 ch
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 ret
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 that
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" er
Hi,
Josh Berkus 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 and such. Or use
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=
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 pg_xlog/arc
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 co
78 matches
Mail list logo
