Re: [HACKERS] Why we still see some reports of "could not access transaction status"

2004-10-13 Thread Michael Paesold
Tom Lane wrote: Having seen a couple recent reports of "could not access status of transaction" for old, not-obviously-corrupt transaction numbers, I went looking to see if I could find a way that the system could truncate CLOG before it's really marked all occurrences of old transaction numbers as

Re: [HACKERS] Two-phase commit security restrictions

2004-10-13 Thread Oliver Jowett
David Garamond wrote: So it is possible for a user connected to the DB to send random commit or cancel commands, just in case she happens to hit a valid GID? It is not essentially different from someone trying to bruteforce a password. A 128bit value like a random GUID is as strong as a 16 char

Re: [HACKERS] Two-phase commit security restrictions

2004-10-13 Thread David Garamond
Alvaro Herrera wrote: Another approach I've been thinking about is to allow anyone that knows the (user-supplied) global transaction identifier to finish the transaction, and hide the gids of running transactions from regular users. That way, the gid acts as a secret token that's only known by t

Re: [HACKERS] implementing another hash join...

2004-10-13 Thread Tom Lane
Martha Chronopoulou <[EMAIL PROTECTED]> writes: > Im new to postgres and I'm about to implement the algorithm "double > pipelined hash join". I've started using SPI functions but soon I > realised that I 'm not at the right way (am I?). Not even close. You need to be implementing new executor

[HACKERS] implementing another hash join...

2004-10-13 Thread Martha Chronopoulou
Hi, Im new to postgres and I'm about to implement the algorithm "double pipelined hash join". I've started using SPI functions but soon I realised that I 'm not at the right way (am I?). Is there a way that I'm not obliged to change code of the optimizer of postgres but to write a seperate c

Re: [HACKERS] Two-phase commit security restrictions

2004-10-13 Thread Josh Berkus
Heikki, > Another approach I've been thinking about is to allow anyone that knows > the (user-supplied) global transaction identifier to finish the > transaction, and hide the gids of running transactions from regular users. > That way, the gid acts as a secret token that's only known by the > tra

Re: [HACKERS] Two-phase commit security restrictions

2004-10-13 Thread Oliver Jowett
Heikki Linnakangas wrote: Another approach I've been thinking about is to allow anyone that knows the (user-supplied) global transaction identifier to finish the transaction, and hide the gids of running transactions from regular users. That way, the gid acts as a secret token that's only known

Re: [HACKERS] more dirmod CYGWIN

2004-10-13 Thread Bruce Momjian
So those URL's are all fixed? Would you post your remaining failures? --- Reini Urban wrote: > Bruce Momjian schrieb: > > Great, just glad we could get it all working. ... > > Just that regression suite stopped working a w

Re: [HACKERS] Two-phase commit security restrictions

2004-10-13 Thread Heikki Linnakangas
On Wed, 13 Oct 2004, Peter Eisentraut wrote: Heikki Linnakangas wrote: What kind of security restrictions do we want for prepared transactions? Who has the right to finish a transaction that was started by user A? At least the original user, I suppose, but who else? Do we not require transaction in

Re: [HACKERS] Two-phase commit security restrictions

2004-10-13 Thread Peter Eisentraut
Heikki Linnakangas wrote: > What kind of security restrictions do we want for prepared > transactions? Who has the right to finish a transaction that was > started by user A? At least the original user, I suppose, but who > else? Do we not require transaction initiation and conclusion to happen in

Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore

2004-10-13 Thread Magnus Hagander
>> > > > OK, I have applied the following patch that uses Cygwin native >> > > > symlink() instead of the Win32 junctions. The reason >for this is >> > > > that Cygwin symlinks work on Win95/98/ME where >junction points do >> > > > not >> > > >> > > Is this really a Win95/98/ME vs NT distinc

Re: [HACKERS] Two-phase commit security restrictions

2004-10-13 Thread Alvaro Herrera
On Wed, Oct 13, 2004 at 11:58:21PM +0700, David Garamond wrote: > Heikki Linnakangas wrote: > >Another approach I've been thinking about is to allow anyone that knows > >the (user-supplied) global transaction identifier to finish the > >transaction, and hide the gids of running transactions from

Re: [HACKERS] Hypothetical Indexes

2004-10-13 Thread Josh Berkus
Marcos, > Â http://www.inf.puc-rio.br/~postgresql/ > > Â There you will find a link to a tutorial based description of the > hypothetical indexes feature we have implemented on PostgreSQL 7.4 > beta 3. I would love to see this as an add-in project on pgFoundry. Particularly since your online "

Re: [HACKERS] plans for bitmap indexes?

2004-10-13 Thread Tom Lane
Josh Berkus <[EMAIL PROTECTED]> writes: > BTW, Tom, I was talking to Sean last night and he was saying that our > current planner cost calculations assume that a 2-column index fetch > will be twice as expensive as a 1-column index fetch. Is this right? No. regards, tom l

Re: [HACKERS] plans for bitmap indexes?

2004-10-13 Thread Josh Berkus
Andreas, > I think bitmap indexes do have valid use cases, but partitioned indexes > are really a wonderful feature with a lot of use cases, Sure, no question. That's why we have them. > maybe including > this one. Nope, not at all. > Workable examples for useful partitioned indexes, that h

