Re: [HACKERS] Erratic failures on buildfarm member leveret

2006-09-05 Thread Stefan Kaltenbrunner
Tom Lane wrote:
 Hey Stefan, could you run some hardware diagnostics on leveret?
 It's been returning increasingly erratic results over the past few days.

yeah sorry for that - leveret startet to behave weird after the latest
update/reboot. Some of the weird errors can be explained by SElinux not
getting along with icc - but i thought I had fixed that a while ago...
I have disabled the cronjobs on leveret for now until i get more time to
investigate whats going on


Stefan

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


[HACKERS] ECPG regression failures on OpenBSD

2006-09-05 Thread Stefan Kaltenbrunner
After upgrading some of my buildfarm members to the latest version of
the buildfarm script both OpenBSD boxes startet to fail the ECPG
regression tests:

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=emudt=2006-09-05%2002:35:02

and

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbilldt=2006-09-04%2023:50:05



Stefan

---(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] Fix linking of OpenLDAP libraries

2006-09-05 Thread Albe Laurenz
Tom Lane wrote on September 04, 2006:
 Albe Laurenz [EMAIL PROTECTED] writes:
 
   # The backend doesn't need everything that's in LIBS, however
 ! LIBS := $(filter-out -lz -lreadline -ledit -ltermcap -lncurses
-lcurses -lldap_r $(PTHREAD_LIBS), $(LIBS))
 
 This seems pretty risky.  What if PTHREAD_LIBS contains -L switches?
 They'd get removed even if needed for other libraries.
 
 It would probably be safer not to put LDAP into LIBS at all, but
invent
 two new macros for configure to set, say LDAP_LIBS and LDAP_LIBS_R,
 and add these to the link lines in the backend and libpq respectively.

That seems like a good idea.
I'll try to work it out and resubmit the fix.

Yours,
Laurenz Albe

---(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] ECPG regression failures on OpenBSD

2006-09-05 Thread Michael Meskes
On Tue, Sep 05, 2006 at 08:00:12AM +0200, Stefan Kaltenbrunner wrote:
 After upgrading some of my buildfarm members to the latest version of
 the buildfarm script both OpenBSD boxes startet to fail the ECPG
 regression tests:
 ...

complex/test2 gets a segmentation fault on both machines. Could you try
running it under gdb to see where it segfaults? I will try to get a hand
on an OpenBSD machine myself, too

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] ECPG regression failures on OpenBSD

2006-09-05 Thread Stefan Kaltenbrunner

Michael Meskes wrote:

On Tue, Sep 05, 2006 at 08:00:12AM +0200, Stefan Kaltenbrunner wrote:

After upgrading some of my buildfarm members to the latest version of
the buildfarm script both OpenBSD boxes startet to fail the ECPG
regression tests:
...


complex/test2 gets a segmentation fault on both machines. Could you try
running it under gdb to see where it segfaults? I will try to get a hand
on an OpenBSD machine myself, too


will try to get a backtrace soon - if you are trying to do your own 
testing keep in mind that both boxes of mine do run with special 
malloc-settings (as in FGJZ) as discussed in:


http://archives.postgresql.org/pgsql-hackers/2005-06/msg00817.php

while I'm not sure yet that those are causing the errors to show up it 
seems quite likely since they tend to catch hidden memory allocation errors.



Stefan

---(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] [DOCS] New XML section for documentation

2006-09-05 Thread Nikolay Samokhvalov

On 8/26/06, Peter Eisentraut [EMAIL PROTECTED] wrote:

Bruce Momjian wrote:
 I made it clear in the section that the XML syntax was being checked,
 not validation against a schema.  You want Check and Validation
 sections?

Valid and well-formed have very specific distinct meanings in XML.
(Note that check doesn't have any meaning there.)  We will eventually
want a method to verify both the validity and the well-formedness.

I think that a function called xml_valid checks for well-formedness is
an outright bug and needs to be fixed.


That's exactly what I'm talking about. xml_valid() is wrong name and
it may confuse people.
I what to add that, with XML section in the documentation, this bug
becomes more significant.

Bruce suggested to use overload to keep backward compat. - in other
words, 1-arg function for checking for well-formedness and 2-arg
function for validation process. That's bad too:
- two _different_ actions for one function = another confusion
 - I (as a user) would think that 1-arg function is designed for
validation process for cases when XML document contains a reference to
DTD (as an example).

I stand for fixing it via renaming, breaking backward compatibility.
Later it will be more painful.

BTW, what is the deadline for changes (additions) in docs? I would add
general XML terms (such as what is XML, what is well-formed document,
what is validation; short overview of XML standards and SQL/XML as a
part of SQL:200n, etc Maybe about contrib/xml2 installation process -
actually, XSLT support requires additional lib). Moreover, if SQL/XML
patch will be accepted it will require several words too.
--
Best regards,
Nikolay

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org


[HACKERS] large object regression tests

2006-09-05 Thread Jeremy Drake
Sorry if this gets through more than once, I seem to be having email
difficulties...

On Tue, 5 Sep 2006, Jeremy Drake wrote:

 I noticed when I was working on a patch quite a while back that there are
 no regression tests for large object support.  I know, large objects
 are not the most sexy part of the code-base, and I think they tend to be
 ignored/forgotten most of the time.  Which IMHO is all the more reason
 they should have some regression tests.  Otherwise, if someone managed to
 break them somehow, it is quite likely not to be noticed for quite some
 time.

 So in this vein, I have recently found myself with some free time, and a
 desire to contribute something, and decided this would be the perfect
 place to get my feet wet without stepping on any toes.

 I guess what I should ask is, would a patch to add a test for large
 objects to the regression suite be well received?  And, is there any
 advice for how to go about making these tests?

 I am considering, and I think that in order to get a real test of the
 large objects, I would need to load data into a large object which would
 be sufficient to be loaded into more than one block (large object blocks
 were 1 or 2K IIRC) so that the block boundary case could be tested.  Is
 there any precedent on where to grab such a large chunk of data from?  I
 was thinking about using an excerpt from a public domain text such as Moby
 Dick, but on second thought binary data may be better to test things with.

 My current efforts, and probably the preliminary portion of the final
 test, involves loading a small amount (less than one block) of text into a
 large object inline from a sql script and calling the various functions
 against it to verify that they do what they should.  In the course of
 doing so, I find that it is necessary to stash certain values across
 statements (large object ids, large object 'handles'), and so far I am
 using a temporary table to store these.  Is this reasonable, or is there a
 cleaner way to do that?



-- 
Never make anything simple and efficient when a way can be found to
make it complex and wonderful.

---(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] pgcrypto deprecated functions?

2006-09-05 Thread Marko Kreen

On 8/30/06, Bruce Momjian [EMAIL PROTECTED] wrote:

Michael Fuhr wrote:
 In README.pgcrypto, Section 2.3 Deprecated functions says that
 digest_exists(), hmac_exists(), and cipher_exists() are planned to
 be removed in PostgreSQL 8.2.  Those functions still exist -- should
 they be removed or does that section need updating?

Marko, any comment on this pgcrypto item?


Heh, I had it forgotten.  Lets do it.  Although there's no hurry with it,
delaying just will annoy more users.

Also, update my email address.

--
marko
Index: contrib/pgcrypto/README.pgcrypto
===
RCS file: /opt/cvs/pgsql/contrib/pgcrypto/README.pgcrypto,v
retrieving revision 1.17
diff -u -c -r1.17 README.pgcrypto
*** contrib/pgcrypto/README.pgcrypto	5 Aug 2006 00:29:11 -	1.17
--- contrib/pgcrypto/README.pgcrypto	5 Sep 2006 08:29:58 -
***
*** 1,6 
  pgcrypto - cryptographic functions for PostgreSQL
  =
! Marko Kreen marko@l-t.ee
  
  // Note: this document is in asciidoc format.
  
--- 1,6 
  pgcrypto - cryptographic functions for PostgreSQL
  =
! Marko Kreen [EMAIL PROTECTED]
  
  // Note: this document is in asciidoc format.
  
***
*** 79,92 
  are NULL.  This may create security risks on careless usage.
  
  
! 2.3.  Deprecated functions
! ~~~
! 
! The `digest_exists()`, `hmac_exists()` and `cipher_exists()` functions
! are deprecated.  The plan is to remove them in PostgreSQL 8.2.
! 
! 
! 2.4.  Security
  ~~~
  
  All the functions here run inside database server.  That means that all
--- 79,85 
  are NULL.  This may create security risks on careless usage.
  
  
! 2.3.  Security
  ~~~
  
  All the functions here run inside database server.  That means that all
Index: contrib/pgcrypto/pgcrypto.c
===
RCS file: /opt/cvs/pgsql/contrib/pgcrypto/pgcrypto.c,v
retrieving revision 1.22
diff -u -c -r1.22 pgcrypto.c
*** contrib/pgcrypto/pgcrypto.c	13 Jul 2006 04:15:25 -	1.22
--- contrib/pgcrypto/pgcrypto.c	5 Sep 2006 08:28:23 -
***
*** 87,118 
  	PG_RETURN_BYTEA_P(res);
  }
  
- /* check if given hash exists */
- PG_FUNCTION_INFO_V1(pg_digest_exists);
- 
- Datum
- pg_digest_exists(PG_FUNCTION_ARGS)
- {
- 	text	   *name;
- 	PX_MD	   *res;
- 
- 	if (PG_ARGISNULL(0))
- 		PG_RETURN_NULL();
- 
- 	name = PG_GETARG_TEXT_P(0);
- 
- 	res = find_provider(name, (PFN) px_find_digest, Digest, 1);
- 
- 	PG_FREE_IF_COPY(name, 0);
- 
- 	if (res == NULL)
- 		PG_RETURN_BOOL(false);
- 
- 	res-free(res);
- 
- 	PG_RETURN_BOOL(true);
- }
- 
  /* SQL function: hmac(data:bytea, key:bytea, type:text) returns bytea */
  PG_FUNCTION_INFO_V1(pg_hmac);
  
--- 87,92 
***
*** 158,189 
  	PG_RETURN_BYTEA_P(res);
  }
  
- /* check if given hmac type exists */
- PG_FUNCTION_INFO_V1(pg_hmac_exists);
- 
- Datum
- pg_hmac_exists(PG_FUNCTION_ARGS)
- {
- 	text	   *name;
- 	PX_HMAC*h;
- 
- 	if (PG_ARGISNULL(0))
- 		PG_RETURN_NULL();
- 
- 	name = PG_GETARG_TEXT_P(0);
- 
- 	h = find_provider(name, (PFN) px_find_hmac, HMAC, 1);
- 
- 	PG_FREE_IF_COPY(name, 0);
- 
- 	if (h != NULL)
- 	{
- 		px_hmac_free(h);
- 		PG_RETURN_BOOL(true);
- 	}
- 	PG_RETURN_BOOL(false);
- }
- 
  
  /* SQL function: pg_gen_salt(text) returns text */
  PG_FUNCTION_INFO_V1(pg_gen_salt);
