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
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
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
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
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
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
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
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
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
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
>> > > > 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
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
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 "
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
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
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
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
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
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
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
"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
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
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
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
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
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.
---
> > 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
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
> -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
29 matches
Mail list logo