POSTGRESQL BUG REPORT TEMPLATE
Your name : mason
Your email address : mason (at) vanten.com
System Configuration
On Wed, Aug 26, 2009 at 02:55:37PM +, Ken Smith wrote:
> I also noted
> that if I try to run from the commandline that you use '/' in some of the
> program paths causing the OS to say it cannot find the file - "C:/Program
> Files/Java/jdk1.5.0_16/jre/bin/java.exe".
I'm pretty sure that Windows
On Fri, Aug 28, 2009 at 02:06:02PM -0400, Merlin Moncure wrote:
> 3) If we decide the sql standard is correct, so that (null, null) is
> null == true, then we should observe rule 1 and make things work in
> consistent way. This means, for example, that null::foo and (null,
> null)::foo should not
On Mon, Aug 31, 2009 at 07:26:59PM +0200, Pavel Stehule wrote:
> 2009/8/31 Sam Mason :
> > The more awkward case (to me anyway) is that the standard says (1,NULL)
> > IS NULL should evaluate to TRUE.
>
> what?
>
> only (NULL, NULL) IS NULL is true
Bah, sorry you&#
On Tue, Sep 01, 2009 at 04:36:25PM +, Joseph Shraibman wrote:
> Description:CASE returns ELSE value always when type is "char"
I think it's just silently truncating the literal to a single character.
> [local]:playpen=> select c.relkind, CASE c.relkind WHEN 'r' THEN 'table'
> WHEN 'v'
On Tue, Sep 01, 2009 at 05:49:25PM +0100, Sam Mason wrote:
> PG could maybe throw an error to tell you this is
> what is happening?
Would something like the included patch be accepted?
--
Sam http://samason.me.uk/
*** src/backend/utils/adt/char.c~ 2009-01-01 17:23:49.0 +
-
On Wed, Sep 02, 2009 at 03:50:05PM +0100, Greg Stark wrote:
> Perhaps we should stop thinking of "unknown" as, er, "unknown" and
> think of it as "text literal". A text literal has implicit casts to
> every data type but a normal text string has to be explicitly cast.
How does that help things? Y
On Wed, Sep 02, 2009 at 12:36:00PM -0400, Robert Haas wrote:
> On Wed, Sep 2, 2009 at 11:55 AM, Sam Mason wrote:
> > In fact it doesn't seem to want to play ball at all. Even given the
> > apparently unambiguous:
> >
> > SELECT 1+add(1,2);
> > or
> >
On Wed, Sep 02, 2009 at 01:19:07PM -0400, Tom Lane wrote:
> Sam Mason writes:
> > ... For example:
>
> > CREATE FUNCTION add(int,int) RETURNS int LANGUAGE sql
> > AS $$ SELECT $1 + $2; $$;
>
> > CREATE FUNCTION add(int,int,int DEFAULT NULL) RET
On Wed, Sep 02, 2009 at 12:54:03PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > If we did follow Kevin's request directly, should we also be
> > specifying the type of NULL?
>
> I don't *think* the SQL standard requires that, and barring that I
> don&#
On Wed, Sep 02, 2009 at 01:27:35PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > you were requiring the types of literals that happened to be
> > enclosed in quotes to have their type ascribed, so why not the NULL
> > literal?
>
> Well, unless things have ch
On Wed, Sep 02, 2009 at 01:55:28PM -0500, Kevin Grittner wrote:
> So the behavior of the "char" type is anomalous in this regard? Other
> character-based types behave like varchar (which has the behavior I
> would expect here)? That is encouraging. Why isn't the behavior of
> "char" in this rega
On Wed, Sep 02, 2009 at 01:37:20PM -0500, Kevin Grittner wrote:
> That still seems to be the case in the draft of the 2003 standard I
> have:
>
> ::=
>
> |
> |
> |
> |
> |
> |
> ::=
> [ ]
> [ ... ]
> [ { [ ... ]
> }... ]
>
> The ball's in your court to
On Wed, Sep 02, 2009 at 12:54:03PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > If we did follow Kevin's request directly, should we also be
> > specifying the type of NULL?
>
> I don't *think* the SQL standard requires that, and barring that I
> don&#
On Wed, Sep 02, 2009 at 02:41:32PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
>
> > I'd always thought '2001-01-01' was a valid date literal, seems the
> > standard has required it to be prefixed by DATE at least back to
> > SQL92.
>
> Yep.
On Wed, Sep 02, 2009 at 02:59:54PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > CREATE VIEW v (c) AS
> > SELECT NULL;
> >
> > PG allows it, but the resulting view seems somewhat unusable.
>
> I'm not sure whether the only place the s
On Fri, Sep 04, 2009 at 10:59:48AM -0500, Kevin Grittner wrote:
> Tom Lane wrote:
> > I certainly don't want to have "char" emulate the misbegotten
> > decision to have explicit and implicit coercions behave differently.
> > So it looks to me like the argument to make "char" work like char(1)
> >
On Fri, Sep 04, 2009 at 12:26:19PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > Kevin Grittner wrote:
> >> test=# select case when true then 'xxx' else 'a'::"char" end from t;
> >
> > 'xxx' is being used to initia
On Fri, Sep 04, 2009 at 02:01:07PM -0500, Kevin Grittner wrote:
> > "char" is no different other than, by default, it happens to look a
> > lot like any value of text type.
>
> So much so that it has the same name as a text type (wrapped in
> quotes) and behaves a lot like one:
You're getting bi
On Mon, Sep 14, 2009 at 11:16:23AM -0400, Robert Haas wrote:
> I haven't read the code in this area, but for what it's worth, I guess
> I lean toward the view that treating a row of NULLs as being the same
> thing as an undecorated NULL does not make very much sense.
I agree; when compared to most
On Mon, Sep 14, 2009 at 10:54:07AM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > the deeper problem seems to be that the table was created as:
> >
> > create table test (a tstdom);
> >
> > and not as:
> >
> > create table test (a tstdom n
On Mon, Sep 14, 2009 at 10:22:34AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > It seems like regardless of this discussion you oughtn't to be able to
> > store a NULL into that table column. But maybe I'm just confused.
>
> The system is relying on the not-unreasonable assumption that if it
.
If you need additional information we have saved console logs and logs
files from both the primary and secondary servers.
Thanks for reading this far and any help in tracking down the cause of
this unexpected failure.
cheers,
- Mason
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
on of the trigger file.
Of course the best solution is to avoid this issue entirely. Something as
easy to miss as file permissions should not cause data corruption,
especially in the process meant to fail over from a crashing primary
database.
thanks,
Mason Hale
http://www.onespot.com
direct +1 800
> On Fri, Jan 29, 2010 at 12:03 AM, Mason Hale wrote:
> > Of course the best solution is to avoid this issue entirely. Something as
> > easy to miss as file permissions should not cause data corruption,
> > especially in the process meant to fail over from a crashing primar
nfusing,
hard-to-diagnose issue -- one that easily looks like corruption, but
thankfully is not.
Hopefully if anyone tuning into this thread experiences or hears of similar
fail-over problems in the future (say on IRC), they'll remember to check the
permissions on the trigger file.
Thanks
t's certainly seems unfortunate that we don't
> > handle this case a bit more gracefully.
>
> Yeah. I don't think we can do much better in versions <= 8.3, though we
> should change that unlink() call to cause the FATAL error in a more
> explicit way; it seems accident
The following bug has been logged online:
Bug reference: 5459
Logged by: Mason Hale
Email address: ma...@onespot.com
PostgreSQL version: 8.3.8
Operating system: Redhat EL 5.1-64 bit
Description:Unable to cancel query while in send()
Details:
ISSUE: unable to cancel
The following bug has been logged online:
Bug reference: 2739
Logged by: Mason Hale
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: GNU/Linux 2.6.9-42.0.3.ELsmp
Description:INTERSECT ALL not working
Details:
'INTERSECT ALL'
s is not a bug.Unfortunately the INTERSECT ALL as spec'd and implemented doesn't quite give me what I need. So back to the drawing board for me...best regards,Mason
On 11/6/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Mason Hale" <[EMAIL PROTECTED]> writes:> The query below should
The following bug has been logged online:
Bug reference: 3723
Logged by: Sam Mason
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Linux
Description:dropping an index that doesn't refer to table's columns
Details:
Hi,
On Tue, Nov 06, 2007 at 10:00:43AM -0500, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > Not sure that's enough of a use case to justify not banning it...
>
> Yeah, it probably is.
It's reasonably easy to do this instead:
CREATE TABLE foo (
one INTEGER NOT NULL UNIQUE
The following bug has been logged online:
Bug reference: 3724
Logged by: Mason Hale
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Redhat Linux (kernel: Linux 2.6.18-8.1.15.el5PAE)
Description:Duplicate values added to table despite
On Nov 6, 2007 11:16 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> > However running the same query on the original 8.2.4 database returns
> zero
> > rows:
>
> > prod_1=> select page_id, count(*) from topic
On Nov 6, 2007 1:06 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> >> For that matter, do you still see dups if you prevent use of the index
> >> in the 8.2.5 query? Maybe it's that index that is corrupt.
&
> >> 2. Can you check that there are still 1 (rather than 0) copies of the
> >> rows in the 8.2.5 DB?
>
> > Yes, we have 1 of each row (I kept the most recently updated version of
> > each):
>
> Ah, I forgot that the rows were obviously not identical because of the
> differing updated_at values.
>
ility of unique indexes is becoming somewhat
suspect. Please help. ;-)
thanks in advance,
Mason
On Dec 30, 2007 12:09 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> > Given my experience, the reliability of unique indexes is becoming
> somewhat
> > suspect. Please help. ;-)
>
> Well, as in the previous r
ive server
processes
This seems related to the entry table -- so I wonder if it is related to
this problem?
On Dec 30, 2007 8:23 PM, Mason Hale <[EMAIL PROTECTED]> wrote:
>
>
> On Dec 30, 2007 12:09 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > "Mason Hal
ns used: -i -f -R 1508573
*
* Dump created on: Sun Dec 30 23:18:01 2007
***
Error: Seek error encountered before requested start block <1508573>.
I tried a few other files in the 1-92 range with the same results.
Mason
-12-20 04:14:40 CST () LOG: restored log
file "000104220058" from archive
2007-12-20 04:14:40 CST () LOG: archive recovery complete
2007-12-20 04:24:57 CST () LOG: database system is ready
thanks,
Mason
On Dec 31, 2007 9:48 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> >> I think you misread Mason's post of 20:23 GMT-6 where he says the
> >> created_at values are the *same*, not different. Mason's previ
Tom, I'll send these to you privately.
Mason
On Dec 31, 2007 10:22 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> >> Can you show us all the triggers on this table?
>
> > Here they are:
>
> > Triggers:
>
> Something else interesting about that: the apparent interloper page
> contains just a single WAL record, which appears to be a shutdown
> checkpoint bearing the timestamp "Thu Dec 27 2007, 16:55:01 EST".
> Not sure if Mason can correlate that with any recent activi
On Dec 31, 2007 12:51 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> > If it is some mysterious hardware or kernel error -- any suggestions for
> how
> > I should go about narrowing that down?
>
> The first thing
ed, and those exist on a dedicated disk (not in a
RAID), then doesn't that indicate that the RAID controller is not involved?
Mason
On Tue, Jan 01, 2008 at 08:11:01PM +, Ion wrote:
> Email address: [EMAIL PROTECTED]
lets hope Ion is subscribed! :)
> I tested PostgreSQL 8.3 beta4 with tinyerp and I have this problem:
> pg_catalog.substring(date, integer, integer) does not exist
This is most likely a bug in tinyerp. s
On Tue, Jan 01, 2008 at 04:29:47PM -0500, Tom Lane wrote:
> Sam Mason <[EMAIL PROTECTED]> writes:
> > I've just downloaded the source of tinyerp and had a look though and
> > this practice seems pretty endemic. They should really be using
> > to_char(dat
Hi everyone --
Sorry to revisit a dead horse, but I wanted to clear up some misinformation
--
On Dec 31, 2007 5:35 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> >> This could be the kernel's fault, but I'm w
On Fri, Mar 14, 2008 at 08:53:08PM +, RGF wrote:
> PostgreSQL version: latest
do you mean 8.2.6, 8.3.0 or a latest version of some other series?
please try a little harder next time!!
> Description:sql table aliases do not work
they do whenever I use them! by the looks of your SQL yo
On Fri, Mar 28, 2008 at 01:43:25PM -0300, Euler Taveira de Oliveira wrote:
> [EMAIL PROTECTED] wrote:
> >a column definition list is required for functions returning "record"
> >It seems a BUG
> >
> I don't think so. We can say it is a missing feature. As stated in [1],
> record types don't have a
On Thu, Apr 03, 2008 at 12:24:17AM +0200, Peter Eisentraut wrote:
> Jeff Dwyer wrote:
> > This works fine:
> > select 1 where current_date between '1900-3-3' and '1900-2-2';
> > This doesn't:
> > select 1 where current_date between coalesce(null,current_date) and
> > coalesce(null, '1900-1-2');
>
On Sat, Apr 19, 2008 at 11:26:57AM -0400, Tom Lane wrote:
> Roman Kononov <[EMAIL PROTECTED]> writes:
> > The below test cases show the obvious inconsistency between different
> > integer types.
>
> [ shrug... ] The << and >> operators just expose the behavior of the
> local C compiler's shift o
On Sun, Apr 20, 2008 at 12:27:38PM -0400, Tom Lane wrote:
> Sam Mason <[EMAIL PROTECTED]> writes:
> > Wouldn't it be easy to put some code like this in:
> > if (arg2 < 16)
> > return PG_RETURN_INT16(arg1 << arg2);
> > return PG_RETURN_INT16(0)
On Sun, Apr 20, 2008 at 08:17:50PM +0200, Zdenek Kotala wrote:
> Roman Kononov napsal(a):
> >The below test cases show the obvious inconsistency between different
> >integer types.
>
> It seems to be OK regarding how C shift operator works. Try
Yes, but I interpret this behaviour as not being ver
On Mon, Apr 28, 2008 at 02:14:17PM +0200, Nicolas ZABOURI wrote:
> My server is down and all my dump aren't make.
> How can make for re-install the data on a new install of the server ?
If you can get another copy of 7.4 installed that's built for the same
processor as the database was originally
On Thu, May 29, 2008 at 07:01:46AM +, Jeferson Kasper wrote:
> the EXTRACT(field FROM source) function allows to use some kind of 'fields',
> and i need to know if a time (like '07:00') is after the midday(12:00) or
> not.
> I know i can resolve it implementing some function like "select
> ('07
57 matches
Mail list logo