--- 132,137 
***
*** 565,591 
  	PG_RETURN_BYTEA_P(res);
  }
  
- /* SQL function: pg_cipher_exists(text) returns bool */
- PG_FUNCTION_INFO_V1(pg_cipher_exists);
- 
- Datum
- pg_cipher_exists(PG_FUNCTION_ARGS)
- {
- 	text	   *arg;
- 	PX_Combo   *c;
- 
- 	if (PG_ARGISNULL(0))
- 		PG_RETURN_NULL();
- 
- 	arg = PG_GETARG_TEXT_P(0);
- 
- 	c = find_provider(arg, (PFN) px_find_combo, Cipher, 1);
- 	if (c != NULL)
- 		px_combo_free(c);
- 
- 	PG_RETURN_BOOL((c != NULL) ? true : false);
- }
- 
  static void *
  find_provider(text *name,
  			  PFN provider_lookup,
--- 513,518 
Index: contrib/pgcrypto/pgcrypto.h
===
RCS file: /opt/cvs/pgsql/contrib/pgcrypto/pgcrypto.h,v
retrieving revision 1.10
diff -u -c -r1.10 pgcrypto.h
*** contrib/pgcrypto/pgcrypto.h	13 Jul 2006 04:15:25 -	1.10
--- contrib/pgcrypto/pgcrypto.h	5 Sep 2006 08:27:28 -
***
*** 36,44 
  
  /* exported functions */
  Datum		pg_digest(PG_FUNCTION_ARGS);
- Datum		pg_digest_exists(PG_FUNCTION_ARGS);
  Datum		pg_hmac(PG_FUNCTION_ARGS);
- Datum		pg_hmac_exists(PG_FUNCTION_ARGS);
  Datum		pg_gen_salt(PG_FUNCTION_ARGS);
  Datum		pg_gen_salt_rounds(PG_FUNCTION_ARGS);
  Datum		pg_crypt(PG_FUNCTION_ARGS);
--- 36,42 
***
*** 46,52 
  Datum		pg_decrypt(PG_FUNCTION_ARGS);
  Datum		pg_encrypt_iv(PG_FUNCTION_ARGS);
  Datum		pg_decrypt_iv(PG_FUNCTION_ARGS);
- Datum		pg_cipher_exists(PG_FUNCTION_ARGS);
  

[HACKERS] TODO item: GUID

2006-09-05 Thread Gevik Babakhani
I have two questions regarding the GUID todo item...

1. Do we want to have a new datatype for that or just a macro like the
SERIAL type? 

create table bla
( 
  my_pk GUID  /* that is my_pk varchar(32) DEFAULT 'new_guid()' */
)

2. Didn't we have a contrib module doing the GUID?

Regards,
Gevik.




---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] ECPG regression failures on OpenBSD

2006-09-05 Thread Chris Mair

  After upgrading some of my buildfarm members to the latest version of
  the buildfarm script both OpenBSD boxes startet to fail the ECPG
  regression tests:
  ...
  
  complex/test2 gets a segmentation fault on both machines. Could you try
  running it under gdb to see where it segfaults? I will try to get a hand
  on an OpenBSD machine myself, too
 
 will try to get a backtrace soon - if you are trying to do your own 
 testing keep in mind that both boxes of mine do run with special 
 malloc-settings (as in FGJZ) as discussed in:
 
 http://archives.postgresql.org/pgsql-hackers/2005-06/msg00817.php
 
 while I'm not sure yet that those are causing the errors to show up it 
 seems quite likely since they tend to catch hidden memory allocation errors.

Hi,

I've just upgraded guppy, the only other OpenBSD machine that builds
head to the latest buildfarm version.

I don't have any special malloc settings. When guppy finishes, we will
see what happens.

Bye, Chris.


-- 

Chris Mair
http://www.1006.org


---(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] ECPG regression failures on OpenBSD

2006-09-05 Thread Michael Meskes
On Tue, Sep 05, 2006 at 11:58:41AM +0200, Stefan Kaltenbrunner wrote:
 #0  0x0add8c83 in replace_variables (text=0x7e709780 select name, born, 
 age, married, children from meskes where name = ?) at prepare.c:42
 ptr = 0x7e70a000 Address 0x7e70a000 out of bounds
 string = 0 '\0'

I think I found this one. Will commit as soon as I finished my tests and
the parser update.

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

---(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] ECPG regression failures on OpenBSD

2006-09-05 Thread Michael Meskes
On Tue, Sep 05, 2006 at 08:00:12AM +0200, Stefan Kaltenbrunner wrote:
 http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=emudt=2006-09-05%2002:35:02
 
 and
 
 http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbilldt=2006-09-04%2023:50:05

Hmm, for some reason the x86 machine doesn't give a
PGTYPES_NUM_UNDERFLOW error when it should. The Sparc correctly throws
that error as do Linux based x86 machines. 

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

---(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


[HACKERS] Question about 8-byte datatypes

2006-09-05 Thread Gregory Stark

Is int8 a passed-by-value data type on 64-bit platforms? How do we arrange for
that to be the case? I don't see any magic in pg_type.h but I'm not sure what
I'm looking for.

I'm asking because I have another 8-byte data type I want to use and it would
be nice to have that same property, assuming we have it for int8.


-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] ECPG regression failures on OpenBSD

2006-09-05 Thread Michael Meskes
On Tue, Sep 05, 2006 at 01:08:48PM +0200, Stefan Kaltenbrunner wrote:
 FYI: complex/test2 fails on lionfish (my linux/mipsel box) too:
 
 http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lionfishdt=2006-09-05%2005:30:07

This needs some debugging. The output difference comes from an indicator
not correctly set/evaluated. To get more infos I need to get access to
such a machine. 

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] TODO item: GUID

2006-09-05 Thread Martijn van Oosterhout
On Tue, Sep 05, 2006 at 11:29:40AM +0200, Gevik Babakhani wrote:
 I have two questions regarding the GUID todo item...
 
 1. Do we want to have a new datatype for that or just a macro like the
 SERIAL type? 

A new datatype. Just because someone has a guid column doesn't mean
they want it autogenerated. Provide a generation function (not
absolutly necessary) and you're done.

Have a nice day,
-- 
Martijn van Oosterhout   kleptog@svana.org   http://svana.org/kleptog/
 From each according to his ability. To each according to his ability to 
 litigate.


signature.asc
Description: Digital signature


Re: [HACKERS] Question about 8-byte datatypes

2006-09-05 Thread Martijn van Oosterhout
On Tue, Sep 05, 2006 at 11:16:06AM +0100, Gregory Stark wrote:
 
 Is int8 a passed-by-value data type on 64-bit platforms? How do we arrange for
 that to be the case? I don't see any magic in pg_type.h but I'm not sure what
 I'm looking for.

Not AFAIK. It would involve fiddeling the catalog, tricky since the
catalog genration script doesn't understand #ifdef's. Also you would
have to add conditionals for the the PG_RETURN_* and PG_GET* macros.

 I'm asking because I have another 8-byte data type I want to use and it would
 be nice to have that same property, assuming we have it for int8.

Yes that'd be nice, but not entirely straightforward.

Have a nice day,
-- 
Martijn van Oosterhout   kleptog@svana.org   http://svana.org/kleptog/
 From each according to his ability. To each according to his ability to 
 litigate.


signature.asc
Description: Digital signature


Re: [HACKERS] ECPG regression failures on OpenBSD

2006-09-05 Thread Stefan Kaltenbrunner

Michael Meskes wrote:

On Tue, Sep 05, 2006 at 01:08:48PM +0200, Stefan Kaltenbrunner wrote:

FYI: complex/test2 fails on lionfish (my linux/mipsel box) too:

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lionfishdt=2006-09-05%2005:30:07


This needs some debugging. The output difference comes from an indicator
not correctly set/evaluated. To get more infos I need to get access to
such a machine. 


hmm I might be able to arrange access to lionfish - but that box is slow 
(it needs between 5 and 6 hours to finish a buildfarm run).



Stefan

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org


Re: [HACKERS] ECPG regression failures on OpenBSD

2006-09-05 Thread Chris Mair
 
  will try to get a backtrace soon - if you are trying to do your own 
  testing keep in mind that both boxes of mine do run with special 
  malloc-settings (as in FGJZ) as discussed in:
  
  http://archives.postgresql.org/pgsql-hackers/2005-06/msg00817.php
  
  while I'm not sure yet that those are causing the errors to show up it 
  seems quite likely since they tend to catch hidden memory allocation errors.
 
 Hi,
 
 I've just upgraded guppy, the only other OpenBSD machine that builds
 head to the latest buildfarm version.
 
 I don't have any special malloc settings. When guppy finishes, we will
 see what happens.

Hi,

after a spurious run due to a config mistake after upgrading (sorry),
guppy just now completed a new run and also failed on make ecpg check:

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=guppydt=2006-09-05%
2010:02:05

Michael, if you want shell access to guppy, just contact me privately.
Warning: guppy too, is somewhat dated (1:10 hours for the make step) :/

Bye, Chris.



-- 

Chris Mair
http://www.1006.org


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] Open items for 8.2

2006-09-05 Thread Alvaro Herrera
Tom Lane wrote:
 Alvaro Herrera [EMAIL PROTECTED] writes:
  A quickie: this item
  Store only active XIDs in subtransaction cache
  was already done:
 
 I think Bruce is referring to the idea that you and I each arrived at
 recently, ie removing subcommitted subxact XIDs from the PGPROC cache
 if they hadn't stored any tuples.  That certainly wasn't done by my
 commit you mention ... did you do it when I wasn't looking?

Ah, true -- no, I didn't do it, sorry :-)

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


[HACKERS] Dead code?

2006-09-05 Thread Gregory Stark



Is there anywhere we make use of this code that handles attlen == -2?

If so I'm curious where because I was thinking of doing something similar and
didn't realise we already had this capability. But I suspect it's just dead
code left over, possibly from the days before the Name data type?


/*
 * att_addlength increments the given offset by the length of the attribute.
 * attval is only accessed if we are dealing with a variable-length attribute.
 */
#define att_addlength(cur_offset, attlen, attval) \
( \
((attlen)  0) ? \
( \
(cur_offset) + (attlen) \
) \
: (((attlen) == -1) ? \
( \
(cur_offset) + VARATT_SIZE(DatumGetPointer(attval)) \
) \
: \
( \
AssertMacro((attlen) == -2), \
(cur_offset) + (strlen(DatumGetCString(attval)) + 1) \
)) \
)


-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] TODO item: GUID

