On Thu, Jul 9, 2009 at 2:20 PM, Robert Haas wrote:
> On Jul 9, 2009, at 12:16 PM, Tom Lane wrote:
>
>> Brendan Jurd writes:
>>>
>>> We're now about a week away from the start of the July 2009
>>> commitfest, and we need to make a decision about whether to start
>>> using http://commitfest.postgre
Greg Stark wrote:
> On Mon, Jul 13, 2009 at 2:07 AM, Bruce Momjian wrote:
> > This might open the larger question of: ?What do we actually _promise_
> > users?
>
> The discussion had already covered that ground. If someone wants a
> promise they'll have to fork over money to one of the companies w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Jul 13, 2009 at 01:22:30PM +0900, Itagaki Takahiro wrote:
>
> Sam Mason wrote:
>
> > As others have said, handling encryption client side would seem to offer
> > many more benefits (transparently within libpq offering easy adoption).
>
> Li
Sam Mason wrote:
> As others have said, handling encryption client side would seem to offer
> many more benefits (transparently within libpq offering easy adoption).
Libpq is not the only driver. Do we need to develop transparent decryption
for each drivers? (libpq, JDBC, npgsql, py-postgresql,
Robert Haas wrote:
> 2009/7/12 KaiGai Kohei :
>> Robert, thanks for your comments.
>>
>> Robert Haas wrote:
>>> 2009/7/10 KaiGai Kohei :
The SE-PostgreSQL patches are updated as follows:
[1/5]
http://sepgsql.googlecode.com/files/sepgsql-01-sysatt-8.5devel-r2163.patch
[2/5]
2009/7/12 KaiGai Kohei :
> Robert, thanks for your comments.
>
> Robert Haas wrote:
>> 2009/7/10 KaiGai Kohei :
>>> The SE-PostgreSQL patches are updated as follows:
>>>
>>> [1/5]
>>> http://sepgsql.googlecode.com/files/sepgsql-01-sysatt-8.5devel-r2163.patch
>>> [2/5]
>>> http://sepgsql.googlecod
On Mon, Jul 13, 2009 at 2:07 AM, Bruce Momjian wrote:
> This might open the larger question of: What do we actually _promise_
> users?
The discussion had already covered that ground. If someone wants a
promise they'll have to fork over money to one of the companies which
sell such things.
That's
Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
> > For what it's worth I find it hard to believe anyone's really
> > surprised by this. Nearly all other open source projects stop
> > supporting old branches as soon as
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> For what it's worth I find it hard to believe anyone's really
> surprised by this. Nearly all other open source projects stop
> supporting old branches as soon as there's a newer branch is released.
I'm not surprised at all. Our product holds
On Sun, Jul 12, 2009 at 11:53 PM, Josh Berkus wrote:
>
> Well, what I'm really concerned about is letting people know that we expect
> to *stop* providing update versions after 5 years.
That seems like a reasonable thing to say and you've just said it more
simply than any of your previous proposal
Robert, thanks for your comments.
Robert Haas wrote:
> 2009/7/10 KaiGai Kohei :
>> The SE-PostgreSQL patches are updated as follows:
>>
>> [1/5]
>> http://sepgsql.googlecode.com/files/sepgsql-01-sysatt-8.5devel-r2163.patch
>> [2/5]
>> http://sepgsql.googlecode.com/files/sepgsql-02-core-8.5devel-
Andrew Dunstan writes:
> Josh Berkus wrote:
>> Oh, I didn't think about the Flex version. That's going to be a far
>> more widespread problem. OSX 10.5, for example, still ships with
>> 2.5.33. I suspect that a *lot* of OSes won't have anything up-to-date.
> That's the version Tom is proposi
Josh Berkus wrote:
This is ready to go except for changing the minimum flex version test
in configure (and associated documentation). I see that a good-sized
fraction of the buildfarm is still on flex 2.5.4 and will therefore go
red when this goes in. Should I hold off a bit longer, or is c
This is ready to go except for changing the minimum flex version test
in configure (and associated documentation). I see that a good-sized
fraction of the buildfarm is still on flex 2.5.4 and will therefore go
red when this goes in. Should I hold off a bit longer, or is committing
the best way
For an open source project, would such a statement really mean
anything more than "we'll provide support as long as some
community members feel like it, and we guess that's about 5 years"?
Well, what I'm really concerned about is letting people know that we
expect to *stop* providing update v
Tom Lane wrote:
I see that a good-sized
fraction of the buildfarm is still on flex 2.5.4 and will therefore go
red when this goes in. Should I hold off a bit longer, or is committing
the best way to get their attention?
Probably the latter. I will update my various members. I see that 2.
Before I forget, here is a quick brain dump on $SUBJECT.
The latest release of flex is currently 2.5.35. 2.5.33 is pretty
widespread as well, and there's at least one 2.5.34 in the buildfarm.
There was no 2.5.32. 2.5.31 and (possibly) earlier versions contain
an extremely nasty security problem
Josh Berkus wrote:
> I'd suggest that we publish an official policy, with the following dates
> for "EOL":
> 7.4 2009-08-01 ...
> 8.4 2014-08-01
What would such forward-looking statements even mean for a
community-driven project?
I assume for a commercial product, such a statement would mean
Andrew Dunstan writes:
> If we're going to have a reentrant lexer, I think we should go the whole
> nine yards. I agree that a couple of percent slowdown on just the lexing
> and parsing will be lost in the noise. So +1 from me.
I found a couple of places where a few cycles could be shaved. Th
On Sun, Jul 12, 2009 at 3:55 PM, Peter Eisentraut wrote:
> On occasion, I would have found it useful if a SIGHUP didn't only log *that*
> it reloaded the configuration files, but also logged *what* had changed
> (postgresql.conf changes in particular, not so much interested in
> pg_hba.conf). Espe
2009/7/10 KaiGai Kohei :
> The SE-PostgreSQL patches are updated as follows:
>
> [1/5]
> http://sepgsql.googlecode.com/files/sepgsql-01-sysatt-8.5devel-r2163.patch
> [2/5] http://sepgsql.googlecode.com/files/sepgsql-02-core-8.5devel-r2163.patch
> [3/5] http://sepgsql.googlecode.com/files/sepgsql-0
Hello
there is fix for bug Re: [BUGS] BUG #4907: stored procedures and changed tables
regards
Pavel Stehule
2009/7/10 Sergey Burladyan :
> Sergey Burladyan writes:
>
>> Alvaro Herrera writes:
>>
>> > Michael Tenenbaum wrote:
>> >
>> > > If I have a stored procedure that returns a set of recor
On occasion, I would have found it useful if a SIGHUP didn't only log *that*
it reloaded the configuration files, but also logged *what* had changed
(postgresql.conf changes in particular, not so much interested in
pg_hba.conf). Especially in light of the common mistake of forgetting to
uncomm
On Sun, Jul 12, 2009 at 4:42 PM, Tom Lane wrote:
>
> I'm kind of wondering how big the use case for that really is.
> AFAICT the point of a concurrent build is to (re)build an index
> without incurring too much performance penalty for foreground
> query processing. So how often are you really goin
Actually ... why do we have to have that third wait step at all?
Doesn't the indcheckxmin mechanism render it unnecessary, or couldn't
we adjust the comparison xmin to make it unnecessary?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
Greg Stark writes:
> So I think we're back to looking at a special case for concurrent
> index builds to not wait on other concurrent index builds.
I'm kind of wondering how big the use case for that really is.
AFAICT the point of a concurrent build is to (re)build an index
without incurring too
On Sun, Jul 12, 2009 at 4:17 PM, Tom Lane wrote:
> The requirement wasn't just on not changing SQL data though. To make
> use of this you'd also have to forbid indexed functions from *reading*
> other tables. Which is something we discourage because of the risk that
> the results aren't really im
Josh Berkus writes:
> On 7/11/09 3:50 AM, Greg Stark wrote:
>> Hm. Actually maybe not. What if the index is an expression index and
>> the expression includes a function which does an SQL operation? I'm
>> not sure how realistic that is since to be a danger that SQL operation
>> would have to be a
2009/7/12 Tom Lane :
> Pavel Stehule writes:
>> 2009/7/12 Tom Lane :
>>> If we're going to go for reentrancy
>>> I think we should fix both components.
>
>> when we don't use reentrant grammar, then we cannot use main sql parser in
>> SQL?
>
> It wouldn't be a problem for the immediate applicatio
Andres Freund writes:
> Has anybody tried Geqo without ERX in recent time?
No, I don't think so. Anything that's ifdef'd out at the moment has
been that way for quite a few years, and so is likely broken anyhow :-(
regards, tom lane
--
Sent via pgsql-hackers mailing li
On Sunday 12 July 2009 16:44:59 Tom Lane wrote:
> Andres Freund writes:
> > On Saturday 11 July 2009 20:33:14 Tom Lane wrote:
> >> This ties into something I was thinking about earlier: the planner is
> >> potentially recursive (eg, it might call a user-defined function that
> >> contains a planna
Andres Freund writes:
> On Saturday 11 July 2009 20:33:14 Tom Lane wrote:
>> This ties into something I was thinking about earlier: the planner is
>> potentially recursive (eg, it might call a user-defined function that
>> contains a plannable query), and it'd probably be a good idea if the
>> beh
Pavel Stehule writes:
> 2009/7/12 Tom Lane :
>> If we're going to go for reentrancy
>> I think we should fix both components.
> when we don't use reentrant grammar, then we cannot use main sql parser in
> SQL?
It wouldn't be a problem for the immediate application I have in mind,
which is to re
Tom Lane wrote:
As best I can tell after some casual testing on a couple of machines,
the actual bottom line is that "raw_parser" (ie, the bison and flex
processing) is going to be a couple of percent slower with a reentrant
grammar and lexer, for typical queries involving a lot of short tokens
Hi Tom,
On Saturday 11 July 2009 20:33:14 Tom Lane wrote:
> Andres Freund writes:
> > I just realized doing it in a naive way (in geqo()) causes the state to
> > be reset multiple times during one query- at every invocation of
> > make_rel_from_joinlist.
> >
> > Does anybody see a problem with th
On Tue, Jul 07, 2009 at 05:35:28PM +0900, Itagaki Takahiro wrote:
> Our manual says we can use pgcrypto functions or encrypted filesystems
> for data encryption.
> http://www.postgresql.org/docs/8.4/static/encryption-options.html
>
> However, they are not always the best approaches in some cases.
2009/7/12 Tom Lane :
> Andrew Dunstan writes:
>> Tom Lane wrote:
>>> Andrew Dunstan writes:
I think it would need to be benchmarked. My faint recollection is that
the re-entrant lexers are slower.
>>>
>>> The flex documentation states in so many words:
>>> The option `--reentrant' do
37 matches
Mail list logo
