On Fri, 2009-03-27 at 23:25 -0400, Bruce Momjian wrote:
> Josh Berkus wrote:
> >
> > > Josh, this isn't a rejection. Both Tom and I asked for more exploration
> > > of the implications of doing as you suggest. Tom has been more helpful
> > > than I was in providing some scenarios that would cause
On Fri, 27 Mar 2009, Josh Berkus wrote:
These bugs strike me as especially pernicious and to need fixing before 8.4
release (but NOT before Beta):
* GiST picksplit (maybe GIN too?) can fail
we have patch for recent problem raised by Sergey Konoplev (thanks Andrew for
the test case), whic
As we are moving very close to 8.4 beta, please join us for testing 8.4
release.
I just released new RPM sets, which is based on Mar 27 CVS snapshot.
Please note that these packages are **not** production ready. They are
for Fedora 9,10 and RHEL/CentOS 5. I have no intention to push 8.4
developme
On Thu, Mar 26, 2009 at 02:39:05PM +, Andrew Gierth wrote:
> A user on IRC reported a crash (backend segfault) in GiST insertion
> (in 8.3.5 but I can reproduce this in today's HEAD) that turns out
> to be due to misbehaviour of gist_box_picksplit.
>
> The nature of the problem is this: if gis
> "Jaime" == Jaime Casanova writes:
Jaime> In the TODO list there is an item "[D] Completed itemAdd
Jaime> array_agg() and UNNEST functions for arrays " marked as done
Jaime> but 5 items below there is: "Add SQL-standard array_agg() and
Jaime> unnest() array functions " it's the same item
On Fri, Mar 27, 2009 at 9:38 PM, Bruce Momjian wrote:
> I have applied the attached patch which does several things:
>
> o documents that libssl _and_ libcrypto initialization is
> turned off by PQinitSSL(0)
> o clarified cases where this behavior is important
> o
On Sat, Mar 28, 2009 at 9:23 AM, Merlin Moncure wrote:
> It is still a bug in the sense that it is impossible to properly
> initialize crypto features in some scenarios. A doc patch (which I
Meant to say: 'your doc patch"
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
Hi,
Recently, I am reading the postgres codes, and I have a question about the
deparsing some expressions which is contains Const node. The following SQL
will retrieve the definition stored by postgres database for table "t":
CREATE TABLE "t" (c1 CHAR(5) DEFAULT 'abc',
c2 CHAR(5
Andrew Gierth wrote:
> > "Jaime" == Jaime Casanova writes:
>
> Jaime> In the TODO list there is an item "[D] Completed itemAdd
> Jaime> array_agg() and UNNEST functions for arrays " marked as done
> Jaime> but 5 items below there is: "Add SQL-standard array_agg() and
> Jaime> unnest() arr
Simon Riggs wrote:
>
> On Fri, 2009-03-27 at 23:25 -0400, Bruce Momjian wrote:
> > Josh Berkus wrote:
> > >
> > > > Josh, this isn't a rejection. Both Tom and I asked for more exploration
> > > > of the implications of doing as you suggest. Tom has been more helpful
> > > > than I was in providin
David E. Wheeler wrote:
> On Mar 27, 2009, at 6:40 PM, Bruce Momjian wrote:
>
> > Thanks, text updated:
> >
> > While semi-joins merely replace existing IN joins, anti-joins
> > are a new capability for NOT EXISTS clauses (Tom) This improves
> > optimization possibilities.
>
> I
> "Martijn" == Martijn van Oosterhout writes:
>> The nature of the problem is this: if gist_box_picksplit doesn't
>> find a good disposition on the first try, then it tries to split
>> the data again based on the positions of the box centers. But
>> there's a problem here with floating-po
> "Bruce" == Bruce Momjian writes:
>> The unnest() implementation is largely unrelated to the standard
>> one, which is impossible to provide without LATERAL.
Bruce> I removed the duplicate item; we can add more details about
Bruce> what additional functionality we need once we get user
Andrew Gierth wrote:
> > "Bruce" == Bruce Momjian writes:
>
> >> The unnest() implementation is largely unrelated to the standard
> >> one, which is impossible to provide without LATERAL.
>
> Bruce> I removed the duplicate item; we can add more details about
> Bruce> what additional func
On Sat, 2009-03-28 at 11:57 +, Andrew Gierth wrote:
> The array_agg() does, I believe, match the standard one, at least
> my reading of the spec doesn't reveal any obvious issues there.
I think it's missing the ORDER BY clause. This is not as important for
PostgreSQL because we can do ORDER BY
> "Jeff" == Jeff Davis writes:
> On Sat, 2009-03-28 at 11:57 +, Andrew Gierth wrote:
>> The array_agg() does, I believe, match the standard one, at least
>> my reading of the spec doesn't reveal any obvious issues there.
Jeff> I think it's missing the ORDER BY clause.
Hm, yeah, so i
> "Bruce" == Bruce Momjian writes:
>> 1) select ... from foo, unnest(foo.bar); -- UNNEST is implicitly LATERAL
[...]
>> It's point (1) that's the killer - without it, unnest() is just a
>> trivial shorthand for stuff that can be done anyway; it doesn't
>> actually add any functionality
On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane wrote:
>> and the first two items from the "questions" category, which
>> don't seem important enough to worry about at this stage of the game.
>
> Both of those things are related to 8.4 feature changes, so we should
> either do them now or decide we won
Robert Haas writes:
> On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane wrote:
>> Both of those things are related to 8.4 feature changes, so we should
>> either do them now or decide we won't do them.
> Well, "Should we have a LOCALE option in CREATE DATABASE?" has to do
> with making:
> CREATE DATAB
"Tao Ma" writes:
> CREATE TABLE "t" (c1 CHAR(5) DEFAULT 'abc',
> c2 CHAR(5) DEFAULT 'abc'::CHAR(5));
> SELECT pg_get_expr(adbin, adrelid)
> FROM pg_attrdef
> WHERE adrelid = (SELECT oid FROM pg_class WHERE relname = 't');
> pg_get_expr
> -
> 'a
Bruce Momjian writes:
> Tom, you mentioned this should be a TODO item. Do we put it on our main
> TODO, and if so, in what section?
Optimizer/executor I guess. It's a pretty vague TODO though. We need
some way to consider alternative join orders for joins that do not
semantically commute. Whe
Bruce Momjian writes:
> Tom Lane wrote:
>> But having said that, there isn't any real harm in fixing the OID
>> counter to match what it was. You need to run pg_resetxlog to set the
>> WAL position and XID counter anyway, and it can set the OID counter too.
> FYI, I decided against restoring the
Hitoshi Harada writes:
> So I tried pass EState.es_tupleTables to tuplestore_begin_heap() to
> trace those TupleTableSlots. Note that if you pass NULL the behavior
> is as before so nothing's broken. Regression passes but I'm not quite
> sure EState.es_tupleTable is only place that holds TupleTabl
On Sat, Mar 28, 2009 at 4:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane wrote:
>>> Both of those things are related to 8.4 feature changes, so we should
>>> either do them now or decide we won't do them.
>
>> Well, "Should we have a LOCALE option in C
I wrote:
> After reviewing this thread and the one that led up to the 8.3 behavior,
> it seems clear that we failed to draw a distinction between getopt and
> getopt_long when we should have. We don't like Solaris' getopt but
> there seems no reason not to use Solaris' getopt_long. So Zdenek's
>
On Sat, 2009-03-28 at 15:35 +, Andrew Gierth wrote:
> > "Jeff" == Jeff Davis writes:
>
> > On Sat, 2009-03-28 at 11:57 +, Andrew Gierth wrote:
> >> The array_agg() does, I believe, match the standard one, at least
> >> my reading of the spec doesn't reveal any obvious issues there.
Bruce, Simon,
I don't think there is an agreed todo item there. We were in the middle
of discussing other ideas and this is the wrong time to have a longer
debate on the topic. We should not squash other ideas by putting this as
a todo item yet.
I agree. We don't have consensus on the TODO.
Bruce Momjian escreveu:
> The psql system object display issue has not been completely resolved
> for 8.4; see 8.4 open items:
>
> http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes
>
> So what is the proposal? Have U/S/A flags for all commands and have
> different system d
Merlin Moncure wrote:
> It is still a bug in the sense that it is impossible to properly
> initialize crypto features in some scenarios. A doc patch (which I
> argued is the best way to go for 8.4) fails to properly raise the
> seriousness of the issue and also fails to suggest a workaround.
>
>
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> But having said that, there isn't any real harm in fixing the OID
> >> counter to match what it was. You need to run pg_resetxlog to set the
> >> WAL position and XID counter anyway, and it can set the OID counter too.
>
> > FYI, I
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom, you mentioned this should be a TODO item. Do we put it on our main
> > TODO, and if so, in what section?
>
> Optimizer/executor I guess. It's a pretty vague TODO though. We need
> some way to consider alternative join orders for joins that do no
Josh Berkus wrote:
> Bruce, Simon,
>
> > I don't think there is an agreed todo item there. We were in the middle
> > of discussing other ideas and this is the wrong time to have a longer
> > debate on the topic. We should not squash other ideas by putting this as
> > a todo item yet.
>
> I agree.
Bruce Momjian writes:
> Well, we are not the "Make Merlin Happy club". ;-)
Merlin and Andrew were the ones complaining initially. If they feel
that a proposed patch doesn't fix the problem, then I'd say that it
isn't fixing the problem.
> My personal opinion is that adding #defines to PQinitSS
Tom Lane wrote:
This is just a rehash of one of the patches that was discussed earlier.
There wasn't consensus for it then, and there's not now.
I am personally out of ideas. It feels like this issue has been beaten
to death. There are only a few ways to do it and I believe they have
all b
Euler Taveira de Oliveira wrote:
> Bruce Momjian escreveu:
> > The psql system object display issue has not been completely resolved
> > for 8.4; see 8.4 open items:
> >
> > http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes
> >
> > So what is the proposal? Have U/S/A flags f
Andrew Chernow wrote:
> Tom Lane wrote:
> > This is just a rehash of one of the patches that was discussed earlier.
> > There wasn't consensus for it then, and there's not now.
> >
>
> I am personally out of ideas. It feels like this issue has been beaten
> to death. There are only a few ways
On Sat, Mar 28, 2009 at 4:26 PM, Bruce Momjian wrote:
> Andrew Chernow wrote:
>> Tom Lane wrote:
>> > This is just a rehash of one of the patches that was discussed earlier.
>> > There wasn't consensus for it then, and there's not now.
>> >
>>
>> I am personally out of ideas. It feels like this i
Hi,
Le 27 mars 09 à 21:42, Sam Mason a écrit :
OK, that's turned out to be a good point. I've now written five
different versions and they don't seem to give the results I'm
expecting
at all!
If you're that much willing to have a good concurrent load simulator
client for postgresql, my t
Guillaume Smet wrote:
> On Fri, Mar 27, 2009 at 2:44 AM, Bruce Momjian wrote:
> > Guillaume Smet wrote:
> >> - "Add -M (query mode) to /contrib/pgbench (ITAGAKI Takahiro)"
> >> ->Itagaki san's name inconsistent with other mentions of his name
> >
> > Above all fixed, thanks.
>
> I think you fixed
Tom Lane wrote:
> Peter Eisentraut writes:
> > Joshua D. Drake wrote:
> > Do we want to give a more informative error message, like "not supported
> > on this platform?"
>
> > The trick will be to fit this into the GUC framework.
>
> You could do it by enforcing the limit in an assign hook, but
On Sat, Mar 28, 2009 at 3:51 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Well, we are not the "Make Merlin Happy club". ;-)
>
> Merlin and Andrew were the ones complaining initially. If they feel
> that a proposed patch doesn't fix the problem, then I'd say that it
> isn't fixing the problem
On Sat, Mar 28, 2009 at 1:25 AM, Euler Taveira de Oliveira
wrote:
> Bruce Momjian escreveu:
>> The psql system object display issue has not been completely resolved
>> for 8.4; see 8.4 open items:
>>
>> http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes
>>
>> So what is the p
On Sat, Mar 28, 2009 at 4:25 PM, Bruce Momjian wrote:
> Euler Taveira de Oliveira wrote:
>> Bruce Momjian escreveu:
>> > The psql system object display issue has not been completely resolved
>> > for 8.4; see 8.4 open items:
>> >
>> > http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#
Robert Haas wrote:
Is there more substance here than meets the eye?
No, you about summed it up. We need a way to init libssl and libcrypto
in any combo. Along the way, PQinit() was discussed which may have
muddied the waters.
I prefer leaving the PQinitSSL function alone, thus my patch
Andrew Chernow wrote:
> Robert Haas wrote:
> >
> > Is there more substance here than meets the eye?
> >
>
> No, you about summed it up. We need a way to init libssl and libcrypto
> in any combo. Along the way, PQinit() was discussed which may have
> muddied the waters.
>
> I prefer leaving
45 matches
Mail list logo