2006-09-05 Thread Gevik Babakhani
For developing the GUID datatype, I was wondering if I could use the
sample code from http://www.ietf.org/rfc/rfc4122.txt (hate to reinvent
the wheel)

The code has a copyright which says: use and modify as you wish but
include the copyright notice with your code

What are our rules is such matters?

Regards,
Gevik.



---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] Dead code?

2006-09-05 Thread Gregory Stark
Martijn van Oosterhout kleptog@svana.org writes:

 attlen -2 is used for cstring (null terminated strings).

 Hope this helps,

Well that's what the code I quoted indicates. But when do we ever store a
cstring in a tuple? Certainly I can't find any standard data types that use
it.

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com

---(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] Dead code?

2006-09-05 Thread Martijn van Oosterhout
On Tue, Sep 05, 2006 at 01:21:46PM +0100, Gregory Stark wrote:
 
 
 
 Is there anywhere we make use of this code that handles attlen == -2?
 
 If so I'm curious where because I was thinking of doing something similar and
 didn't realise we already had this capability. But I suspect it's just dead
 code left over, possibly from the days before the Name data type?

attlen -2 is used for cstring (null terminated strings).

Hope this helps,
-- 
Martijn van Oosterhout   kleptog@svana.org   http://svana.org/kleptog/
 From each according to his ability. To each according to his ability to 
 litigate.


signature.asc
Description: Digital signature


Re: [HACKERS] Dead code?

2006-09-05 Thread Martijn van Oosterhout
On Tue, Sep 05, 2006 at 01:42:57PM +0100, Gregory Stark wrote:
 Martijn van Oosterhout kleptog@svana.org writes:
 
  attlen -2 is used for cstring (null terminated strings).
 
  Hope this helps,
 
 Well that's what the code I quoted indicates. But when do we ever store a
 cstring in a tuple? Certainly I can't find any standard data types that use
 it.

# select textout('text');
 textout 
-
 text
(1 row)

The output is cstring, and stored in a tuple to send...

Hope this helps,
-- 
Martijn van Oosterhout   kleptog@svana.org   http://svana.org/kleptog/
 From each according to his ability. To each according to his ability to 
 litigate.


signature.asc
Description: Digital signature


Re: [HACKERS] TODO item: GUID

2006-09-05 Thread Martijn van Oosterhout
On Tue, Sep 05, 2006 at 02:29:15PM +0200, Gevik Babakhani wrote:
 For developing the GUID datatype, I was wondering if I could use the
 sample code from http://www.ietf.org/rfc/rfc4122.txt (hate to reinvent
 the wheel)
 
 The code has a copyright which says: use and modify as you wish but
 include the copyright notice with your code

Do you really want to copy the code verbatim? I mean, there's a lot of
stuff which would need quite a bit of massaging to get working in
postgres. I'd say just look at it, understand it, and then write
something that will work. The copyright won't matter then.

BTW, I seem to remember something about the stuff in the RFC not being
good for some reason, not unique enough or too predictable. Do you know
anything about that?

Have a nice day,
-- 
Martijn van Oosterhout   kleptog@svana.org   http://svana.org/kleptog/
 From each according to his ability. To each according to his ability to 
 litigate.


signature.asc
Description: Digital signature


Re: [HACKERS] TODO item: GUID

2006-09-05 Thread Gevik Babakhani

 Do you really want to copy the code verbatim? I mean, there's a lot of
 stuff which would need quite a bit of massaging to get working in
 postgres. I'd say just look at it, understand it, and then write
 something that will work. The copyright won't matter then.
 

This is a better idea i must say. I will take a closer look at the code
then see which parts I can reuse. 

 BTW, I seem to remember something about the stuff in the RFC not being
 good for some reason, not unique enough or too predictable. Do you know
 anything about that?
 

It was a privacy issue regarding GUID generation introduced by MS. The
version 1 (V1) of the algorithm was created based on the MAC which was
somehow back-traceable to the computer it was generated on I guess.
Version 4 was based on a better algorithm.

 Have a nice day,


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


[HACKERS] Fixed length data types issue

2006-09-05 Thread Gregory Stark


So I'm thinking again about the problems with fixed length data types not
having typmod available when they would need it. But I'm having trouble
finding enough old posts to get a handle on exactly what the problem is.

This would make a nice test of the new wiki. I would be indebted to whoever
could summarize the root of the problem and explain exactly what circumstances
the typmod is unavailable. I would summarize the responses and put them up on
the wiki.

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] Ding-dong, contrib is dead ...

2006-09-05 Thread Tom Lane
Josh Berkus josh@agliodbs.com writes:
 Migrated to pgFoundry:
   adddepends (Greg)
 dbmirror (Steve Singer)
 dbase -- dbf2pg
 fulltextindex -- simplefti
 mac (LER) -- mac-manufacturer
 userlock (Merlin)

 Please also kill the following two contrib directories, because despite an 
 impassioned plea by Robert Treat, they appear to not have any users (at least 
 nobody responded to posts on PWN or -hackers)
 tips
 mSQL-interface

Checking my copy of the hit list, I thought we'd agreed to migrate
contrib/oracle as well.

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] Ding-dong, contrib is dead ...

2006-09-05 Thread Tom Lane
Andrew - Supernews [EMAIL PROTECTED] writes:
 Userlock needs to go into core, not get removed; this was discussed in a
 previous let's clean up contrib/ thread.

Something like it ought to go into core, but personally I'd opt for
taking the opportunity to redesign the API, which was a bit crufty to
begin with.  That would eliminate all question of whether the clean room
was clean enough.

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] Ding-dong, contrib is dead ...

2006-09-05 Thread Abhijit Menon-Sen
At 2006-09-05 10:23:19 -0400, [EMAIL PROTECTED] wrote:

 Something like it ought to go into core, but personally I'd opt for
 taking the opportunity to redesign the API, which was a bit crufty to
 begin with.

I'm happy to do the work right away (not that there's much) if someone
suggests a better API. (I don't personally have a need for user-level
locks, and if I did, I'd be happy with just user_lock/user_unlock. So
if anyone has a more specific idea, I'm all ears.)

 That would eliminate all question of whether the clean room was
 clean enough.

It was really, really clean! Honest! :-)

-- ams

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] integration of pgcluster into postgresql

2006-09-05 Thread Andrew Sullivan
On Sun, Aug 27, 2006 at 12:47:12PM -0400, Tom Lane wrote:
 see some kind of joint proposal by multiple replication projects about
 what hooks to add.  Anybody out there want to organize such a thing?

We were attempting to define such a set of hooks as part of the
Slony-II work, but that sort of fell off the rails.  I am very
strongly in favour of such a framework, though, and would love to see
it.

I am willing to do the co-ordination and project management slog
work on this if those who need the hooks are willing to work on a set
of common definitions.  If anyone would like that, please let me
know.  If people want to contact me off-list, that's also fine; I'll
summarise.

A

-- 
Andrew Sullivan  | [EMAIL PROTECTED]
Everything that happens in the world happens at some place.
--Jane Jacobs 

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] Fixed length data types issue

2006-09-05 Thread Tom Lane
Gregory Stark [EMAIL PROTECTED] writes:
 So I'm thinking again about the problems with fixed length data types not
 having typmod available when they would need it. But I'm having trouble
 finding enough old posts to get a handle on exactly what the problem is.

The problem is it isn't available ;-)

AFAIR the only context where datatype-specific functions *do* get passed
typmod is in the invocation of a datatype input function or length
coercion function.  And in those contexts the semantics are really
convert the input to match this typmod, not this typmod describes
what you've been passed.

The basic rule here is that you have to be able to find out everything
you need to know about a given instance of a datatype just by looking at
the Datum.  If you try to rely on external data then you have the same
security problems that we had to redesign output functions to get rid
of: there's not sufficient guarantee that the external data actually
matches the datum.

regards, tom lane

---(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] Open items for 8.2

2006-09-05 Thread Andrew Dunstan

Bruce Momjian wrote:

Here are the open items for 8.2:

http://momjian.postgresql.org/cgi-bin/pgopenitems

This list will be continually updated until we release 8.2.

  


Emacs code example 	not submitted 	Gregory Stark [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]




This one is actually on my list, and will be done in a day or two. I 
have Greg's suggestion, which will be included.


cheers

andrew

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org


Re: [HACKERS] [PATCHES] Gen_fmgrtab.sh fails with LANG=et_EE

2006-09-05 Thread Tom Lane
Marko Kreen [EMAIL PROTECTED] writes:
 I grepped around source and did not find other instances of this.
 The A-Z experssion was only in perl scripts or in configure and
 configure should be fine as it explicitly resets locale.

Why not do the same in Gen_fmgrtab.sh?  A quick LANG=C seems less
invasive than this.

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] Ding-dong, contrib is dead ...

2006-09-05 Thread Andrew Dunstan

Tom Lane wrote:

Andrew - Supernews [EMAIL PROTECTED] writes:
  

Userlock needs to go into core, not get removed; this was discussed in a
previous let's clean up contrib/ thread.



Something like it ought to go into core, but personally I'd opt for
taking the opportunity to redesign the API, which was a bit crufty to
begin with.  That would eliminate all question of whether the clean room
was clean enough.


  


It seems odd to remove the module from contrib for 8.2 and then put a 
replacement in core for 8.3. I guess we could signal our intentions in 
the release notes.


It's a pity we didn't have Abhijit's patch 6 weeks ago.

cheers

andrew


---(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] TODO Request

2006-09-05 Thread Rocco Altier
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Hannu Krosing
 
 Ühel kenal päeval, T, 2006-08-29 kell 22:12, kirjutas Joshua D. Drake:
   Auto creations of partitions
  
  This would be something like:
  
  create table foo () partition by ...
 
 from the referenced MySQL manual entry
 
 CREATE TABLE members (
 ...
 joined DATE NOT NULL
 )
 PARTITION BY KEY(joined)
 PARTITIONS 6;
 
 Do you have any idea how this should work ?
 
 What date range should go into which partition ?
 
Since we don't have any knowledge about the date ranges in question, and the 
fact that they could change over time, I think the only stable way to handle 
this scenario would be to use a hash function which had 6 buckets (something 
like 'date % 6' could work).

I do see an issue, if someone wanted to change the number of partitions in use, 
since it would have to rehash the table, and move data around.

I don't see any other way to handle this, but I might not be thinking hard 
enough.

-rocco

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Ding-dong, contrib is dead ...

2006-09-05 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes:
 It's a pity we didn't have Abhijit's patch 6 weeks ago.

Well, now that we have it, the question is whether we want to do
anything with it.  One problem is it lacks documentation.

However, as I said, I'd really rather choose a new API altogether.  The
main thing that seems to be lacking is a way to wait for a lock, rather
than having only the equivalent of ConditionalLockAcquire.  Also I don't
much like exposing a LOCKMODE directly to user code --- to use
user_lock() or user_unlock() you have to put magic numbers into your SQL
code and hope nobody reassigns the C enum values in future releases.
I'd be inclined to just expose the notions of share and exclusive
lock and make these separate functions instead of magic numbers.

