> "Heikki" == Heikki Linnakangas writes:
>> Also, receivexlog is ignoring .partial and .history files when
>> determining which timeline to start streaming from, which means
>> that if there are two timeline changes that are not separated by a
>> WAL segment switch, it will fail to operat
Seems clearly your mistake to me... you do realize that (null + z) is
always going to be null, right? Maybe your totals columns should have
been declared NOT NULL (and presumably DEFAULT 0) to avoid this
problem?
Adding some diagnostics to your function (and fixing all the syntax
errors) and runni
> "Tom" == Tom Lane writes:
>> The gist one is just that the old code was abusing DatumGetHStoreP
>> by applying it to something that wasn't an hstore. This didn't
>> matter before the format upgrade code was put in, and it didn't
>> show up in tests because you need to index a very large
> "Tom" == Tom Lane writes:
>> Two small fixes for hstore-new.
>> The hstore_compat one is arguable as to what is the best approach; the
>> assert that was there was just wrong, but I have been unable after
>> considerable searching to find any architectures that would fail the
>> check.
Two small fixes for hstore-new.
The hstore_compat one is arguable as to what is the best approach; the
assert that was there was just wrong, but I have been unable after
considerable searching to find any architectures that would fail the
check. The version in this patch will just treat any old-fo
>>>>> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> I don't think it's particularly closely related to #4907.
Tom> Yeah.
BTW, did #4907 ever get fixed in the back branches?
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs m
> "David" == "David Gardner" writes:
David> The following bug has been logged online:
David> Bug reference: 5240
David> Logged by: David Gardner
David> Email address: dgard...@creatureshop.com
David> PostgreSQL version: 8.4.1
David> Operating system: Debian Linux,
> "Robert" == Robert Haas writes:
> On Thu, Dec 10, 2009 at 1:46 AM, Tom Lane wrote:
>>
>> My reading of the spec is that USING (and therefore NATURAL) is
>> defined to join identically named columns. Â Therefore, renaming
>> one of the input columns as the OP did *should* indeed *must*
>>>>> "Andrew" == Andrew Gierth writes:
Andrew> What are the definitions of your instr() and ad_parent_tree()
Andrew> functions?
Well, there's so much wrong with that ad_parent_tree function - it's
always going to recurse infinitely (with a new subxact
> "Oleg" == Oleg Jurtšenko writes:
Oleg> I tried to execute "select instr(ad_parent_tree(?,?),'|'||'?'||'|') AS
Oleg> isItsOwnChild from dual;" query with psql terminal and got
Oleg> segmentation fault as well.
Oleg> The most interesting thing is that this function makes segmentation
Ol
> "Robert" == Robert Haas writes:
Robert> How about (3) getrlimit(RLIMIT_STACK) lies through its teeth,
Robert> by ignoring the existence of another and lower limit imposed
Robert> elsewhere?
Robert> A little Googling seems to reveal that FreeBSD has a
Robert> parameter called MAXSSIZ (
> "Pavel" == Pavel Stehule writes:
>> As discussed on the irc. I had a problem with a utility function
>> that was being passed a NEW row and a null for the OLD row. The
>> error was created when it tries to store the row variable in the
>> local variables. RhodiumToad on the list provide
> "Tom" == Tom Lane writes:
Tom> The conversion itself is dependent on changeable catalog
Tom> entries, ie, pg_conversion. So "stable" seems the appropriate
Tom> marking to me.
>> That sounds like a bit of a stretch to me... we treat lots of
>> stuff as immutable which is actually easi
> "Tom" == Tom Lane writes:
>> convert_to is a builtin function. If there's a bug here, it's that
>> convert_to is defined as stable rather than immutable. (Sure it
>> depends on server_encoding, but that can't exactly change... if
>> there's any other reason why it's not immutable, I can
> "Peter" == Peter Eisentraut writes:
>> I have table with bytea column, which is indexed (1)
>> I want to use index during pattern matching (eg. dir like
>> someDirectoryName
>> || '/%'), but concatenation of two strings cause error (2)
>> So I have to use function convert_to (convertin
> "dan" == "dan" writes:
dan> I expect the explain to say index scan; instead it says table scan.
dan> The index has ALL the info I need
It may have all the info _you_ need, but what it doesn't have is all the
info that _postgres_ needs; specifically it doesn't contain enough row
visibili
> "Joshua" == Joshua Tolley writes:
>> > To pick a recent case, bug #5085 was submitted by an IRC user (at my
>> > suggestion) at 2009-09-28 22:12 +, or a bit over 22 hours ago as I
>> > write
Joshua> I am a -bugs moderator, and don't see that I ever got a
Joshua> notice that I nee
> "Tom" == Tom Lane writes:
>> They get processed in the moderator queue of -bugs along with all
>> other posts there... We're probably just back in the situation
>> where we need more moderators for it...
Tom> A quick grep in my mail logs shows that since Jan 1, I have
Tom> received 44
The following bug has been logged online:
Bug reference: 5087
Logged by: Andrew Gierth
Email address: and...@tao11.riddles.org.uk
PostgreSQL version: any
Operating system: any
Description:Submitted bug reports not showing up in a timely manner
(or at all)
Details
> "Tom" == Tom Lane writes:
Tom> I'm inclined to think that the best solution is to have
Tom> process_equivalence just reject any clauses that have equal()
Tom> left and right sides, ie, throw them back to be processed as
Tom> ordinary non-equivalence clauses.
>> Hmm. Is it ever possibl
> "Tom" == Tom Lane writes:
Tom> After digging into it, I find that:
Tom> 1. Without ORDER BY, process_equivalence generates an
Tom> equivalence class that lists k twice. This is pretty bogus but
Tom> it happens to produce the desired results in the example at
Tom> hand. (In some othe
> Bernt Marius Johnsen wrote:
>> Dump of the database:
To save anyone else the bother, there's a VASTLY simpler testcase for
this one, requiring no tables at all:
test1=# explain select * from (values (1),(null)) v(k) where k = k order by k;
QUERY PLAN
> "Bryan" == "Bryan McLemore" writes:
Bryan> "invalid page header in block 900 of relation
pg_tblspc/32041/138911/187737"
Bryan> http://pgsql.privatepaste.com/83JfmQGtS5
Privatepaste urls do expire, so for the record here is the relevant
part of the data in question:
82 00 00
The following bug has been logged online:
Bug reference: 5053
Logged by: Andrew Gierth
Email address: and...@tao11.riddles.org.uk
PostgreSQL version: 8.5devel
Operating system: FreeBSD
Description:domain constraints still leak
Details:
Domain NOT NULL constraints
> "Greg" == Greg Stark writes:
Greg> Either of two things are true.
Greg> Either transaction 6179 committed,
[snip]
This is all missing the point. The row should have been killed by
transaction 4971, NOT 6179. By the time transaction 6179 tried to
do anything with it, it was almost certain
> "Tom" == Tom Lane writes:
> "Robert Treat" writes:
>> PostgreSQL version: 8.3.1
>> Description:Corrupted pg_class, possibly truncate/rollback related
Tom> FWIW, there is a bug fix in 8.3.4 addressing possible HOT-chain
Tom> corruption after a REINDEX of pg_class. Not sure if
> "Robert" == "Robert Treat" writes:
Robert> Bug reference: 4929
Robert> Logged by: Robert Treat
Robert> Email address: xzi...@users.sourceforge.net
Robert> PostgreSQL version: 8.3.1
pe2=# select xmin, xmax, cmin, cmax, ctid, oid, relnamespace, relname,
reltype, relow
> "Tom" == Tom Lane writes:
>> The system was recently dump/restored from a different box. The
>> failing rows are all new inserts since the restore.
Tom> So the table has been insert-only so far? I was just thinking
Tom> that HOT bugs seemed like a probable explanation, but that idea
> "Tom" == Tom Lane writes:
>> Notice that the two rows seem entirely independent (different
>> xmin). The OP stated that his app generally does single-row
>> inserts (with some exceptions not relevent here); however, we
>> found a nearby row which shares the xmin:
Tom> How is the time
> "Mathieu" == "Mathieu De Zutter" writes:
Mathieu> I have a table log_event with a primary key on an integer
Mathieu> 'id', called log_event_pkey.
Mathieu> The tables contains a duplicate for id = 15723018. The
Mathieu> duplicate (note that besides the id, all data differs)
Mathieu> do
The following bug has been logged online:
Bug reference: 4821
Logged by: Andrew Gierth
Email address: and...@tao11.riddles.org.uk
PostgreSQL version: 8.3-8.4
Operating system: all
Description:LIKE '%_' fails
Details:
# select 'foo'
The following bug has been logged online:
Bug reference: 4553
Logged by: Andrew Gierth
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3-8.4
Operating system: all
Description:HOLD cursors not materializing results fully
Details:
(tested on 8.3.5 and HEAD as
> "Pavel" == "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> Well, changing the semantics of an already-released statement
>> carries a risk of breaking existing apps that aren't expecting it
>> to change FOUND. So I'd want to see a pretty strong case why this
>> is important --- not just
> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes:
Alex> I submitted http://rt.perl.org/rt3/Public/Bug/Display.html?id=60374
Feel free to add my explanation to that (I couldn't see an obvious way
to do it myself)
--
Andrew.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.o
> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes:
>> Then explain why the problem goes away when you build perl with
>> threading turned off.
Alex> Hrm yep i built one without threads problem disappears... Guess
Alex> Ive just been out to lunch :)
If it helps any, I've tracked down i
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
>> Nice theory, but completely wrong: sort creates $a and $b in the
>> current package, not in main::.
Tom> Hmm ... so then why are we seeing a failure?
FWIW, I _don't_ see the failure. It seems to occur ONLY if perl was
built with threading
> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes:
>> Hmm ... so then why are we seeing a failure?
[...]
Alex> This is not a Safe bug IMHO its our (ab)use of it that is
Alex> causing the problem.
Then explain why the problem goes away when you build perl with
threading turned off.
--
> "nathan" == nathan wagner <[EMAIL PROTECTED]> writes:
nathan> Completely untested speculation based on my knowledge of perl
nathan> and a bit of reading:
nathan> The reason you can't see $a and $b is that sort internally
nathan> sets these variables in the main package. That is, sort i
38 matches
Mail list logo
