Re: [HACKERS] [PATCHES] pgstattuple extension for indexes

2006-07-28 Thread satoshi nagayasu
Hi folks, As I said on -PATCHES, I've been working on an utility to get a b-tree index information. I'm happy to introduce my new functions to you. pgstattuple module provides a `pgstatindex()`, and other small functions, which allow you to get b-tree internal information. I believe this module

Re: [HACKERS] GUC with units, details

2006-07-28 Thread Peter Eisentraut
Tom Lane wrote: If that actually worked, it'd be one thing, but it doesn't work and isn't going to do so in 8.2. So I think people will indeed be trying to use setting || unit for display purposes. In any case 8kB isn't a valid unit. I thought we set SHOW ALL aside for display purposes and

Re: [HACKERS] [PATCHES] extension for sql update

2006-07-28 Thread Susanne Ebrecht
Am Donnerstag, den 27.07.2006, 08:30 -0400 schrieb Tom Lane: Susanne Ebrecht [EMAIL PROTECTED] writes: ... We could provide the mixed update syntax and leave the typed row value expression for the next release. Do you agree? I don't really see the point --- the patch won't provide any new

Re: [HACKERS] [PATCHES] putting CHECK_FOR_INTERRUPTS in qsort_comparetup()

2006-07-28 Thread Charles Duffy
On 7/15/06, Tom Lane [EMAIL PROTECTED] wrote: Anyway, Qingqing's question still needs to be answered: how can a sort of under 30k items take so long? It happens because (as previously suggested by Tom) the dataset for the 'short' (~10k rows, .3 sec) sort has no rows whose leftmost fields

Re: [HACKERS] The vacuum-ignore-vacuum patch

2006-07-28 Thread Hannu Krosing
Ühel kenal päeval, N, 2006-07-27 kell 22:05, kirjutas Bruce Momjian: Another idea Jan had today was whether we could vacuum more rows if a long-running backend is in serializable mode, like pg_dump. I don't see how this gives us ability to vacuum more rows, as the snapshot of a serializable

[HACKERS] request: support of array in plperl OUT arguments

2006-07-28 Thread Pavel Stehule
Hello, I miss better support OUT arguments in plerlu: create or replace function foo(out p varchar[]) as $$ return { p = [pavel, jana] }; $$ language plperlu; postgres=# select foo(); ERROR: array value must start with { or dimension information postgres=# I starting work on it. I hope It

[HACKERS] LWLock statistics collector (was: CSStorm occurred again by postgreSQL8.2)

2006-07-28 Thread ITAGAKI Takahiro
Hi hackers, I tackled the performance problem on SUBTRANS module with Okano. He and I reach a conclusion that SubTrans log is heavily read on a specific access pattern in my TPC-W implementation. There seems to be awful traffic on SUBTRANS to check visivility of tuples in

Re: [HACKERS] GUC with units, details

2006-07-28 Thread Hannu Krosing
Ühel kenal päeval, N, 2006-07-27 kell 01:03, kirjutas Tom Lane: Michael Glaesemann [EMAIL PROTECTED] writes: I've seen this mentioned a couple of times. I'm not nearly as familiar with these settings as I should be, but it seems to me that if the memory size *does* need to be a integral

[HACKERS] [Fwd: RE: Build farm on Windows]

2006-07-28 Thread Andrew Dunstan
Can one of the Windows buildfarm owners please try building and running make check by hand rather than using the buildfarm script? It looks like they all stopped reporting around the same time, and this might give us a better clue about when things fall over. Also, if you're up for it,

Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]

2006-07-28 Thread Stefan Kaltenbrunner
Andrew Dunstan wrote: Can one of the Windows buildfarm owners please try building and running make check by hand rather than using the buildfarm script? It looks like they all stopped reporting around the same time, and this might give us a better clue about when things fall over. Also,

Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]

2006-07-28 Thread Andrew Dunstan
Stefan Kaltenbrunner wrote: Andrew Dunstan wrote: Can one of the Windows buildfarm owners please try building and running make check by hand rather than using the buildfarm script? It looks like they all stopped reporting around the same time, and this might give us a better clue about

Re: [HACKERS] Better name/syntax for online index creation

2006-07-28 Thread Paul Silveira
I really like the CREATE INDEX CONCURRENTLY suggestion that I've seem in this thread. That seems like a good alternative to ONLINE and is very easy to understand. Regards, Paul -- View this message in context:

Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]