And then there's the question of what to expose in the way of lock
identifier options.  What we've got now is two int4's or an OID
which seems a bit random, not to mention that the key space overlaps
in an undocumented fashion.  Possibly we could offer OID, int8, or
two int4s, and modify the code to set locktag_field4 to distinguish
these cases so that the key spaces are independent.

I have no opinions about function names, except that I'd suggest
choosing names based around advisory lock instead of user lock.
Advisory locks are a standard concept and so that terminology
already tells people something ...

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Fixed length data types issue

2006-09-05 Thread Martijn van Oosterhout
On Tue, Sep 05, 2006 at 02:48:45PM +0100, Gregory Stark wrote:
 
 
 So I'm thinking again about the problems with fixed length data types not
 having typmod available when they would need it. But I'm having trouble
 finding enough old posts to get a handle on exactly what the problem is.

Like Tom said, the problem is you don't have it. In the specific case
of type input functions, what typmod is the output? For type output
functions relying on a passed typmod is a security risk.

So you end up storing the typmod in the Datum itself, which brings you
right back to varlena.

 This would make a nice test of the new wiki. I would be indebted to whoever
 could summarize the root of the problem and explain exactly what circumstances
 the typmod is unavailable. I would summarize the responses and put them up on
 the wiki.

Well, the root of the problem depends on your perspective. If the
purpose behind all of this is to save disk space, perhaps the root of
the problem is that disk representation and memory representation are
intimately tied?

Have a nice day,
-- 
Martijn van Oosterhout   kleptog@svana.org   http://svana.org/kleptog/
 From each according to his ability. To each according to his ability to 
 litigate.


signature.asc
Description: Digital signature


Re: [HACKERS] Where is hstore?

2006-09-05 Thread Tom Lane
Teodor Sigaev [EMAIL PROTECTED] writes:
 AFAIR the authors have never proposed it for inclusion.

 We'll be glad if hstore will be in main tarball. As I remember, when we 
 suggest 
 (may be, in private exchange of letters) to include it, somebody  says that 
 hstore breaks relational in db.

It seems there is no objection to adding hstore to contrib/.  Please
commit it this week if you can.

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module

2006-09-05 Thread Tom Lane
Jeremy Kronuz [EMAIL PROTECTED] writes:
 Hello again,This is an usable version of my EAN13/UPC/ISBN module.

I'm reviewing this for addition to contrib/ now.  I notice that there is
no clear license statement.  Is it OK to put the following into the
README file?


EAN13 - UPC - ISBN (books) - ISMN (music) - ISSN (serials)
--

Copyright Germán Méndez Bravo (Kronuz), 2004 - 2006
This module is released under the same BSD license as the rest of PostgreSQL.

The information to implement this module was collected through ...


regards, tom lane

---(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] Ding-dong, contrib is dead ...

2006-09-05 Thread Josh Berkus

Andrew,

It seems odd to remove the module from contrib for 8.2 and then put a 
replacement in core for 8.3. I guess we could signal our intentions in 
the release notes.


The current code is GPL.   It *has* to be removed.

--Josh

---(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] Ding-dong, contrib is dead ...

2006-09-05 Thread Josh Berkus

Tom,


Checking my copy of the hit list, I thought we'd agreed to migrate
contrib/oracle as well.


Hmmm ... somehow that got dropped out of discussions early on, without 
any reason why.  See the more nuclear options thread; oracle is 
nowhere on it.


Will only take me 30 min to migrate, but we need to give people time to 
object ... and I need to check whether there's even any code in there 
that superceded orasysviews and orafce and oralink.


Hey, everyone, if you have a reason for contrib/oracle not to migrate 
out to pgFoundry, speak up now!


Or if you want to take the new project over, speak up too.

--Josh Berkus

---(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] TODO Request

2006-09-05 Thread Alvaro Herrera
Rocco Altier wrote:
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Hannu Krosing
  
  Ühel kenal päeval, T, 2006-08-29 kell 22:12, kirjutas Joshua D. Drake:
Auto creations of partitions
   
   This would be something like:
   
   create table foo () partition by ...
  
  from the referenced MySQL manual entry
  
  CREATE TABLE members (
  ...
  joined DATE NOT NULL
  )
  PARTITION BY KEY(joined)
  PARTITIONS 6;
  
  Do you have any idea how this should work ?
  
  What date range should go into which partition ?

 Since we don't have any knowledge about the date ranges in question,
 and the fact that they could change over time, I think the only stable
 way to handle this scenario would be to use a hash function which had
 6 buckets (something like 'date % 6' could work).

IMHO we shouldn't be giving too many partitioning options until we solve
the important problems it brings with it, like FKs or unique constraints
not working across the hierarchy.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] Ding-dong, contrib is dead ...

2006-09-05 Thread Tom Lane
Josh Berkus josh@agliodbs.com writes:
 Checking my copy of the hit list, I thought we'd agreed to migrate
 contrib/oracle as well.

 Hmmm ... somehow that got dropped out of discussions early on, without 
 any reason why.

Actually ... never mind that, it seems to have been done already.
Sorry for the noise.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Ding-dong, contrib is dead ...

2006-09-05 Thread Merlin Moncure

On 9/5/06, Tom Lane [EMAIL PROTECTED] wrote:

Andrew Dunstan [EMAIL PROTECTED] writes:
 It's a pity we didn't have Abhijit's patch 6 weeks ago.

Well, now that we have it, the question is whether we want to do
anything with it.  One problem is it lacks documentation.


yes, userlocks have to be documented, in particular the dangers of
lock exhaustion.  also a tie-in to the recently upgraded pg_locks view
would be nice.


However, as I said, I'd really rather choose a new API altogether.  The
main thing that seems to be lacking is a way to wait for a lock, rather
than having only the equivalent of ConditionalLockAcquire.  Also I don't
much like exposing a LOCKMODE directly to user code --- to use
user_lock() or user_unlock() you have to put magic numbers into your SQL
code and hope nobody reassigns the C enum values in future releases.
I'd be inclined to just expose the notions of share and exclusive
lock and make these separate functions instead of magic numbers.


I agree 100%.


And then there's the question of what to expose in the way of lock
identifier options.  What we've got now is two int4's or an OID
which seems a bit random, not to mention that the key space overlaps
in an undocumented fashion.  Possibly we could offer OID, int8, or
two int4s, and modify the code to set locktag_field4 to distinguish
these cases so that the key spaces are independent.


right, this is some legacy cruft, in fact I raised this to your
attention which was perhaps part of the inspiration to upgrade
pg_locks.


I have no opinions about function names, except that I'd suggest
choosing names based around advisory lock instead of user lock.
Advisory locks are a standard concept and so that terminology
already tells people something ...


Agreement here also.

As to the point of userlocks being in core, they are in fact already
in core, and have been several years, the name 'userlock' having been
taken from the in source documentation.  The userlock contrib module
is nothing besides some wrappers for exisiting functions built into
the backend.  Removing userlock from contrib just removes a convenient
mechanism to use them.

I also agree with Andrew that pgfoundry is not a appropriate place for
userlocks.  They should be properly documented with a cleaned up api.
I have no objection from them being removed from contrib in the short
term due to the gpl issue, although I am not sure how you can
copyright a function wrapper.

merlin

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] Ding-dong, contrib is dead ...

2006-09-05 Thread Tom Lane
Merlin Moncure [EMAIL PROTECTED] writes:
 I also agree with Andrew that pgfoundry is not a appropriate place for
 userlocks.  They should be properly documented with a cleaned up api.
 I have no objection from them being removed from contrib in the short
 term due to the gpl issue, although I am not sure how you can
 copyright a function wrapper.

Right, I see the pgfoundry project as just a backwards-compatibility
thing for anyone who doesn't want to change their code.  I'm happy to
put some cleaned-up functions into core right now (ie, for 8.2) if
someone will do the legwork to define and implement them.

After further thought it occurs to me that having both OID and int8
keys might be a problem, in that it's not too clear which you'd get
from a single-argument call.  But we could offer just int8 and two-int4
signatures and rely on promoting OID to int8 if you need a lock on OID.

So the function list might look like

void pg_advisory_lock(int8) wait
void pg_advisory_lock_shared(int8)  wait
bool pg_try_advisory_lock(int8) no wait
bool pg_try_advisory_lock_shared(int8)  no wait
bool pg_advisory_unlock(int8)   returns T if successful
bool pg_advisory_unlock_shared(int8)returns T if successful

plus all the above taking 2 int4's, plus

void pg_advisory_unlock_all()

Not wedded to these names at all...

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] Ding-dong, contrib is dead ...

2006-09-05 Thread Andrew - Supernews
On 2006-09-05, Tom Lane [EMAIL PROTECTED] wrote:
 Andrew Dunstan [EMAIL PROTECTED] writes:
 It's a pity we didn't have Abhijit's patch 6 weeks ago.

 Well, now that we have it, the question is whether we want to do
 anything with it.  One problem is it lacks documentation.

 However, as I said, I'd really rather choose a new API altogether.

What about existing users?

 The main thing that seems to be lacking is a way to wait for a lock,

Is this a feature that people actually want or need?

Certainly exposing the lockmode as a magic number isn't ideal.

 And then there's the question of what to expose in the way of lock
 identifier options.  What we've got now is two int4's or an OID
 which seems a bit random, not to mention that the key space overlaps
 in an undocumented fashion.

It is documented in the original README.user_locks.

-- 
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Ding-dong, contrib is dead ...

2006-09-05 Thread Andrew - Supernews
On 2006-09-05, Josh Berkus josh@agliodbs.com wrote:
 The current code is GPL.   It *has* to be removed.

Which is why Abhijit's version exists - it's intended to be a drop-in,
BSD-licensed replacement for the current code.

-- 
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

---(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] Ding-dong, contrib is dead ...

2006-09-05 Thread Merlin Moncure

On 9/5/06, Andrew - Supernews [EMAIL PROTECTED] wrote:

On 2006-09-05, Josh Berkus josh@agliodbs.com wrote:
 The current code is GPL.   It *has* to be removed.

Which is why Abhijit's version exists - it's intended to be a drop-in,
BSD-licensed replacement for the current code.



does his patch include documentation? I can help with that if it isn't
done.  was it reviewed?

merlin

---(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] [COMMITTERS] pgsql: sslinfo contrib module - information about current SSL

2006-09-05 Thread Peter Eisentraut
Bruce Momjian wrote:
  Yes, it can be removed. I just wasn't aware that copyright transfer
  is neccessary. Most open-source projects don't have such a
  requirement, and individual portions of code are copyrighted by
  their respecitve authors.

