[BUGS] BUG #2245: pg_dump doesn't dump expressions with sequence in DEFAULT setting for some column in table
The following bug has been logged online:
Bug reference: 2245
Logged by: Nikolay Samokhvalov
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.2
Operating system: Linux Fedora Core 4
Description:pg_dump doesn't dump expressions with sequence in
DEFAULT setting for some column in table
Details:
I use some expression as DEFAULT setting for some column of some table. For
example, nextval('myseq') * 10.
Then, I pg_dump my database and restore it. I see 'nextval('myseq')' (w/o
'*10').
(Surely, '*10' is just an example, I know, that I can increase the INCREMENT
parameter for the sequence.)
I suppose it's a bug.
More details:
http://archives.postgresql.org/pgsql-general/2006-02/msg00251.php
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2245: pg_dump doesn't dump expressions with sequence in DEFAULT setting for some column in table
"Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes:
> I use some expression as DEFAULT setting for some column of some table. For
> example, nextval('myseq') * 10.
> Then, I pg_dump my database and restore it. I see 'nextval('myseq')' (w/o
> '*10').
You mustn't fool with the default expression for a serial column. You
should have declared this as a plain integer column with a handmade
default expression.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2242: Inconsistent casting in query with literal vs query with parameter
"Matthew Bellew" <[EMAIL PROTECTED]> writes:
> In the script below, I'd expect all four queries to return 10 rows
> (1,2,3,4,5,10,20,30,40,50). However, function bystr() returns two rows
> (1,10). Clearly, in this one case the query processor is casting the column
> to the parameter type, rather than the other way around. The optimizer
> should always preferentially cast the parameter to the type of the column.
I see no bug here. You are confused about the difference between an
unknown literal ('100') and a value that is actually declared to be of
type text. See
http://www.postgresql.org/docs/8.1/static/typeconv.html
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[BUGS] BUG #2243: Postgresql fails to finish some queries
The following bug has been logged online: Bug reference: 2243 Logged by: Matej Rizman Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 and 8.1 Operating system: Linux Debian, kernel 2.6.12-1-k7 Description:Postgresql fails to finish some queries Details: Execute the following script: CREATE TABLE a ( num int4 ); CREATE TABLE b ( num int4 ); CREATE UNIQUE INDEX ix_a_num ON a(num); CREATE INDEX ix_b_num ON b(num); COPY a FROM '/tmp/a_3.txt'; COPY b FROM '/tmp/b_3.txt'; SELECT * FROM b WHERE num NOT IN (SELECT num FROM a); Files a_3.txt and b_3.txt contain 3 numbers each. The last query (SELECT) is executed on my machine in 125ms. If I load data from files a_10.txt and b_10.txt that contain 10 numbers each, the last SELECT does not finish in more than ten minutes (the real-world sample hasn't finished in more than an hour). The similar real-world sample does not even return the results of EXPLAIN statement. However, this real-world sample is quite complex and I am not posting it there. In the case I provided the EXPLAIN statement works fine. This behaviour has been observed on postgresql 8.0 and on postgresql 8.1. It has also been tested on two different computers, both running debian linux. I can provide files a_* and b_* if you want. However, they are quite large and unsuitable for mailing list attachments. Best regards, Matej Rizman ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #2244: silent installation to set password never expires
The following bug has been logged online: Bug reference: 2244 Logged by: KF Tai Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: windows XP Description:silent installation to set password never expires Details: Hi there: Can someone help to provide some guideline how to do the silent installation WITH setting the services account password never expires. Thanks in advance. tai ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2240: length() with geometric types
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
sorry to bug you with that. I figured that out, too, in the meantime. I
wonder why the default behaviour of the path-constructor to end up in a
closed path. I would intentionally expect an open path - since I
understand a path as a connection of points that go from a start to a
destination and not necessarily back. If I would like to have a closed
path I would probably use the polygon datatype.
What was the intenion behind some of the geometric datatypes anyway. I
would have liked to work with them (esp. path) but they turned out not
to be very useful. (I cannot append or prepend a point to a path, I
cannot index-access it, I didn't even find a way to cast it to a string).
Is there any further development planned or will you keep this status? I
would prefer to see these datatypes handier in the future so they
probably get more useful.
Thx
CU
ae
James William Pye schrieb:
> On Mon, Feb 06, 2006 at 02:41:39PM +, Andreas Erber wrote:
>> Hi,
>>
>> I discovered some strange behaviour:
>> The length() function returns different results depending on the geometric
>> data type used as argument.
>>
>> length(lseg) produces the correct result, i.e. length(lseg('(0,0),(2,0)')) =
>> 2
>>
>> length(path) always produces the double result (independently from the
>> length of the path), i.e.
>> length(path('(0,0),(2,0)')) = 4
>> length(path('(0,0),(2,0),(4,0),(6,0),(8,0)')) = 16
>>
>> Is it supposed to be that way? If yes, why?
>
> Yes.
>
> You specified your path as a closed path. With its "loopback", it's twice as
> long.
>
> To specify it as an open path, do path('[(0,0),(2,0)]').
>
> SELECT length(path('[(1,0),(0,0)]')) = '1';
> SELECT length(path('(1,0),(0,0)')) = '2';
- --
- --
Information is a weapon of mass destruction
[Faithless]
- --
Andreas Erber
Berlin
Germany
-
e-mail [EMAIL PROTECTED]
homehttp://www.andreas-erber.net
-
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFD6KhuBzgniz6LxFMRArrzAJ49GKPSOqB+S3ifW/RRzCEPjvMFOQCeMJjn
AJX3rHfm+YEzEcfJv5epuf4=
=6+08
-END PGP SIGNATURE-
begin:vcard
fn:Andreas Erber
n:Erber;Andreas
adr:;;Maximilianstr. 45A;Berlin;Berlin;13187;Germany
email;internet:[EMAIL PROTECTED]
title:cand. rer. nat.
tel;cell:++491723071667
x-mozilla-html:FALSE
url:http://www.andreas-erber.net
version:2.1
end:vcard
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2239: "vacuumdb -a" remove freeze
Olleg Samoylov <[EMAIL PROTECTED]> writes: > IMHO "vacuumdb -a" must don't vacuum database with > datvacuumxid=datfrozenxid. That's not going to work because it will fail to detect whether the database has been modified since the VACUUM FREEZE command. In any case, what's the point? As long as you have a routine vacuuming process in place, it doesn't really matter whether template1 gets scanned. The only reason VACUUM FREEZE exists at all is to make it possible to have a non-connectable, non-vacuumable template0. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] vacuum segmentation fault
I've tried to run vacuum full analyze with postgresql 8.1.1 and 8.1.2 and in both cases I've seen a segmentation fault. I read the archives and found something related to 8.1.1 but it was supposed to be fixed in version 8.1.2. Is there any patch available ? #0 ArrayGetNItems (ndim=3342336, dims=0x901adf4) at arrayutils.c:62 #1 0x08192b4f in array_cmp (fcinfo=0xfeef8430) at arrayfuncs.c:2678 #2 0x081ff3dd in inlineApplySortFunction (sortFunction=0xfeef9330, kind=SORTFUNC_CMP, datum1=151127420, isNull1=0 '\0', datum2=151104996, isNull2=-125 '\203') at tuplesort.c:1899 #3 0x080e2bf9 in compare_scalars (a=0x7083, b=0x0) at analyze.c:2212 #4 0x00231fd0 in msort_with_tmp () from /lib/tls/libc.so.6 #5 0x00231f57 in msort_with_tmp () from /lib/tls/libc.so.6 #6 0x00231f30 in msort_with_tmp () from /lib/tls/libc.so.6 #7 0x00231f30 in msort_with_tmp () from /lib/tls/libc.so.6 #8 0x00231f57 in msort_with_tmp () from /lib/tls/libc.so.6 #9 0x00231f57 in msort_with_tmp () from /lib/tls/libc.so.6 #10 0x002321f8 in qsort () from /lib/tls/libc.so.6 #11 0x080e240d in compute_scalar_stats (stats=0x9017030, fetchfunc=0x80e1a7c , samplerows=61, totalrows=61) at analyze.c:1845 #12 0x080e091a in analyze_rel (relid=2620, vacstmt=0x8fe2d88) at analyze.c:379 #13 0x0810dd12 in vacuum (vacstmt=0x8fe2d88, relids=0xa3c) at vacuum.c:476 #14 0x081895ba in PortalRunUtility (portal=0x8ff4bf0, query=0x8fe2e20, dest=0x8fe2dd8, completionTag=0xfeef96d0 "") at pquery.c:987 #15 0x0818983a in PortalRunMulti (portal=0x8ff4bf0, dest=0x8fe2dd8, altdest=0x8fe2dd8, completionTag=0xfeef96d0 "") at pquery.c:1054 #16 0x08189080 in PortalRun (portal=0x8ff4bf0, count=2147483647, dest=0x8fe2dd8, altdest=0x8fe2dd8, completionTag=0xfeef96d0 "") at pquery.c:665 #17 0x08185525 in exec_simple_query (query_string=0x8fe2ac8 "VACUUM FULL ANALYZE VERBOSE;") at postgres.c:1002 #18 0x08187cad in PostgresMain (argc=4, argv=0x8fa2a40, username=0x8fa2a18 "alfranio") at postgres.c:3217 #19 0x08166979 in BackendRun (port=0x8fba910) at postmaster.c:2859 #20 0x08166489 in BackendStartup (port=0x8fba910) at postmaster.c:2503 #21 0x08164a5f in ServerLoop () at postmaster.c:1236 #22 0x08163f59 in PostmasterMain (argc=6, argv=0x8fa0908) at postmaster.c:947 #23 0x0812facc in main (argc=6, argv=0x8fa0908) at main.c:263 BINDIR = /usr/local/pgsql/bin DOCDIR = /usr/local/pgsql/doc INCLUDEDIR = /usr/local/pgsql/include PKGINCLUDEDIR = /usr/local/pgsql/include INCLUDEDIR-SERVER = /usr/local/pgsql/include/server LIBDIR = /usr/local/pgsql/lib PKGLIBDIR = /usr/local/pgsql/lib LOCALEDIR = MANDIR = /usr/local/pgsql/man SHAREDIR = /usr/local/pgsql/share SYSCONFDIR = /usr/local/pgsql/etc PGXS = /usr/local/pgsql/lib/pgxs/src/makefiles/pgxs.mk CONFIGURE = '--enable-debug' '--enable-dep' CC = gcc CPPFLAGS = -D_GNU_SOURCE CFLAGS = -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g CFLAGS_SL = -fpic LDFLAGS = -Wl,-rpath,/usr/local/pgsql/lib LDFLAGS_SL = LIBS = -lpgport -lz -lreadline -ltermcap -lcrypt -lresolv -lnsl -ldl -lm -lbsd VERSION = PostgreSQL 8.1.2 gcc (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7) - Linux version 2.6.5-1.358 ([EMAIL PROTECTED]) (gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)) #1 Sat May 8 09:04:50 EDT 2004 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] vacuum segmentation fault
Alfranio Correia Junior <[EMAIL PROTECTED]> writes: > I've tried to run vacuum full analyze with postgresql 8.1.1 and 8.1.2 > and in both cases I've seen a segmentation fault. > #0 ArrayGetNItems (ndim=3342336, dims=0x901adf4) at arrayutils.c:62 This looks like a corrupt-data problem to me. If so, this isn't the way to diagnose it --- you should go about identifying and getting rid of the corrupted row. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2236: extremely slow to get unescaped bytea data
On Sat, Feb 04, 2006 at 04:06:11PM -0800, Kalador Tech Support wrote:
> I've since isolated the problem to the unescape_bytea function not the
> SELECT.
>
> I inserted the same image to a bytea column using base64 encoding, and
> extracted it from the table (using base64 decoding) and this worked very
> fast (<1 second). So, it is the unescape_bytea function that is to blame.
pg_unescape_bytea is fast here; I just unescaped an 850K jpeg image
in about 0.18 seconds on a slow (500MHz) machine.
How did you determine that pg_unescape_bytea was the problem? What
does something like the following show?
$tstart = microtime(true);
$data = pg_unescape_bytea(pg_fetch_result($res, 'data'));
$dt = microtime(true) - $tstart;
header("Content-Type: text/plain");
printf("unescape time = %.3fms, %d bytes\n", $dt * 1000.0, strlen($data));
--
Michael Fuhr
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