2006-07-28 Thread Andrew Dunstan
The TimeZone changes are looking might suspicious ... cheers andrew Stefan Kaltenbrunner wrote: Andrew Dunstan wrote: Can one of the Windows buildfarm owners please try building and running make check by hand rather than using the buildfarm script? It looks like they all stopped

Re: [HACKERS] [PATCHES] putting CHECK_FOR_INTERRUPTS in qsort_comparetup()

2006-07-28 Thread Tom Lane
Charles Duffy [EMAIL PROTECTED] writes: ... For the 'long' data, the compare moves on rightward until it encounters 'flato', which is a TEXT column with an average length of 7.5k characters (with some rows up to 400k). The first 6 columns are mostly INTEGER, so compares on them are relatively

Re: [HACKERS] [PATCHES] pgstattuple extension for indexes

2006-07-28 Thread Bruce Momjian
I thought these new functions were going to be merged into /contrib/pgstattuple. --- satoshi nagayasu wrote: Hi folks, As I said on -PATCHES, I've been working on an utility to get a b-tree index information. I'm happy

Re: [HACKERS] The vacuum-ignore-vacuum patch

2006-07-28 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Good question. Imagine you have a serializable transaction like pg_dump, and then you have lots of newer transactions. If pg_dump is xid=12, and all the new transactions start at xid=30, any row created and expired between 12 and 30 can be removed

Re: [HACKERS] The vacuum-ignore-vacuum patch

2006-07-28 Thread Bruce Momjian
Hannu Krosing wrote: ?hel kenal p?eval, N, 2006-07-27 kell 22:05, kirjutas Bruce Momjian: Another idea Jan had today was whether we could vacuum more rows if a long-running backend is in serializable mode, like pg_dump. I don't see how this gives us ability to vacuum more rows, as the

Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]

2006-07-28 Thread Tom Lane
I wrote: Andrew Dunstan [EMAIL PROTECTED] writes: The TimeZone changes are looking might suspicious ... FATAL: failed to initialize timezone_abbreviations to Default Hm. It looks like this is working in the postmaster but failing in subprocesses. I'll see if I can duplicate it using

Re: [HACKERS] Re: [hackers-jp: 219] Re: postgresql-8.1.4文字セットサポート

2006-07-28 Thread Tom Lane
I wrote: Michael Glaesemann [EMAIL PROTECTED] writes: Just to confirm, it does look like there's a discrepancy between what is in the documentation and the actual behavior of the server. The documentation indicates that SJIS is a valid server encoding: This is a documentation error ---

[HACKERS] facing problem while using CVS

2006-07-28 Thread Saurabh Vyas
Hi All, I am facing problem while using CVS. I am working on Solaris 10 and trying to fetch source code of Postgres as Anonymous CVS as follows : /$ cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot login / (url : http://developer.postgresql.org/docs/postgres/anoncvs.html

Re: [HACKERS] The vacuum-ignore-vacuum patch

2006-07-28 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Good question. Imagine you have a serializable transaction like pg_dump, and then you have lots of newer transactions. If pg_dump is xid=12, and all the new transactions start at xid=30, any row created and expired between 12 and

Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]

2006-07-28 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: The TimeZone changes are looking might suspicious ... FATAL: failed to initialize timezone_abbreviations to Default Hm. It looks like this is working in the postmaster but failing in subprocesses. I'll see if I can duplicate it using EXEC_BACKEND.

[HACKERS] Attack against postgresql.org ...

2006-07-28 Thread Marc G. Fournier
There are some days where High Speed Internet for Personal use just should never have been invented ... Over the past 24 hours, we've been experiencing a problem with the network that has taken us a bit to identify as being at our end, and a little bit longer to identify as being with the

Re: [HACKERS] [CORE] Attack against postgresql.org ...