This isn't a copyright transfer, but if you just write (C) me 
without anything else then you haven't given any license for anyone 
else to use it.  If we put a uniform copyright statement everywhere, 
then this gives reasonable assurance (as in: we got away with it so 
far) to everyone about the nature of the license and such.  Your name 
is still on record, so you are still the copyright holder under law.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] [COMMITTERS] pgsql: sslinfo contrib module - information about current SSL

2006-09-05 Thread Peter Eisentraut
Tom Lane wrote:
 Fixed --- I noticed it about the same time you did.  I'm surprised
 Peter didn't get a Makefile right the first time though ...

I'm surprised how crazy the contrib makefiles got while I wasn't 
looking. :)  I was glad to get something working at all.  The 
uniformity isn't that great at the moment and I'm unsure about the 
purpose of all that pgxs stuff there, but I think we've had that 
discussion and I'm not interested in reopening it.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Where is hstore?

2006-09-05 Thread Tom Lane
I'm seeing the following compiler warnings from hstore on x86_64:

hstore_io.c: In function 'get_val':
hstore_io.c:51: warning: format '%d' expects type 'int', but argument 4 has 
type 'long int'
hstore_io.c: In function 'parse_hstore':
hstore_io.c:150: warning: format '%d' expects type 'int', but argument 4 has 
type 'long int'
hstore_io.c:158: warning: format '%d' expects type 'int', but argument 4 has 
type 'long int'
hstore_io.c:181: warning: format '%d' expects type 'int', but argument 4 has 
type 'long int'

It passes its regression test anyway, but these need to be fixed.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] [PATCHES] Gen_fmgrtab.sh fails with LANG=et_EE

2006-09-05 Thread Peter Eisentraut
Tom Lane wrote:
 Marko Kreen [EMAIL PROTECTED] writes:
  I grepped around source and did not find other instances of this.
  The A-Z experssion was only in perl scripts or in configure and
  configure should be fine as it explicitly resets locale.

 Why not do the same in Gen_fmgrtab.sh?  A quick LANG=C seems less
 invasive than this.

Well, the line of code is

cpp_define=`echo $OIDSFILE | tr abcdefghijklmnopqrstuvwxyz 
ABCDEFGHIJKLMNOPQRSTUVWXYZ | sed -e 's/[^A-Z]/_/g'`

so it ought to be pretty obvious what the correct solution for the
problem character ranges are locale-dependent is.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] Ding-dong, contrib is dead ...

2006-09-05 Thread Josh Berkus
Merlin, 

   The current code is GPL.   It *has* to be removed.
 
  Which is why Abhijit's version exists - it's intended to be a drop-in,
  BSD-licensed replacement for the current code.

 does his patch include documentation? I can help with that if it isn't
 done.  was it reviewed?

No, and no.  It's unfortunately too late for Abhijit's patch to make it 
into 8.2; it was't submitted until last week, I believe.  

So userlocks will be in pgFoundry for the next rev -- frankly, it should 
have been for 8.1 but I forgot it.  For the 8.3 version, as Tom has 
indicated we may want to change the API somewhat anyway, so we'll want the 
pgFoundry version for backwards-compat.

-- 
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

---(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] Ding-dong, contrib is dead ...

2006-09-05 Thread Peter Eisentraut
Tom Lane wrote:
 Checking my copy of the hit list, I thought we'd agreed to migrate
 contrib/oracle as well.

It has already been removed because it is being actively maintained 
elsewhere.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] [PATCHES] Gen_fmgrtab.sh fails with LANG=et_EE

2006-09-05 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes:
 Well, the line of code is
 cpp_define=`echo $OIDSFILE | tr abcdefghijklmnopqrstuvwxyz 
 ABCDEFGHIJKLMNOPQRSTUVWXYZ | sed -e 's/[^A-Z]/_/g'`
 so it ought to be pretty obvious what the correct solution for the
 problem character ranges are locale-dependent is.

Doh.  Patched that way.

Curiously, I couldn't replicate the failure on Fedora 5 --- Marko's
platform must have different locale behavior for et_EE.

regards, tom lane

---(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] Ding-dong, contrib is dead ...

2006-09-05 Thread Merlin Moncure

On 9/5/06, Josh Berkus josh@agliodbs.com wrote:

So userlocks will be in pgFoundry for the next rev -- frankly, it should
have been for 8.1 but I forgot it.  For the 8.3 version, as Tom has
indicated we may want to change the API somewhat anyway, so we'll want the
pgFoundry version for backwards-compat.


well, I'm confused now.  Tom said that cleaned up functions might be
sneaked into 8.2, which is what prompted my question.  If that's the
case I'm considering putting something together quickly.  It's no big
deal to me either way really.  However, it would really be a shame to
drop the contrib module and leave 8.2 without a way of easily use them
(userlocks being, imho, the #1 greatest undiscovered feature in pg).

To be honest, I don't see the need for a backwards-compat version at
all, because all you need to do is copy and paste the code from 8.1.
If advisory functions are promoted in core (8.3 or no), sql wrappers
for compatibility would be trivial to implement.  These are one line
wrappers here.

merlin

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Ding-dong, contrib is dead ...

2006-09-05 Thread Josh Berkus
Merlin,

 well, I'm confused now.  Tom said that cleaned up functions might be
 sneaked into 8.2, which is what prompted my question. 

You're correct, he did.  Tom?

 If that's the 
 case I'm considering putting something together quickly.  It's no big
 deal to me either way really.  However, it would really be a shame to
 drop the contrib module and leave 8.2 without a way of easily use them
 (userlocks being, imho, the #1 greatest undiscovered feature in pg).

Well, all I'm dealing with is that the *existing GPL code* can't stay.   
Let me know if Abhijit's version (or something else) gets accepted and 
I'll kill the pgFoundry project.

Overall, though, I think we should really wait until 8.3 for core merge and 
API improvements.  Wasn't Tom just complaining about last-minute features, 
and not enough code reviewers?

-- 
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] Ding-dong, contrib is dead ...

2006-09-05 Thread Andrew - Supernews
On 2006-09-05, Merlin Moncure [EMAIL PROTECTED] wrote:
 On 9/5/06, Andrew - Supernews [EMAIL PROTECTED] wrote:
 On 2006-09-05, Josh Berkus josh@agliodbs.com wrote:
  The current code is GPL.   It *has* to be removed.

 Which is why Abhijit's version exists - it's intended to be a drop-in,
 BSD-licensed replacement for the current code.

 does his patch include documentation? I can help with that if it isn't
 done.  was it reviewed?

I don't think it has docs. The existing docs would be fine unless anyone
thinks that those also have copyright problems. 

-- 
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

---(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] Ding-dong, contrib is dead ...

2006-09-05 Thread Stefan Kaltenbrunner
Tom Lane wrote:
 Merlin Moncure [EMAIL PROTECTED] writes:
 I also agree with Andrew that pgfoundry is not a appropriate place for
 userlocks.  They should be properly documented with a cleaned up api.
 I have no objection from them being removed from contrib in the short
 term due to the gpl issue, although I am not sure how you can
 copyright a function wrapper.
 
 Right, I see the pgfoundry project as just a backwards-compatibility
 thing for anyone who doesn't want to change their code.  I'm happy to
 put some cleaned-up functions into core right now (ie, for 8.2) if
 someone will do the legwork to define and implement them.

hmm - that is all a nice and such - but is it really a good idea to do
this that late in the release-cycle ?
I think the most natural thing would be to replace the existing GPL'd
userlock code with the new one and discuss the API-change one for 8.3
and up ...


Stefan

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] Ding-dong, contrib is dead ...

2006-09-05 Thread Andrew - Supernews
On 2006-09-05, Tom Lane [EMAIL PROTECTED] wrote:
 Right, I see the pgfoundry project as just a backwards-compatibility
 thing for anyone who doesn't want to change their code.  I'm happy to
 put some cleaned-up functions into core right now (ie, for 8.2) if
 someone will do the legwork to define and implement them.

So you're prepared to violate the feature freeze to stick in a new API
that nobody currently wants to _use_, while forcing existing users to
resort to pgfoundry for a module that's been around for several major
releases?

-- 
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] Ding-dong, contrib is dead ...

2006-09-05 Thread Merlin Moncure

On 9/5/06, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:

Tom Lane wrote:
 Merlin Moncure [EMAIL PROTECTED] writes:
 I also agree with Andrew that pgfoundry is not a appropriate place for
 userlocks.  They should be properly documented with a cleaned up api.
 I have no objection from them being removed from contrib in the short
 term due to the gpl issue, although I am not sure how you can
 copyright a function wrapper.

 Right, I see the pgfoundry project as just a backwards-compatibility
 thing for anyone who doesn't want to change their code.  I'm happy to
 put some cleaned-up functions into core right now (ie, for 8.2) if
 someone will do the legwork to define and implement them.

hmm - that is all a nice and such - but is it really a good idea to do
this that late in the release-cycle ?
I think the most natural thing would be to replace the existing GPL'd
userlock code with the new one and discuss the API-change one for 8.3
and up ...


I think that's a reasonable solution, replace the existing (renamed?)
contrib with new wrappers and push core migration/documentation out to
8.3.  Then we are talking about one line wrappers here, not a feature
per se...

merlin

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [HACKERS] Open items for 8.2

2006-09-05 Thread Joachim Wieland
On Mon, Sep 04, 2006 at 11:58:35PM -0400, Tom Lane wrote:
 timezone changes: appendix B is out of date, and do we need a list at
 all rather than telling people to look at the config file + system view?

Since I did the initial patch I also volunteer to submit documentation for
it. As far as the table is concerned, I think we agreed on removing the list
(that has been inaccurate since long anyway) and tell people to check out
the system view.


Joachim

-- 
Joachim Wieland  [EMAIL PROTECTED]
   GPG key available

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] Ding-dong, contrib is dead ...

2006-09-05 Thread Andrew Dunstan

Tom Lane wrote:

I'm happy to
put some cleaned-up functions into core right now (ie, for 8.2) if
someone will do the legwork to define and implement them.

  



OK, who are you and what have you done with the real Tom Lane?

cheers

andrew

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [HACKERS] Ding-dong, contrib is dead ...

2006-09-05 Thread Tom Lane
Josh Berkus josh@agliodbs.com writes:
 Merlin,
 well, I'm confused now.  Tom said that cleaned up functions might be
 sneaked into 8.2, which is what prompted my question. 

 You're correct, he did.  Tom?

Well, it's not like we're done with forced initdb's for 8.2, so I don't
particularly see the harm in adding a few more functions.  I would be
against writing something large and complicated at this point, but these
functions are trivial (practically one-liners) and I don't think there's
a lot of debate needed about the API.  The biggest part of the work
needed is to write the documentation --- but we'd have to do that for
Abhijit's patch too, since the userlocks docs presumably fall under GPL
along with the code.

