And I wanted to know what type of data structures are created by the parser
/ planner and how are they read by the executor.
I know that it is some sort of tree. But how many child nodes are there in a
node on the tree and what structure is the NODE itself of?
Which files should I look into to ge
On Mon, Nov 1, 2010 at 8:32 PM, Heikki Linnakangas
wrote:
> Yeah, that's one approach. Another is to validate the TLI in the xlog page
> header, it should always match the current timeline we're on. That would
> feel more robust to me.
Yeah, that seems better.
> We're a bit fuzzy about what TLI
I have worked on some improvements on how we handle recursive make in
our makefiles. Most places uses for loops, which has some
disadvantages: parallel make doesn't work across directories, make -k
doesn't work, and make -q doesn't work. Instead, I went with the
approach that we already use in th
Hello,
I think that I want to get indulged in development. Have gone through the
code a bit, Unable to understand so might need some help over there. I hope
I will recieve help.
What version should I start from? I guess postgresql 9.1 alpha would be
good.
Please suggest some other dev version (i
Now that we have MergeAppend in place, it strikes me that the current
support for implementing MIN() and MAX() via indexscan+LIMIT subplans
could be generalized to work on inheritance trees: a MergeAppend
plan plus LIMIT would just about do it.
However, extending the existing implementation in pla
2010/11/2 Tom Lane :
> Hitoshi Harada writes:
>> I wonder why SortState is a ScanState. As far as I know ScanState
>> means the node may need projection and/or qualification, or it scans
>> some relation, but Sort actually doesn't do such things.
>
> No, not really. Per the comment for ScanState:
On Tue, Nov 2, 2010 at 8:43 AM, Hiroshi Inoue wrote:
> The problem which was fixed by your old patch is at runtime not
> at compilation time. Is it fixed with gcc 4.5?
Now it works as far as simple test, including core functions and
dynamic modules. So, I think the fix for dllexport is safe enoug
Hitoshi Harada writes:
> I wonder why SortState is a ScanState. As far as I know ScanState
> means the node may need projection and/or qualification, or it scans
> some relation, but Sort actually doesn't do such things.
No, not really. Per the comment for ScanState:
*ScanState extends
I wonder why SortState is a ScanState. As far as I know ScanState
means the node may need projection and/or qualification, or it scans
some relation, but Sort actually doesn't do such things. I also tried
to modify SortState as PlanState as in the attached patch and
regression test passed. Do I mis
On Tuesday 02 November 2010 01:37:43 Andres Freund wrote:
> Revised version attached - I will submit this to the next comittfest now.
Context diff attached this time...
diff --git a/src/backend/utils/adt/int.c b/src/backend/utils/adt/int.c
index c450333..5340052 100644
*** a/src/backend/utils/adt/i
On Mon, Nov 1, 2010 at 16:59, Tom Lane wrote:
> Alex Hunsaker writes:
>> Speaking of which, pltcl stores the trigger reloid instead of a flag
>> (it also uses tg_reloid in the internal proname). It seems a tad
>> excessive to have one function *per* trigger table.
>
> Surely, removing the intern
Hi,
On Monday 01 November 2010 10:15:01 Andres Freund wrote:
> On Monday 01 November 2010 04:04:51 Itagaki Takahiro wrote:
> > On Mon, Nov 1, 2010 at 6:41 AM, Andres Freund wrote:
> > > While looking at binary COPY performance I forgot to add BINARY and was
> > > a bit shocked to see printf that
(2010/11/02 8:31), Itagaki Takahiro wrote:
On Tue, Nov 2, 2010 at 6:02 AM, Hiroshi Inoue wrote:
1. warning: '' redeclared without dllimport attribute:
previous dllimport ignored
Is it safe to put back the patch you applied in
http://archives.postgresql.org/pgsql-committers/2010-05/msg00338.ph
On Tue, Nov 2, 2010 at 6:02 AM, Hiroshi Inoue wrote:
>> 1. warning: '' redeclared without dllimport attribute:
>> previous dllimport ignored
>
> Is it safe to put back the patch you applied in
> http://archives.postgresql.org/pgsql-committers/2010-05/msg00338.php
> in the case __GNUC__ >=4?
Hmmm,
On Mon, Nov 1, 2010 at 2:29 PM, Kevin Grittner
wrote:
> Jeff Davis wrote:
>
>> Seriously though, I think that we should stick as closely to the
>> letter of the standard as possible here (or, if there is
>> ambiguity, pick one reasonable interpretation). NULL semantics are
>> confusing enough wit
Alex Hunsaker writes:
> Speaking of which, pltcl stores the trigger reloid instead of a flag
> (it also uses tg_reloid in the internal proname). It seems a tad
> excessive to have one function *per* trigger table. I looked through
> the history to see if there was some reason, it goes all the wa
Greg Stark writes:
> On Mon, Nov 1, 2010 at 12:37 AM, Heikki Linnakangas
> wrote:
>> Yes, indeed there is a corner-case bug when you try to stream the very first
>> WAL segment, with log==seg==0.
> This smells very much like
> http://article.gmane.org/gmane.comp.db.postgresql.devel.general/13705
On Mon, Nov 1, 2010 at 15:24, Alex Hunsaker wrote:
houldn't cache any of the setup but just redo it all every time.
>
> Huh? I might try and argue that if the new test was more complex than
> 2 compares :P. In-fact the way it stands now we uselessly grab the
> functions pg_proc entry in the comm
On Mon, Nov 1, 2010 at 09:28, Tom Lane wrote:
> I think the crash is dependent on the fact that the function is created
> and called in the same session. That means the validator gets called on
> it first, and the validator not unreasonably assumes istrigger = true,
> and then it calls compile_pl
>Hmm. I am reminded of Knuth's famous dictum: "never generate random
numbers with a method chosen at random". Is there any actual theory
behind that algorithm, and if so what is it? The combination of
shifting with addition (not xor) seems more likely to lead to weird
cancellations than any impr
(2010/11/01 19:24), Itagaki Takahiro wrote:
I compiled the source with mingw gcc 4.5.0, that has been released recently.
The compile was succeeded and worked well at least for simple queries,
but there were many warnings during the compile.
1. warning: '' redeclared without dllimport attribu
On Mon, 2010-11-01 at 20:36 +0100, Dimitri Fontaine wrote:
> "Kevin Grittner" writes:
> > Would you be comfortable writing that '012[3-5]' range as
> > '[0123, 0126)' or something similar? What benefits do you see to
> > using a range for prefixes versus a regular expression?
>
> Your proposed s
On Mon, Nov 1, 2010 at 12:37 AM, Heikki Linnakangas
wrote:
> Yes, indeed there is a corner-case bug when you try to stream the very first
> WAL segment, with log==seg==0.
This smells very much like
http://article.gmane.org/gmane.comp.db.postgresql.devel.general/137052
I wonder if there's some de
Heikki Linnakangas wrote:
Yes, indeed there is a corner-case bug when you try to stream the very
first WAL segment, with log==seg==0.
I confirmed that the bug exists in only this case by taking my problem
install and doing this:
psql -d postgres -c "checkpoint; select pg_switch_xlog();"
To
"Kevin Grittner" writes:
> Would you be comfortable writing that '012[3-5]' range as
> '[0123, 0126)' or something similar? What benefits do you see to
> using a range for prefixes versus a regular expression?
Your proposed syntax would do fine, sure. Something like this is even on
the TODO list
Jeff Davis wrote:
> Seriously though, I think that we should stick as closely to the
> letter of the standard as possible here (or, if there is
> ambiguity, pick one reasonable interpretation). NULL semantics are
> confusing enough without everyone making their own subtle tweaks.
+1
If the s
On Mon, 2010-11-01 at 09:44 -0500, Jim Nasby wrote:
> > My take on this is that we are stuck with the status quo. If a
> change
> > must be done, the 'is null' change should be reverted to un-standard
> > behavior. The SQL standard position on this issue is, IMNSHO, on
> > mars.
>
> As someone w
Jim Nasby writes:
> (looking at original case)... the original bug wasn't actually
> recursive.
No, there are two different cases being dealt with here. If the first
call of an expression results in an error, and then we come back and try
to re-use the expression state tree, we can have trouble
On Oct 28, 2010, at 11:41 AM, Merlin Moncure wrote:
> On Thu, Oct 28, 2010 at 10:15 AM, Tom Lane wrote:
>> Pavel Stehule writes:
>>> I am checking PLpgSQL ToDo topics, and I am not sure if this topic
>>> isn't done. And if not, then I would to get some detail.
>>
>> I think that thread petered o
UNIQUE constraints suffer from the same behavior; feel like fixing that too? :)
On Oct 9, 2010, at 1:07 PM, Gurjeet Singh wrote:
> This is a continuation from this thread:
> http://archives.postgresql.org/pgsql-hackers/2010-09/msg02153.php
>
> The attached patch allows creating a primary key us
On Oct 29, 2010, at 10:54 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Tom Lane's message of mié oct 27 18:18:06 -0300 2010:
>>> I spent quite a bit of time trying to deal with the memory-leakage
>>> problem without adding still more bookkeeping overhead. It wasn't
>>> looking go
On 11/01/2010 11:28 AM, Tom Lane wrote:
The fundamental issue here is that the contents of plperl_proc_desc
structs are different between the trigger and non-trigger cases.
Unless you're prepared to make them the same, and guarantee that they
always will be the same in future, I think that in
Robert Haas writes:
> On Fri, Oct 29, 2010 at 7:33 PM, Marti Raudsepp wrote:
>> patch 0001 turns (a - b == 0) into (a == b) and similarly with !=
>> patch 0002 applies the same to operators >, >=, <, <=
>>
>> I'm well aware that there's a point where code cleanups defeat their
>> purpose and bec
Andrew Dunstan writes:
> On 10/31/2010 04:40 PM, Alex Hunsaker wrote:
>> which happens because prodesc->result_in_func.fn_addr (flinfo) is
>> NULL. That happens because when we are a trigger we don't setup
>> input/output conversion. And with the change we get the same
>> proc_desc for triggers
I wrote:
> I haven't looked to see if any of these have an excessive amount of
> local variables.
I poked through the call stack and found that the only function in
this nest that seems to have a large amount of local variables is
ExecMakeFunctionResult(). The space hog there is the local
Functio
I wrote:
> samples %symbol name
> 447433 47.1553 get_tabstat_entry
> 185458 19.5456 find_all_inheritors
> 53064 5.5925 SearchCatCache
> 33864 3.5690 pg_strtok
> get_tabstat_entry and find_all_inheritors are both obviously O(N^2) in
> the number of tables they have to deal
On 01.11.2010 12:32, Fujii Masao wrote:
A related issue is that we should have a check for the issue I also
mentioned in the comments:
/*
* If the current timeline is not part of the history of the
* new timeline, we cannot proceed to it.
*
* XXX This
On Wed, Oct 27, 2010 at 11:42 PM, Heikki Linnakangas
wrote:
> At the moment, when you specify recovery_target_timeline='latest', we scan
> for the latest timeline at the beginning of recovery, and pick that as the
> target. If new timelines appear during recovery, we stick to the target
> chosen i
I compiled the source with mingw gcc 4.5.0, that has been released recently.
The compile was succeeded and worked well at least for simple queries,
but there were many warnings during the compile.
1. warning: '' redeclared without dllimport attribute:
previous dllimport ignored
2. warning: unk
On Mon, Nov 1, 2010 at 5:17 PM, Heikki Linnakangas
wrote:
> Committed that. Thanks for the report, both of you. I'm not subscribed to
> pgsql-admin which is why I didn't see Matt's original report.
Thanks!
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Softw
On Monday 01 November 2010 04:04:51 Itagaki Takahiro wrote:
> On Mon, Nov 1, 2010 at 6:41 AM, Andres Freund wrote:
> > While looking at binary COPY performance I forgot to add BINARY and was a
> > bit shocked to see printf that high in the profile...
> >
> > A change from 9192.476ms 5309.928ms se
On 01.11.2010 09:37, Heikki Linnakangas wrote:
On 31.10.2010 23:31, Greg Smith wrote:
LOG: replication connection authorized: user=rep host=127.0.0.1
port=52571
FATAL: requested WAL segment 0001 has already been
removed
Which is confusing because that file is certainly on th
On 31.10.2010 23:31, Greg Smith wrote:
LOG: replication connection authorized: user=rep host=127.0.0.1 port=52571
FATAL: requested WAL segment 0001 has already been
removed
Which is confusing because that file is certainly on the master still,
and hasn't even been considered
43 matches
Mail list logo