2006-07-28 Thread Tom Lane
Marc G. Fournier [EMAIL PROTECTED] writes: The attacking IP, from the logs, appears to be 87.230.6.96 ... Perhaps a complaint to their ISP is in order --- RIPE suggests [EMAIL PROTECTED] regards, tom lane ---(end of

Re: [HACKERS] The vacuum-ignore-vacuum patch

2006-07-28 Thread Alvaro Herrera
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: Uh, why? Because it's used to determine the Xmin that our vacuum will use. If there is a transaction whose Xmin calculation included the Xid of a transaction running vacuum, we have gained nothing from directly

Re: [HACKERS] [CORE] Attack against postgresql.org ...

2006-07-28 Thread Csaba Nagy
On Fri, 2006-07-28 at 17:37, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: The attacking IP, from the logs, appears to be 87.230.6.96 ... Perhaps a complaint to their ISP is in order --- RIPE suggests [EMAIL PROTECTED] That looks 1 level too high, the immediate source seems to

Re: [HACKERS] The vacuum-ignore-vacuum patch

2006-07-28 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: Uh, why? Because it's used to determine the Xmin that our vacuum will use. If there is a transaction whose Xmin calculation included the Xid of a transaction running vacuum, we have gained nothing from directly excluding said

Re: [HACKERS] The vacuum-ignore-vacuum patch

2006-07-28 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: But the patch changes things so that *everyone* excludes the vacuum from their xmin. Or at least I thought that was the plan. We shouldn't do that, because that Xmin is also used to truncate SUBTRANS. Yeah, but you were going to

Re: [HACKERS] Re: [hackers-jp: 219] Re: postgresql-8.1 .4文字セット サポート

2006-07-28 Thread Michael Glaesemann
On Jul 29, 2006, at 0:20 , Tom Lane wrote: I'm going to change that text, and also add a column to table 21-1 marking the supported server encodings. Thanks, Tom. Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 1: if

Re: [HACKERS] GUC with units, details

2006-07-28 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane wrote: If that actually worked, it'd be one thing, but it doesn't work and isn't going to do so in 8.2. So I think people will indeed be trying to use setting || unit for display purposes. In any case 8kB isn't a valid unit. I thought we

Re: [HACKERS] Re: [hackers-jp: 219] Re: postgresql-8.1.4文字セットサポート

2006-07-28 Thread Tom Lane
Michael Glaesemann [EMAIL PROTECTED] writes: Just to confirm, it does look like there's a discrepancy between what is in the documentation and the actual behavior of the server. The documentation indicates that SJIS is a valid server encoding: This is a documentation error --- SJIS is

Re: [HACKERS] [CORE] Attack against postgresql.org ...

2006-07-28 Thread D'Arcy J.M. Cain
On Fri, 28 Jul 2006 17:51:11 +0200 Csaba Nagy [EMAIL PROTECTED] wrote: Perhaps a complaint to their ISP is in order --- RIPE suggests [EMAIL PROTECTED] That looks 1 level too high, the immediate source seems to be http://www.ehost.pl/onas.php I would go to both. ehost.pl could very well

Re: [HACKERS] Role incompatibilities

2006-07-28 Thread Clark C. Evans
Sorry to ressurect this thread. However, I've been playing with the new role system and I'd prefer to keep CURRENT_USER as the login user, and not making it a synonymn for CURRENT_ROLE. In my application, I love the ability to shed privleges by SET ROLE dataentry;. However, I need CURRENT_USER

Re: [HACKERS] GUC with units, details

2006-07-28 Thread Jim C. Nasby
On Fri, Jul 28, 2006 at 01:03:00AM +0200, Peter Eisentraut wrote: Accepting page (or block?) as a unit might be a reasonable You hit on something that's always irked me a bit... we tend to toss out 'page' and 'block' (and sometimes even 'buffer') randomly when referring to different things that

Re: [HACKERS] Role incompatibilities

2006-07-28 Thread Stephen Frost
* Clark C. Evans ([EMAIL PROTECTED]) wrote: Sorry to ressurect this thread. However, I've been playing with the new role system and I'd prefer to keep CURRENT_USER as the login user, and not making it a synonymn for CURRENT_ROLE. In my application, I love the ability to shed privleges by SET

Re: [HACKERS] Hash indexes (was: On-disk bitmap index patch)

2006-07-28 Thread Jim C. Nasby
On Thu, Jul 27, 2006 at 01:46:01PM -0400, Alvaro Herrera wrote: Jim Nasby wrote: On Jul 25, 2006, at 3:31 PM, Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: What would be the use-case for hash indexes ? And what should be done to make them faster than btree ? If we knew,

Re: [HACKERS] On-disk bitmap index patch

2006-07-28 Thread Jim C. Nasby
On Thu, Jul 27, 2006 at 09:13:21AM -0700, Jie Zhang wrote: On 7/26/06 11:50 PM, Tom Lane [EMAIL PROTECTED] wrote: Jie Zhang [EMAIL PROTECTED] writes: On 7/26/06 10:14 PM, Tom Lane [EMAIL PROTECTED] wrote: ... A nonuniform distribution would probably mean that some of the bitmaps compress

Re: [HACKERS] [CORE] Attack against postgresql.org ...

2006-07-28 Thread Marc G. Fournier
I have email'd both, thanks ... On Fri, 28 Jul 2006, Csaba Nagy wrote: On Fri, 2006-07-28 at 17:37, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: The attacking IP, from the logs, appears to be 87.230.6.96 ... Perhaps a complaint to their ISP is in order --- RIPE suggests

Re: [HACKERS] [PATCHES] pgstattuple extension for indexes

2006-07-28 Thread Alvaro Herrera
Bruce Momjian wrote: I thought these new functions were going to be merged into /contrib/pgstattuple. Well, that's exactly what this patch seems to do ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.

Re: [HACKERS] [PATCHES] pgstattuple extension for indexes

2006-07-28 Thread Bruce Momjian
Alvaro Herrera wrote: Bruce Momjian wrote: I thought these new functions were going to be merged into /contrib/pgstattuple. Well, that's exactly what this patch seems to do ... Well, looking at the tarball it puts everything in pgstatindex, and the Makefile is:

Re: [HACKERS] [PATCHES] Resurrecting per-page cleaner for btree

2006-07-28 Thread Jim C. Nasby
On Thu, Jul 27, 2006 at 05:24:35PM -0400, Greg Stark wrote: Jim Nasby [EMAIL PROTECTED] writes: Even if we stopped right there it would still be a huge win in many (most?) cases. How often do the indexes on a table comprise even 50% of the table's size? I would say they're usually

Re: [HACKERS] The vacuum-ignore-vacuum patch

2006-07-28 Thread Jim C. Nasby
On Fri, Jul 28, 2006 at 03:08:08AM +0300, Hannu Krosing wrote: The other POV is that we don't really care about long-running transaction in other databases unless they are lazy vacuum, a case which is appropiately covered by the patch as it currently stands. This seems to be the POV that

Re: [HACKERS] Do we need multiple forms of the SQL2003 statistics aggregates?

2006-07-28 Thread Tom Lane
I wrote: There is room to argue that the numeric-arithmetic version would be worth having on the grounds of greater precision or range, but it's a big chunk of code and the public demand for the functionality has not exactly been overwhelming. Comments? Since no one's even bothered to

[HACKERS] A couple remarks on TODO

2006-07-28 Thread Tom Lane
TODO has an entry o Allow UPDATE to handle complex aggregates [update]? which I think is now obsolete, because we've settled on rejecting aggregates at the top level of UPDATE, as the spec tells us to do. Also, there's one remaining unfinished feature in the multi-argument aggregate

Re: [HACKERS] A couple remarks on TODO

2006-07-28 Thread Bruce Momjian
Thanks, done. --- Tom Lane wrote: TODO has an entry o Allow UPDATE to handle complex aggregates [update]? which I think is now obsolete, because we've settled on rejecting aggregates at the top level of

Re: [HACKERS] Role incompatibilities

2006-07-28 Thread Tom Lane
Clark C. Evans [EMAIL PROTECTED] writes: Sorry to ressurect this thread. However, I've been playing with the new role system and I'd prefer to keep CURRENT_USER as the login user, and not making it a synonymn for CURRENT_ROLE. In my application, I love the ability to shed privleges by SET

Re: [HACKERS] The vacuum-ignore-vacuum patch

2006-07-28 Thread Chris Browne
[EMAIL PROTECTED] (Jim C. Nasby) writes: There are other transactions to consider: user transactions that will run a long time, but only hit a limited number of relations. These are as big a problem in an OLTP environment as vacuum is. Rather than coming up with machinery that will

Re: [HACKERS] Hash indexes (was: On-disk bitmap index patch)

2006-07-28 Thread Alvaro Herrera
Jim C. Nasby wrote: What I'm getting at is that I've never seen any explanation for the theoretical use cases where a hash index would outperform a btree. If we knew what kind of problems hash indexes were supposed to solve, we could try and interest people who are solving those kinds of

Re: [HACKERS] On-disk bitmap index patch

2006-07-28 Thread Luke Lonergan
Jim, On 7/28/06 10:17 AM, Jim C. Nasby [EMAIL PROTECTED] wrote: If the usefulness of bitmap indexes is still in doubt, could someone at Greenplum provide data from actual data warehouses from actual customers? First, is anyone in doubt? - Luke ---(end of

Re: [HACKERS] On-disk bitmap index patch

2006-07-28 Thread Bruce Momjian
Luke Lonergan wrote: Jim, On 7/28/06 10:17 AM, Jim C. Nasby [EMAIL PROTECTED] wrote: If the usefulness of bitmap indexes is still in doubt, could someone at Greenplum provide data from actual data warehouses from actual customers? First, is anyone in doubt? Sure. I think we are

Re: [HACKERS] Hash indexes (was: On-disk bitmap index patch)

2006-07-28 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: The btree index needs to descend potentially many pages before getting to the leaf page, where the actual index is stored. The hash index can get at the leaf node in --supposedly-- one fetch. Btree is O(logN) to get a single key, while hash is O(1).

Re: [HACKERS] Hash indexes (was: On-disk bitmap index patch)

2006-07-28 Thread Jim C. Nasby
On Fri, Jul 28, 2006 at 03:14:33PM -0400, Alvaro Herrera wrote: Jim C. Nasby wrote: What I'm getting at is that I've never seen any explanation for the theoretical use cases where a hash index would outperform a btree. If we knew what kind of problems hash indexes were supposed to solve,

Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]

2006-07-28 Thread Stefan Kaltenbrunner
Tom Lane wrote: I wrote: Andrew Dunstan [EMAIL PROTECTED] writes: The TimeZone changes are looking might suspicious ... FATAL: failed to initialize timezone_abbreviations to Default Hm. It looks like this is working in the postmaster but failing in subprocesses. I'll see if I can

Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]