So basically I don't see the point of investing effort in a
bug-compatible version of userlocks, when we can have something cleaner
and suitable for the long run with not very much more effort.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Win32 hard crash problem

2006-09-05 Thread Joshua D. Drake

Magnus Hagander wrote:

Oops, going backwards through the mails it seems :)


Subsequent connections to the database will fail (such as pgAdmin)
and Windows must be completely rebooted.


Fail in what way. Hang, not connect, or get an error msg?


PostgreSQL will also not recover on its own (e.g; auto restart and
roll through the logs).


What do you mean by this? It doesn't start upon reboot? What is needed
to make it start?


It means that postgresql doesn't recover on its own. On linux if a 
backend crashes all of PostgreSQL will restart and come back up if it can.


On Win32 it doesn't.

Joshua D. Drake





//Magnus






--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] Win32 hard crash problem

2006-09-05 Thread Merlin Moncure

On 9/5/06, Joshua D. Drake [EMAIL PROTECTED] wrote:

Magnus Hagander wrote:
 What do you mean by this? It doesn't start upon reboot? What is needed
 to make it start?

It means that postgresql doesn't recover on its own. On linux if a
backend crashes all of PostgreSQL will restart and come back up if it can.

On Win32 it doesn't.


it does for me, at least for me when I used to work with windows :).
I think it just doesn't restart for this particular type of crash.  I
had a couple of similarly wierd undetectable windows problems that I
could never quite figured out until I got hired by another company and
left that monster behind for good.

merlin

---(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] Win32 hard crash problem

2006-09-05 Thread Joshua D. Drake

Magnus Hagander wrote:
PostgreSQL will also not recover on its own (e.g; auto restart and 
roll through the logs).
What do you mean by this? It doesn't start upon reboot? 
What is needed 

to make it start?
It means that postgresql doesn't recover on its own. On linux 
if a backend crashes all of PostgreSQL will restart and come 
back up if it can.


On Win32 it doesn't.


Ah, I thought you meant that the database recovery process (that runs
after a crash) failed and lost data. But it's not data-loss then, it
just took a reboot to fix it?


Right, but just took a reboot to fix it isn't very confidence inspiring ;)



I think we're somehow seeing a complete postmaster hang, where it's
either not able to kill off th ebackends as required, or just not
capable of accepting new connections after that. Which makes a
stacktrace from the postmaster the most interesting one to look at.


I have asked the customer to also look and see if there was one 
particular process that was eating cpu via the task master and see if 
that process can be killed. If that process can be killed and postgresql 
comes back clean, then that is a step.


However, debugging this beast is a pain. I take it mingw doesn't have a 
gdb we can use?




//Magnus




--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org


Re: [HACKERS] Win32 hard crash problem

2006-09-05 Thread Magnus Hagander
  PostgreSQL will also not recover on its own (e.g; auto restart and 
  roll through the logs).
  
  What do you mean by this? It doesn't start upon reboot? 
 What is needed 
  to make it start?
 
 It means that postgresql doesn't recover on its own. On linux 
 if a backend crashes all of PostgreSQL will restart and come 
 back up if it can.
 
 On Win32 it doesn't.

Ah, I thought you meant that the database recovery process (that runs
after a crash) failed and lost data. But it's not data-loss then, it
just took a reboot to fix it?

I think we're somehow seeing a complete postmaster hang, where it's
either not able to kill off th ebackends as required, or just not
capable of accepting new connections after that. Which makes a
stacktrace from the postmaster the most interesting one to look at.

//Magnus

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] Win32 hard crash problem

2006-09-05 Thread Tom Lane
Merlin Moncure [EMAIL PROTECTED] writes:
 On 9/5/06, Joshua D. Drake [EMAIL PROTECTED] wrote:
 Magnus Hagander wrote:
 What do you mean by this? It doesn't start upon reboot? What is needed
 to make it start?
 
 It means that postgresql doesn't recover on its own. On linux if a
 backend crashes all of PostgreSQL will restart and come back up if it can.
 
 On Win32 it doesn't.

 it does for me, at least for me when I used to work with windows :).
 I think it just doesn't restart for this particular type of crash.

As best I can tell, Josh isn't describing a crash at all.  Something
(possibly in the TCP stack) has locked up, but there's no way for the
postmaster to know there's anything wrong, and probably no way for the
postmaster to fix it if it did know.  Restarting backends certainly
isn't going to fix a communication problem.

Josh failed to answer the most important question though:

 Subsequent connections to the database will fail (such as pgAdmin)
 and Windows must be completely rebooted.
 
 Fail in what way. Hang, not connect, or get an error msg?

regards, tom lane

---(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] pgcrypto deprecated functions?

2006-09-05 Thread Tom Lane
Marko Kreen [EMAIL PROTECTED] writes:
 On 8/30/06, Bruce Momjian [EMAIL PROTECTED] wrote:
 Michael Fuhr wrote:
 In README.pgcrypto, Section 2.3 Deprecated functions says that
 digest_exists(), hmac_exists(), and cipher_exists() are planned to
 be removed in PostgreSQL 8.2.  Those functions still exist -- should
 they be removed or does that section need updating?
 
 Marko, any comment on this pgcrypto item?

 Heh, I had it forgotten.  Lets do it.  Although there's no hurry with it,
 delaying just will annoy more users.
 Also, update my email address.

Applied, thanks.

regards, tom lane

---(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] Open items for 8.2

2006-09-05 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  Here are the open items for 8.2:
  http://momjian.postgresql.org/cgi-bin/pgopenitems
 
 Had a bitmap-index patch arrived in my inbox this morning, as had been
 promised to me for three weekends running, I might have been willing to
 drop all else and review it.  But, no patch.  This item is dead for 8.2.
 Do not even think of suggesting otherwise.

Well, we have to use some objective criteria, rather than one person's
decision.  I would say we are one month past feature freeze, and have
not received a patch to review, and you have asked repeatedly.  That is
enough of a basis to reject this feature for 8.2.  Removed from open
items list.

 Updatable views are likewise dead --- we don't have a credible patch or
 any short-term path to get one.  I hope to see both of these items land
 early in the 8.3 devel cycle, but for 8.2, nyet.

OK, same criteria.  Removed.

 The list is missing the issue of removing the long-since-agreed-on-to-remove
 contrib modules.

Added.

 A couple of recently discussed FE/BE protocol issues are: not storing a
 plan at all for unnamed-statement cases, and thus allowing bind
 parameters to be treated as constants; allowing parameter types to go
 unresolved rather than throwing an error.  Perhaps it's too late to
 consider these for 8.2, but they seem no more invasive than some other
 items on the open-issues list.

Well, I think the difference is that they are new items, rather than
something pre-August 1 (or bugs), but I figure we could throw them in if
it wasn't risky.  Added to list.

 Other docs issues:
 
 VALUES-list syntax --- not real clear where to put it
 
 timezone changes: appendix B is out of date, and do we need a list at
 all rather than telling people to look at the config file + system view?

Both added.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] Open items for 8.2

2006-09-05 Thread Bruce Momjian
Andrew Dunstan wrote:
 Bruce Momjian wrote:
  Here are the open items for 8.2:
 
  http://momjian.postgresql.org/cgi-bin/pgopenitems
 
  This list will be continually updated until we release 8.2.
 

 
 Emacs code examplenot submitted   Gregory Stark [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED]
 
 
 
 This one is actually on my list, and will be done in a day or two. I 
 have Greg's suggestion, which will be included.

OK.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] Win32 hard crash problem

2006-09-05 Thread Joshua D. Drake



Josh failed to answer the most important question though:


Sorry.




Subsequent connections to the database will fail (such as pgAdmin)
and Windows must be completely rebooted.

Fail in what way. Hang, not connect, or get an error msg?


Just verified with customer. Once the problem occurs the first time, the 
customer will continually get the same error message for each subsequent 
connection attempt:


server sent data (D message) without prior row description (T message)




regards, tom lane




--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] updatable views and default values

2006-09-05 Thread David Fetter
On Sat, Sep 02, 2006 at 06:22:49PM -0500, Jim C. Nasby wrote:
 On Thu, Aug 31, 2006 at 06:29:50PM -0400, Tom Lane wrote:
  For backwards compatibility we should probably say that this
  automatic lifting of base-table defaults happens only if the
  INSERT rule is implicitly generated ... if you write a manual
  INSERT rule you need manual defaults too.  Or should propagate
  default values become an explicit attribute of ON INSERT rules?
 
 ISTM that least surprise dictates that inserting into a view uses
 the base table default unless you specifically override them.

+1 :)

Cheers,
D
-- 
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 415 235 3778AIM: dfetter666
  Skype: davidfetter

Remember to vote!

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] Open items for 8.2

2006-09-05 Thread Tom Lane
We made pretty good progress today on the open-items list:

ISBN/EAN: I've reviewed this and fixed a couple small issues, it's ready
to commit as soon as the author indicates his assent to license
statement.  I'll remove isbn_issn at the same time.

Altering view ownership doesn't work: fixed

Remove pgcrypto deprecated functions: done

Intel compiler fails for GIN build: I think Teodor did something with
this

Add /contrib/hstore: done by Teodor

plpgsql, return can contains any expression: actually, this is bounced
back to author for rework.  Dunno if you intend reviewing to include
that state.

Remove contrib stuff: done

regards, tom lane

---(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] Open items for 8.2

2006-09-05 Thread Bruce Momjian
Joachim Wieland wrote:
 On Mon, Sep 04, 2006 at 11:58:35PM -0400, Tom Lane wrote:
  timezone changes: appendix B is out of date, and do we need a list at
  all rather than telling people to look at the config file + system view?
 
 Since I did the initial patch I also volunteer to submit documentation for
 it. As far as the table is concerned, I think we agreed on removing the list
 (that has been inaccurate since long anyway) and tell people to check out
 the system view.

OK, added.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(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] Win32 hard crash problem

2006-09-05 Thread Tom Lane
Joshua D. Drake [EMAIL PROTECTED] writes:
 Fail in what way. Hang, not connect, or get an error msg?

 Just verified with customer. Once the problem occurs the first time, the 
 customer will continually get the same error message for each subsequent 
 connection attempt:

 server sent data (D message) without prior row description (T message)

During the connection attempt?  I don't think libpq can report that
message until it tries to do a regular query (might be wrong though).
Is the client using some application that's going to issue a query
immediately on connecting?

It would be useful to turn on log_connections and log_statement (and
perhaps crank log_min_messages all the way up to DEBUG5) to see if we
can get anything in the postmaster log giving a hint what actually
happens here.  A TCP sniff of the connection attempt traffic would be
pretty useful too.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] [PATCHES] Gen_fmgrtab.sh fails with LANG=et_EE

