Josh Berkus wrote:
Not everything is sanely convertible into some sort of plugin. A plugin
mechanism for this would be FAR more trouble that it is worth, IMNSHO.
We are massively over-egging this pudding (as a culinary blogger you
should appreciate this analogy).
OK, then let's just
David Fetter da...@fetter.org writes:
We have a very unfortunate naming situation with Jeff Davis's new
feature, namely the shorter name, which is one permutation away from
an existing and entirely unrelated feature: Constraint Exclusion,
which has to do with queries over partitioned tables
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2009-12-07 at 19:07 +0200, Heikki Linnakangas wrote:
Why not just follow the example of postresql.conf?
Much better idea.
Rather than reinventing all the infrastructure associated with GUCs,
maybe we should just make the recovery parameters
On Mon, 2009-12-07 at 19:21 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2009-12-07 at 19:07 +0200, Heikki Linnakangas wrote:
Why not just follow the example of postresql.conf?
Much better idea.
Rather than reinventing all the infrastructure associated with
On Mon, Dec 07, 2009 at 07:11:56PM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
We have a very unfortunate naming situation with Jeff Davis's new
feature, namely the shorter name, which is one permutation away
from an existing and entirely unrelated feature: Constraint
Andrew Dunstan and...@dunslane.net writes:
I was in fact prepared to commit this patch, despite some significant
misgivings about its wisdom, mainly because it does have such a low
impact. But then other people raised objections. I'm not sure how strong
those objections are, though.
The
Albe Joshua, thanks for the advice. I am in the process of deciding what to
work on and am looking at the TODO list. I definitely do not intend to work in a
vacuum :-) I am really excited about this and look forward to being challenged and
learning a lot.
Regards
Ashish
On Mon, 7 Dec 2009,
On 12/7/09 4:41 PM, Ashish wrote:
Albe Joshua, thanks for the advice. I am in the process of deciding
what to work on and am looking at the TODO list. I definitely do not
intend to work in a vacuum :-) I am really excited about this and look
forward to being challenged and learning a lot.
Robert Haas robertmh...@gmail.com writes:
There's an awful lot of layers of function calls happening in
explain.c for no really discernable purpose that I can see.
ExplainOneQuery() calls either ExplainOneUtility() if it has a utility
command or ExplainOneQuery_hook() if that's defined or else
2009/12/8 Kevin Grittner kevin.gritt...@wicourts.gov:
Jaime Casanova jcasa...@systemguards.com.ec wrote:
Dave Page dp...@pgadmin.org wrote:
The new committers are:
Robert Haas
Simon Riggs
Greg Stark
ITAGAKI Takahiro
Congratulations!
+1
Outstanding! Congratulations, all!
+1
On Mon, 2009-12-07 at 13:53 -0800, David Fetter wrote:
We have a very unfortunate naming situation with Jeff Davis's new
feature, namely the shorter name, which is one permutation away from
an existing and entirely unrelated feature: Constraint Exclusion,
which has to do with queries over
Hi Robert,
Thanks. If I may, what encompasses your area of expertise...
BTW Congratulation on becoming a committer!
Regards
Ashish
On Mon, 7 Dec 2009, Robert Haas wrote:
On Sun, Dec 6, 2009 at 9:24 PM, abin...@u.washington.edu wrote:
2. Would someone be willing to be a mentor? It would be
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 7, 2009 at 9:48 AM, Bruce Momjian br...@momjian.us wrote:
I wonder if we should rephrase this as, How hard will this feature be
to add, and how hard will it be to remove in a few years if we decide we
don't want it?
Yes,
David Fetter da...@fetter.org writes:
It's not work you personally would have to do, and the confusion we've
already bought with this naming scheme is already evident.
What confusion? The only person complaining is you.
regards, tom lane
--
Sent via pgsql-hackers
Simon Riggs si...@2ndquadrant.com writes:
If we do need to do this, perhaps we should change the older parameter
to be partition_exclusion.
Yeah, if we do want to do something about this then changing the name of
the existing GUC would be a lot less work. However, partition_exclusion
seems to
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Yes, I think that's the right way to think about it. At a guess, it's
two man-months of work to get it in, and ripping it out is likely
technically fairly simple but will probably be politically
On Mon, 2009-12-07 at 21:28 +0200, Heikki Linnakangas wrote:
The changes to ReadRecord in the streaming replication patch feel a
bit awkward, because it has to work around the fact that WAL is
streamed as a stream of bytes, but ReadRecord works one page at a
time. I'd like to replace
On 12/7/09 5:17 PM, Tom Lane wrote:
David Fetter da...@fetter.org writes:
It's not work you personally would have to do, and the confusion we've
already bought with this naming scheme is already evident.
What confusion? The only person complaining is you.
Actually, he has a very good
Robert Haas wrote:
On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian br...@momjian.us wrote:
As Alvaro mentioned, the original patch used ACE but it added too much
code so the community requested its removal from the patch. It could be
re-added if we have a need.
Well, there's no point in
On Mon, 07 Dec 2009 20:20:45 -0500 Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
If we do need to do this, perhaps we should change the older parameter
to be partition_exclusion.
Yeah, if we do want to do something about this then changing the name of
the existing GUC would
Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
If we do need to do this, perhaps we should change the older parameter
to be partition_exclusion.
Yeah, if we do want to do something about this then changing the name of
the existing GUC would be a lot less work. However,
On Mon, 2009-12-07 at 23:12 -0300, Alvaro Herrera wrote:
Perhaps
table_exclusion = {on, off, partition}
Sounds good to me.
Of course, constraint_exclusion should continue to work as a synonym for
backwards compatibility, but it wouldn't be documented.
+1.
Regards,
Jeff Davis
--
On Mon, 2009-12-07 at 17:41 -0800, Josh Berkus wrote:
Actually, he has a very good point; we're going to get a *lot* of
confusion from the users on this one. I just wish I'd noticed the issue
before.
The issue has been mentioned several times, but must have gotten lost
among the other emails.
I could not find the message from David P. Quigley in the list,
although pgsql-hackers@postgresql.org was Cc:'ed.
(something troubled?)
So, I'll send it again for your information.
Original Message
Subject: Re: [HACKERS] Adding support for SE-Linux security
Date: Mon, 07 Dec
KaiGai Kohei escribió:
I could not find the message from David P. Quigley in the list,
although pgsql-hackers@postgresql.org was Cc:'ed.
(something troubled?)
Weird. It didn't even made it to the moderator queue for some reason.
Perhaps the system dropped it as spam.
So, I'll send it again
Here is an updated patch per discussion.
* Counters are accumulative. They contain I/Os by child nodes.
* Text format shows all counters.
* Add shared_ prefix to variables representing shared buffers/blocks.
Euler Taveira de Oliveira eu...@timbira.com wrote:
Itagaki Takahiro escreveu:
On Mon, Dec 7, 2009 at 9:12 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
If we do need to do this, perhaps we should change the older parameter
to be partition_exclusion.
Yeah, if we do want to do something about this then
On Mon, Dec 7, 2009 at 9:58 PM, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Here is an updated patch per discussion.
* Counters are accumulative. They contain I/Os by child nodes.
* Text format shows all counters.
* Add shared_ prefix to variables representing shared
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I was in fact prepared to commit this patch, despite some significant
misgivings about its wisdom, mainly because it does have such a low
impact. But then other people raised objections. I'm not sure how strong
those objections
2009/12/7 黄晓骋 huangxcl...@gmail.com:
I’m a student from Nankai University in China. Now I and my team do a
project which aims to integrate XML to Postgresql. What I do is to complete
the function of XML Update.
Now I’m researching in concurrency control. I have read the code about the
On Mon, Dec 7, 2009 at 8:33 AM, marcin mank marcin.m...@gmail.com wrote:
The current behavior of levenshtein(text,text,int,int,int) is wrong. Consider:
Is this the same problem as bug #5098?
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Mon, Dec 7, 2009 at 8:04 PM, Ashish abin...@u.washington.edu wrote:
Hi Robert,
Thanks. If I may, what encompasses your area of expertise...
BTW Congratulation on becoming a committer!
Thanks. As others have said, it's probably best to pick a project
first, or at least an area. It's more
David P. Quigley wrote:
Not to start a flame war here about access control models but you gave 3
different examples one of which I don't think has any means to do
anything productive here.
You won't be starting a flame war for the same reason some of the
community members are so concerned about
On Sun, Dec 6, 2009 at 9:04 AM, Greg Smith g...@2ndquadrant.com wrote:
And that won't work at all. Buffer is a structure, not an integer. You
need to wait until it's been locked, then save the same data as on the read
side (relation and block number) from inside the structure. You probably
Robert Haas wrote:
On Mon, Dec 7, 2009 at 9:58 PM, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Obviously I should not hide any information only in the text format.
The new output will be: (in one line)
Shared Blocks: (hit=2 read=1641 written=0) Local Blocks: (hit=0 read=0
On Mon, Dec 7, 2009 at 11:09 PM, Greg Smith g...@2ndquadrant.com wrote:
Robert Haas wrote:
On Mon, Dec 7, 2009 at 9:58 PM, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Obviously I should not hide any information only in the text format.
The new output will be: (in one line)
Hello,
I think in Postgresql, concurrency control acts like this:
tuple's infomask shows if it is being updated. If it is being updated now,
the latter transaction should reread the tuple and get the newer tuple.
During the progress of getting the newer tuple, it must use transaction
lock, I
Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 7, 2009 at 11:09 PM, Greg Smith g...@2ndquadrant.com wrote:
(1) Blocks Shared: (hit=2 read=1641 written=0) Local: (hit=0 read=0
written=0) Temp: (read=1443 written=1443)
I could live with the equals signs, but the use of parentheses
Robert Haas wrote:
I could live with the equals signs, but the use of parentheses seems
weird and inconsistent with normal english usage (which permits
parentheses as a means of making parenthetical comments).
But it is consistent with people seeing:
Seq Scan on foo (cost=0.00..155.00
2009/12/7 黄晓骋 huangxcl...@gmail.com:
Hello,
I think in Postgresql, concurrency control acts like this:
tuple's infomask shows if it is being updated. If it is being updated now,
the latter transaction should reread the tuple and get the newer tuple.
During the progress of getting the newer
Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
In particular I wonder why we bother with the page headers.
Since we re-use the file for a new segment, without overwriting the
old contents, it seems like we
Itagaki Takahiro escreveu:
Here is an updated patch per discussion.
* Counters are accumulative. They contain I/Os by child nodes.
* Text format shows all counters.
* Add shared_ prefix to variables representing shared buffers/blocks.
Nice. Despite of the other opinions, I'm
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
In particular I wonder why we bother with the page headers. A much
simpler format would be:
- get rid of page headers, except for the header at the beginning of
each WAL segment
- get rid of continuation records
Jonas J wrote:
I took a look in the code again and made some changes. For the
readBuffer im doing now:
ReadBuffer(Relation reln, BlockNumber blockNum)
fprintf(fp,r%u\n,(unsigned int) blockNum); //as defined in
header, typedef uint32 BlockNumber;
and from the write pages:
On Tue, Dec 8, 2009 at 10:28 AM, Simon Riggs si...@2ndquadrant.com wrote:
If this was earlier in the release cycle, I'd feel happier.
2.5 months before beta is the wrong time to re-design the crash recovery
data format, especially because its only a bit awkward. We're bound to
break something
* Alvaro Herrera:
Florian Weimer escribió:
* Dimitri Fontaine:
Well we have JSON and agreed it was a good idea to have it. Now JSON is
a subset of YAML and some would prefer another YAML style (me included).
YAML is rather difficult to parse, and most parsers assume a trusted
document
On Tue, Dec 8, 2009 at 4:10 AM, Robert Haas robertmh...@gmail.com wrote:
The current behavior of levenshtein(text,text,int,int,int) is wrong.
Consider:
Is this the same problem as bug #5098?
Yes. Exact same change, plus the shortcut evaluation (for when one of
the inputs is empty) was also
101 - 147 of 147 matches
Mail list logo