2006-07-28 Thread Tom Lane
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: I get a much more useful: WARNING: could not read time zone file Default: No such file or directory FATAL: failed to initialize timezone_abbreviations to Default Hm, but why would the file not be there? Try hacking it to print the whole path

Re: [HACKERS] lastval exposes information that currval does not

2006-07-28 Thread Martijn van Oosterhout
On Thu, Jul 27, 2006 at 09:37:22PM -0400, Stephen Frost wrote: Got any others beyond 'lastval'? Is 'lastval' even doing what you're claiming (looking at the actual catalog on disk by using the OID)? My recollection was that it was actually just storing the value in a bit of backend-local

Re: [PATCHES] [HACKERS] pg_regress breaks on msys

2006-07-28 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: I checked on MinGW and system() just returns the value returned by the application. There isn't any special two-values-in-one layering like is done on Unix for wait() and the return value from system(). It seems if the child dies from a signal, the

Re: [PATCHES] [HACKERS] pg_regress breaks on msys

2006-07-28 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I checked on MinGW and system() just returns the value returned by the application. There isn't any special two-values-in-one layering like is done on Unix for wait() and the return value from system(). It seems if the child dies

Re: [PATCHES] [HACKERS] pg_regress breaks on msys

2006-07-28 Thread Bruce Momjian
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I checked on MinGW and system() just returns the value returned by the application. There isn't any special two-values-in-one layering like is done on Unix for wait() and the return value from system(). It

