On 01.11.2010 05:21, Robert Haas wrote:
There seem to be two cases in the code that can generate that error.
One, attempting to open the file returns ENOENT. Two, after the data
has been read, the last-removed position returned by
XLogGetLastRemoved precedes the data we think we just read,
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
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
On Monday 01 November 2010 04:04:51 Itagaki Takahiro wrote:
On Mon, Nov 1, 2010 at 6:41 AM, Andres Freund and...@anarazel.de 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
On Mon, Nov 1, 2010 at 5:17 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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: 'symbol' redeclared without dllimport attribute:
previous dllimport ignored
2.
On Wed, Oct 27, 2010 at 11:42 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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,
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
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 with.
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
Andrew Dunstan and...@dunslane.net 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
Robert Haas robertmh...@gmail.com writes:
On Fri, Oct 29, 2010 at 7:33 PM, Marti Raudsepp ma...@juffo.org 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
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
On Oct 29, 2010, at 10:54 AM, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
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 using
On Oct 28, 2010, at 11:41 AM, Merlin Moncure wrote:
On Thu, Oct 28, 2010 at 10:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com 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.
Jim Nasby j...@nasby.net 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
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 who's
Jeff Davis pg...@j-davis.com 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.
Kevin Grittner kevin.gritt...@wicourts.gov 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
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
On Mon, Nov 1, 2010 at 12:37 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Mon, 2010-11-01 at 20:36 +0100, Dimitri Fontaine wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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?
(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: 'symbol' redeclared without dllimport
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
On Mon, Nov 1, 2010 at 09:28, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Nov 1, 2010 at 15:24, Alex Hunsaker bada...@gmail.com 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
Greg Stark gsst...@mit.edu writes:
On Mon, Nov 1, 2010 at 12:37 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
Alex Hunsaker bada...@gmail.com 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
On Mon, Nov 1, 2010 at 2:29 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Jeff Davis pg...@j-davis.com 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
On Tue, Nov 2, 2010 at 6:02 AM, Hiroshi Inoue in...@tpf.co.jp wrote:
1. warning: 'symbol' 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
(2010/11/02 8:31), Itagaki Takahiro wrote:
On Tue, Nov 2, 2010 at 6:02 AM, Hiroshi Inouein...@tpf.co.jp wrote:
1. warning: 'symbol' redeclared without dllimport attribute:
previous dllimport ignored
Is it safe to put back the patch you applied in
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 and...@anarazel.de wrote:
While looking at binary COPY performance I forgot to add BINARY and was
a bit shocked to see
On Mon, Nov 1, 2010 at 16:59, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com 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.
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
***
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
Hitoshi Harada umi.tan...@gmail.com 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 in...@tpf.co.jp 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
2010/11/2 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com 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.
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
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 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
On Mon, Nov 1, 2010 at 8:32 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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.
43 matches
Mail list logo