2006-09-05 Thread Marko Kreen

On 9/5/06, Tom Lane [EMAIL PROTECTED] wrote:

Peter Eisentraut [EMAIL PROTECTED] writes:
 Well, the line of code is
 cpp_define=`echo $OIDSFILE | tr abcdefghijklmnopqrstuvwxyz 
ABCDEFGHIJKLMNOPQRSTUVWXYZ | sed -e 's/[^A-Z]/_/g'`
 so it ought to be pretty obvious what the correct solution for the
 problem character ranges are locale-dependent is.

Doh.  Patched that way.

Curiously, I couldn't replicate the failure on Fedora 5 --- Marko's
platform must have different locale behavior for et_EE.


Did you add it to locale-gen config and ran it?

Btw, I removed all the pipeline in my patch, because I felt
such messy pipeline for such a tiny thing is ugly.  Especially
as the filename wont change that much.  Thus I though it would
be cleaner to just put the symbol together with filename definition.

--
marko

---(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] Win32 hard crash problem

2006-09-05 Thread Alvaro Herrera
Tom Lane wrote:
 Joshua D. Drake [EMAIL PROTECTED] writes:
  Fail in what way. Hang, not connect, or get an error msg?
 
  Just verified with customer. Once the problem occurs the first time, the 
  customer will continually get the same error message for each subsequent 
  connection attempt:
 
  server sent data (D message) without prior row description (T message)
 
 During the connection attempt?  I don't think libpq can report that
 message until it tries to do a regular query (might be wrong though).
 Is the client using some application that's going to issue a query
 immediately on connecting?

What I've been wondering all along is whether they are using a
connection pool.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-09-05 Thread Bruce Momjian
Victor Wagner wrote:
 On 2006.09.04 at 15:46:03 -0400, Bruce Momjian wrote:
 
  Tom Lane wrote:
   Bruce Momjian [EMAIL PROTECTED] writes:
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
   
   This version was withdrawn by the author for rework, no?
  
  Right, and the thread in patches_hold shows that.  The reason it is in
  there is so we can ping the author at the start of 8.3 to get an updated
  version.
 
 I've already send version 2 of the patch to patches mailing list.
 I think that this letter even got into thread mentioned above.
 
 It's a pity that it's to late for patch to get into 8.2.
 It means that during all 8.2 lifecycle we'll have to maintain this patch
 separately.

Yep, sorry.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] pgcrypto deprecated functions?

2006-09-05 Thread Bruce Momjian
Tom Lane wrote:
 Marko Kreen [EMAIL PROTECTED] writes:
  On 8/30/06, Bruce Momjian [EMAIL PROTECTED] wrote:
  Michael Fuhr wrote:
  In README.pgcrypto, Section 2.3 Deprecated functions says that
  digest_exists(), hmac_exists(), and cipher_exists() are planned to
  be removed in PostgreSQL 8.2.  Those functions still exist -- should
  they be removed or does that section need updating?
  
  Marko, any comment on this pgcrypto item?
 
  Heh, I had it forgotten.  Lets do it.  Although there's no hurry with it,
  delaying just will annoy more users.
  Also, update my email address.
 
 Applied, thanks.

FYI, and email address updated.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Win32 hard crash problem

2006-09-05 Thread Joshua D. Drake

Tom Lane wrote:

Joshua D. Drake [EMAIL PROTECTED] writes:

Fail in what way. Hang, not connect, or get an error msg?


Just verified with customer. Once the problem occurs the first time, the 
customer will continually get the same error message for each subsequent 
connection attempt:



server sent data (D message) without prior row description (T message)


During the connection attempt?  I don't think libpq can report that
message until it tries to do a regular query (might be wrong though).
Is the client using some application that's going to issue a query
immediately on connecting?


Well, windows ;) Customer says that they double click pgadmin and they 
get that message. I have informed them on how to increase to debug5 and 
hopefully we get something from that, of course it will likely be 24.85 
days from now ;)




It would be useful to turn on log_connections and log_statement (and
perhaps crank log_min_messages all the way up to DEBUG5) to see if we
can get anything in the postmaster log giving a hint what actually
happens here.  A TCP sniff of the connection attempt traffic would be
pretty useful too.



Sincerely,

Joshua D. Drake


--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Win32 hard crash problem

2006-09-05 Thread Joshua D. Drake

Alvaro Herrera wrote:

Tom Lane wrote:

Joshua D. Drake [EMAIL PROTECTED] writes:

Fail in what way. Hang, not connect, or get an error msg?
Just verified with customer. Once the problem occurs the first time, the 
customer will continually get the same error message for each subsequent 
connection attempt:

server sent data (D message) without prior row description (T message)

During the connection attempt?  I don't think libpq can report that
message until it tries to do a regular query (might be wrong though).
Is the client using some application that's going to issue a query
immediately on connecting?


What I've been wondering all along is whether they are using a
connection pool.



Yes they are using a connection pool. A java based one.

Sincerely,

Joshua D. Drake


--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(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] Ding-dong, contrib is dead ...

2006-09-05 Thread Andrew - Supernews
On 2006-09-05, Merlin Moncure [EMAIL PROTECTED] wrote:
 I have no objection from them being removed from contrib in the short
 term due to the gpl issue, although I am not sure how you can
 copyright a function wrapper.

I made this point several times in the original discussion (which was a
year and a half or so ago). However, others seemed to disagree, which is
why we now have a replacement version.

-- 
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] Win32 hard crash problem

2006-09-05 Thread Jeremy Drake
On Tue, 5 Sep 2006, Joshua D. Drake wrote:

 Right, but just took a reboot to fix it isn't very confidence inspiring ;)

Are you kidding?  This is standard procedure for troubleshooting Windows
problems :)

--
The world is coming to an end.  Please log off.

---(end of broadcast)---
TIP 6: explain analyze is your friend


[HACKERS] New Linux Filesystem: NILFS

2006-09-05 Thread Chris Browne
Recently seen in ACM Operating Systems Review (this is the first time
I've found as many as 1 interesting article in it in a while, and
there were 3 things I found worthwhile...):

NTT (of the recent NTT Power Hour) have created a new filesystem:
  http://www.nilfs.org/en/

NILFS is a log-structured file system developed for Linux.  

In effect, it provides the moral equivalent to MVCC for filesystems;
overwrites are equivalent to delete/insert, and requires a Cleaner
process in order to clean out formerly-used space.

It ought to have two merits over journalling filesystems:

 1.  It doesn't need to write data twice, which should improve
 performance

 2.  It doesn't need to repetitively overwrite metadata, which should
 improve crash safety.

On the latter, per the paper:

... These journaling filesystems enable fast and consistent recovery
of the file system after unexpected system freezes or power
failures. However, they still allow the fatal destruction of the file
system due to the characteristic that recovery is realized by
overwriting meta data with their copies saved in a journal file.  This
recovery is guaranteed to work properly only if the write order of the
on-disk data blocks and meta data blocks is physically conserved on
the disk platters. Unfortunately, this constraint is often violated by
the write optimizations performed by the block I/O subsystem and disk
controllers.

It's still at a somewhat early stage, as they haven't completed coding
the Cleaner.  (Probably should call it the Reaper... :-))

By the way, the Google SOC 2005 also produced one:
  http://logfs.sourceforge.net/

NetBSD used to have a LFS; has that gone anywhere?  Or been
essentially dropped?
-- 
let name=cbbrowne and tld=cbbrowne.com in String.concat @ [name;tld];;
http://linuxdatabases.info/info/emacs.html
I develop for  Linux for a living, I used to  develop for DOS.  Going
from DOS to Linux is like trading a glider for an F117.
-- [EMAIL PROTECTED] Lawrence Foard

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Win32 hard crash problem

2006-09-05 Thread Joshua D. Drake

Alvaro Herrera wrote:

Joshua D. Drake wrote:

Alvaro Herrera wrote:

Tom Lane wrote:

Joshua D. Drake [EMAIL PROTECTED] writes:

Fail in what way. Hang, not connect, or get an error msg?
Just verified with customer. Once the problem occurs the first time, the 
customer will continually get the same error message for each subsequent 
connection attempt:
server sent data (D message) without prior row description (T 
message)

During the connection attempt?  I don't think libpq can report that
message until it tries to do a regular query (might be wrong though).
Is the client using some application that's going to issue a query
immediately on connecting?

What I've been wondering all along is whether they are using a
connection pool.

Yes they are using a connection pool. A java based one.


It's quite possible that it's the connection pool that gets confused,
and not PostgreSQL itself.  It would be interesting if they change the
connection setting when the hang next occurs, to point directly to
PostgreSQL bypassing the connection pool.


Well except when they are connecting with Pgadmin (which wouldn't go 
through the connection pool) they get the error as well.


Joshua D. Drake



OTOH the connection pool may be the thing with the TickCounter problem.





--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module

2006-09-05 Thread Bruce Momjian
Tom Lane wrote:
 Jeremy Kronuz [EMAIL PROTECTED] writes:
  Hello again,This is an usable version of my EAN13/UPC/ISBN module.
 
 I'm reviewing this for addition to contrib/ now.  I notice that there is
 no clear license statement.  Is it OK to put the following into the
 README file?
 
 
 EAN13 - UPC - ISBN (books) - ISMN (music) - ISSN (serials)
 --
 
 Copyright Germ?n M?ndez Bravo (Kronuz), 2004 - 2006
 This module is released under the same BSD license as the rest of PostgreSQL.
 
 The information to implement this module was collected through ...

Do we want to go down this road for all submissions?  I think saying
nothing is best.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(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] [PATCHES] Updatable views

2006-09-05 Thread Bruce Momjian

This has been saved for the 8.3 release:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---