Re: [HACKERS] On-disk bitmap index patch

2006-07-28 Thread Dann Corbit
-Original Message- From: [EMAIL PROTECTED] [mailto:pgsql-hackers- [EMAIL PROTECTED] On Behalf Of Luke Lonergan Sent: Friday, July 28, 2006 12:18 PM To: Jim C. Nasby; Jie Zhang Cc: Tom Lane; Mark Kirkwood; Josh Berkus; Gavin Sherry; pgsql- [EMAIL PROTECTED] Subject: Re: [HACKERS]

Re: [PATCHES] [HACKERS] pg_regress breaks on msys

2006-07-28 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: The cases that I think we most need to defend against are (A) diff program not found In summary, on MinGW, files differ or 'diff' not found, returns 1. If one of the files to be compared does not exist, it returns 2. And of course,

Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]

2006-07-28 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: I get a much more useful: WARNING: could not read time zone file Default: No such file or directory FATAL: failed to initialize timezone_abbreviations to Default Hm, but why would the file not be there? Try hacking it to

Re: [HACKERS] On-disk bitmap index patch

2006-07-28 Thread Tom Lane
Dann Corbit [EMAIL PROTECTED] writes: Others have looked into the usefulness of bitmap indexes. Here is what they found: http://www.oracle.com/technology/pub/articles/sharma_indexes.html I like this guy's style of argument: he admits a bitmap index on a unique column will be much bigger than

