austijc <[EMAIL PROTECTED]> writes:
> The question is can anyone more familiar with this tell me what's going on
> here? I don't know if this is a Postgres, Sun, or NetApp issue. Could it
> be a work around for an old Linux bug causing an issue with acceptable
> behavior of the NetApp device?
P
Configuration:
Postgres 8.3.1
Solaris 10 Sparc System NFS mounting the database directory from a NetApp
2020 NAS device.
Mount options:
rw,bg,hard,rsize=32768,wsize=32768,vers=3,forcedirectio,nointr,proto=tcp,suid
Error:
ERROR: unexpected data beyond EOF in block 315378 of relation "file"
HI
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Yeah. The given case is actually an invalid LIKE pattern. I wonder
>> whether we should make LIKE throw error for an invalid pattern.
> Yes, I think we should throw an error; the original query looked odd to
> me too.
A quick check
On Thu, Sep 25, 2008 at 4:05 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 25, 2008 at 10:22 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> A likely bet is that this is caused by use of uninitialized memory,
>> which happens to have garbage rather than zeroes in it the second
>> time throu
On Thu, Sep 25, 2008 at 10:22 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> A likely bet is that this is caused by use of uninitialized memory,
> which happens to have garbage rather than zeroes in it the second
> time through.
Yep both DCH_MC and DCH_US were going past the end of the string
because t
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Mathieu Fenniak wrote:
> >> I noticed that (SELECT E'\\' LIKE E'\\') returns false,
>
> > I believe this is caused because backslash is the default escape
> > character for LIKE, so you need:
> > test=> SELECT E'\\' LIKE E'';
I confirm this as a bug. First ANALYZE after crash recovery leaves stats
showing as zeroes. Repeatable on CVS HEAD with ANALYZE and VACUUM
ANALYZE.
Forwarding to bugs.
On Wed, 2008-09-24 at 15:29 -0400, Chirag Dave wrote:
>
> Testing AutoVac on 8.3 , i came across the problem of loosing stats
"Tim Leppard" <[EMAIL PROTECTED]> writes:
> Returning NULL from a BEFORE DELETE trigger function on a referencing table
> using CASCADE allows you to break RI.
Yup, so don't do that ;-). Actually there are any number of ways to
break an RI constraint with poorly designed triggers. The only way
w
The following bug has been logged online:
Bug reference: 4437
Logged by: Tim Leppard
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.4
Operating system: Multiple
Description:Breaking referential integrity with a trigger
Details:
Returning NULL from a BEFORE
"Joshua Tolley" <[EMAIL PROTECTED]> writes:
> I'm running this on 8.4devel built from CVS HEAD as of 9:44 AM Moutain
> Daylight time today, on a 32-bit Ubuntu 7.04 box. This is a completely
> new database.
Ugh, apparently there's some state-dependent bug in the recent
to_timestamp fixes:
regressi
I'm running this on 8.4devel built from CVS HEAD as of 9:44 AM Moutain
Daylight time today, on a 32-bit Ubuntu 7.04 box. This is a completely
new database.
[EMAIL PROTECTED]:~/devel/raybo$ psql raybo -f test.sql
CREATE TABLE
INSERT 0 1
INSERT 0 1
psql:test.sql:21: ERROR: invalid AM/PM string
psql
11 matches
Mail list logo
