O Hans Olav Eggestad έγραψε στις Jul 5, 2005 :
> I've just installed v8.0.3 and tested the 'epoch' part of extract, which for
> my applications is fundamental. here is the result:
>
> jova=# select extract(epoch from timestamp '19700102')\g
> date_part
> ---
> 82800
> (1 row)
>
>
O James Doherty έγραψε στις Jun 10, 2005 :
>
> The following bug has been logged online:
>
> Bug reference: 1715
> Logged by: James Doherty
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0.3
> Operating system: Solaris 8 Intel
> Description:dbmirror repla
O Tom Lane έγραψε στις May 3, 2005 :
> Achilleus Mantzios <[EMAIL PROTECTED]> writes:
> > Its obvious that FreeBSD says: DONT USE IPC in jails, so its far from a
> > bug.
>
> Marc's been running PG inside FreeBSD jails for years, so it seems
> like there'
O Tom Lane έγραψε στις Apr 30, 2005 :
> "Nicolai Petri (lists)" <[EMAIL PROTECTED]> writes:
> > It might still be a good idea for postgresql to be able to detect this
> > collision without crashing each others backend or doing other weird stuff.
>
> It tries --- see IpcSemaphoreCreate in src/ba
O Alexander Rusinov έγραψε στις Apr 27, 2005 :
>
> The following bug has been logged online:
>
> Bug reference: 1632
> Logged by: Alexander Rusinov
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 7.4.7
> Operating system: FreeBSD 5.4-PRERELEASE i386
> Description:
Consider that
foodb=# \d parent
Table "public.parent"
Column | Type | Modifiers
+-+
id | integer | not null default nextval('public.parent_id_seq'::text)
name | text
O Cao Duy έγραψε στις Nov 18, 2004 :
> hi,
>
> I created this table:
> CREATE TABLE public.stresslog(
> "AbfrageId" int8 NOT NULL DEFAULT
> nextval('public."stresslog_AbfrageId_seq"'::text),
> "AbfrageTyp" varchar(50) NOT NULL,
> "Abfrage" varchar(300),
> "AnzZeilen" int8 DEFAULT 0,
> "
O kyrios Ilir Gashi egrapse stis Jul 2, 2004 :
SELECT '01.01.2004 10:00:00'::timestamp + ('01.01.2004
10:01:00'::timestamp - '01.01.2004 10:00:00'::timestamp)::interval;
?column?
-
2004-01-01 10:01:00
(1 row)
works fine in my 7.4.2
> Hi,
>
> I saw this behaviour in P
Hi, i noticed a failure when i pg_dump/reload a database with tsearch2.sql
installed.
I get ERRORS of the type:
dynacom=# SELECT lexize('en_stem','foo bar');
ERROR: cache lookup failed for function 4652394
dynacom=# SELECT lexize('en_stem','foo bar');
ERROR: cache lookup failed for function 4
O kyrios Tom Lane egrapse stis Feb 5, 2004 :
> Achilleus Mantzios <[EMAIL PROTECTED]> writes:
> > Whereas IN seems to not working ok when negated as shown below:
>
> If the sub-select returns any NULLs then this behavior is per SQL spec.
Thanx a lot!
>
>
EXISTS and IN seem to work ok for:
dynacom=# SELECT count(*) from parts p where p.id in (select md.partid
from machdefs md);
count
---
12656
(1 row)
dynacom=# SELECT count(*) from parts p where exists (select 1 from
machdefs md where md.partid = p.id);
count
---
12656
(1 row)
Wh
O kyrios Kris Jurka egrapse stis Jan 15, 2004 :
>
>
> On Thu, 10 Jan 2002, Achilleus Mantzios wrote:
>
> >
> > Well, altho not a bug (actually i think its a fix),
> > the change of the behaviour should be listed in
> > JDBC changes in the pgsql4.1 README fi
Well, altho not a bug (actually i think its a fix),
the change of the behaviour should be listed in
JDBC changes in the pgsql4.1 README file.
(Its the first time i actually read every single line
of the README and i failed to locate the point that
was supposed to give me trouble).
--
-Achilleu
_
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
> ---(end of broadcast)---
> TIP 7: don't forget to increase your free space map settings
&g
On Wed, 2 Jul 2003, Tom Lane wrote:
> Achilleus Mantzios <[EMAIL PROTECTED]> writes:
> > Finally i found the bad row in the bad table.
>
> Were you able to determine what value was actually stored? (You might
> try using EXTRACT to get different parts of it.)
>
On Wed, 2 Jul 2003, Tom Lane wrote:
> Achilleus Mantzios <[EMAIL PROTECTED]> writes:
> > dynacom=# VACUUM ANALYZE ;
> > ERROR: Unable to format timestamp with time zone; internal coding error
>
> Is it possible you have any really wacko timestamp values in your data
e girl who does data entry has no clue of what keys she pressed
I am curious if this will happen to anyone again.
On Wed, 2 Jul 2003, Achilleus Mantzios wrote:
>
> Also,
> % pg_dump -t noonmsg dynacom > noonmsg_dump.sql
> pg_dump: ERROR: Unable to format timestamp with time zone;
failed.
Also,
# ANALYZE/pg_dump seems to work with other tables.
Are there any thoughts on that?
On Wed, 2 Jul 2003, Achilleus Mantzios wrote:
>
> dynacom=# SELECT version();
>version
> -
>
dynacom=# VACUUM ;
VACUUM
dynacom=# ANALYZE ;
ERROR: Unable to format timestamp with time zone; internal coding error
Anyone knows whats going on??
--
==
Achilleus Mantzios
S/W Engineer
IT dept
Dynacom Tankers Mngmt
Nikis 4, Glyfada
t; information, which is confidential and legally privileged, and the same
> shall not be used, or dealt with, by any third party, in any manner
> whatsoever, without the specific consent of Indus Software.
>
> The opinions expressed are those of the sender, and do not necessarily
> reflect those of the Indus Sof
unregister command
> (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
>
--
==
Achilleus Mantzios
S/W Engineer
IT dept
Dynacom Tankers Mngmt
Nikis 4, Glyfada
Athens 16610
Greece
tel:+30-210-8981112
fax:+30-210-8981877
email: achill at matrix dot gatewaynet dot c
whats your
java -version
?
--
==
Achilleus Mantzios
S/W Engineer
IT dept
Dynacom Tankers Mngmt
Nikis 4, Glyfada
Athens 16610
Greece
tel:+30-210-8981112
fax:+30-210-8981877
email: achill at matrix dot gatewaynet dot com
22 matches
Mail list logo
