Re: [HACKERS] Cygwin - make check broken

Rocco Altier schrieb: It looks like when we changed regress/GNUmakefile to pull rules from Makefile.shlib, cygwin got broken in the process. The problem is that regess.dll ends up being a symlink back to itself, because we do a: $(NAME)$(DLSUFFIX): $(shlib) rm -f $(NAME)$(DLSUFFIX)

Re: [HACKERS] MySQL to PostgreSQL for SugarCRM

dennis, look at vtiger crm (http://www.vtiger.com) vtiger is a fork of sugarcrm and are 100% commited to open source. (unlike sugar, who offer the full version only for purchase) and they actively want to support more databases. regards, /sak Denis Lussier wrote: At EnterpriseDB we're doing a

[HACKERS] problem building 7.3 on FreeBSD 6

Hi! Can someone with a FreeBSD 6.x installation confirm the build error referred here: I maintain the postgresql ports for FreeBSD, but I have no version 6 installed yet. Thanks, Palle ---

[HACKERS] Qustions about timestampz

Hello I am working on trunc and round function now. I have some problems with timestemp with time zone datatype. First question? is correct behaviour (I am in GMT+2 time zone)? select current_timestamp, date_trunc('year', current_timestamp), date_trunc('month', current_timestamp); timesta

Re: [HACKERS] win32 _dosmaperr()

""Magnus Hagander"" <[EMAIL PROTECTED]> writes > > I suggest you try using Process Explorer from www.sysinternals.com to > figure out who has the file open. Most of the time it should be able to > tell you exactly who has locked the file - at least as long as it's done > from userspace. I'm not 10

Re: [HACKERS] Solving the OID-collision problem

Tom Lane sss.pgh.pa.us> writes: > > I was reminded again today of the problem that once a database has been > in existence long enough for the OID counter to wrap around, people will > get occasional errors due to OID collisions, eg > > http://archives.postgresql.org/pgsql-general/2005-08/msg001

Re: [HACKERS] US Census database (Tiger 2004FE) - 4.4G

I thought bout it, but it isn't the best program around, but it does work. My program also reformats numbers, i.e. long/lat become properly decimal-ed numerics, zips become integers, etc. The question is... Do you download the raw data and convert it into a database, or do you download the pre-fo

Re: [HACKERS] openbsd, plpython, missing threading symbols

On Thu, Aug 04, 2005 at 08:14:51PM +0200, Stefan Kaltenbrunner wrote: > Tom Lane wrote: > >Andrew Dunstan <[EMAIL PROTECTED]> writes: > >>Tom Lane wrote: > >>>The alternative is to say that plpython isn't supported on BSDen unless > >>>you choose to build an unthreaded libpython. > >>I'm OK with th

Re: [HACKERS] Cygwin - make check broken

"Rocco Altier" <[EMAIL PROTECTED]> writes: > It looks like when we changed regress/GNUmakefile to pull rules from > Makefile.shlib, cygwin got broken in the process. > ... > I don't know enough about the rest of the way the cygwin port is put > together, but it seems that the other platforms all ha

[HACKERS] Cygwin - make check broken

It looks like when we changed regress/GNUmakefile to pull rules from Makefile.shlib, cygwin got broken in the process. The problem is that regess.dll ends up being a symlink back to itself, because we do a: $(NAME)$(DLSUFFIX): $(shlib) rm -f $(NAME)$(DLSUFFIX) $(LN_S) $(shlib) $(NA

Re: [HACKERS] US Census database (Tiger 2004FE) - 4.4G

Mark Woodward wrote: It is 4.4G in space in a gzip package. I'll mail a DVD to two people who promise to host it for Hackers. Would it be easier to release the program you did to do this conversion? I use this pretty short (274 line) C program: http://www.forensiclogic.com/tmp/tgr2sql.c t

Re: [HACKERS] openbsd, plpython, missing threading symbols

Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: > >>Tom Lane wrote: >> >>>The alternative is to say that plpython isn't supported on BSDen unless >>>you choose to build an unthreaded libpython. > > >>I'm OK with that, but if that's what's done I think we should check for >>it up fr

Re: [HACKERS] Solving the OID-collision problem

On Thu, Aug 04, 2005 at 12:20:24PM -0400, Tom Lane wrote: > "Mark Woodward" <[EMAIL PROTECTED]> writes: > >> I'm too lazy to run an experiment, but I believe it would. Datum is > >> involved in almost every function-call API in the backend. In > >> particular this means that it would affect perfor

Re: [HACKERS] pg_dump -- data and schema only?

> "Mark Woodward" <[EMAIL PROTECTED]> writes: >> Actually, there isn't a setting to just dump the able definitions and >> the >> data. When you dump the schema, it includes all the tablespaces, >> namespaces, owners, etc. > >> Just the table nd object declarations and data would be useful. > > pg_d

Re: [HACKERS] Solving the OID-collision problem

> "Mark Woodward" <[EMAIL PROTECTED]> writes: >>> I'm too lazy to run an experiment, but I believe it would. Datum is >>> involved in almost every function-call API in the backend. In >>> particular this means that it would affect performance-critical code >>> paths. > >> I hear you on the "lazy"

Re: [HACKERS] Enhanced containment selectivity function

Matteo Beccati <[EMAIL PROTECTED]> writes: > Moving it in contrib/ltree would be more difficult to me because it > depends on other functions declared in selfuncs.c > (get_restriction_variable, etc). I'd be willing to consider exporting those functions from selfuncs.c. r

Re: [HACKERS] Enhanced containment selectivity function

Tom Lane wrote: After looking at this a little, it doesn't seem like it has much to do with the ordinary 2-D notion of containment. In most of the core geometric types, the "histogram" ordering is based on area, and so testing the histogram samples against the query doesn't seem like it's able t

Re: [HACKERS] pg_dump -- data and schema only?

"Mark Woodward" <[EMAIL PROTECTED]> writes: > Actually, there isn't a setting to just dump the able definitions and the > data. When you dump the schema, it includes all the tablespaces, > namespaces, owners, etc. > Just the table nd object declarations and data would be useful. pg_dump -t table

Re: [HACKERS] US Census database (Tiger 2004FE) - 4.4G

You can send it to me, and ehpg will host it. I'll send you a private email with my info. Gavin On Aug 4, 2005, at 8:26 AM, Mark Woodward wrote: It is 4.4G in space in a gzip package. I'll mail a DVD to two people who promise to host it for Hackers. ---(end of br

Re: [HACKERS] Solving the OID-collision problem

"Mark Woodward" <[EMAIL PROTECTED]> writes: >> I'm too lazy to run an experiment, but I believe it would. Datum is >> involved in almost every function-call API in the backend. In >> particular this means that it would affect performance-critical code >> paths. > I hear you on the "lazy" part, bu

Re: [HACKERS] Enhanced containment selectivity function

Matteo Beccati <[EMAIL PROTECTED]> writes: > This also made me think: is there a reason why geometric selectivity > functions return constant values rather than checking statistics for a > better result? Because no one's ever bothered to work on them. You should talk to the PostGIS guys, howeve

Re: [HACKERS] pg_dump -- data and schema only?

Am Donnerstag, den 04.08.2005, 11:52 -0400 schrieb Mark Woodward: > > Am Donnerstag, den 04.08.2005, 10:26 -0400 schrieb Mark Woodward: > >> I haven't seen this option, and does anyone thing it is a good idea? > >> > >> A option to pg_dump and maybe pg_dump all, that dumps only the table > >> decla

[HACKERS] buildfarm happenings

If you haven't visited the buildfarm recently you might have missed a few developments: . we are now reporting flags used on builds on the main dashboard page - I am working on making that look nicer by using icons - see http://www.pgbuildfarm.org/cgi-bin/show_status4.pl for prgress. . the

Re: [HACKERS] Enhanced containment selectivity function

Matteo Beccati <[EMAIL PROTECTED]> writes: > Someone on IRC (AndrewSN if I'm not wrong) pointed out that the > restriction selectivity function for <@ is contsel, which returns a > constant value of 0.001. So I started digging in the source code trying > to understand how the default behaviour c

Re: [HACKERS] pg_dump -- data and schema only?

> Am Donnerstag, den 04.08.2005, 10:26 -0400 schrieb Mark Woodward: >> I haven't seen this option, and does anyone thing it is a good idea? >> >> A option to pg_dump and maybe pg_dump all, that dumps only the table >> declarations and the data. No owners, tablespace, nothing. >> >> This, I think, w

Re: [HACKERS] pg_dump -- data and schema only?

Am Donnerstag, den 04.08.2005, 10:26 -0400 schrieb Mark Woodward: > I haven't seen this option, and does anyone thing it is a good idea? > > A option to pg_dump and maybe pg_dump all, that dumps only the table > declarations and the data. No owners, tablespace, nothing. > > This, I think, would a

[HACKERS] US Census database (Tiger 2004FE) - 4.4G

It is 4.4G in space in a gzip package. I'll mail a DVD to two people who promise to host it for Hackers. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] Solving the OID-collision problem

> "Mark Woodward" <[EMAIL PROTECTED]> writes: >>> 2. Performance. Doing this would require widening Datum to 64 bits, >>> which is a system-wide performance hit on 32-bit machines. > >> Do you really think it would make a measurable difference, more so than >> your proposed solution? (I'm skeptica

Re: [HACKERS] Solving the OID-collision problem

"Mark Woodward" <[EMAIL PROTECTED]> writes: >> 2. Performance. Doing this would require widening Datum to 64 bits, >> which is a system-wide performance hit on 32-bit machines. > Do you really think it would make a measurable difference, more so than > your proposed solution? (I'm skeptical it wo

[HACKERS] Enhanced containment selectivity function

Hi, I've recently had problems with slow queries caused by the selectivity of the <@ ltree operator, as you may see in my post here: http://archives.postgresql.org/pgsql-performance/2005-07/msg00473.php Someone on IRC (AndrewSN if I'm not wrong) pointed out that the restriction selectivity

Re: [HACKERS] Solving the OID-collision problem

> "Mark Woodward" <[EMAIL PROTECTED]> writes: >> Why is there collision? It is because the number range of an OID is >> currently smaller than the possible usage. > > Expanding OIDs to 64 bits is not really an attractive answer, on several > grounds: > > 1. Disk space. I don't really see this as a

[HACKERS] pg_dump -- data and schema only?

I haven't seen this option, and does anyone thing it is a good idea? A option to pg_dump and maybe pg_dump all, that dumps only the table declarations and the data. No owners, tablespace, nothing. This, I think, would allow more generic PostgreSQL data transfers. ---(end

Re: [HACKERS] Solving the OID-collision problem

"Mark Woodward" <[EMAIL PROTECTED]> writes: > Why is there collision? It is because the number range of an OID is > currently smaller than the possible usage. Expanding OIDs to 64 bits is not really an attractive answer, on several grounds: 1. Disk space. 2. Performance. Doing this would requir

Re: [HACKERS] US Census database (Tiger 2004FE)

It's been running for about an hour now, and it is up to 3.3G. pg_dump tiger | gzip > tiger.pgz | bzip2 > tiger.sql.bz2 :) Chris ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/fa

Re: [HACKERS] US Census database (Tiger 2004FE)

>> It's been running for about an hour now, and it is up to 3.3G. >> >> pg_dump tiger | gzip > tiger.pgz > > | bzip2 > tiger.sql.bz2 :) > I find bzip2 FAR SLOWER than the gain in compression. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postm

Re: [HACKERS] Bug introduced by recent ALTER OWNER permissions check change

Stephen Frost <[EMAIL PROTECTED]> writes: > Does it really? I don't think so. If you have owner privileges on the > schema you can grant create rights to the role, then either ALTER OWNER > if the patch is kept or just change to the role, create table x as > select * from y;, etc, and then revoke

Re: [HACKERS] US Census database (Tiger 2004FE)

> * Mark Woodward ([EMAIL PROTECTED]) wrote: >> > How big dumped & compressed? I may be able to host it depending on >> how >> > big it ends up being... >> >> It's been running for about an hour now, and it is up to 3.3G. > > Not too bad. I had 2003 (iirc) loaded into 7.4 at one point. Cool. >

Re: [HACKERS] US Census database (Tiger 2004FE)

Am Donnerstag, den 04.08.2005, 08:40 -0400 schrieb Mark Woodward: > > * Mark Woodward ([EMAIL PROTECTED]) wrote: > >> I just finished converting and loading the US census data into > >> PostgreSQL > >> would anyone be interested in it for testing purposes? > >> > >> It's a *LOT* of data (about 40+

Re: [HACKERS] US Census database (Tiger 2004FE)

* Mark Woodward ([EMAIL PROTECTED]) wrote: > > How big dumped & compressed? I may be able to host it depending on how > > big it ends up being... > > It's been running for about an hour now, and it is up to 3.3G. Not too bad. I had 2003 (iirc) loaded into 7.4 at one point. > pg_dump tiger | gz

Re: [HACKERS] US Census database (Tiger 2004FE)

> * Mark Woodward ([EMAIL PROTECTED]) wrote: >> I just finished converting and loading the US census data into >> PostgreSQL >> would anyone be interested in it for testing purposes? >> >> It's a *LOT* of data (about 40+ Gig in PostgreSQL) > > How big dumped & compressed? I may be able to host it

Re: [HACKERS] US Census database (Tiger 2004FE)

* Mark Woodward ([EMAIL PROTECTED]) wrote: > I just finished converting and loading the US census data into PostgreSQL > would anyone be interested in it for testing purposes? > > It's a *LOT* of data (about 40+ Gig in PostgreSQL) How big dumped & compressed? I may be able to host it depending o

Re: [HACKERS] Solving the OID-collision problem

> I was reminded again today of the problem that once a database has been > in existence long enough for the OID counter to wrap around, people will > get occasional errors due to OID collisions, eg > > http://archives.postgresql.org/pgsql-general/2005-08/msg00172.php > > Getting rid of OID usage i

Re: [HACKERS] Bug introduced by recent ALTER OWNER permissions check change

* Tom Lane ([EMAIL PROTECTED]) wrote: > Stephen Frost <[EMAIL PROTECTED]> writes: > > I don't like this approach to solving the problem. I would rather see > > the check modified to allow the ownership change provided: > > > the user issueing the command has access to destination role > > AND > >

Re: [HACKERS] US Census database (Tiger 2004FE)

Wow! a lot of people seem to want it! I am dumping out with pg_dump right now, it may take a few hours. It is in PostgreSQL 8.0.3 Does anyone have access to a high bandwidth server? I could mail it on a DVD to someone who would host it. > > David Fetter wrote: > >>On Wed, Aug 03, 2005 at 05:00:16P

Re: [HACKERS] Fundamental error in "no WAL log" index/file

"Simon Riggs" <[EMAIL PROTECTED]> writes > > I have learnt that Tom means: read the code. :-) > > CREATE INDEX doesn't produce xlog records *except* when you use PITR, so > PITR does work correctly. > wstate.btws_use_wal = XLogArchivingActive() && !wstate.index->rd_istemp; Ah-oh, that's true

Re: [HACKERS] dbt3 data with 10GB scale factor

On Tue, 2005-08-02 at 14:22 -0700, Mark Wong wrote: > I've started scaling dbt3 up to the 10GB scale factor against CVS and > the fast COPY patch: > > http://www.testing.osdl.org/projects/dbt3testing/results/dev4-010/53/ Try "www1" if this URL fails for you. > I'm sure there are some better data