On Wed, 2010-09-01 at 20:57 -0400, Tom Lane wrote:
> I wrote:
> > Probably the best fix would be to make typcache flushing fully
> > independent of the relcache, but that would mean making sure that all
> > ALTER TABLE variants that affect the rowtype will issue an explicit
> > typcache flush. Tha
(2010/09/02 12:38), Robert Haas wrote:
> 2010/9/1 KaiGai Kohei:
>> (2010/09/02 11:57), Robert Haas wrote:
>>> 2010/9/1 KaiGai Kohei:
Right now, it stands on a strict assumption that considers operators
implemented with built-in functions are safe; it does not have no
possibility to l
On Wed, Sep 1, 2010 at 4:11 PM, Heikki Linnakangas
wrote:
> The obvious next question is how to wait for multiple sockets and a latch at
> the same time? Perhaps we should have a select()-like interface where you
> can pass multiple file descriptors. Then again, looking at the current
> callers of
2010/9/1 KaiGai Kohei :
> (2010/09/02 11:57), Robert Haas wrote:
>> 2010/9/1 KaiGai Kohei:
>>> Right now, it stands on a strict assumption that considers operators
>>> implemented with built-in functions are safe; it does not have no
>>> possibility to leak supplied arguments anywhere.
>>>
>>> Plea
(2010/09/02 11:57), Robert Haas wrote:
> 2010/9/1 KaiGai Kohei:
>> Right now, it stands on a strict assumption that considers operators
>> implemented with built-in functions are safe; it does not have no
>> possibility to leak supplied arguments anywhere.
>>
>> Please note that this patch does not
On Wed, Sep 1, 2010 at 6:39 AM, Magnus Hagander wrote:
>> That definitely didn't fix it, although I'm not quite sure why. Can
>> you throw the modified CVS you ran this off of up somewhere I can
>> rsync it?
>
> no rsync server on that box, but I put up a tarball for you at
> http://www.hagander.
On Mon, Aug 30, 2010 at 5:30 PM, Marko Tiikkaja
wrote:
> On 2010-08-31 12:07 AM +0300, I wrote:
>>
>> I looked at fixing this..
>
> The previous patch had a bug in fmgr_sql() our regression tests didn't
> catch. Fixed version attached.
It would probably be a good idea to add this to the currentl
2010/8/25 Boszormenyi Zoltan :
> PostgreSQL allows in plain SQL to declare a cursor
> e.g. in all lower case and fetch from is in all upper case.
> We need to allow this from ECPG, too, but strictly when
> the cursor name is not in a variable. Otherwise this code
> below doesn't notice the cursor's
2010/8/28 Alexander Korotkov :
> Now test for levenshtein_less_equal performance.
Nice results. I'll try to find time to look at this.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
2010/9/1 KaiGai Kohei :
> Right now, it stands on a strict assumption that considers operators
> implemented with built-in functions are safe; it does not have no
> possibility to leak supplied arguments anywhere.
>
> Please note that this patch does not case about a case when
> a function inside a
I wrote:
> Probably the best fix would be to make typcache flushing fully
> independent of the relcache, but that would mean making sure that all
> ALTER TABLE variants that affect the rowtype will issue an explicit
> typcache flush. That seems a bit too invasive to be back-patchable.
> I'm not en
This patch allows external security providers to check privileges
to create a new relation and to inform the security labels to be
assigned on the new one.
This hook is put on DefineRelation() and OpenIntoRel(), but isn't
put on Boot_CreateStmt, create_toast_table() and make_new_heap(),
although t
Jeff Davis writes:
> I have attached regression.diffs after a "make check". The diffs don't
> look trivial, and actually look quite strange to me.
BTW, if I dike out the flush_rowtype_cache call at relcache.c:1929,
the regression tests do pass for me, so it seems there is only one
bug exposed by
Bruce Momjian writes:
> Tom Lane wrote:
>> I certainly hope that pg_regress isn't freeing the strings it passes
>> to putenv() ...
> pg_regress does not restore these settings (it says with C/English) so
> the code is different.
That's not what I'm on about. You're trashing strings that are par
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> However, that's something for 9.1 and beyond. Bruce's immediate problem
> >> is what to do in pg_upgrade in 9.0, and there I concur that he should
> >> duplicate what pg_regress is doing.
>
> > OK, here is a patch that sets all the
I wrote:
> Jeff Davis writes:
>> I have attached regression.diffs after a "make check". The diffs don't
>> look trivial, and actually look quite strange to me.
> Hmm, sorta looks like that breaks something related to checking for
> composite types. That would be a bug. Will look.
So here is th
On Sep 1, 2010, at 11:02 AM, "Kevin Grittner"
wrote:
> The patch to implement true serializable transactions using SSI
> renames/rewords these things to avoid confusion. However, there are
> seven files which are changed only for this reason, and another
> where there is one "real" change of two
On Sep 1, 2010, at 10:21 AM, Greg Stark wrote:
> For what it's worth I disagree with Tom. I think this is a situation
> where we need *both* types of solution. Ideally we will be able to use
> a plain Append node for cases where we know the relative ordering of
> the data in different partitions,
Bruce Momjian writes:
> Tom Lane wrote:
>> However, that's something for 9.1 and beyond. Bruce's immediate problem
>> is what to do in pg_upgrade in 9.0, and there I concur that he should
>> duplicate what pg_regress is doing.
> OK, here is a patch that sets all the variables that pg_regress.c s
Jeff Davis writes:
> On Wed, 2010-09-01 at 15:31 -0400, Tom Lane wrote:
>> Jeff Davis writes:
>>> Compiling with RELCACHE_FORCE_RELEASE doesn't pass "make check" on my
>>> machine.
>> What happens exactly?
> I have attached regression.diffs after a "make check". The diffs don't
> look trivial,
Tom Lane wrote:
> Alvaro Herrera writes:
> > Excerpts from Bruce Momjian's message of mi?? sep 01 16:35:18 -0400 2010:
> >> I have implemented your suggestion of setting LANG, LANGUAGE, and
> >> LC_MESSAGES based on code in pg_regress.c; that is the only place I see
> >> where we force English, a
Alvaro Herrera writes:
> Excerpts from Bruce Momjian's message of mié sep 01 16:35:18 -0400 2010:
>> I have implemented your suggestion of setting LANG, LANGUAGE, and
>> LC_MESSAGES based on code in pg_regress.c; that is the only place I see
>> where we force English, and it certainly has receiv
Excerpts from Bruce Momjian's message of mié sep 01 16:35:18 -0400 2010:
> I have implemented your suggestion of setting LANG, LANGUAGE, and
> LC_MESSAGES based on code in pg_regress.c; that is the only place I see
> where we force English, and it certainly has received more testing.
I think a r
On Wed, 2010-09-01 at 13:23 +0300, Heikki Linnakangas wrote:
> On 01/09/10 10:53, Fujii Masao wrote:
> > Before discussing about that, we should determine whether registering
> > standbys in master is really required. It affects configuration a lot.
> > Heikki thinks that it's required, but I'm sti
Tom Lane wrote:
> Bruce Momjian writes:
> > Greg Sabino Mullane wrote:
> >> Specifically, LANGUAGE changes the headers of pg_controldata
> >> (but not the actual output, LC_ALL does that). Thanks for the
> >> nudge, I'll get to rewriting some code.
>
> > pg_upgrade does this in controldata.c fo
Jeff Davis writes:
> Compiling with RELCACHE_FORCE_RELEASE doesn't pass "make check" on my
> machine.
What happens exactly?
> Is it supposed to pass?
It shouldn't crash, but I'm not certain whether you'd see any
visible diffs in the tests.
regards, tom lane
--
Sent vi
2010/9/1 Tom Lane :
> Pavel Stehule writes:
>> 2010/9/1 Tom Lane :
>>> Well, you can build your own version of array_agg with the same
>>> implementation, except you mark the transition function as strict ...
>
>> I am checking this now, and it is not possible - it needs a some
>> initial value an
Pavel Stehule writes:
> 2010/9/1 Tom Lane :
>> Well, you can build your own version of array_agg with the same
>> implementation, except you mark the transition function as strict ...
> I am checking this now, and it is not possible - it needs a some
> initial value and there isn't possible to se
Compiling with RELCACHE_FORCE_RELEASE doesn't pass "make check" on my
machine.
Is it supposed to pass?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2010/9/1 Tom Lane :
> "David E. Wheeler" writes:
>> On Sep 1, 2010, at 11:09 AM, Pavel Stehule wrote:
>>> Then you can eliminate NULLs with simple function
>
>> Kind of defeats the purpose of the efficiency of the aggregate.
>
> Well, you can build your own version of array_agg with the same
> imp
"David E. Wheeler" writes:
> On Sep 1, 2010, at 11:09 AM, Pavel Stehule wrote:
>> Then you can eliminate NULLs with simple function
> Kind of defeats the purpose of the efficiency of the aggregate.
Well, you can build your own version of array_agg with the same
implementation, except you mark th
"David E. Wheeler" writes:
> On Sep 1, 2010, at 10:30 AM, Tom Lane wrote:
>> Most aggregate functions ignore null inputs, so that rows in which
>> one or more of the expression(s) yield null are discarded. (This
>> can be assumed to be true, unless otherwise specified, for all
>> built-in aggrega
On Sep 1, 2010, at 11:09 AM, Pavel Stehule wrote:
> Then you can eliminate NULLs with simple function
>
> CREATE OR REPLACE FUNCTION remove_null(anyarray)
> RETURNS anyarray AS $$
> SELECT ARRAY(SELECT x FROM unnest($1) g(x) WHERE x IS NOT NULL)
> $$ LANGUAGE sql;
Kind of defeats the purpose of
2010/9/1 Thom Brown :
> On 1 September 2010 18:47, David Fetter wrote:
>> On Wed, Sep 01, 2010 at 08:16:41AM -0700, David Wheeler wrote:
>>> On Sep 1, 2010, at 12:30 AM, Pavel Stehule wrote:
>>>
>>> > Docs is wrong :) I like current implementation. You can remove a
>>> > NULLs from aggregation ve
On Sep 1, 2010, at 10:30 AM, Tom Lane wrote:
> Hm, actually the whole para needs work. It was designed at a time when
> DISTINCT automatically discarded nulls, which isn't true anymore, and
> that fact was patched-in in a very awkward way too. Perhaps something
> like
>
>The first form of a
On Wed, 2010-09-01 at 08:33 +0300, Heikki Linnakangas wrote:
> On 01/09/10 04:02, Robert Haas wrote:
> > See the thread on interruptible sleeps. The problem
> > right now is that there are some polling loops that act to throttle
> > the maximum rate at which a node doing sync rep can make forward
On Sep 1, 2010, at 10:52 AM, Thom Brown wrote:
>>> ould appreciate the recipe for removing the NULLs.
>>
>> WHERE clause :P
>
> There may be cases where that's undesirable, such as there being more
> than one aggregate in the SELECT list, or the column being grouped on
> needing to return rows r
On 1 September 2010 18:47, David Fetter wrote:
> On Wed, Sep 01, 2010 at 08:16:41AM -0700, David Wheeler wrote:
>> On Sep 1, 2010, at 12:30 AM, Pavel Stehule wrote:
>>
>> > Docs is wrong :) I like current implementation. You can remove a
>> > NULLs from aggregation very simply, but different dire
On Wed, Sep 01, 2010 at 08:16:41AM -0700, David Wheeler wrote:
> On Sep 1, 2010, at 12:30 AM, Pavel Stehule wrote:
>
> > Docs is wrong :) I like current implementation. You can remove a
> > NULLs from aggregation very simply, but different direction isn't
> > possible
>
> Would appreciate the re
"David E. Wheeler" writes:
> On Sep 1, 2010, at 10:12 AM, Tom Lane wrote:
>> Even more to the point, should we deliberately make this vaguer so that
>> we aren't finding ourselves with obsolete text again and again? You can
>> bet that people adding new aggregates in the future aren't going to
>>
On Sep 1, 2010, at 10:12 AM, Tom Lane wrote:
> I think when that text was written, it was meant to imply "all the
> aggregates defined in SQL92". There seems to be a lot of confusion
> in this thread about whether "standard" means "defined by SQL spec"
> or "built-in in Postgres". Should we try
"David E. Wheeler" writes:
> *** 1543,1549
> The first form of aggregate expression invokes the aggregate
> across all input rows for which the given expression(s) yield
> non-null values. (Actually, it is up to the aggregate function
> ! whether to ignore null values o
On Sep 1, 2010, at 12:30 AM, Pavel Stehule wrote:
>> So are the docs right, or is array_agg() right?
>
> Docs is wrong :) I like current implementation. You can remove a NULLs
> from aggregation very simply, but different direction isn't possible
Patch:
diff --git a/doc/src/sgml/syntax.sgml b/d
On Wed, Sep 1, 2010 at 6:23 AM, Heikki Linnakangas
wrote:
> I'm not sure what we should aim for in the first phase. But if you want as
> little code as possible yet have something useful, I think 'replay' mode
> with no standby registration is the way to go.
IMHO, less is more. Trying to do too
On Sep 1, 2010, at 1:06 AM, Thom Brown wrote:
>> I think it might be both. array_agg doesn't return NULL, it returns
>> an array which contains NULL.
>
> The second I wrote that, I realised it was b*ll%$ks, as I was still in
> the process of waking up.
I know that feeling.
/me sips his coffee
David Christensen writes:
> In doing a schema upgrade, we noticed the following behavior, which certainly
> seems like a bug. Steps to reproduce:
> ...
> The bug in this case is that "b" has full permissions on all of the
> underlying tables, but runs into issues when trying to access the
> refe
Hey -hackers,
In doing a schema upgrade, we noticed the following behavior, which certainly
seems like a bug. Steps to reproduce:
CREATE USER a;
CREATE USER b;
CREATE TABLE t1 (id serial primary key);
CREATE TABLE t2 (id int references t1(id));
ALTER TABLE t1 OWNER TO a;
hello tom,
yeah, we have followed quite a lot of discussion as well ...
and yes, no patches.
as far as this problem is concerned: we are working on a patch and did some
prototyping inside the planner already (attached).
the code we have is pretty limited atm (such as checking for a sort clause
Maybe the issue, for the momtent, could be avoided modifying the shared heap
for sessions on Windows. But I don't really have idea how much to increase
or decrease the values. Try and error? But, inside the opened Windows
sessions nothing alerts of a heap exaust so could be unpredictable how much
t
On Sep 1, 2010, at 12:30 AM, Pavel Stehule wrote:
> Docs is wrong :) I like current implementation. You can remove a NULLs
> from aggregation very simply, but different direction isn't possible
Would appreciate the recipe for removing the NULLs.
Best,
David
--
Sent via pgsql-hackers mailing
On Wed, Sep 1, 2010 at 3:49 PM, Cristian Bittel wrote:
> Maybe the issue, for the momtent, could be avoided modifying the shared heap
> for sessions on Windows. But I don't really have idea how much to increase
> or decrease the values. Try and error? But, inside the opened Windows
> sessions noth
There are many comments in the code which use "serializable
transaction" to mean "transaction snapshot based transaction". This
doesn't matter much as long as REPEATABLE READ and SERIALIZABLE
transaction isolation levels behave identically, but will be
confusing and inaccurate when there is any di
=?iso-8859-1?Q?PostgreSQL_-_Hans-J=FCrgen_Sch=F6nig?=
writes:
> On Sep 1, 2010, at 4:10 PM, Tom Lane wrote:
>> This is really premature, and anything you do along those lines now will
>> probably never get committed.
> well, why non-overlapping? the idea is to make append smart enough to
> take
On 30/08/10 15:14, Fujii Masao wrote:
I think that the advantage of registering standbys is that we can
specify which WAL files the master has to keep for the upcoming
standby. IMO, it's usually called together with pg_start_backup
as follows:
SELECT register_standby('foo', pg_start_backup(
> 1. The statement
>
> UPDATE table SET fld1 = :input1
> WHERE CURRENT OF :curname
> RETURNING id + :input2;
>
> is transformed into
>
> UPDATE table SET fld1 = $1
> WHERE CURRENT OF $0
> RETURNING id + $2;
>
> and the $0 is past $1. The current code cannot deal
On Sep 1, 2010, at 4:10 PM, Tom Lane wrote:
> Boszormenyi Zoltan writes:
>> we are experimenting with modifying table partitioning
>> so the ORDER BY clause can be pushed down to
>> child nodes on the grounds that:
>
> This is really premature, and anything you do along those lines now will
> pr
2010/9/1 Boszormenyi Zoltan :
> we are experimenting with modifying table partitioning
> so the ORDER BY clause can be pushed down to
> child nodes on the grounds that:
> 1. smaller datasets are faster to sort, e.g. two datasets that almost
> spill out to disk are faster to sort in memory and la
Boszormenyi Zoltan writes:
> we are experimenting with modifying table partitioning
> so the ORDER BY clause can be pushed down to
> child nodes on the grounds that:
This is really premature, and anything you do along those lines now will
probably never get committed. The problem is that the tra
Hi,
we are experimenting with modifying table partitioning
so the ORDER BY clause can be pushed down to
child nodes on the grounds that:
1. smaller datasets are faster to sort, e.g. two datasets that almost
spill out to disk are faster to sort in memory and later merge them
than the union
On Wed, Sep 1, 2010 at 02:33, Robert Haas wrote:
> On Tue, Aug 31, 2010 at 5:07 PM, Magnus Hagander wrote:
>> On Tue, Aug 31, 2010 at 19:46, Magnus Hagander wrote:
>>> On Tue, Aug 31, 2010 at 19:44, Tom Lane wrote:
Magnus Hagander writes:
> Ok. I've got a new migration runinng. Here's
On 01/09/10 10:53, Fujii Masao wrote:
Before discussing about that, we should determine whether registering
standbys in master is really required. It affects configuration a lot.
Heikki thinks that it's required, but I'm still unclear about why and
how.
Why do standbys need to be registered in m
removable, 11 nonremovable row versions in
1655 pages
DETAIL: 1 dead row versions cannot be removed yet.
CPU 0.03s/0.06u sec elapsed 0.21 sec.
Note that the patch says nothing about reindexing. But if
required, I'm willing to add some VERBOSE messages for
indexes (ex. REINDEX VERBOS
(2010/07/21 19:35), KaiGai Kohei wrote:
> (2010/07/21 19:26), Robert Haas wrote:
>> 2010/7/21 KaiGai Kohei:
On the other hand, if it's enough from a performance
point of view to review and mark only a few built-in functions like
index operators, maybe it's ok.
>>> I also think i
On 1 September 2010 07:56, Thom Brown wrote:
> On 1 September 2010 06:45, David E. Wheeler wrote:
>> The aggregate docs say:
>>
>>> The first form of aggregate expression invokes the aggregate across all
>>> input rows for which the given expression(s) yield non-null values.
>>> (Actually, it i
On Wed, Sep 1, 2010 at 2:33 PM, Heikki Linnakangas
wrote:
> Once we're done with that, all the big questions are still left.
Yeah, let's discuss about those topics :)
> How to configure it?
Before discussing about that, we should determine whether registering
standbys in master is really requir
2010/9/1 David E. Wheeler :
> The aggregate docs say:
>
>> The first form of aggregate expression invokes the aggregate across all
>> input rows for which the given expression(s) yield non-null values.
>> (Actually, it is up to the aggregate function whether to ignore null values
>> or not — but
On 31/08/10 15:47, Fujii Masao wrote:
On Fri, Aug 27, 2010 at 4:39 PM, Fujii Masao wrote:
/*
* XXX: Should we invent an API to wait for data coming from the
* client connection too? It's not critical, but we could then
* eliminate the timeout altogether and go to sleep for good.
*/
Ye
On Aug 31, 2010, at 11:56 PM, Thom Brown wrote:
>>> The first form of aggregate expression invokes the aggregate across all
>>> input rows for which the given expression(s) yield non-null values.
>>> (Actually, it is up to the aggregate function whether to ignore null values
>>> or not — but al
68 matches
Mail list logo