Re: [HACKERS] On-disk bitmap index patch

2006-07-28 Thread Bruce Momjian
What we don't want to happen is for us to release bitmapped indexes, and find out later that btree is better in all cases. Then we have to tell people not to use bitmapped indexes until we fix it in the next major releasse. FYI, that is basically where we are right now with hash indexes.

Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]

2006-07-28 Thread Tom Lane
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: WARNING: could not read time zone file /home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default: No such file or directory $ ls -l /home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default -rw-r--r--1 pgbuild Administ

Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]

2006-07-28 Thread Andrew Dunstan
Stefan Kaltenbrunner wrote: WARNING: could not read time zone file /home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default: No such file or directory This is an MSys virtual path, of which postgres naturally knows nothing.We should have made the appropriate calls to turn it into

Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]

2006-07-28 Thread Tom Lane
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: WARNING: could not read time zone file /home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default: No such file or directory so it's there but as a msys-virtual path - is that get passed to some win32 function expecting a windows-style

Re: [HACKERS] lastval exposes information that currval does not

2006-07-28 Thread Phil Frost
On Fri, Jul 28, 2006 at 09:54:38PM +0200, Martijn van Oosterhout wrote: Not the least of which is that arguments involving people can install C code into the backend and break security are truisms: installed C code can do *anything* which is why only superusers can install such functions...

Re: [HACKERS] lastval exposes information that currval does not

2006-07-28 Thread Alvaro Herrera
Phil Frost wrote: Again, fix is really simple. Document the issue, making it damn clear in the docs that the schema usage check means *nothing* when accessing an object by OID, and advising users that the ways to access things by OID are obscure but present and changing, so relying on the

[HACKERS] SubPostmasterMain startup should be a critical section?

2006-07-28 Thread Tom Lane
Now that we've isolated the reason why regression tests are failing on the Windows buildfarm members, it seems to me that there's a systemic problem as well as the immediate bug. The problem is that guc.c is doing an elog(ERROR) during InitializeGucOptions in postmaster children, which ends up

Re: [HACKERS] lastval exposes information that currval does not

2006-07-28 Thread Martijn van Oosterhout
On Fri, Jul 28, 2006 at 04:42:11PM -0400, Phil Frost wrote: Again, fix is really simple. Document the issue, making it damn clear in the docs that the schema usage check means *nothing* when accessing an object by OID, and advising users that the ways to access things by OID are obscure but

Re: [HACKERS] [PATCHES] [PATCH] Provide 8-byte transaction IDs to user level

2006-07-28 Thread Marko Kreen
On 7/27/06, Darcy Buskermolen [EMAIL PROTECTED] wrote: In one of those 3am lightbulbs I belive I have a way to make use of the 64-bit XID counter and still maintain the ability to have backwards compatibility. Is there any chance you could break this patch up into the 2 separate componenets that

Re: [HACKERS] On-disk bitmap index patch

2006-07-28 Thread Luke Lonergan
Bruce, On 7/28/06 1:25 PM, Bruce Momjian [EMAIL PROTECTED] wrote: What we don't want to happen is for us to release bitmapped indexes, and find out later that btree is better in all cases. Then we have to tell people not to use bitmapped indexes until we fix it in the next major releasse.

Re: [HACKERS] The vacuum-ignore-vacuum patch

2006-07-28 Thread Hannu Krosing
Ühel kenal päeval, R, 2006-07-28 kell 12:38, kirjutas Jim C. Nasby: On Fri, Jul 28, 2006 at 03:08:08AM +0300, Hannu Krosing wrote: The other POV is that we don't really care about long-running transaction in other databases unless they are lazy vacuum, a case which is appropiately

[HACKERS] DTrace enabled build fails

2006-07-28 Thread Peter Eisentraut
/usr/sbin/dtrace -G -s utils/probes.d access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o

Re: [HACKERS] On-disk bitmap index patch

