[HACKERS] quoting bug?
Given the following trivial trigger example: -- create language plpgsql; create table foo (a integer, b text, c timestamp); create function foo_insert() returns trigger as $$ begin raise notice '%', new; return null; end; $$ language plpgsql; create trigger foo_ins before insert on foo for each row execute procedure foo_insert(); insert into foo values (1, 'two', current_timestamp); I am surprised to see NOTICE: (1,two,Sat 09 Feb 16:47:44.514503 2008) INSERT 0 0 I would have expected NOTICE: (1,'two','Sat 09 Feb 16:47:44.514503 2008') INSERT 0 0 i.e., a row whose columns look as though they went through quote_literal rather than through quote_ident. This is with yesterday's 8.3.0 (Feb 8 17:24 GMT) Thoughts? Cheers, Patrick ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] quoting bug?
On Sat, Feb 09, 2008 at 12:29:10PM -0500, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: I am surprised to see NOTICE: (1,two,Sat 09 Feb 16:47:44.514503 2008) This is the expected formatting for a composite type. Read http://www.postgresql.org/docs/8.3/static/rowtypes.html#AEN6266 Thank you - sorry for noise. Patrick ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] autoconf
I know that it doesn't matter as configure is in CVS, so there is no need for mere mortals to regenerate it, but why is RCS file: /projects/cvsroot/pgsql/configure.in,v revision 1.538 date: 2007/11/26 12:31:07; author: petere; state: Exp; lines: +2 -2 Require a specific Autoconf version, instead of a lower bound only. a good idea? Cheers, Patrick ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] write past chunk end in ExprContext / to_char
With today's CVS code (originally noticed with 8.2beta3), on a PC where INT_MAX=0x7FFF=2147483647 postgres=# select version(); version - PostgreSQL 8.3devel on i386-unknown-netbsdelf4.99.20, compiled by GCC gcc (GCC) 4.1.2 20070110 prerelease (NetBSD nb1 20070603) (1 row) postgres=# select to_char(2147483647,'999,999,999'); to_char -- ###,###,### (1 row) postgres=# select to_char(2147483648,'999,999,999'); WARNING: detected write past chunk end in ExprContext 0x845509c WARNING: detected write past chunk end in ExprContext 0x845509c to_char -- ###,###,### (1 row) postgres=# select to_char(2147483648,'99,999,999'); to_char - ##,###,### (1 row) postgres=# select to_char(2147483648,'9,999,999,999'); to_char 2,147,483,648 (1 row) postgres=# select to_char(1234567890123,'999,999,999,999'); WARNING: detected write past chunk end in ExprContext 0x845509c WARNING: detected write past chunk end in ExprContext 0x845509c to_char -- ###,###,###,### (1 row) postgres=# select to_char(1234567890123,'99,999,999,999'); to_char - ##,###,###,### (1 row) So strangely, to get the worrying WARNING, I seem to need INT_MAX with a format string with 1 less positions than necessary - no wonder I seemed to only see it randomly... Thoughts? Cheers, Patrick ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] coalesce and aggregate functions
Is this a bug, or don't I understand coalesce()? create table test (a int, b int); insert into test values (1,null); insert into test values (2,1); insert into test values (2,2); select * from test; -- returns: select sum(b) from test where a=1; -- null select sum(b) from test where a=2; -- 3 select coalesce(0,sum(b)) from test where a=1; -- 0 select coalesce(0,sum(b)) from test where a=2; -- 0 delete from test where a=1; select coalesce(0,sum(b)) from test where a=2; -- 0 ! So when I use coalesce() with sum(), I always get the constant. I would have expected it only in the case where sum() returns null.. What am I missing? Cheers, Patrick (PostgreSQL 8.2devel of 21st November 2006) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] coalesce and aggregate functions
On Tue, Dec 12, 2006 at 03:33:04PM +, Heikki Linnakangas wrote: BTW: This type of questions really belong to pgsql-general or pgsql-novice, this list is for discussing development of PostgreSQL itself. ^^ Indeed - I am truly feeling like a novice now... Cheers, Patrick ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] inet increment with int
On Sat, Apr 29, 2006 at 10:24:48PM -0400, Bruce Momjian wrote: FYI, 8.2 will have this and more based on this applied patch: Add INET/CIDR operators: and, or, not, plus int8, minus int8, and inet minus inet. I know, I'm already using it :-) Thanks, Patrick ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] float8 regression test failure in head
On Thu, Apr 20, 2006 at 11:56:29AM -0400, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Don't we have some of these platforms on the build farm. Are they failing? canary, gazelle, and osprey all pass this test just fine. Before accepting any patches in this area we'd better find out the difference between the OP's netbsd system and those machines. Agreed. Quoting from my original post NetBSD-3.99.17/i386 - so what are you running? .. and just to check: patrimoine=# select '1e-400'::float; ERROR: 1e-400 is out of range for type double precision patrimoine=# select version(); version - PostgreSQL 8.2devel on i386-unknown-netbsdelf3.99.17, compiled by GCC gcc (GCC) 3.3.3 (NetBSD nb3 20040520) (1 row) 1e-400 wasn't rounded down to 0. Cheers, Patrick ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] float8 regression test failure in head
On Mon, Mar 22, 2004 at 11:03:38PM -0500, Neil Conway wrote:
Christopher Kings-Lynne wrote:
This has not yet been fixed...
Attached is a patch for this issue. I've checked with Chris, and this
patch allows the regression tests to pass on his machine. I also
updated float8-exp-three-digits expected file, but I wasn't able to
test these changes (I don't have access to a QNX machine).
Mystery: why I haven't I seen this problem before in the last 2 years...
Anyway, on NetBSD-3.99.17/i386, I need the included patch to pass float8.
float8-small-is-zero_1.out probably needs it too, float8.out and
float8-exp-three-digits-win32.out already look OK.
Cheers,
Patrick
Index: float8-small-is-zero.out
===
RCS file:
/projects/cvsroot/pgsql/src/test/regress/expected/float8-small-is-zero.out,v
retrieving revision 1.10
diff -u -r1.10 float8-small-is-zero.out
--- float8-small-is-zero.out8 Jun 2005 21:15:29 - 1.10
+++ float8-small-is-zero.out5 Apr 2006 14:26:25 -
@@ -13,17 +13,9 @@
SELECT '-10e400'::float8;
ERROR: -10e400 is out of range for type double precision
SELECT '10e-400'::float8;
- float8
-
- 0
-(1 row)
-
+ERROR: 10e-400 is out of range for type double precision
SELECT '-10e-400'::float8;
- float8
-
--0
-(1 row)
-
+ERROR: -10e-400 is out of range for type double precision
-- bad input
INSERT INTO FLOAT8_TBL(f1) VALUES ('');
ERROR: invalid input syntax for type double precision:
@@ -377,7 +369,9 @@
INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400');
ERROR: -10e400 is out of range for type double precision
INSERT INTO FLOAT8_TBL(f1) VALUES ('10e-400');
+ERROR: 10e-400 is out of range for type double precision
INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e-400');
+ERROR: -10e-400 is out of range for type double precision
-- maintain external table consistency across platforms
-- delete all values and reinsert well-behaved ones
DELETE FROM FLOAT8_TBL;
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
[HACKERS] postmaster core dump
I seem to have an unhappy postgresql:
(gdb) bt
#0 0xbd99871b in kill () from /usr/lib/libc.so.12
#1 0xbda217e7 in abort () from /usr/lib/libc.so.12
#2 0x0820c1fa in ExceptionalCondition (
conditionName=0x8298920 !(batchno hashtable-curbatch),
errorType=0x823919f FailedAssertion,
fileName=0x82988e0 /usr/src/local/pgsql/src/backend/executor/nodeHash.c,
lineNumber=675) at /usr/src/local/pgsql/src/backend/utils/error/assert.c:51
#3 0x08136c09 in ExecHashTableInsert (hashtable=0x83e9c9c, tuple=0x83e9ce8,
hashvalue=4294941132)
at /usr/src/local/pgsql/src/backend/executor/nodeHash.c:679
#4 0x081363e1 in MultiExecHash (node=0x83e91b4)
at /usr/src/local/pgsql/src/backend/executor/nodeHash.c:114
#5 0x0812c24f in MultiExecProcNode (node=0x83e91b4)
at /usr/src/local/pgsql/src/backend/executor/execProcnode.c:439
#6 0x0813707a in ExecHashJoin (node=0x83e65ac)
at /usr/src/local/pgsql/src/backend/executor/nodeHashjoin.c:160
#7 0x0812c11a in ExecProcNode (node=0x83e65ac)
at /usr/src/local/pgsql/src/backend/executor/execProcnode.c:358
#8 0x081348f5 in agg_fill_hash_table (aggstate=0x83e62b4)
at /usr/src/local/pgsql/src/backend/executor/nodeAgg.c:911
#9 0x081345fb in ExecAgg (node=0x83e62b4)
at /usr/src/local/pgsql/src/backend/executor/nodeAgg.c:681
#10 0x0812c152 in ExecProcNode (node=0x83e62b4)
at /usr/src/local/pgsql/src/backend/executor/execProcnode.c:377
#11 0x0812aa2b in ExecutePlan (estate=0x83e601c, planstate=0x83e62b4,
operation=CMD_SELECT, numberTuples=0, direction=ForwardScanDirection,
dest=0x83d8d8c)
at /usr/src/local/pgsql/src/backend/executor/execMain.c:1110
#12 0x08129dc7 in ExecutorRun (queryDesc=0x83db848,
direction=ForwardScanDirection, count=0)
at /usr/src/local/pgsql/src/backend/executor/execMain.c:231
#13 0x081a89a3 in PortalRunSelect (portal=0x83e401c, forward=1 '\001',
count=2147483647, dest=0x83d8d8c)
at /usr/src/local/pgsql/src/backend/tcop/pquery.c:797
#14 0x081a8758 in PortalRun (portal=0x83e401c, count=2147483647,
dest=0x83d8d8c, altdest=0x83d8d8c, completionTag=0xbfbfe1d0 )
at /usr/src/local/pgsql/src/backend/tcop/pquery.c:648
#15 0x081a4c2f in exec_simple_query (
query_string=0x834501c select timesliced, count(stats_id) from trans left j
/*
* put the tuple into a temp file for later batches
*/
Assert(batchno hashtable-curbatch);
ExecHashJoinSaveTuple(tuple, hashvalue,
hashtable-innerBatchFile[batchno]);
(gdb) print batchno
$2 = 2
(gdb) print *hashtable
$3 = {nbuckets = 2063, buckets = 0x83f601c, nbatch = 16, curbatch = 3,
nbatch_original = 16, nbatch_outstart = 16, growEnabled = 1 '\001',
totalTuples = 25998, innerBatchFile = 0x83f401c, outerBatchFile = 0x83f4068,
hashfunctions = 0x83ea0a4, spaceUsed = 136816, spaceAllowed = 1048576,
hashCxt = 0x835a648, batchCxt = 0x835a6d4}
cvs of 1 Sept, nodeHash.c v 1.94
Any thoughts?
Cheers,
Patrick
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] postmaster core dump
On Mon, Sep 19, 2005 at 06:12:54PM +0100, Patrick Welche wrote: #15 0x081a4c2f in exec_simple_query ( query_string=0x834501c select timesliced, count(stats_id) from trans left j I just truncated one line early.. the query was: # explain select timesliced, count(stats_id) from trans left join stats on stats_id=stats.id group by timesliced; QUERY PLAN --- HashAggregate (cost=123718.66..123738.61 rows=1596 width=8) - Hash Left Join (cost=4143.88..115550.16 rows=1633701 width=8) Hash Cond: (outer.stats_id = inner.id) - Seq Scan on trans (cost=0.00..61341.01 rows=1633701 width=4) - Hash (cost=3292.30..3292.30 rows=123430 width=8) - Seq Scan on stats (cost=0.00..3292.30 rows=123430 width=8) (6 rows) Cheers, Patrick ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] postmaster core dump
On Mon, Sep 19, 2005 at 03:59:35PM -0400, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: I seem to have an unhappy postgresql: Let's see a test case, not a stack trace. I haven't set up the minimalist test case yet, but the 2 tables involved are incredibly simple. stats.id is an integer primary key, trans.stats_id points to it. You just need a query which uses a HashJoin. This time, no core dump, however: transatlantic=# set enable_hashjoin=on; SET transatlantic=# select timeslice,count(stats_id) from trans,stats where trans.stats_id=stats.id group by timeslice; timeslice | count ---+--- (0 rows) transatlantic=# set enable_hashjoin=off; SET transatlantic=# select timeslice,count(stats_id) from trans,stats where trans.stats_id=stats.id group by timeslice; timeslice | count -+--- 2005-08-28 00:00:00 | 586 2005-08-28 00:00:01 | 378 2005-08-28 00:20:00 | 878 ... So, no results with enable_hashjoin=on. Broken: QUERY PLAN -- GroupAggregate (cost=326296.78..338449.98 rows=97067 width=12) - Sort (cost=326296.78..329943.40 rows=1458648 width=12) Sort Key: stats.timeslice - Hash Join (cost=4203.88..108728.93 rows=1458648 width=12) Hash Cond: (outer.stats_id = inner.id) - Seq Scan on trans (cost=0.00..59706.48 rows=1458648 width=4) - Hash (cost=3292.30..3292.30 rows=123430 width=12) - Seq Scan on stats (cost=0.00..3292.30 rows=123430 width=12) Working: QUERY PLAN --- GroupAggregate (cost=506460.77..518613.97 rows=97067 width=12) - Sort (cost=506460.77..510107.39 rows=1458648 width=12) Sort Key: stats.timeslice - Merge Join (cost=263024.32..288892.93 rows=1458648 width=12) Merge Cond: (outer.id = inner.stats_id) - Index Scan using stats_pkey on stats (cost=0.00..3688.21 rows=123430 width=12) - Sort (cost=263024.32..266670.94 rows=1458648 width=4) Sort Key: trans.stats_id - Seq Scan on trans (cost=0.00..59706.48 rows=1458648 width=4) I'll make a smaller test case over night.. Cheers, Patrick ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] C trigger problem
I am trying to write a C trigger. Essentially TriggerData *in = (TriggerData *) fcinfo-context; HeapTupleHeader tuple=in-tg_trigtuple-t_data; Datum datum; datum = GetAttributeByName(tuple, unit_id, isnull); and that last line fails with ERROR: cache lookup failed for type 4664 I haven't seen anything similar in the documentation.. What is wrong / the correct way of extracting values from the old/new rows in a C trigger fn? Cheers, Patrick ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] inet increment with int
On Fri, Sep 16, 2005 at 06:36:56AM -0400, Bruce Momjian wrote: This has been saved for the 8.2 release: It isn't actually a patch for application yet ;-) It is the function in a state that is easy to test. I take it that as I have basically had no comments back, I will just go ahead and make a patch for the function as a built-in... Cheers, Patrick ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] inet increment with int
On Wed, Sep 07, 2005 at 02:48:00AM -, Andrew - Supernews wrote: On 2005-09-06, Patrick Welche [EMAIL PROTECTED] wrote: Now with: test=# select '192.168.0.0/24'::inet + 1; ERROR: Trying to increment a network (192.168.0.0/24) rather than a host What possible justification is there for this behaviour? test=# select '192.168.0.1/24'::inet + -1; ERROR: Increment returns a network (192.168.0.0/24) rather than a host While I suspect I know where this idea came from, it is equally boneheaded since it is making completely unwarranted assumptions about how inet values are being used. So, back to original version? Comments anyone? Patrick ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] uuid type for postgres
On Wed, Sep 07, 2005 at 09:45:17AM -0700, Josh Berkus wrote: Nathan wrote: Quite a list. I wonder what readline is doing there. Readline is for PSQL command completion and history. As for the rest, they are *optional* modules that apparently your RPM builder chose to include; I build from source and my only dependencies are bison, flex, gcc and perl. Still seems odd to me: I would expect psql to have readline, not postgres. Cheers, Patrick ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] inet increment with int
On Mon, Sep 05, 2005 at 08:10:16PM +0100, Patrick Welche wrote:
On Mon, Sep 05, 2005 at 03:02:55PM -0400, Tom Lane wrote:
Patrick Welche [EMAIL PROTECTED] writes:
* Allow INET + INT4 to increment the host part of the address, or
throw an error on overflow
I think that the naively coded function attached does what is needed,
e.g.,
What happened to the IPv6 case?
My take on the thread is that the IPv6 case doesn't make sense, and the
int8 part was dropped from the TODO.
Also, I think you need to reject CIDR inputs.
OK
Now with:
test=# select '192.168.0.0/24'::inet + 1;
ERROR: Trying to increment a network (192.168.0.0/24) rather than a host
test=# select '192.168.0.1/24'::inet + -1;
ERROR: Increment returns a network (192.168.0.0/24) rather than a host
Cheers,
Patrick
/* From the TODO:
*Allow INET + INT4 to increment the host part of the address, or
*throw an error on overflow
*/
#include postgres.h
#include sys/socket.h
#include fmgr.h
#include utils/inet.h
PG_FUNCTION_INFO_V1(inet_inc);
Datum
inet_inc(PG_FUNCTION_ARGS)
{
inet*in = PG_GETARG_INET_P(0), *out;
int32inc = PG_GETARG_INT32(1);
inet_struct *src, *dst;
uint32 netmask, host, newhost;
int i;
src = (inet_struct *)VARDATA(in);
if (src-family != PGSQL_AF_INET)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg(Function \inet_inc\ only supports AF_INET
addresses)));
/* avoid int32 overflow when bits == 0 */
netmask = (src-bits == 0) ? 0 : (~((1 (32 - src-bits)) - 1));
/* if (inc doesn't fit in src-bits) overflow */
if ((abs(inc) ~netmask) != abs(inc))
ereport(ERROR,
(errcode(ERRCODE_DATA_EXCEPTION),
errmsg(Increment (%d) too big for network (/%d),
inc,
src-bits)));
/* can do this with htonl/ntohl */
host = 0;
for (i=0; i4; ++i)
host |= src-ipaddr[i] (8 * (3-i));
if ((host ~netmask) == 0)
ereport(ERROR,
(errcode(ERRCODE_DATA_EXCEPTION),
errmsg(Trying to increment a network (%d.%d.%d.%d/%d)
rather
than a host, src-ipaddr[0], src-ipaddr[1],
src-ipaddr[2], src-ipaddr[3],
src-bits)));
newhost = host + inc;
if (((host netmask) != (newhost netmask))
|| (inc0 newhosthost)
|| (inc0 newhosthost))
ereport(ERROR,
(errcode(ERRCODE_DATA_EXCEPTION),
errmsg(Increment (%d) takes address (%d.%d.%d.%d) out
of its
network (/%d), inc,
src-ipaddr[0], src-ipaddr[1], src-ipaddr[2],
src-ipaddr[3], src-bits)));
out = (inet *)palloc0(VARHDRSZ + sizeof(inet_struct));
dst = (inet_struct *)VARDATA(out);
dst-family = src-family;
dst-bits = src-bits;
dst-type = src-type;
for (i=0; i4; ++i)
dst-ipaddr[i] = (newhost (8 * (3-i))) 0xff;
for (i=4; i16; ++i)
dst-ipaddr[i] = 0;
if ((inc 0) (newhost ~netmask) == 0)
ereport(ERROR,
(errcode(ERRCODE_DATA_EXCEPTION),
errmsg(Increment returns a network (%d.%d.%d.%d/%d)
rather
than a host, dst-ipaddr[0], dst-ipaddr[1],
dst-ipaddr[2], dst-ipaddr[3],
dst-bits)));
VARATT_SIZEP(out) = VARHDRSZ + sizeof(dst-family) + sizeof(dst-bits)
+ sizeof(dst-type) + 4;
PG_RETURN_INET_P(out);
}
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
[HACKERS] inet increment with int
Ilya Kovalenko posted some code at in a thread starting at
http://archives.postgresql.org/pgsql-hackers/2005-04/msg00417.php
which lead to the TODO item:
* Allow INET + INT4 to increment the host part of the address, or
throw an error on overflow
I think that the naively coded function attached does what is needed, e.g.,
CREATE OR REPLACE FUNCTION inet_inc(inet, int4)
RETURNS inet
AS '/tmp/inet.so','inet_inc'
LANGUAGE C STRICT;
CREATE OPERATOR + (
leftarg = inet,
rightarg = int4,
procedure = inet_inc
);
test=# select '192.168.0.1/24'::inet + 300;
ERROR: Increment (300) too big for network (/24)
test=# select '192.168.0.1/24'::inet + 254;
?column?
--
192.168.0.255/24
(1 row)
test=# select '192.168.0.1/24'::inet + 255;
ERROR: Increment (255) takes address (192.168.0.1) out of its network (/24)
test=# select '192.168.0.1/24'::inet + -2;
ERROR: Increment (-2) takes address (192.168.0.1) out of its network (/24)
test=# select '255.255.255.254/0'::inet + 2;
ERROR: Increment (2) takes address (255.255.255.254) out of its network (/0)
and just for fun:
create table list (
host inet
);
insert into list values ('192.168.0.1/24');
insert into list values ('192.168.0.2/24');
insert into list values ('192.168.0.4/24');
insert into list values ('192.168.0.5/24');
insert into list values ('192.168.0.6/24');
insert into list values ('192.168.0.8/24');
insert into list values ('192.168.0.9/24');
insert into list values ('192.168.0.10/24');
insert into list values ('192.168.1.1/24');
insert into list values ('192.168.1.3/24');
select host+1 from list
where host+1 = '192.168.1.0/24'
and not exists
( select 1
from list
where host=host+1
and host '192.168.1.0/24' )
limit 1;
If you agree that this is the right thing, I can code it less
naively, (Ilya rightly uses ntohl/htonl), create the operator's
commutator, provide a patch which makes it a built-in, and some
obvious documentation.
Cheers,
Patrick
/* From the TODO:
*Allow INET + INT4 to increment the host part of the address, or
*throw an error on overflow
*/
#include postgres.h
#include sys/socket.h
#include fmgr.h
#include utils/inet.h
PG_FUNCTION_INFO_V1(inet_inc);
Datum
inet_inc(PG_FUNCTION_ARGS)
{
inet*in = PG_GETARG_INET_P(0), *out;
int32inc = PG_GETARG_INT32(1);
inet_struct *src, *dst;
uint32 netmask, host, newhost;
int i;
src = (inet_struct *)VARDATA(in);
if (src-family != PGSQL_AF_INET)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg(Function \inet_inc\ only supports AF_INET
addresses)));
/* avoid int32 overflow when bits == 0 */
netmask = (src-bits == 0) ? 0 : (~((1 (32 - src-bits)) - 1));
/* if (inc doesn't fit in src-bits) overflow */
if ((abs(inc) ~netmask) != abs(inc))
ereport(ERROR,
(errcode(ERRCODE_DATA_EXCEPTION),
errmsg(Increment (%d) too big for network (/%d),
inc,
src-bits)));
/* can do this with htonl/ntohl */
host = 0;
for (i=0; i4; ++i)
host |= src-ipaddr[i] (8 * (3-i));
newhost = host + inc;
if (((host netmask) != (newhost netmask))
|| (inc0 newhosthost)
|| (inc0 newhosthost))
ereport(ERROR,
(errcode(ERRCODE_DATA_EXCEPTION),
errmsg(Increment (%d) takes address (%d.%d.%d.%d) out
of its
network (/%d), inc,
src-ipaddr[0], src-ipaddr[1], src-ipaddr[2],
src-ipaddr[3], src-bits)));
out = (inet *)palloc0(VARHDRSZ + sizeof(inet_struct));
dst = (inet_struct *)VARDATA(out);
dst-family = src-family;
dst-bits = src-bits;
dst-type = src-type;
for (i=0; i4; ++i)
dst-ipaddr[i] = (newhost (8 * (3-i))) 0xff;
for (i=4; i16; ++i)
dst-ipaddr[i] = 0;
VARATT_SIZEP(out) = VARHDRSZ + sizeof(dst-family) + sizeof(dst-bits)
+ sizeof(dst-type) + 4;
PG_RETURN_INET_P(out);
}
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Proof of concept COLLATE support with patch
On Mon, Sep 05, 2005 at 01:52:45AM +0200, Petr Jelinek wrote: Tom Lane wrote: The hole in that argument is the assumption that there *is* a freely available library that can be used (where freely == BSD license). We wouldn't be having this discussion if we knew of one. I see this discussion as another reason to use ICU, I mean complete rewrite of locale handling to use ICU on all platforms. I know it's big project but it's doable for 8.2 and it would virtually solve all locale problems and could be base for new unicode/locale features. I am not sure if this is the way postgres wants to go tho (having dependency on such a big and uncommon library). Maybe not so uncommon... % ldd /usr/local/bin/php /usr/local/bin/php: ... -lresolv.1 = /usr/lib/libresolv.so.1 -lpq.4 = /usr/local/pgsql/lib/libpq.so.4 -lintl.0 = /usr/lib/libintl.so.0 -licudata.34 = /usr/local/lib/libicudata.so.34 -licuuc.34 = /usr/local/lib/libicuuc.so.34 -licui18n.34 = /usr/local/lib/libicui18n.so.34 -licuio.34 = /usr/local/lib/libicuio.so.34 ... Cheers, Patrick ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] inet increment with int
On Mon, Sep 05, 2005 at 03:02:55PM -0400, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: * Allow INET + INT4 to increment the host part of the address, or throw an error on overflow I think that the naively coded function attached does what is needed, e.g., What happened to the IPv6 case? My take on the thread is that the IPv6 case doesn't make sense, and the int8 part was dropped from the TODO. Also, I think you need to reject CIDR inputs. OK Patrick ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] upgrade path / versioning roles
On Thu, Sep 01, 2005 at 02:59:37PM -0400, Tom Lane wrote:
Patrick Welche [EMAIL PROTECTED] writes:
I tried the fix mentioned in the earlier message to encourage
validation. Now dumping this fixed database, and loadinging it into the
new database gives:
ALTER FUNCTION
psql:./huge.db:4403: ERROR: function plpgsql_validator(oid) does not exist
CREATE FUNCTION
ALTER FUNCTION
psql:./huge.db:4517: ERROR: language plpgsql does not exist
HINT: You need to use createlang to load the language into the database.
Ah, right, *that's* why it's a good idea to have the dependency from the
language to the function ;-) ... else there's no guarantee pg_dump will
dump them in the right order. If you want you could add a suitable
pg_depend row.
:-) Thanks all OK..
One other thing I noticed on this longlived database, is that one can
pg_dump new tables, and their associated sequences will be created,
but for old tables, the associated sequences need creating. The
difference seems to be old:
Table public.meter
id | integer | not null default nextval('meter_id_seq'::text)
new:
Table public.summary
id | integer | not null default nextval('public.summary_id_seq'::text)
that the old sequence hasn't got the schema explicitly appended..
(Just in case someone else comes across this..)
Cheers,
Patrick
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
[HACKERS] upgrade path / versioning roles
I think we still recommend using *new* pg_dump to dump *old* server when upgrading. If one tries that with today's pg_dump (8.1beta1) against a 8.1devel server of 6 May, i.e., predating roles, one gets: pg_dump: SQL command failed pg_dump: Error message from server: ERROR: relation pg_catalog.pg_roles does not exist pg_dump: The command was: SELECT tableoid, oid, nspname, (SELECT rolname FROM pg_catalog.pg_roles WHERE oid = nspowner) as rolname, nspacl FROM pg_namespace Cheers, Patrick ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] upgrade path / versioning roles
On Thu, Sep 01, 2005 at 02:31:15PM -0400, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: I think we still recommend using *new* pg_dump to dump *old* server when upgrading. If one tries that with today's pg_dump (8.1beta1) against a 8.1devel server of 6 May, i.e., predating roles, one gets: [ shrug... ] The current code is expecting that 8.1 means what it means today. For dumping from a between-releases snapshot, you'd better use the pg_dump from the same snapshot. OK - that way around just gets the NOTICE psql:./huge.db:11: NOTICE: SYSID can no longer be specified - fair enough. BTW there was an earlier thread about plpgsql validation. The aforementioned 8.1devel database has a long history and createlang was run against an early 7 incarnation, with pg_dumpall - new database all the way to the present. I tried the fix mentioned in the earlier message to encourage validation. Now dumping this fixed database, and loadinging it into the new database gives: ALTER FUNCTION psql:./huge.db:4403: ERROR: function plpgsql_validator(oid) does not exist CREATE FUNCTION ALTER FUNCTION psql:./huge.db:4517: ERROR: language plpgsql does not exist HINT: You need to use createlang to load the language into the database. now to unfix the fix... Cheers, Patrick ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] escape string syntax and pg_dumpall
On Mon, Jul 18, 2005 at 03:01:31PM -0400, Tom Lane wrote: Andrew - Supernews [EMAIL PROTECTED] writes: WHERE spcname NOT LIKE E'pg\\_%'); It's not even correct as it stands - if you want to match a literal _ using LIKE then you would need E'pg_%' there. Good point! Would NOT LIKE 'pg!_%' ESCAPE '!' be better? Seems like a fine solution --- I was about to object that ESCAPE doesn't go back as far as PG 7.0, but neither does pg_tablespace, so that seems OK. The ESCAPE version which you commited works, thanks! Or perhaps better, use a regular regex: spcname !~ '^pg_'. The majority of the comparable cases in psql's describe.c do it this way, and they seem more readable to me ... Likewise.. then again your fix already works.. Cheers, Patrick ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] escape string syntax and pg_dumpall
I just ran pg_dumpall from today's CVS against a 14 April server - I got: pg_dumpall: query failed: ERROR: type e does not exist pg_dumpall: query was: SELECT spcname, pg_catalog.pg_get_userbyid(spcowner) AS spcowner, spclocation, spcacl FROM pg_catalog.pg_tablespace WHERE spcname NOT LIKE E'pg\_%' That comes from v1.62 of pg_dumpall.c : res = executeQuery(conn, SELECT spcname, pg_catalog.pg_get_userbyid(spcowner) AS spcowner, spclocation, spcacl FROM pg_catalog.pg_tablespace WHERE spcname NOT LIKE E'pg\\_%'); revision 1.62 date: 2005/06/26 03:03:48; author: momjian; state: Exp; lines: +2 -2 Add E'' syntax so eventually normal strings can treat backslashes literally. Add GUC variables: escape_string_warning - warn about backslashes in non-E strings escape_string_syntax - supports E'' syntax? standard_compliant_strings - treats backslashes literally in '' Update code to use E'' when escapes are used. My version of the server predates those GUC settings - could the code be assuming that my server can cope with something it can't? (Normally I would just upgrade everything - and I bet it will work - but, I think we still recommend that people use new pg_dumpall to dump their old server when upgrading..) Cheers, Patrick ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] inet increment w/ int8
On Mon, Apr 18, 2005 at 08:58:01PM -0400, Bruce Momjian wrote: Would you modify this so it can go in /contrib or pgfoundry? Is there general interest for this? I was about to sit down and write the same function yesterday, when as if by magic this appeared. In my case it is to loop over ip numbers in a class C looking for a free one to allocate. So, from here there is interest.. Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Cannot link to postgres 8.0.0 databases using ODBC from Access
On Mon, Feb 21, 2005 at 12:50:44PM +, [EMAIL PROTECTED] wrote: host all all 127.0.0.1/0 trust Should that not be 127.0.0.1/32 ? or even host all all 127.0.0.1 255.255.255.255trust ? Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Goals for 8.1
On Mon, Jan 24, 2005 at 05:21:35PM -0400, Marc G. Fournier wrote: On Sun, 23 Jan 2005, Benjamin Arai wrote: What are the goals for 8.1? Replace ARC ... anything else is a bonus ... So the betting is that the patent will be granted.. Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Trouble with plpgsql on 7.4.6
On Tue, Nov 23, 2004 at 07:25:17AM -0500, D'Arcy J.M. Cain wrote: The stderr was in the previous message. No gripes there either other than in the startup after the failure. Also see about getting a stack trace from one of the core dumps. I did look at the core file and here is what I saw: #0 0x483cafeb in kill () from /usr/lib/libc.so.12 #1 0x483cd0af in __libc_mutex_catchall_stub (m=1212478892) at /usr/src/lib/libc/thread-stub/thread-stub.c:112 #2 0x4843f0f7 in free (ptr=incomplete type) at /usr/src/lib/libc/stdlib/malloc.c:1149 #3 0x081b3efc in AllocSetDelete (context=error type) at aset.c:464 #4 0x081b468a in MemoryContextDelete (context=error type) at #mcxt.c:192 Would setting the following environment variable get you an earlier abort / more logging? (pthread(3)) PTHREAD_DIAGASSERT Possible values are any combinations of: A Ignore errors. a Abort on errors, creating a core dump for further debugging. E Do not log errors to stdout. e Log errors to stdout. L Do not log errors via syslogd(8). l Log errors via syslogd(8). Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Improvements to PostgreSQL
On Mon, Jul 26, 2004 at 06:13:30PM +1000, Justin Clift wrote: + An SNMP agent to report on PostgreSQL's status and allows remote control of the PostgreSQL daemon. From an Oracle perspective, this would be the equivalent of Oracle Intelligent Agents, part of the core features of the Oracle Enterprise Manager (OEM). Is there more to remote control than setting GUC variables? Tell me more! Cheers, Patrick ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Log rotation
On Sat, Mar 13, 2004 at 10:36:23AM -0500, Fernando Nasser wrote: Lamar Owen wrote: Ok, riddle me this: If I have PostgreSQL set to log to syslog facility LOCAL0, and a local0.none on /var/log/messages and local0.* to /var/log/pgsql (assuming only one postmaster, unfortunately) then you get a flat file. The problem is that sysloging has more overhead than a plain append to a file. There are some very strict response time AppServer applications where we want to keep this things out of the picture. I thought it was an advantage to say log to that box running syslog over there and leave my disk alone - what do you have in mind with AppServer applications ? It may be desirable to logrotate them at different times as well, so they would have to be in different files. syslogd with newsyslog, just like any other log file? I must be missing something.. I don't see why postgresql is different.. Cheers, Patrick ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] NetBSD/acorn32
On Sun, Nov 09, 2003 at 09:51:31PM +0100, Peter Eisentraut wrote: Patrick Welche writes: PostgreSQL 7.5devel on arm-unknown-netbsdelf1.6ZE, compiled by GCC gcc (GCC) 3.3.2-nb1 Can you test 7.4? Several days of compiling later.. All 93 tests passed. with 7.4rc2 on NetBSD-1.6ZE/acorn32. Patrick ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] NetBSD/acorn32
I may have missed 1.4: PostgreSQL 7.5devel on arm-unknown-netbsdelf1.6ZE, compiled by GCC gcc (GCC) 3.3.2-nb1 but all tests work there. I didn't manage to compile bison 1.875 under NetBSD-1.6P/acorn32, as gcc 2.95.3 really didn't like it. Upgrading to NetBSD-1.6ZE/acorn32 upgraded to gcc 3.3.2, so let me build the bison. (bison 1.75 was fine for both) This doesn't say anything about postgresql though, and I'm guessing that postgresql itself would be fine with the older NetBSD/acorn32... Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Open items
On Mon, Oct 27, 2003 at 11:32:45PM -0500, Tom Lane wrote: Have gcc use -g, add --disable-debug, rename? Personally I don't like the idea of this behavior defaulting differently depending on which compiler you use. I can see the practical arguments for doing so, but it still rubs me the wrong way. Can anyone offer new arguments pro or con here? Not an argument.. I use gcc, and I configure --enable-debug --enable-cassert. I was surprised reading the discussion that the --enable-debug was superfluous and thought it didn't feel right.. Cheers, Patrick ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] ecpg doesn't compile (datetime.h/dtime_t)
On Fri, Oct 03, 2003 at 03:00:36PM +0100, Patrick Welche wrote: On Fri, Oct 03, 2003 at 12:59:19PM +0200, Michael Meskes wrote: On Mon, Sep 29, 2003 at 06:41:48PM +0100, Patrick Welche wrote: Today's cvs doesn't compile. I think it is due to cvs diff -r1.7 -r1.8 src/interfaces/ecpg/include/datetime.h I have dtime_t defined in my sys/types.h. The old version of datetime.h used I tried too hide these type definitions from our build process. It should compile now. All fine today.. Patrick ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] ecpg doesn't compile (datetime.h/dtime_t)
On Fri, Oct 03, 2003 at 12:59:19PM +0200, Michael Meskes wrote: On Mon, Sep 29, 2003 at 06:41:48PM +0100, Patrick Welche wrote: Today's cvs doesn't compile. I think it is due to cvs diff -r1.7 -r1.8 src/interfaces/ecpg/include/datetime.h I have dtime_t defined in my sys/types.h. The old version of datetime.h used I tried too hide these type definitions from our build process. It should compile now. Now I get: gcc -O2 -pipe -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/include -g -c -o timestamp.o timestamp.c In file included from ../../../../src/interfaces/ecpg/include/compatlib.h:7, from ../../../../src/interfaces/ecpg/include/datetime.h:4, from timestamp.c:14: ../../../../src/interfaces/ecpg/include/ecpglib.h:9:22: libpq-fe.h: No such file or directory In file included from ../../../../src/interfaces/ecpg/include/compatlib.h:7, from ../../../../src/interfaces/ecpg/include/datetime.h:4, from timestamp.c:14: ../../../../src/interfaces/ecpg/include/ecpglib.h:75: error: parse error before PGresult ../../../../src/interfaces/ecpg/include/ecpglib.h:79: warning: `enum ECPGttype' declared inside parameter list ../../../../src/interfaces/ecpg/include/ecpglib.h:79: warning: its scope is only this definition or declaration, which is probably not what you want ../../../../src/interfaces/ecpg/include/ecpglib.h:79: warning: parameter has incomplete type ../../../../src/interfaces/ecpg/include/ecpglib.h:80: warning: `enum ECPGttype' declared inside parameter list ../../../../src/interfaces/ecpg/include/ecpglib.h:80: warning: parameter has incomplete type In file included from timestamp.c:14: ../../../../src/interfaces/ecpg/include/datetime.h:6: error: conflicting types for `dtime_t' /usr/include/sys/types.h:184: error: previous declaration of `dtime_t' gmake[4]: *** [timestamp.o] Error 1 gmake[4]: Leaving directory `/usr/src/local/pgsql/src/interfaces/ecpg/pgtypeslib I did do a gmake distclean beforehand.. % cd src/interfaces/ecpg/include % more datetime.h #ifndef _ECPG_DATETIME_H #define _ECPG_DATETIME_H #include compatlib.h typedef timestamp dtime_t; typedef interval intrvl_t; #endif /* ndef _ECPG_DATETIME_H */ % Cheers, Patrick ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 7.4 status
On Mon, Sep 29, 2003 at 11:50:23PM +0200, Peter Eisentraut wrote:
Tom Lane writes:
At the very least we need to set a strings freeze soon, so the
translators can catch up. Peter, are you getting close to done with the
message revisions you've been making?
Yes, I think we're ready for a string freeze. Alvaro, do you have
anything you still want to submit in that area?
Does this count a string change? :)
Patrick
? psql
Index: help.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/help.c,v
retrieving revision 1.80
diff -u -r1.80 help.c
--- help.c 14 Sep 2003 22:37:13 - 1.80
+++ help.c 1 Oct 2003 19:58:15 -
@@ -234,8 +234,8 @@
ON(pset.popt.topt.format == PRINT_HTML));
fprintf(output, _( \\pset NAME [VALUE]\n
set table output option\n
- (NAME :=
{format|border|expanded|fieldsep|null|recordsep|\n
- tuples_only|title|tableattr|pager})\n));
+ (NAME :=
{format|border|expanded|fieldsep|footer|null|\n
+
recordsep|tuples_only|title|tableattr|pager})\n));
fprintf(output, _( \\t show only rows (currently %s)\n),
ON(pset.popt.topt.tuples_only));
fprintf(output, _( \\T [STRING]set HTML table tag attributes, or unset
if none\n));
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] ecpg doesn't compile (datetime.h/dtime_t)
On Mon, Sep 29, 2003 at 08:08:01PM +0200, Michael Meskes wrote: On Mon, Sep 29, 2003 at 06:41:48PM +0100, Patrick Welche wrote: Today's cvs doesn't compile. I think it is due to Forgot one question. WHich platform do you use? NetBSD - to quote cvs blame: 1.42 (eeh 30-Dec-99): typedef int32_t dtime_t; /* on-disk time_t */ Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] ecpg doesn't compile (datetime.h/dtime_t)
Today's cvs doesn't compile. I think it is due to
cvs diff -r1.7 -r1.8 src/interfaces/ecpg/include/datetime.h
I have dtime_t defined in my sys/types.h. The old version of datetime.h used
#define dtime_t timestamp, the new one uses a typedef. Is there actually
a reason to keep dtime_t, or would just performing the #define, i.e.,
the following patch be sufficient? It allows me to compile and install
postgres.. (I don't use ecpg, so I really can't say..)
Cheers,
Patrick
Index: src/interfaces/ecpg/compatlib/informix.c
===
RCS file: /projects/cvsroot/pgsql-server/src/interfaces/ecpg/compatlib/informix.c,v
retrieving revision 1.27
diff -u -r1.27 informix.c
--- src/interfaces/ecpg/compatlib/informix.c22 Sep 2003 13:19:39 - 1.27
+++ src/interfaces/ecpg/compatlib/informix.c29 Sep 2003 17:15:34 -
@@ -886,7 +886,7 @@
}
int
-dtcvfmtasc(char *inbuf, char *fmtstr, dtime_t * dtvalue)
+dtcvfmtasc(char *inbuf, char *fmtstr, timestamp * dtvalue)
{
return PGTYPEStimestamp_defmt_asc(inbuf, fmtstr, dtvalue);
}
Index: src/interfaces/ecpg/include/datetime.h
===
RCS file: /projects/cvsroot/pgsql-server/src/interfaces/ecpg/include/datetime.h,v
retrieving revision 1.8
diff -u -r1.8 datetime.h
--- src/interfaces/ecpg/include/datetime.h 20 Sep 2003 09:10:09 - 1.8
+++ src/interfaces/ecpg/include/datetime.h 29 Sep 2003 17:15:34 -
@@ -4,15 +4,12 @@
#include pgtypes_timestamp.h
#include pgtypes_interval.h
-typedef timestamp dtime_t;
-typedef interval intrvl_t;
-
-extern void dtcurrent(dtime_t *);
-extern int dtcvasc(char *, dtime_t *);
-extern int dtsub(dtime_t *, dtime_t *, intrvl_t *);
-extern int dttoasc(dtime_t *, char *);
-extern int dttofmtasc(dtime_t *, char *, int, char *);
-extern int intoasc(intrvl_t *, char *);
-extern int dtcvfmtasc(char *, char *, dtime_t *);
+extern void dtcurrent(timestamp *);
+extern int dtcvasc(char *, timestamp *);
+extern int dtsub(timestamp *, timestamp *, interval *);
+extern int dttoasc(timestamp *, char *);
+extern int dttofmtasc(timestamp *, char *, int, char *);
+extern int intoasc(interval *, char *);
+extern int dtcvfmtasc(char *, char *, timestamp *);
#endif /* ndef _ECPG_DATETIME_H */
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 2-phase commit
On Fri, Sep 26, 2003 at 02:49:30PM -0300, Marc G. Fournier wrote: ... if we are talking two computers sitting next to each other on a switch, you'd expect those to be low ... but if you were talking about two seperate geographical locations (and yes, I realize you are adding lag to the mix with waiting for responses), you'd expect those #s to rise ... Which I thought was the whole point of using a group communication protocol such as spread in postgresql-r. It seemed solved there... Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] missing pg_clog files ?
On Mon, Sep 22, 2003 at 02:21:43PM -0400, Alvaro Herrera wrote: On Mon, Sep 22, 2003 at 05:03:28PM +0100, Patrick Welche wrote: On Mon, Sep 22, 2003 at 11:33:30AM -0400, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: I hope I guessed the right syntax... % pg_filedump -R 71716 data/base/17148/283342 Yes, but this doesn't give all the available info. Add -i and -f options. A plain -d dump might be interesting too. Indeed, the plain -d dump says that I have a chunk of /var/mail/prlw1 in 1000-13ff. No wonder postgres complained! For the record, what filesystem is this on? Is it ReiserFS by any chance? Nope, ffs with soft dependencies, on a 1 month old IDE drive (read not yet known good...) Hmm maybe I'd better ask over on the NetBSD list, though I think my kernel is from just before ide rototill which was actually on atapi rather than straight ide AFAICT, and certainly before gcc 3.3.1, so the duff hardware scenario seems best.. Cheers, Patrick ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] missing pg_clog files ?
There was a thread on missing pg_clog files caused due to dodgy practices in glibc *last year*. I am seeing something similar *now* with a server PostgreSQL 7.4beta1 on i386-unknown-netbsdelf1.6X, compiled by GCC 2.95.3 accessed by a similar client and a client PostgreSQL 7.4devel on i686-pc-linux-gnu, compiled by GCC 2.95.4 The following works: select * from olddata02_03vac offset 2573718 limit 1; however select * from olddata02_03vac offset 2573719 limit 1; ERROR: could not access status of transaction 1664158221 DETAIL: open of file /usr/local/pgsql/data/pg_clog/0633 failed: No such file or directory and # ls -l pg_clog total 32 -rw--- 1 postgres postgres 16384 Sep 22 13:12 # Is it true that the problem was with the server, so the fact that a glibc client was connecting and possibly doing a vacuum is irrelevant? What can I do now to fix it? Known problem with beta1 which is now old? Cheers, Patrick ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] missing pg_clog files ?
On Mon, Sep 22, 2003 at 10:50:22AM -0400, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: select * from olddata02_03vac offset 2573719 limit 1; ERROR: could not access status of transaction 1664158221 DETAIL: open of file /usr/local/pgsql/data/pg_clog/0633 failed: No such file or directory # ls -l pg_clog total 32 -rw--- 1 postgres postgres 16384 Sep 22 13:12 What you have here is a corrupted tuple (viz, a silly transaction number). It would be useful to look at the page containing the tuple to see if any pattern can be detected in the corruption. To do this, get the ctid of the prior tuple: select ctid from olddata02_03vac offset 2573718 limit 1; (71716,15) This will give you a result (blocknumber,tuplenumber). The bogus tuple is probably on the same page, though possibly further along. Next find a dump tool --- I usually use Red Hat's pg_filedump: http://sources.redhat.com/rhdb/tools.html Dump out the page(s) in question and send them along. I hope I guessed the right syntax... % pg_filedump -R 71716 data/base/17148/283342 *** * PostgreSQL File/Block Formatted Dump Utility - Version 2.0-Alpha * * File: data/base/17148/283342 * Options used: -R 71716 * * Dump created on: Mon Sep 22 16:21:29 2003 *** Block 71716 Header - Block Offset: 0x23048000 Offsets: Lower 176 (0x00b0) Block: Size 8192 Version1Upper 236 (0x00ec) LSN: logid 1 recoff 0xd308022c Special 8192 (0x2000) Items: 39 Free Space: 60 Length (including item array): 180 Data -- Item 1 -- Length: 204 Offset: 7988 (0x1f34) Flags: USED Item 2 -- Length: 204 Offset: 7784 (0x1e68) Flags: USED Item 3 -- Length: 204 Offset: 7580 (0x1d9c) Flags: USED Item 4 -- Length: 204 Offset: 7376 (0x1cd0) Flags: USED Item 5 -- Length: 204 Offset: 7172 (0x1c04) Flags: USED Item 6 -- Length: 204 Offset: 6968 (0x1b38) Flags: USED Item 7 -- Length: 204 Offset: 6764 (0x1a6c) Flags: USED Item 8 -- Length: 204 Offset: 6560 (0x19a0) Flags: USED Item 9 -- Length: 204 Offset: 6356 (0x18d4) Flags: USED Item 10 -- Length: 204 Offset: 6152 (0x1808) Flags: USED Item 11 -- Length: 204 Offset: 5948 (0x173c) Flags: USED Item 12 -- Length: 204 Offset: 5744 (0x1670) Flags: USED Item 13 -- Length: 204 Offset: 5540 (0x15a4) Flags: USED Item 14 -- Length: 204 Offset: 5336 (0x14d8) Flags: USED Item 15 -- Length: 204 Offset: 5132 (0x140c) Flags: USED Item 16 -- Length: 204 Offset: 4928 (0x1340) Flags: USED Item 17 -- Length: 204 Offset: 4724 (0x1274) Flags: USED Item 18 -- Length: 204 Offset: 4520 (0x11a8) Flags: USED Item 19 -- Length: 204 Offset: 4316 (0x10dc) Flags: USED Item 20 -- Length: 204 Offset: 4112 (0x1010) Flags: USED Item 21 -- Length: 204 Offset: 3908 (0x0f44) Flags: USED Item 22 -- Length: 204 Offset: 3704 (0x0e78) Flags: USED Item 23 -- Length: 204 Offset: 3500 (0x0dac) Flags: USED Item 24 -- Length: 204 Offset: 3296 (0x0ce0) Flags: USED Item 25 -- Length: 204 Offset: 3092 (0x0c14) Flags: USED Item 26 -- Length: 204 Offset: 2888 (0x0b48) Flags: USED Item 27 -- Length: 204 Offset: 2684 (0x0a7c) Flags: USED Item 28 -- Length: 204 Offset: 2480 (0x09b0) Flags: USED Item 29 -- Length: 204 Offset: 2276 (0x08e4) Flags: USED Item 30 -- Length: 204 Offset: 2072 (0x0818) Flags: USED Item 31 -- Length: 204 Offset: 1868 (0x074c) Flags: USED Item 32 -- Length: 204 Offset: 1664 (0x0680) Flags: USED Item 33 -- Length: 204 Offset: 1460 (0x05b4) Flags: USED Item 34 -- Length: 204 Offset: 1256 (0x04e8) Flags: USED Item 35 -- Length: 204 Offset: 1052 (0x041c) Flags: USED Item 36 -- Length: 204 Offset: 848 (0x0350) Flags: USED Item 37 -- Length: 204 Offset: 644 (0x0284) Flags: USED Item 38 -- Length: 204 Offset: 440 (0x01b8) Flags: USED Item 39 -- Length: 204 Offset: 236 (0x00ec) Flags: USED *** End of Requested Range Encountered. Last Block Read: 71716 *** Cheers, Patrick ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] missing pg_clog files ?
On Mon, Sep 22, 2003 at 11:33:30AM -0400, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: I hope I guessed the right syntax... % pg_filedump -R 71716 data/base/17148/283342 Yes, but this doesn't give all the available info. Add -i and -f options. A plain -d dump might be interesting too. Indeed, the plain -d dump says that I have a chunk of /var/mail/prlw1 in 1000-13ff. No wonder postgres complained! Highlight: 0fe0: 0600 0ff0: 0100 3e00 ... 1000: 52657475 726e2d70 6174683a 203c7072 Return-path: pr 1010: 6c773140 6e65776e 2e63616d 2e61632e [EMAIL PROTECTED] ... 13e0: 38323020 20202020 37313139 38202020 820 71198 13f0: 20323425 20202020 32303637 20202032 24%2067 2 1400: 3e00 0300 b609 ...¶... 1410: 01002418 0f001a00 ..$. Would you be interested in the full dump anyway? It seems this is trashed and I need to bring out the backups, right? Next is speculation as to how? I read a very large mail file with mutt which I think uses mmap. It still begs the question how did that end up in the database.. Worth reloading into same database server, or upgrade to current cvs? NetBSD-1.6ZC/i386 with 2Gb memory. Thanks for the help! Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] compile warnings in CVS HEAD?
On Mon, Sep 15, 2003 at 08:09:22PM +0200, Peter Eisentraut wrote: Neil Conway writes: On Thu, 2003-09-04 at 13:14, Kurt Roeckx wrote: tablecmds.c: In function `validateForeignKeyConstraint': tablecmds.c:3546: warning: dereferencing type-punned pointer will break strict-aliasing rules So, what should we do with this? Rumor has it that many of these warnings are bogus. But I wouldn't want to turn them off altogether because that might hide real problems. At this point, I think we should wait a while until the compiler becomes more mature. Bother - I'm just upgrading from 2.95.3 to 3.3.1 as this will be default on NetBSD :/ Patrick ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Upgrading my BSDI box, again
On Wed, Jul 30, 2003 at 12:38:54AM -0400, Bruce Momjian wrote: [ CC to Kurt and Steven on bsdi list.] Guys, I just replied to this email on the BSDi email list. The issue is that someone found that some(most?) IDE drives have write cache enabled, though the drives do not preserve the write cache data on power failure. I am surprised we have not heard of this failure before because I know most vendors who ship PostgreSQL test our crash recovery thoroughly. Are they testing only using SCSI drives? Below you will read that my Seagate SCSI drive has write cache disabled, but another guy has a Seagate IDE drive that has it enabled, though it loses data on power failure. Scarey! Does anyone have any more detailed information on this? Not really, just that I had data corruption on SCSI disks which had write cache enabled and tagged queueing. Disabling write cache has allowed them to function flawlessly since. The moral seems to be: write cache gives pretty performance figures, but you really want it swiched off. Cheers, Patrick ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] cvs problem
On Wed, Jul 23, 2003 at 12:53:34PM -0400, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: On a different note, I also wonder about: M src/backend/parser/gram.c It seems that you checkout the source with no gram.c. Build it, thus creating gram.c. Next time you cvs update, you get Attic/gram.c merged in :/ - or is my use of cvs incorrect? (cvs -z3 update -P -d) Hm. Doesn't happen for me. What CVS version are you using? (I have 1.10.7 and 1.11.2 on two different machines, and neither of them have any problem with gram.c being present during cvs update ...) Do you have any other settings in ~/.cvsrc? I have 2 machines which both have a problem with it. However, I found a third which had Dec 2002 source on it (the other 2 are updated regularly). The difference was the that the 2 unhappy ones had /gram.c/2.90/Thu Jul 24 11:45:32 2003// in src/backend/parser/CVS/Entries whereas the old one didn't.. Editing Entries fixed it :) Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] cvs problem
cvs server: Updating src/bin/scripts/po cvs server: failed to create lock directory for `/projects/cvsroot/pgsql-server/src/bin/scripts/po' (/projects/cvsroot/pgsql-server/src/bin/scripts/po/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/projects/cvsroot/pgsql-server/src/bin/scripts/po' cvs [server aborted]: read lock failed - giving up On a different note, I also wonder about: M src/backend/parser/gram.c It seems that you checkout the source with no gram.c. Build it, thus creating gram.c. Next time you cvs update, you get Attic/gram.c merged in :/ - or is my use of cvs incorrect? (cvs -z3 update -P -d) Cheers, Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] cvs problem
On Wed, Jul 23, 2003 at 11:34:04AM -0300, The Hermit Hacker wrote: try it now ... I think its a pathing problem with a cron entry ... just fixed that, so should be okay now ... ... cvs [server aborted]: read lock failed - giving up Yup - that's all fine thanks! On a different note, I also wonder about: M src/backend/parser/gram.c It seems that you checkout the source with no gram.c. Build it, thus creating gram.c. Next time you cvs update, you get Attic/gram.c merged in :/ - or is my use of cvs incorrect? (cvs -z3 update -P -d) What do you make of this bit? Cheers, Patrick ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] backend/parser compile prob
On Tue, Jul 15, 2003 at 12:42:45PM -0400, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: ... What string constant?! Will try again later... Which flex version are you using? You need 2.5.4 --- the most recent versions have broken backwards compatibility :-(. I'm not sure what the symptom looks like, though. Answer is: a broken flex 2.5.4. There were some commits to NetBSD flex to use bounded strings. Using 13th July flex source builds a happy PostgreSQL. Now to track down which bit broke - anyway, not a PostgreSQL problem :-) Cheers, Patrick == All 91 tests passed. == NetBSD-1.6U/i386 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] backend/parser compile prob
On Wed, Jul 16, 2003 at 11:58:01PM +0900, [EMAIL PROTECTED] wrote: could you try lex/scan.l 1.13 i just committed? Yes, that fixed it! Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] backend/parser compile prob
I'm getting far too many errors while trying to compile gram.c in the backend/parser, that I must be missing something.. Story so far gmake distclean cvs update configure --enable-debug --enable-cassert gmake gmake[3]: Entering directory `/usr/src/local/pgsql/src/backend/parser' gcc -O2 -pipe -g -Wall -Wmissing-prototypes -Wmissing-declarations -I. -I../../../src/include -c -o gram.o gram.c gram.y:105: parse error before `Attr' gram.y:105: warning: no semicolon at end of struct or union gram.y:109: parse error before `*' gram.y:109: warning: type defaults to `int' in declaration of `param' gram.y:109: warning: data definition has no type or storage class ... GNU Make version 3.79.1 % cvs diff src/backend/parser/gram.c % In other words, I'm not even regenerating gram.c with bison (GNU Bison) 1.875 flex version 2.5.4 Thoughts? Cheers, Patrick ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] backend/parser compile prob
On Tue, Jul 15, 2003 at 11:21:51AM -0400, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: I'm getting far too many errors while trying to compile gram.c in the backend/parser, that I must be missing something. I think you need to force gram.c to be regenerated. Try removing it (and parse.h too) before building. % cvs diff src/backend/parser/gram.c gram.c is not in CVS. I'm surprised you didn't get an error from that. (I get cvs server: I know nothing about gram.c.) Ah: Attic: % cvs status gram.c === File: gram.cStatus: Up-to-date Working revision:2.90 Repository revision: 2.90 /projects/cvsroot/pgsql-server/src/backend/parser/Attic/gram.c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) hmm... rm gram.c parse.h scan.c gmake[3]: Leaving directory `/usr/src/local/pgsql/src/port' gmake -C parser parse.h gmake[3]: Entering directory `/usr/src/local/pgsql/src/backend/parser' bison -y -d gram.y mv -f y.tab.c ./gram.c mv -f y.tab.h ./parse.h gmake[3]: Leaving directory `/usr/src/local/pgsql/src/backend/parser' prereqdir=`cd parser/ /dev/null pwd` \ cd ../../src/include/parser/ rm -f parse.h \ ln -s $prereqdir/parse.h . gmake -C access all gmake[3]: Entering directory `/usr/src/local/pgsql/src/backend/access' ... gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/usr/src/local/pgsql/src/backend/catalog' gmake -C parser all gmake[3]: Entering directory `/usr/src/local/pgsql/src/backend/parser' /usr/bin/flex -CF -o'scan.c' scan.l gcc -O2 -pipe -g -Wall -Wmissing-prototypes -Wmissing-declarations -I. -I../../../src/include -c -o gram.o gram.c In file included from gram.y:7990: scan.c:121: parse error before string constant scan.c:247: parse error before string constant scan.c:250: parse error before string constant scan.c:251: parse error before string constant ... What string constant?! Will try again later... Cheers, Patrick ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Pre-allocation of shared memory ...
On Thu, Jun 12, 2003 at 10:10:02PM -0400, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: You have to love that swap + 1/2 ram option --- when you need four possible options, there is something wrong with your approach. :-) I'm still wondering what the no overcommit handling option does, exactly. I assume it does no kills, and allows you to commit until you run of of swap and hang. This might be the BSD 4.4 behavior, actually. ? I thought the idea of no overcommit was that your malloc fails ENOMEM if there isn't enough memory free for your whole request, rather than gambling that other processes aren't actually using all of theirs right now and have pages swapped out. I don't see where the hang comes in.. It is bad to hang the system, but if it reports swap failure, at least the admin knows why it failed, rather than killing random processes. Yes! Patrick ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] request for sql3 compliance for the update command
On Wed, Feb 19, 2003 at 07:31:35AM -0500, Dave Cramer wrote: Bruce, Can you chime in with your support here? Dave I have a large customer who is converting from informix to postgres and they have made extensive use of update table set (col...) = ( val...) as a first pass would it be possible to translate this in the parser to update table set col=val It would appear that this is SQL3 compliant set clause ::= update target equals operator row value designator update target ::= object column | left paren object column list right paren or can someone think of another way? I don't understand the original problem. What does informix give you? A text file full of update table set ()=() which you then try to feed into postgres? In that case, why not pass said text file through a sed or perl script first? Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psql and readline
On Sat, Feb 15, 2003 at 03:10:19PM -0600, Ross J. Reedstrom wrote:
On Fri, Feb 14, 2003 at 11:32:02AM -0500, Tom Lane wrote:
Patrick Welche [EMAIL PROTECTED] writes:
On Thu, Feb 13, 2003 at 10:25:52AM -0500, Tom Lane wrote:
Well, is that a bug in your wrapper? Or must we add a configure test
for the presence of replace_history_entry()?
Good question. Easiest for now for me would be add a configure test.
Okay with me --- Ross, can you handle that?
I'll take a crack at it. Testing will be a problem, since all my machines
have libreadline installed, but I've got one I can probably pull it off
of. Patrick, is 'your libedit wrapper' your personal code, or something
standard on some set of systems (e.g. *BSD) ?
It's the standard NetBSD libedit which comes with built-in readline emulation,
it's just that replace_history_entry isn't one of the emulated functions.
({read,write,add}_history() are included)
Ross one line patches always grow Reedstrom
:-)
I'm of course very happy to test the growing patch!
Cheers,
Patrick
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] psql and readline
On Thu, Feb 13, 2003 at 10:25:52AM -0500, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: The sad thing is that my readline wrapper for libedit doesn't wrap replace_history_entry, Well, is that a bug in your wrapper? Or must we add a configure test for the presence of replace_history_entry()? Good question. Easiest for now for me would be add a configure test. Long term libedit needs tweeking... In fact for now, I just comment out the call the replace_history_entry, as I am more than happy with the rest of the readline behaviour (as implemented in libedit). Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] psql and readline
The sad thing is that my readline wrapper for libedit doesn't wrap replace_history_entry, so I could use readline up until now, the tests for readline succeed as the functions tested for exist, but command.o: In function `do_edit': /usr/src/local/pgsql/src/bin/psql/command.c:1652: undefined reference to `replace_history_entry' ho hum.. Patrick On Wed, Feb 12, 2003 at 11:08:16PM -0500, Bruce Momjian wrote: Patch applied. Thanks. --- Ross J. Reedstrom wrote: On Fri, Jan 10, 2003 at 11:02:55PM +0100, Peter Eisentraut wrote: Ross J. Reedstrom writes: I already posted a one-line patch to implement this, but it doesn't seem to hve come through to the list. Here it is inline, instead of as an attachment: We need this to work without readline as well. (Of course there won't be any history, but it needs to compile.) blush Even after slogging my way through the nesting #ifdefs for readline and win32, I forgot! Let's make that a three line patch, then. Index: src/bin/psql/command.c === RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/command.c,v retrieving revision 1.84 diff -u -r1.84 command.c --- src/bin/psql/command.c 2002/10/23 19:23:56 1.84 +++ src/bin/psql/command.c 2003/01/10 22:06:07 @@ -1639,6 +1639,9 @@ error = true; } +#ifdef USE_READLINE + replace_history_entry(where_history(),query_buf-data,NULL); +#endif fclose(stream); } Ross ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Changing the default configuration (was Re: [pgsql-advocacy] [HACKERS] PostgreSQL Benchmarks)
On Tue, Feb 11, 2003 at 11:20:14AM -0500, Tom Lane wrote: ... We could retarget to try to stay under SHMMAX=4M, which I think is the next boundary that's significant in terms of real-world platforms (isn't that the default SHMMAX on some BSDen?). ... Assuming 1 page = 4k, and number of pages is correct in GENERIC kernel configs, SHMMAX=4M for NetBSD (8M for i386, x86_64) Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] SIGSEGV
Using cvs source of Dec 4 15:13:
test=# \d amount
Table public.amount
Column | Type | Modifiers
+-+
id | integer | not null default nextval('public.amount_id_seq'::text)
value | integer |
test=# select value from amount;
value
---
(0 rows)
test=# select value from amount;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!#
Not very graceful... (and this is different to the geqo prob I saw with my
libpq++ program, cured with geqo=false (Thanks Tom!))
Program received signal SIGSEGV, Segmentation fault.
transformTargetEntry (pstate=0x82e235c, node=0x82e21fc, expr=0x0, colname=0x0,
resjunk=0 '\000') at parse_target.c:61
61 if (IsA(expr, RangeVar))
(gdb) bt
#0 transformTargetEntry (pstate=0x82e235c, node=0x82e21fc, expr=0x0,
colname=0x0, resjunk=0 '\000') at parse_target.c:61
#1 0x80c2af0 in transformTargetList (pstate=0x82e235c, targetlist=0x82e2234)
at parse_target.c:192
#2 0x80a9c00 in transformSelectStmt (pstate=0x82e235c, stmt=0x82e22b4)
at analyze.c:1654
#3 0x80a7feb in transformStmt (pstate=0x82e235c, parseTree=0x82e22b4,
extras_before=0xbfbfa9b0, extras_after=0xbfbfa9b4) at analyze.c:308
#4 0x80a7bd0 in parse_analyze (parseTree=0x82e22b4, parentParseState=0x0)
at analyze.c:147
#5 0x813e1c0 in pg_analyze_and_rewrite (parsetree=0x82e22b4) at postgres.c:408
#6 0x813e4a3 in pg_exec_query_string (query_string=0x82e201c, dest=Remote,
parse_context=0x828c8ac) at postgres.c:696
#7 0x813f935 in PostgresMain (argc=5, argv=0xbfbfaca8,
username=0x826a925 prlw1) at postgres.c:2016
#8 0x8124332 in DoBackend (port=0x826a800) at postmaster.c:2293
#9 0x8123c25 in BackendStartup (port=0x826a800) at postmaster.c:1915
#10 0x8122e0b in ServerLoop () at postmaster.c:1002
#11 0x8122972 in PostmasterMain (argc=3, argv=0x8266030) at postmaster.c:781
#12 0x80fb135 in main (argc=3, argv=0xbfbfb4b4) at main.c:209
#13 0x8069e84 in ___start ()
Cheers,
Patrick
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] possible libpq++ prob
I have a program which worked merrily under 1.3b1, but with 1.4devel I get the first query working (so connection OK), and the second query, which may well be wrong, getting me: DEBUG: reaping dead processes DEBUG: child process (pid 13025) was terminated by signal 11 LOG: server process (pid 13025) was terminated by signal 11 LOG: terminating any other active server processes DEBUG: CleanupProc: sending SIGQUIT to process 13022 WARNING: Message from PostgreSQL backend: The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory. I have rolled back the current transaction and am going to terminate your database system connection and exit. Please reconnect to the database system and repeat your query. DEBUG: reaping dead processes DEBUG: child process (pid 13022) exited with exit code 1 LOG: all server processes terminated; reinitializing shared memory and semaphores Should I be able to cause this with a duff query? I'm now digging myself in further by trying to recompile the program which uses libpq++ - I don't think libpq++ works terribly well anymore but unfortunately I have to leave now before figuring out what pg_config.h includes may be needed to define eg DLLIMPORT etc. More later no doubt... Cheers, Patrick ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] postgres core dump
Just tried a make runcheck with source from Dec 4 15:13 GMT, and:
Core was generated by `postgres'.
Program terminated with signal 11, Segmentation fault.
#0 ExecGetTupType (node=0x8453978) at execProcnode.c:744
744 slot =
hashjoinstate-jstate.cs_ResultTupleSlot;
(gdb) bt
#0 ExecGetTupType (node=0x8453978) at execProcnode.c:744
#1 0x80e6f6e in InitPlan (operation=CMD_INSERT, parseTree=0x837bb68,
plan=0x8453978, estate=0x8453bc0) at execMain.c:585
#2 0x80e69a0 in ExecutorStart (queryDesc=0x8453b94, estate=0x8453bc0)
at execMain.c:124
#3 0x81404bc in ProcessQuery (parsetree=0x837bb68, plan=0x8453978,
dest=Debug, completionTag=0xbfbfb1a4 Ô±¿¿|à\023\bP³\\b\n)
at pquery.c:214
#4 0x813e6b1 in pg_exec_query_string (query_string=0x837b01c, dest=Debug,
parse_context=0x8367444) at postgres.c:838
#5 0x813f991 in PostgresMain (argc=9, argv=0x8266000,
username=0x8268120 prlw1) at postgres.c:2016
#6 0x80fb21f in main (argc=9, argv=0xbfbfb310) at main.c:234
#7 0x8069e84 in ___start ()
I think it had just got to the initdb..
(gdb) print *node
$1 = {type = T_HashJoin, startup_cost = 2.9253,
total_cost = 50.047, plan_rows = 370, plan_width = 172,
state = 0x8453bc0, instrument = 0x0, targetlist = 0x8453a4c, qual = 0x0,
lefttree = 0x8452874, righttree = 0x84538ec, extParam = 0x0, locParam = 0x0,
chgParam = 0x0, initPlan = 0x0, subPlan = 0x0, nParamExec = 0}
(gdb) print *node-hashjoinstate
There is no member named hashjoinstate.
??
Cheers,
Patrick
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[HACKERS] postgres core dump PS
(gdb) print *((HashJoin *) node)-hashjoinstate
$4 = {jstate = {type = T_HashJoinState, cs_OuterTupleSlot = 0x0,
cs_ResultTupleSlot = 0x84527cc, cs_ExprContext = 0x8453e60,
cs_ProjInfo = 0x84546e0, cs_TupFromTlist = 0 '\000'}, hj_HashTable = 0x0,
hj_CurBucketNo = 0, hj_CurTuple = 0x0, hj_OuterHashKeys = 0x8454728,
hj_InnerHashKeys = 0x84538d0, hj_OuterTupleSlot = 0x84527e0,
hj_HashTupleSlot = 0x8452790, hj_NullInnerTupleSlot = 0x0,
hj_NeedNewOuter = 1 '\001', hj_MatchedOuter = 0 '\000',
hj_hashdone = 0 '\000'}
of course.. but still, why the segfault?
Patrick
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] postgres core FALSE ALARM
I must have had an old object file in the build tree... It's all happy now. Sorry for the noise, Patrick (geometry fails just because of the ordering of the rows in twenty) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] 24:00:00 ?
transatlantic=# select '23:59:59.72'::time(0) without time zone; time -- 24:00:00 (1 row) So dumping a table with times derived from the timestamp then fails on the reload with: psql:transatlantic.dat:43681: ERROR: copy: line 5818, Bad time external representation '24:00:00' psql:transatlantic.dat:43681: lost synchronization with server, resetting connection timeslice | timestamp(6) without time zone | timesliced | date | timeslicet | time(0) without time zone | (timesliced and timesllicet are for M$ Access' benefit and just contain the date and time parts of timeslice as per above) So, that's what happened, but what can one do? 24:00:00 seems like a sensible rounding for 23:59:59.72, and it is also true that 24:00:00 isn't really a valid time (or could it in strange days with an extra second?), so both sides seem to be right, it's just the overall effect which seems bad. (sed s/24:00:00/23:59:59/g fixed the 5.6Gb data file..) Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PORTS] Geometry test on NetBSD (was Re: [HACKERS] RC1?)
On Wed, Nov 20, 2002 at 06:48:15PM +0100, Peter Eisentraut wrote: Tom Lane writes: AFAIK, all modern hardware claims compliance to the IEEE floating-point arithmetic standard, so failure to print minus zero as minus zero is very likely to be a software issue not hardware. That suggests strongly that the issue is netbsd version (specifically libc version) and not the hardware platform. I could confirm my initial suspicion: it's a *printf() library issue. The FreeBSD CVS log tells the tale: http://www.de.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/vfprintf.c The next FreeBSD subrelease (4.8?) should have this fixed. OpenBSD is not fixed. NetBSD and Darwin seem to have temporarily hidden their cvsweb in shame, but I would assume it's the same issue. Not sure what HP-UX is doing about it. Right, the equivalent for NetBSD vfprintf.c is: revision 1.40 date: 2001/11/28 11:58:22; author: kleink; state: Exp; lines: +4 -4 Since we're returned the sign of a floating-point number by __dtoa(), use that to decide whether to include a minus sign in the result. Fixes printing -0.0, and thus PR lib/3137. NetBSD 1.5 has revision 1.32, NetBSD 1.6 has revision 1.42 Well spotted, Patrick ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PORTS] Geometry test on NetBSD (was Re: [HACKERS] RC1?)
On Wed, Nov 20, 2002 at 01:21:47PM -0500, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: ... NetBSD 1.5 has revision 1.32, NetBSD 1.6 has revision 1.42 Ah-hah, so it is a version issue --- we could make the resultmap line something like geometry/.*-netbsd1.[0-5]=geometry-positive-zeros Would you confirm what config.guess prints on your box --- in particular, is there a dot in the version number? Yes: NetBSD/i386-1.6H i386-unknown-netbsdelf1.6H (checked 7.3rc1) NetBSD/acorn32-1.6K arm-unknown-netbsdelf1.6K (still building 7.3rc1) (several NetBSDs probably come up with arm-unknown..) Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [PORTS] Geometry test on NetBSD (was Re: [HACKERS] RC1?)
On Wed, Nov 20, 2002 at 01:51:28PM -0500, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: On Wed, Nov 20, 2002 at 01:21:47PM -0500, Tom Lane wrote: Ah-hah, so it is a version issue --- we could make the resultmap line something like geometry/.*-netbsd1.[0-5]=geometry-positive-zeros NetBSD/i386-1.6H i386-unknown-netbsdelf1.6H (checked 7.3rc1) NetBSD/acorn32-1.6K arm-unknown-netbsdelf1.6K (still building 7.3rc1) Hm, is that elf always there? I'm a little uncomfortable with making the pattern be geometry/.*-netbsd.*1.[0-5]=geometry-positive-zeros as this seems way too lax ... elf won't always be there - that acorn32 is a case in point: it became elf for 1.6. acorn26 has always been elf. I can't remember when i386 became elf.. (In fact the old config.guess that comes with NeTraMet44b8 says i386-unknown-netbsd1.6K - so maybe the config.guess cvs log may shed some light) Just realised: the answers I gave above were with the config.guess from automake 1.7a! % uname -srmp NetBSD 1.6K acorn32 arm % postgresql-7.3rc1/config/config.guess acorn32-unknown-netbsd1.6K % automake/lib/config.guess arm-unknown-netbsdelf1.6K Confusing.. Patrick ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] RC1?
On Wed, Nov 20, 2002 at 09:33:41AM -0500, Bruce Momjian wrote: Patrick Welche wrote: On Tue, Nov 19, 2002 at 06:22:08PM +0100, Peter Eisentraut wrote: He was testing 7.4devel. That's not the right one. What's the difference? (Do I really want to wait another day while this ancient box compiles it given that the chances of it working under 7.4devel and not under 7.3rcN are smaller than the chances of it working under 7.3rcN and not under 7.4devel, no?) Uh, you are right, but we have made a _few_ 7.4 changes so I do think we need a 7.3-specific test. OK - did 7.3rc1 successfully on NetBSD-1.6K/acorn32 and NetBSD-16H/i386 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] RC1?
On Thu, Nov 14, 2002 at 09:06:01AM -0500, Tom Lane wrote: Magnus Naeslund(f) [EMAIL PROTECTED] writes: OK OK, before anyone rubs my nose in it, i see the fork() failures :) I'll see what's causing the fork() problems... Too low processes-per-user limit, likely. Success for PostgreSQL 7.4devel on acorn32-unknown-netbsd1.6K, compiled by GCC 2.95.3 In other words NetBSD/acorn32-1.6K. The fork() problem for me was not enough memory, but checking with --schedule=./serial_schedule made it pass all the tests, except geometry, which leads me to change my mind and suggest: Index: resultmap === RCS file: /projects/cvsroot/pgsql-server/src/test/regress/resultmap,v retrieving revision 1.59 diff -u -r1.59 resultmap --- resultmap 2002/11/12 20:02:32 1.59 +++ resultmap 2002/11/19 15:20:19 @@ -18,7 +18,6 @@ geometry/alpha.*-freebsd4.[0-5]=geometry-positive-zeros geometry/i.86-.*-openbsd=geometry-positive-zeros geometry/sparc-.*-openbsd=geometry-positive-zeros -geometry/.*-netbsd=geometry-positive-zeros geometry/hppa.*-hpux9=geometry-positive-zeros geometry/hppa.*-hpux10=geometry-positive-zeros geometry/.*-irix6=geometry-positive-zeros as this acorn32 is running on a StrongARM processor, so has nothing to do with libm387. Maybe get rid of the geometry-positive-zeros and see if someone complains and tells me otherwise? Cheers, Patrick ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] RC1?
On Tue, Nov 19, 2002 at 10:53:59AM -0500, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: [remove this:] -geometry/.*-netbsd=geometry-positive-zeros as this acorn32 is running on a StrongARM processor, so has nothing to do with libm387. Maybe get rid of the geometry-positive-zeros and see if someone complains and tells me otherwise? Presumably that was put in because it was correct on i86. How do you feel about changing that entry to geometry/i.86-.*-netbsd=geometry-positive-zeros rather than deleting it? I was under the impression until now that it was geometry.out for i86 using the libm387 math library, and geometry-positive-zeros for everyone else, but this acorn32 box is also giving geometry.out, so I must be wrong, in fact I've just tried not using libm387 on an i386, and it gives geometry.out too, so we might as well delete it... BTW cluster.out wants changing now that the ALL in CLUSTER ALL is no longer allowed.. Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Debian build prob
On Thu, Nov 14, 2002 at 08:55:22PM +, Patrick Welche wrote: Believe it or not, I'm trying to compile today's cvs pgsql on a Debian 2.2.19 system. Compilation dies while compiling pg_dump with ../../../src/interfaces/libpq/libpq.so: undefined reference to `atexit' In the mail archives there is a mention of upgrading libc to libc6-dev_2.2.5-3_i386.deb. As far as I can tell, that should read libc6_2.2.5-3_i386.deb, and again AFAICT this system already has libc6_2.2.5-6_i386.deb on it. I can see atexit is undefined in libpq, and it is defined in /usr/lib/libc.a. For some reason /lib/libc*.so are stripped, so it is hard to tell, but I assume it must be the same as for /usr/lib/libc.a. Have any of you managed to compile postgresql on an oldstable Debian system? Adam Buraczewski tells me its a linux i386 gcc=2.95.3 problem. Upgrading gcc to gcc version 2.95.4 20011002 (Debian prerelease) yielded a working postgresql! PostgreSQL 7.4devel on i686-pc-linux-gnu, compiled by GCC 2.95.4 Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RC1?
On Thu, Nov 14, 2002 at 06:13:56PM +, Patrick Welche wrote: On Wed, Nov 13, 2002 at 07:53:00PM +0100, Peter Eisentraut wrote: Tom Lane writes: We can't just wait around indefinitely for port reports that may or may not ever appear. In any case, most of the 7.3 entries in the list seem to be various flavors of *BSD; I think it's unlikely we broke those ... Note that we have *zero* reports for any flavor of NetBSD and OpenBSD. That is highly suspicious, and I would not venture a guess about how likely it is they're broken. PostgreSQL 7.3b1 on i386-unknown-netbsdelf1.6H, compiled by GCC 2.95.3 PostgreSQL 7.4devel on i386-unknown-netbsdelf1.6K, compiled by GCC 2.95.3 I in fact get geometry.out rather than geometry-positive-zeros.out, but I think you get the former when you use libm387.so.0 instead of libm.so.0 which isn't exactly the general case for NetBSD, though I have only one NetBSD/i386 box which can't make use of libm387 (it's a 486SX25) The 7.4devel was with source from Nov 9 12:27 GMT, so I think rather close to 7.3, and again with source from just now. Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Debian build prob
Believe it or not, I'm trying to compile today's cvs pgsql on a Debian 2.2.19 system. Compilation dies while compiling pg_dump with ../../../src/interfaces/libpq/libpq.so: undefined reference to `atexit' In the mail archives there is a mention of upgrading libc to libc6-dev_2.2.5-3_i386.deb. As far as I can tell, that should read libc6_2.2.5-3_i386.deb, and again AFAICT this system already has libc6_2.2.5-6_i386.deb on it. I can see atexit is undefined in libpq, and it is defined in /usr/lib/libc.a. For some reason /lib/libc*.so are stripped, so it is hard to tell, but I assume it must be the same as for /usr/lib/libc.a. Have any of you managed to compile postgresql on an oldstable Debian system? Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] RC1?
On Wed, Nov 13, 2002 at 07:53:00PM +0100, Peter Eisentraut wrote: Tom Lane writes: We can't just wait around indefinitely for port reports that may or may not ever appear. In any case, most of the 7.3 entries in the list seem to be various flavors of *BSD; I think it's unlikely we broke those ... Note that we have *zero* reports for any flavor of NetBSD and OpenBSD. That is highly suspicious, and I would not venture a guess about how likely it is they're broken. Does all OK on this count? PostgreSQL 7.3b1 on i386-unknown-netbsdelf1.6H, compiled by GCC 2.95.3 (I'm trying to build bison at the mo to have a go with whatever is in cvs tip at the moment.) Cheers, Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] mac typo prob?
I just cut and pasted someone's mac address: patrimoine=# update ethernet set mac='00-00-39-AB-92-FO' where id=623; UPDATE 1 patrimoine=# select mac from ethernet where id=623; mac --- 00:00:39:ab:92:0f (1 row) Note the typo O instead of 0. I can see how that happened - should it be notifyed against? (pre-25 Sept code, 7.3b1) Cheers, Patrick ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 issues
On Thu, Aug 15, 2002 at 12:09:00AM -0400, Neil Conway wrote: Bruce Momjian [EMAIL PROTECTED] writes: ... integrate or remove new libpqxx integrate or add to gborg Pg:DBD Seems like gborg is the place for these. Yes, but I'd also like to see libpq++, perl5, and possibly some other interfaces re-packaged separately. I think everyone agrees on the direction here, it just needs someone (Marc?) to do the work. Would the method of use be - checkout postgresql - cd pgsql/src/interfaces - checkout libpq++ from gborg - cd ../.. - configure --with-CXX or would libpq++ become more removed.. (configure options to libpq++ to point to the rest or pgsql?) Cheers, Patrick (prefer former) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PostgreSQL mission statement?
On Thu, May 02, 2002 at 01:14:34PM -0300, Marc G. Fournier wrote: On 2 May 2002, Hannu Krosing wrote: ... BTW, I think PostgreSQL does _not_ need any mission statement. Nope, it doesn't ... never did before, don't know why it does suddenly ... do any other open source projects have one? Its kinda fun to see what ppl banter around, but I can't see it being useful to adopt any single one, considering I can't see *everyone* agreeing with it ... Quick - get out the Dilbert! Patick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] anoncvs failure...
On Mon, Sep 24, 2001 at 06:04:17PM +0100, Patrick Welche wrote: ... and CVSROOT is not set as an environment variable... Also odd that it appears there and there is no sign of home anywhere.. Got it: had /home/... in pgsql/src/backend/access/heap/CVS/Repository (!) All OK now.. Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] anoncvs failure...
On Mon, Sep 24, 2001 at 10:22:28AM -0400, Marc G. Fournier wrote: okay, somehow you have two different CVSROOT's configured? /home/projects/pgsql/cvsroot was the old server, /projects/cvsroot is the new one Any hints? I had done a (csh) cd /usr/src/local/pgsql find . -name Root -print allroots grep -v CVS allroots foreach i ( `cat allroots`) echo :pserver:[EMAIL PROTECTED]:/projects/cvsroot $i end and CVSROOT is not set as an environment variable... Also odd that it appears there and there is no sign of home anywhere.. Cheers, Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] anoncvs failure...
On Sat, Sep 22, 2001 at 08:15:11PM -0500, Dominic J. Eidson wrote: On Sat, 22 Sep 2001, Marc G. Fournier wrote: anoncvs: :pserer:[EMAIL PROTECTED]:/projects/cvsroot - passwd is blank, but postgresql should work just as well I can confirm that this works. Still no good for me: protocol error: directory '/home/projects/pgsql/cvsroot/pgsql/src/backend/access/heap' not within root '/projects/cvsroot' Checking: % pwd /usr/src/local/pgsql/src/backend/access/heap % cat CVS/Root :pserver:[EMAIL PROTECTED]:/projects/cvsroot ? Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Further CVS errors
On Fri, Sep 21, 2001 at 07:27:10PM +0200, Horák Daniel wrote: ... but still I am getting cannot create_adm_p /tmp/cvs-serv24877/ChangeLogs Permission denied aol Me Too! /aol ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Major change to CVS effective immediately ...
On Wed, Sep 19, 2001 at 10:14:44AM -0400, Marc G. Fournier wrote: :pserver:[EMAIL PROTECTED]:/projects/cvsroot While trying a cvs update, I get ? ChangeLogs/libecpg.so.3.1.1 ? ChangeLogs/HTML ? ChangeLogs/GTAGS ? ChangeLogs/GPATH ? ChangeLogs/GRTAGS ? ChangeLogs/GSYMS ? ChangeLogs/libpqpp.h cannot create_adm_p /tmp/cvs-serv27285/ChangeLogs Cheers, Patrick ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] backend hba.c prob
On Fri, Sep 07, 2001 at 04:05:58PM -0400, Bruce Momjian wrote: ... OK, I have modified the CVS CREDS code to work on FreeBSD and BSD/OS, and hopefully NetBSD. I talked to Jason at Linuxworld and I think this code should work. Please test the CVS version and let me know. OpenBSD doesn't support creds as far as I can tell. To test, define 'ident sameuser' for 'local' in pg_hba.conf and restart postmaster. Then connect as local user. All tested OK under NetBSD :) Cheers, Patrick ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] factorial doc bug?
On Wed, Sep 12, 2001 at 02:45:10PM +0200, Peter Eisentraut wrote: Thomas Lockhart writes: Keep in mind that he is a mathematician, and I'll guess that he won't have much patience with folks who expect a result for a factorial of a fractional number ;) Real mathematicians will be perfectly happy with a factorial for a fractional number, as long as it's properly and consistently defined. ;-) Seriously, there is a well-established definition of factorials of non-integral real numbers, but the current behaviour is probably the most intuitive for the vast majority of users. I would be happy with with exp(lgamma(x+1)) as a synonym for x! (So 4.3!=38.078 as far as I'm concerned :) ) Cheers, Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] backend hba.c prob
gcc -O2 -pipe -g -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../src/include -c -o hba.o hba.c
hba.c: In function `ident_unix':
hba.c:923: sizeof applied to an incomplete type
hba.c:960: dereferencing pointer to incomplete type
hba.c:965: dereferencing pointer to incomplete type
gmake: *** [hba.o] Error 1
Now, the problem is sizeof(Cred), typedef struct cmsgcred Cred, and I don't
have a cmsgcred anywhere! The closest is my sys/ucred.h which defines a
struct ucred {
u_short cr_ref; /* reference count */
uid_t cr_uid; /* effective user id */
gid_t cr_gid; /* effective group id */
short cr_ngroups; /* number of groups */
gid_t cr_groups[NGROUPS]; /* groups */
};
Thoughts?
Cheers,
Patrick
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] backend hba.c prob
On Fri, Sep 07, 2001 at 10:14:27AM -0400, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: hba.c: In function `ident_unix': hba.c:923: sizeof applied to an incomplete type Now, the problem is sizeof(Cred), typedef struct cmsgcred Cred, and I don't have a cmsgcred anywhere! That's new code and we expected some portability issues with it :-( What platform are you on exactly? NetBSD-1.5X/i386 Remeber me? :) What changes are needed to make the code work there, and how might we #ifdef or autoconfigure a test for it? I need to look at it some more for that.. Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS]
On Thu, Jul 26, 2001 at 04:55:14PM +0700, Zudi Iswanto wrote: I am developing application with c++ ... /tmp/ccy63XDd.o(.text+0x70): undefined reference to `PQsetdbLogin' /tmp/ccy63XDd.o(.text+0x91): undefined reference to `PQstatus' /tmp/ccy63XDd.o(.text+0xc4): undefined reference to `PQerrorMessage' Did you link libpq as well as libpq++ ? ie something like -L/usr/local/lib/pgsql -Wl,-R/usr/local/lib/pgsql -lpq++ -lpq Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] iconv?
On Thu, Jul 12, 2001 at 12:04:25PM +0900, Tatsuo Ishii wrote: Has it ever been considered to (optionally) use the iconv interface for character set conversion instead of rolling our own? It seems to be a lot more flexible, has pluggable conversion modules (depending on the implementation), supports more character sets. It seems to be available on quite a few systems, too. I have not checked iconv seriously since it's not very portable among our supported platforms. Just FYI, in the mutt readme: - Mutt needs an implementation of the iconv API for character set conversions. A free one can be found under the following URL: http://clisp.cons.org/~haible/packages-libiconv.html Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] shared library strangeness?
I just upgraded PostgreSQL from 21 March CVS (rc1?) to May 19 16:21 GMT CVS. I found that all my cgi/fcg scripts which use libpq++ stopped working in the vague sense of apache mentioning an internal server error. Relinking them cured the problem (had to do this in haste = unfortunately no more information) -rwxr-xr-x 1 postgres postgres 154795 Mar 21 21:28 libpq++.so.3.1 -rwxr-xr-x 1 postgres postgres 155212 May 21 14:48 libpq++.so.3.2 is the change. The programs using libpq only (not lipq++ as well) worked as before. I am sorry, I don't have an error message to say how it is broken, but I do have a slight feeling that maybe the major shared library number could have been bumped up... Ah... A clue! Undefined PLT symbol ConnectionBad__12PgConnection (reloc type = 7, symnum = 132) quartz% nm -g libpq++.so.3.1 | grep ConnectionBad 25e8 T ConnectionBad__12PgConnection quartz% !:s/1/2/ nm -g libpq++.so.3.2 | grep ConnectionBad 24fc T ConnectionBad__C12PgConnection RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/libpq++/pgconnection.h,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- pgconnection.h 2001/02/10 02:31:30 1.10 +++ pgconnection.h 2001/05/09 17:29:10 1.11 - int ConnectionBad(); ... + bool ConnectionBad() const; So I would suggest that the major number be bumped, leaving a small window since 9 May with a problem.. Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] cvs snapshot compile problems
On Sat, May 19, 2001 at 08:03:50PM -0400, bpalmer wrote: On OBSD from cvs source, clean checkout: gcc -O2 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -DLIBDIR=\/usr/local/pgsql/lib\ -DDLSUFFIX=\.so\ -c -o dfmgr.o dfmgr.c dfmgr.c: In function `load_external_function': dfmgr.c:118: `RTLD_GLOBAL' undeclared (first use in this function) dfmgr.c:118: (Each undeclared identifier is reported only once dfmgr.c:118: for each function it appears in.) gmake[4]: *** [dfmgr.o] Error 1 gmake[4]: Leaving directory `/home/bpalmer/APPS/pgsql/src/backend/utils/fmgr' ?? RTLD_GLOBAL problems? Not a solution, but a few data points: I had a successful build from cvs of May 19 16:21 GMT under NetBSD/i386, and for me RTLD_GLOBAL is defined in /usr/include/dlfcn.h ie., system header file, not postgresql. Hope that helps, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.2 items
On Sat, May 12, 2001 at 08:00:42PM -0400, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: * Translation: If we want to use gettext I can get started. I don't think I'm interested in using any other interface. I have no objection to the gettext API, but I was and still am concerned about depending on GNU gettext's code, because of license conflicts. There is a BSD-license gettext clone project, but it doesn't look to be very far along. What's missing with it? (eg managed to force gmake's configure to use it rather than its own, and didn't have to fiddle anything for it to just work) % ldd `which gmake` /usr/local/bin/gmake: -lutil.5 = /usr/lib/libutil.so.5 -lkvm.5 = /usr/lib/libkvm.so.5 -lintl.0 = /usr/lib/libintl.so.0 BSD license lib -lc.12 = /usr/lib/libc.so.12 % env LANGUAGE=fr gmake gmake: *** Pas de cibles spécifiées et aucun makefile n'a été trouvé. Arrêt. Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.2 items
On Mon, May 14, 2001 at 09:36:56PM +0200, Peter Eisentraut wrote: Patrick Welche writes: I have no objection to the gettext API, but I was and still am concerned about depending on GNU gettext's code, because of license conflicts. There is a BSD-license gettext clone project, but it doesn't look to be very far along. What's missing with it? * portability At first glance, uses strlcat and strlcpy. Didn't look further. As I said, I didn't change anything within the GNU make source to get it to work. grep strlcat on GNU make, which you must have in order to build postgresql, returns nothing, however grep gettext does. I chose gmake as an example which is probably written with portability in mind. * dedication to portability Only plans to support *BSD. What does this imply? HISTORY The functions are implemented by Citrus project, based on the documenta- tions for GNU gettext. * source code availability Didn't find anything outside NetBSD CVS and the CVS rep where they got it from. From libintl.h /*- * Copyright (c) 2000 Citrus Project, * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ which I think counts as a postgresql compatible license? Is that what you meant? * documentation Related to above. The HISTORY bit was quoted from the gettext man page.. What more documentation is required? AFAIK it's meant to be a direct replacement.. * English support forum Only Japanese mailing list available. Yes, I wondered about that to.. Luckily PostgreSQL is international! Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Call for platforms
On Mon, Apr 09, 2001 at 11:41:55AM -0700, Henry B. Hotz wrote: At 1:50 AM -0400 4/6/01, Tom Lane wrote: ... What version of libreadline do you have installed, and how does it declare completion_matches()? I have whatever is standard on NetBSD 1.5. I noticed that configure found a readline.h include file, but NetBSD doesn't integrate the current GNU implementation. I did not do a test of psql to see if the feature worked. I'm sure you could "fix" this problem if you installed GNU readline and referenced it in the build. Since Solaris had even worse issues with needing GNU support utilities installed this didn't seem like a big deal to me. OTOH it could confuse a new user. Odd: I am using the standard NetBSD readline found in -ledit and it is fine.. Can it be a -1.5 vs -current difference? I have just stumbled across something which is broken though: NetBSD-1.5S/arm32: % ldd `which psql` /usr/local/pgsql/bin/psql: -lpq.2 = /usr/local/pgsql/lib/libpq.so.2.1 (0x2003b000) -lz.0 = /usr/lib/libz.so.0.2 (0x20048000) -lcrypt.0 = /usr/lib/libcrypt.so.0.0 (0x20056000) -lresolv.1 = /usr/lib/libresolv.so.1.0 (0x2005c000) -lm.0 = /usr/lib/libm.so.0.1 (0x20065000) -lutil.5 = /usr/lib/libutil.so.5.5 (0x2008b000) -ledit.2 = /usr/lib/libedit.so.2.5 (0x20096000) -lc.12 = /usr/lib/libc.so.12.74 (0x200ae000) NetBSD-1.5U/i386: % ldd `which psql` /usr/local/pgsql/bin/psql: -lcrypt.0 = /usr/lib/libcrypt.so.0 -lresolv.1 = /usr/lib/libresolv.so.1 -lpq.2 = /usr/local/pgsql/lib/libpq.so.2 -lz.0 = /usr/lib/libz.so.0 -lm.0 = /usr/lib/libm387.so.0 -lm.0 = /usr/lib/libm.so.0 -lutil.5 = /usr/lib/libutil.so.5 -ledit.2 = /usr/lib/libedit.so.2 -ltermcap.0 = /usr/lib/libtermcap.so.0 -lc.12 = /usr/lib/libc.so.12 -ltermcap is missing from arm32 - it's necessary if libedit is going to find _tgetent.. Investigating now.. Cheers, Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: Call for platforms
On Fri, Apr 13, 2001 at 01:25:45PM +, Thomas Lockhart wrote: Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's patch should be applied? I'm unclear on what y'all mean by "i386 + fpu", especially since NetBSD seems to insist on calling every Intel processor a "i386". History ;-) In this case, are you suggesting that this patch covers all NetBSD installations on every Intel processor from i386 + fpu forward to i486, i586, etc etc? Yes! It's simply, if the peecee type thing has a fpu (as in the sysctl machdep.fpu_present returns 1), then libm387.so is used, and you get differences in the (from memory 44th insignificant figure?) otherwise it just uses libm.so and you get what is currently correct in resultmap. Cheers, Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for platforms
Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's patch should be applied? Cheers, Patrick (just checked, it isn't in today's cvs) On Thu, Mar 22, 2001 at 10:27:44PM +0200, Marko Kreen wrote: On Thu, Mar 22, 2001 at 07:58:04PM +0000, Patrick Welche wrote: On Fri, Mar 23, 2001 at 06:25:50AM +1100, Giles Lean wrote: PS: AFAIK geometry-positive-zeros-bsd works for all NetBSD platforms - the above difference is only for i386 + fpu. It doesn't on NetBSD-1.5/alpha -- there geometry-positive-zeros is correct. Sorry, that should have read: AFAIK geometry-positive-zeros works for all NetBSD platforms - the above difference is only for i386 + fpu. Seems that following patch is needed. Now It Works For Me (tm). Giles, does the regress test now succed for you? -- marko Index: src/test/regress/resultmap === RCS file: /home/projects/pgsql/cvsroot/pgsql/src/test/regress/resultmap,v retrieving revision 1.45 diff -u -r1.45 resultmap --- src/test/regress/resultmap2001/03/22 15:13:18 1.45 +++ src/test/regress/resultmap2001/03/22 17:29:49 @@ -17,6 +17,7 @@ geometry/.*-openbsd=geometry-positive-zeros-bsd geometry/.*-irix6=geometry-irix geometry/.*-netbsd=geometry-positive-zeros +geometry/i.86-.*-netbsdelf1.5=geometry-positive-zeros-bsd geometry/.*-sysv5uw7.*:cc=geometry-uw7-cc geometry/.*-sysv5uw7.*:gcc=geometry-uw7-gcc geometry/alpha.*-dec-osf=geometry-alpha-precision ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Call for platforms
On Thu, Mar 22, 2001 at 12:49:39PM -0500, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: These are parallel tests right? What's the failure diffs? same as last time: dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress more results/opr_sanity.out psql: connectDBStart() -- connect() failed: Connection refused Is the postmaster running locally and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'? See Peter's comment elsewhere that he doesn't think Solaris handles Unix socket connections very well. Try patching pg_regress to force unix_sockets=no. and yet another run (and different results): = 1 of 76 tests failed, 1 failed test(s) ignored. = That's just ye olde random "random" failure ... Funny, I get the more optimistic: == 75 of 76 tests passed, 1 failed test(s) ignored. == Different version? PostgreSQL 7.1RC1 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Call for platforms
On Thu, Mar 22, 2001 at 10:27:44PM +0200, Marko Kreen wrote: On Thu, Mar 22, 2001 at 07:58:04PM +, Patrick Welche wrote: AFAIK geometry-positive-zeros works for all NetBSD platforms - the above difference is only for i386 + fpu. Seems that following patch is needed. Now It Works For Me (tm). Giles, does the regress test now succed for you? Your patch works for me (i386) - I'd just like to point out that it's because we are both running on peecees with fpus and thus with libm387 loaded (else works without patch) BTW NetBSD 2.8 alpha 7.1 2001-03-22, Giles Lean Shouldn't that be 1.5? Cheers, Patrick ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Call for platforms
On Fri, Mar 23, 2001 at 06:25:50AM +1100, Giles Lean wrote: PS: AFAIK geometry-positive-zeros-bsd works for all NetBSD platforms - the above difference is only for i386 + fpu. It doesn't on NetBSD-1.5/alpha -- there geometry-positive-zeros is correct. Sorry, that should have read: AFAIK geometry-positive-zeros works for all NetBSD platforms - the above difference is only for i386 + fpu. (-bsd is for bsdi) Thanks for the correction, Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Performance monitor signal handler
On Fri, Mar 16, 2001 at 05:25:24PM -0500, Jan Wieck wrote: Jan Wieck wrote: ... Just to get some evidence at hand - could some owners of different platforms compile and run the attached little C source please? ... Seems Tom is (unfortunately) right. The pipe blocks at 4K. On NetBSD-1.5S/i386 with just the highly conservative shmem defaults: Pipe buffer is 4096 bytes Sys-V message queue buffer is 2048 bytes Cheers, Patrick ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