Re: [HACKERS] Two-phase commit security restrictions

2004-10-13 Thread David Garamond
Heikki Linnakangas wrote: What kind of security restrictions do we want for prepared transactions? Who has the right to finish a transaction that was started by user A? At least the original user, I suppose, but who else? Under what account is the transaction manager typically going to run? A s

Re: [HACKERS] Two-phase commit security restrictions

2004-10-13 Thread Tom Lane
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > What kind of security restrictions do we want for prepared transactions? > Who has the right to finish a transaction that was started by user A? At > least the original user, I suppose, but who else? I would say the original user, any superuser, a

[HACKERS] Why we still see some reports of "could not access transaction status"

2004-10-13 Thread Tom Lane
Having seen a couple recent reports of "could not access status of transaction" for old, not-obviously-corrupt transaction numbers, I went looking to see if I could find a way that the system could truncate CLOG before it's really marked all occurrences of old transaction numbers as known-dead or k

[HACKERS] Two-phase commit security restrictions

2004-10-13 Thread Heikki Linnakangas
What kind of security restrictions do we want for prepared transactions? Who has the right to finish a transaction that was started by user A? At least the original user, I suppose, but who else? Under what account is the transaction manager typically going to run? A separate TM account perhaps

Re: [HACKERS] more dirmod CYGWIN

2004-10-13 Thread Reini Urban
Bruce Momjian schrieb: Great, just glad we could get it all working. ... Just that regression suite stopped working a while ago :( That's by far more serious than the tiny build patches. http://archives.postgresql.org/pgsql-hackers/2004-09/msg00252.php http://archives.postgresql.org/pgsql-hackers/2

Re: [HACKERS] plans for bitmap indexes?

2004-10-13 Thread Tom Lane
"Zeugswetter Andreas DAZ SD" <[EMAIL PROTECTED]> writes: > Workable examples for useful partitioned indexes, that help here are: > create index people_male_ix on people (city) where gender = 'male'; > create index people_gay_ix on people (city) where orientation = 'gay'; > create index people_male

Re: [HACKERS] more dirmod CYGWIN

2004-10-13 Thread Reini Urban
Bruce Momjian schrieb: I have added the attached patch to allow Cygwin /contrib compiles. I am a little confused why Cygwin requires -lpgport and no other platform does, but it is in the Cygwin-specific section so we can always improve it later if we find the cause. thanks. duplicate does not harm

Re: [HACKERS] plans for bitmap indexes?

2004-10-13 Thread Reini Urban
Josh Berkus schrieb: The most nearly comparable thing is be the notion of "partial indexes," where, supposing you had 60 region codes (e.g. - 50 US states, 10 Canadian provinces), you might set up indices thus: I'm afraid that you're mistaken about the functionality of bitmap indexes. The purpos

Re: [CYGWIN] [HACKERS] open item: tablespace handing in pg_dump/pg_restore

2004-10-13 Thread Reini Urban
Leeuw van der, Tim schrieb: There are certainly cygwin-users trying out PostgreSQL on cygwin on WinXX. If the newest cygwin-version will suddenly stop working under WinXX, they will not be happy. That's why we use cygwin symlinks, not junctions. I've given consideration to the argument that you can

Re: [HACKERS] plans for bitmap indexes?

2004-10-13 Thread Hannu Krosing
On K, 2004-10-13 at 00:09, Greg Stark wrote: > Josh Berkus <[EMAIL PROTECTED]> writes: > > > SELECT * FROM people WHERE orientation = 'gay' AND gender = 'male' AND city = > > 'San Francisco'; > > There are actually two TODOs here. > > 1) a "bitmap scan" that would be usable with any type of ind

Re: [HACKERS] more dirmod CYGWIN

2004-10-13 Thread Bruce Momjian
I have added the attached patch to allow Cygwin /contrib compiles. I am a little confused why Cygwin requires -lpgport and no other platform does, but it is in the Cygwin-specific section so we can always improve it later if we find the cause. Thanks. ---

Re: [HACKERS] plans for bitmap indexes?

2004-10-13 Thread Zeugswetter Andreas DAZ SD
> > The most nearly comparable thing is be the notion of "partial > > indexes," where, supposing you had 60 region codes (e.g. - 50 US > > states, 10 Canadian provinces), you might set up indices thus: > For example, imagine you have a table on a dating website with 18 columns > representing 18

Re: [HACKERS] plans for bitmap indexes?

2004-10-13 Thread Neil Conway
On Sun, 2004-10-10 at 03:36, Chris Browne wrote: > There are doubtless cases where the optimizer won't use them where it > would be plausible to do so; that suggests, to me, possibilities for > enhancing the optimizer. Speaking of which, if anyone has any examples of queries for which we ought to

Re: [HACKERS] PL/PgSQL for counting all rows in all tables.

2004-10-13 Thread Dave Page
> -Original Message- > From: Robert Treat [mailto:[EMAIL PROTECTED] > Sent: 12 October 2004 21:21 > To: Dave Page > Cc: [EMAIL PROTECTED] > Subject: Re: [HACKERS] PL/PgSQL for counting all rows in all tables. > > Maybe I didn't phrase that quite right. How would a user know > that he