2006-07-28 Thread Andrew Dunstan
Tom Lane wrote: Both of these pages say up front that they are considering read-only data. So one of the questions that has to be answered (and the submitters have been entirely mum about) is exactly how bad is the update performance? If it's really awful that's going to constrain the use

Re: [HACKERS] The vacuum-ignore-vacuum patch

2006-07-28 Thread Jim Nasby
On Jul 28, 2006, at 5:05 PM, Hannu Krosing wrote: Ühel kenal päeval, R, 2006-07-28 kell 12:38, kirjutas Jim C. Nasby: There are other transactions to consider: user transactions that will run a long time, but only hit a limited number of relations. These are as big a problem in an OLTP

Re: [HACKERS] On-disk bitmap index patch

2006-07-28 Thread Hannu Krosing
Ühel kenal päeval, R, 2006-07-28 kell 16:18, kirjutas Tom Lane: Dann Corbit [EMAIL PROTECTED] writes: Others have looked into the usefulness of bitmap indexes. Here is what they found: http://www.oracle.com/technology/pub/articles/sharma_indexes.html I like this guy's style of argument:

Re: [HACKERS] On-disk bitmap index patch

2006-07-28 Thread Hannu Krosing
Ühel kenal päeval, R, 2006-07-28 kell 16:25, kirjutas Bruce Momjian: What we don't want to happen is for us to release bitmapped indexes, and find out later that btree is better in all cases. Actually I'd love it if adding bitmap indexes to core pg would magically make btree several times

Re: [HACKERS] pg_dump: add option to ignore TABLE DATA for failed

2006-07-28 Thread Bruce Momjian
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. ---

[HACKERS] Formulating an sql query with CTID

2006-07-28 Thread Tzahi Fadida
Hi, I have a query i am having trouble to formulate: I used to do: SELECT DISTINCT a0,a1 FROM public.t1 However, now i need to add the CTID attribute, but CTID is unique thus, distinct is useless. In addition, i can't seem to be able to use max() etc... or casting to anything on CTID in order to

Re: [HACKERS] DTrace enabled build fails

2006-07-28 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes: Does it not like static functions? I seem to recall Robert mentioning that they'd only recently fixed DTrace to cope with probes in static functions. Maybe you need to get an update? regards, tom lane

Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]

2006-07-28 Thread Andrew Dunstan
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: WARNING: could not read time zone file /home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default: No such file or directory so it's there but as a msys-virtual path - is that get passed to some win32 function

Re: [HACKERS] The vacuum-ignore-vacuum patch

2006-07-28 Thread Alvaro Herrera
Jim Nasby wrote: On Jul 28, 2006, at 5:05 PM, Hannu Krosing wrote: So instead of actually *solving* one problem you suggest *thinking* about solving the general case ? We have been *thinking* about dead-space-map for at least three years by now. No, I just wanted anyone who was actually

Re: [HACKERS] The vacuum-ignore-vacuum patch

2006-07-28 Thread Alvaro Herrera
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: But the patch changes things so that *everyone* excludes the vacuum from their xmin. Or at least I thought that was the plan. We shouldn't do that, because that Xmin is also used to truncate SUBTRANS. Yeah,

Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]

2006-07-28 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: Is there a reason we have to do things in this order? Could we just postpone the call to InitializeGUCOptions() for a couple of lines? Maybe, but I'm disinclined to mess with that. I have a patch that makes it work like TimeZone, but am having

Re: [HACKERS] Possible explanation for Win32 stats regression test

2006-07-28 Thread Bruce Momjian
Is anyone working on this? --- Tom Lane wrote: korry [EMAIL PROTECTED] writes: The problem is that, each time you go through pgwin32_waitforsinglesocket(), you tie the *same* kernel object (waitevent is static) to

Re: [HACKERS] On-disk bitmap index patch

2006-07-28 Thread mark
On Fri, Jul 28, 2006 at 02:43:23PM -0700, Luke Lonergan wrote: On 7/28/06 1:25 PM, Bruce Momjian [EMAIL PROTECTED] wrote: What we don't want to happen is for us to release bitmapped indexes, and find out later that btree is better in all cases. Then we have to tell people not to use

Re: [HACKERS] On-disk bitmap index patch

2006-07-28 Thread Luke Lonergan
Mark, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 9:26 PM But irrefutable? Irrefutable is not true. :-) How about unrefuted. The evidence has not been refuted, and not directly discussed or discounted. BTREE can not be