Bernd Helmle wrote:
 --On Freitag, September 01, 2006 11:41:16 -0400 Tom Lane 
 [EMAIL PROTECTED] wrote:
 
 
  So in other words, views on serial columns don't work?  I don't think
  that's going to be acceptable.
 
 
 They work in such a case that someone isn't allowed to put a volatile
 function in an update query
 
 
  Not really worse than what the rewriter is doing already --- in fact,
  I think it's isomorphic to what would happen to the rule qual
  expressions in your existing patch.
 
 
 Currently you don't have to rewrite the rule conditions itself every
 time you apply them to the query tree since they are stored in pg_rewrite
 matching all various (reversed) varattno's, resno's and whatever.
 If i understand correctly you need to do that with constraints every time
 you fire an update query on a view for each underlying relation
 
 
  I'm about to propose that we should try to go beta next week (see
  forthcoming message).  If you can strip down your patch to avoid the
  multi-eval problems in the next couple of days, I'm still willing to
 
 Depends on how many days couple of days are.if you mean the next 
 three days
 then definitely not, since i'm afk for the whole upcoming weekend. Bad 
 timing, but
 it's not deferrable :(
 
  consider it, but at the moment I'm assuming that it needs to be held
  for 8.3.
 
 Well, i'll see what i can do next weekit's a little bit disappointing 
 that these problems
 raises so late, but that's no one's fault since there are many side effects 
 of the rewriting
 system involved
 
 Many thanks for your comments.
 
 Bernd
 
 
 ---(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

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Win32 hard crash problem

2006-09-05 Thread Dave Cramer


On 5-Sep-06, at 6:05 PM, Joshua D. Drake wrote:


Alvaro Herrera wrote:

Tom Lane wrote:

Joshua D. Drake [EMAIL PROTECTED] writes:

Fail in what way. Hang, not connect, or get an error msg?
Just verified with customer. Once the problem occurs the first  
time, the customer will continually get the same error message  
for each subsequent connection attempt:
server sent data (D message) without prior row description  
(T message)

During the connection attempt?  I don't think libpq can report that
message until it tries to do a regular query (might be wrong  
though).

Is the client using some application that's going to issue a query
immediately on connecting?

What I've been wondering all along is whether they are using a
connection pool.


Yes they are using a connection pool. A java based one.
Since java has it's own protocol implementation, this is totally  
unrelated to any libpq error messages.


While I've not personally used the pool in question (c3p0) my  
understanding is that it is pretty robust.


Personally, I'm betting on some windows TCP/IP weirdness here.

Dave


Sincerely,

Joshua D. Drake


--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(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




---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module

2006-09-05 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
 Tom Lane wrote:
 I'm reviewing this for addition to contrib/ now.  I notice that there is
 no clear license statement.  Is it OK to put the following into the
 README file?

 This module is released under the same BSD license as the rest of PostgreSQL.

 Do we want to go down this road for all submissions?  I think saying
 nothing is best.

The alternative is to ask him to remove his personal copyright notice
and put Copyright PostgreSQL Global Development Group instead.  I
don't really care which, but without one or the other it's not clear
that he is giving permission for redistribution.

As for all submissions, I'm only concerned about the ones that come
plastered with copyright notices.

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] Win32 hard crash problem

2006-09-05 Thread Alvaro Herrera
Joshua D. Drake wrote:
 Alvaro Herrera wrote:
 Joshua D. Drake wrote:
 Alvaro Herrera wrote:

 What I've been wondering all along is whether they are using a
 connection pool.
 Yes they are using a connection pool. A java based one.
 
 It's quite possible that it's the connection pool that gets confused,
 and not PostgreSQL itself.  It would be interesting if they change the
 connection setting when the hang next occurs, to point directly to
 PostgreSQL bypassing the connection pool.
 
 Well except when they are connecting with Pgadmin (which wouldn't go 
 through the connection pool) they get the error as well.

Are you assuming, or did they/you verify that this is indeed the case?
I see no reason to assume that pgAdmin can't connect via a pool.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] Win32 hard crash problem

2006-09-05 Thread Tom Lane
Dave Cramer [EMAIL PROTECTED] writes:
 On 5-Sep-06, at 6:05 PM, Joshua D. Drake wrote:
 Yes they are using a connection pool. A java based one.

 Since java has it's own protocol implementation, this is totally  
 unrelated to any libpq error messages.

Another important point that we've not been given information on:
when pgAdmin/libpq starts failing like this, exactly what is happening
with the connection pool?  Is it still able to issue queries, and
if not what happens exactly?

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] New Linux Filesystem: NILFS

2006-09-05 Thread Douglas McNaught
Chris Browne [EMAIL PROTECTED] writes:

 NetBSD used to have a LFS; has that gone anywhere?  Or been
 essentially dropped?

My reading over the last few years has indicated that LFSs tend to
suffer bad performance degradation as data and metadata for a given
file get scattered all over the disk.  This tends to cancel out the
performance gain from being able to cluster writes in a single area.
For a heavily write-intensive workload, it might be a win, but no one
seems to have demonstrated an advantage for normal, mostly
read-heavy usage.

-Doug

---(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] Win32 hard crash problem

2006-09-05 Thread Alvaro Herrera
Joshua D. Drake wrote:
 Alvaro Herrera wrote:
 Tom Lane wrote:
 Joshua D. Drake [EMAIL PROTECTED] writes:
 Fail in what way. Hang, not connect, or get an error msg?
 Just verified with customer. Once the problem occurs the first time, the 
 customer will continually get the same error message for each subsequent 
 connection attempt:
 server sent data (D message) without prior row description (T 
 message)
 During the connection attempt?  I don't think libpq can report that
 message until it tries to do a regular query (might be wrong though).
 Is the client using some application that's going to issue a query
 immediately on connecting?
 
 What I've been wondering all along is whether they are using a
 connection pool.
 
 Yes they are using a connection pool. A java based one.

It's quite possible that it's the connection pool that gets confused,
and not PostgreSQL itself.  It would be interesting if they change the
connection setting when the hang next occurs, to point directly to
PostgreSQL bypassing the connection pool.

OTOH the connection pool may be the thing with the TickCounter problem.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(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] Open items for 8.2

2006-09-05 Thread Bruce Momjian
Tom Lane wrote:
 We made pretty good progress today on the open-items list:
 
 ISBN/EAN: I've reviewed this and fixed a couple small issues, it's ready
 to commit as soon as the author indicates his assent to license
 statement.  I'll remove isbn_issn at the same time.
 
 Altering view ownership doesn't work: fixed
 
 Remove pgcrypto deprecated functions: done
 
 Intel compiler fails for GIN build: I think Teodor did something with
 this
 
 Add /contrib/hstore: done by Teodor
 
 plpgsql, return can contains any expression: actually, this is bounced
 back to author for rework.  Dunno if you intend reviewing to include
 that state.

Yes, it does, but I changed it to resubmit.

 Remove contrib stuff: done

Other stuff all updated/removed.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] Win32 hard crash problem

2006-09-05 Thread Joshua D. Drake

Alvaro Herrera wrote:

Joshua D. Drake wrote:

Alvaro Herrera wrote:

Joshua D. Drake wrote:

Alvaro Herrera wrote:



What I've been wondering all along is whether they are using a
connection pool.

Yes they are using a connection pool. A java based one.

It's quite possible that it's the connection pool that gets confused,
and not PostgreSQL itself.  It would be interesting if they change the
connection setting when the hang next occurs, to point directly to
PostgreSQL bypassing the connection pool.
Well except when they are connecting with Pgadmin (which wouldn't go 
through the connection pool) they get the error as well.


Are you assuming, or did they/you verify that this is indeed the case?
I see no reason to assume that pgAdmin can't connect via a pool.



Verified. They do not connect to the connection pool for pgadmin.

Although I would think pgadmin might have problems connecting to a java 
based pool. If I recall, (I could be cranked) JDBC apps can't use pgpool 
for example.


Sincerely,

Joshua D. Drake



--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] [PATCHES] WIP: bitmap indexes

2006-09-05 Thread Bruce Momjian

This has been saved for the 8.3 release:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---
Jie Zhang wrote:
 
 
 On 8/15/06 6:18 AM, Tom Lane [EMAIL PROTECTED] wrote:
 
  Gavin Sherry [EMAIL PROTECTED] writes:
  On Mon, 14 Aug 2006, Tom Lane wrote:
  Correct me if I'm wrong, but isn't the patch's present hacking on the
  executor intended to make it happen like this?
  
  Not really. It reads ahead on the bitmap index and passes back the bitmap
  words. The other executor routines are hacked up to process the data in
  this format.
  
  Well, as I said, I don't think there's justification for exposing a
  bitmap index's internal data formats to the rest of the system like
  that: it's not very future-proof and I don't see that it's buying any
  significant performance gain.  At some point you have to convert to TIDs
  anyway, at least in the sense of knowing what page and line number you
  are at, so passing the data as an array of TIDs really isn't going to
  hurt much.  So my advice is to rip out all those changes and go back to
  the existing tidbitmap.c readout API.  There's nothing wrong with
  the TBMIterateResult data structure.
 
 
 The bitmap words in the bitmap index are very simple and can be very
 generic. You can think about them as one bit per tuple along with some
 padding bits between heap pages. The problem I have is that I do not know a
 good way to construct an in-memory version of this for other index
 structures, like b-tree. To be able to handle both cases nicely, you are
 right -- TBMIterateResult is better. Or, PagetableEntry may be better since
 it will make AND/OR easier.
 
  What I do find interesting to think about is whether, strictly within
  tidbitmap.c, there could be an alternate kind of bitmap object that
  doesn't have to materialize the whole bitmap for an indexscan in memory
  because it knows it can fetch the data on-demand, ie, build the next
  page TBMIterateResult data structure on-the-fly from the index when it's
  requested.  Call it a stream bitmap in contrast to the present
  materialized bitmaps.  The trick here is to be able to AND and OR a
  stream bitmap with another stream bitmap or a materialized bitmap.
  I don't see any reason in principle why that couldn't be done: the
  output of the AND/OR would be a stream of TBMIterateResults just like
  the inputs.  That is, it's another stream bitmap, but with a different
  generating function and some internal state that includes its source
  bitmaps.  You'd have to sort a materialized bitmap into order before
  starting to AND/OR it with a stream bitmap, but that code is there
  already.
 
 I like this idea. I think that we can define a new TBMStatus to be
 TBM_STREAM in TIDBitmap. *getmulti functions will remain the same, except
 that we add a new returning bool argument, stating if this is a stream
 bitmap. If this is a stream bitmap, nodeBitmapIndexScan simply fills spages,
 and passes it upstream. When nodeBitmapAnd or nodeBitmapOr ANDs/ORs several
 bitmaps, the result bitmap is a stream bitmap if there is at least one
 bitmap is a stream bitmap. Then we add another loop in nodeBitmapHeapscan to
 be able to pull more data from its subnode.
 
 Thanks,
 Jie
 
 
 
 ---(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

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module

2006-09-05 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  Tom Lane wrote:
  I'm reviewing this for addition to contrib/ now.  I notice that there is
  no clear license statement.  Is it OK to put the following into the
  README file?
 
  This module is released under the same BSD license as the rest of 
  PostgreSQL.
 
  Do we want to go down this road for all submissions?  I think saying
  nothing is best.
 
 The alternative is to ask him to remove his personal copyright notice
 and put Copyright PostgreSQL Global Development Group instead.  I
 don't really care which, but without one or the other it's not clear
 that he is giving permission for redistribution.

Agreed.
 
 As for all submissions, I'm only concerned about the ones that come
 plastered with copyright notices.

Oh, I didn't see one in there.  Oh, I see it now in isn.c:

* Copyright (c) 2004-2006, GermE1n ME9ndez Bravo (Kronuz)

And when you said I notice that there is no clear license statement, I
thought you meant no license at all.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(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


  1   2   >