Robert Haas writes:
> On Fri, Mar 9, 2012 at 8:15 PM, Tom Lane wrote:
>> Um ... how do you get the subquery result rows to join to only the
>> correct rows of the other tables? This looks like an unconstrained join
>> to me, which is not what I believe the SQL spec for LATERAL to be, and
>> it d
On 2012-03-09 21:49, Robert Haas wrote:
On Tue, Mar 6, 2012 at 9:14 AM, Kohei KaiGai wrote:
[ new patch ]
Are we absolutely certain that we want the semantics of
sepgsql_setcon() to be transactional? Because if we made them
non-transactional, this would be a whole lot simpler, and it would
st
On Sat, Feb 18, 2012 at 21:16, Vik Reykja wrote:
> I would be willing to have a go at translating test cases. I do not (yet)
> have the C knowledge to maintain the regex code, though.
I got suddenly swamped and forgot I had signed up for this. I'm still
pretty swamped and I would like these r
On Fri, Mar 9, 2012 at 6:51 PM, Andrew Dunstan wrote:
>
>
> On 03/09/2012 01:40 PM, Robert Haas wrote:
>>
>> On Fri, Mar 9, 2012 at 12:02 PM, David E. Wheeler
>> wrote:
>>>
>>> On Mar 9, 2012, at 7:55 AM, Merlin Moncure wrote:
100% agree (having re-read the thread and Alvaro's idea hav
Hello
2012/3/10 Tom Lane :
> Peter Eisentraut writes:
>> But then I would have to map all language-specific error reports to some
>> SQL error scheme, which is not only cumbersome but pretty useless. For
>> example, a Python programmer will be familiar with the typical output
>> that pylint prod
On Sat, Mar 10, 2012 at 4:16 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 9, 2012 at 8:15 PM, Tom Lane wrote:
>>> Um ... how do you get the subquery result rows to join to only the
>>> correct rows of the other tables? This looks like an unconstrained join
>>> to me, which is not wh
On Sat, Mar 10, 2012 at 4:39 AM, Yeb Havinga wrote:
>> As a separate but related note, the label management here seems to be
>> excessively complicated. In particular, it seems to me that the
>> semantics of sepgsql_get_client_label() become quite muddled under
>> this patch. An explicitly-set l
On Fri, Mar 9, 2012 at 7:47 PM, Tom Lane wrote:
> I think a reasonable way to proceed might be to get some consensus on
> a short list of patches we're willing to try to push to completion,
> then set a schedule accordingly, and then anything that doesn't get
> done by the deadline gets kicked to
W dniu 2012-03-09 16:55, Merlin Moncure pisze:
> On Fri, Mar 9, 2012 at 9:36 AM, Kohei KaiGai
> wrote:
>> 2012/3/6 Alvaro Herrera :
>>> It seems to me that the only thing that needs core support is
>>> the ability to start up the daemon when postmaster is ready to
>>> accept queries, and shut the
On Thu, Feb 23, 2012 at 11:37 PM, Joachim Wieland wrote:
> On Thu, Feb 16, 2012 at 1:29 PM, Robert Haas wrote:
>> Can you provide an updated patch?
>
> Robert, updated patch is attached.
Well, I was hoping someone else would do some work on this, but here
we are. Some more comments from me:
+
On Sat, Mar 10, 2012 at 9:04 AM, Simon Riggs wrote:
> * FOR KEY SHARE locks looks in very good shape and so I'm spending
> time on that with a view to committing it next week if all goes well
Álvaro is a committer and is perfectly capable of committing that
patch for himself, had we consensus on
On 03/10/2012 07:11 AM, Simon Riggs wrote:
On Fri, Mar 9, 2012 at 6:51 PM, Andrew Dunstan wrote:
On 03/09/2012 01:40 PM, Robert Haas wrote:
On Fri, Mar 9, 2012 at 12:02 PM, David E. Wheeler
wrote:
On Mar 9, 2012, at 7:55 AM, Merlin Moncure wrote:
100% agree (having re-read the thread a
>>
>
> here is draft
and there some cleaned version
Regards
Pavel Stehule
>
>
>> regards, tom lane
plpgsql_check_function.diff.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
Simon Riggs writes:
> * pg_stat_statements looks good also, I hope someone is looking at that
I will take that one, if it ever gets marked RFC, but in the meantime
I plan to spend my time elsewhere.
> At this stage the CF app isn't helping us much. We need some way to
> indicate who is actively
Vik Reykja writes:
> On Sat, Feb 18, 2012 at 21:16, Vik Reykja wrote:
>> I would be willing to have a go at translating test cases. I do not (yet)
>> have the C knowledge to maintain the regex code, though.
> I got suddenly swamped and forgot I had signed up for this. I'm still
> pretty swampe
Shigeru Hanada writes:
> I've not read whole of the patch yet, but I have basic questions.
> 1) IIUC, GetForeignRelSize should set baserel->rows to the number of
> rows the ForeignScan node returns to upper node, but not the number
> of rows FDW returns to core executor, right?
It should be the
Shigeru Hanada writes:
> Thanks for the review. Agreed to write own depraser for pgsql_fdw
> which handles nodes which can be pushed down. Every SQL-based FDW
> which constructs SQL statement for each local query would need such
> module inside.
Yeah. That's kind of annoying, and the first thi
On 03/10/2012 02:15 AM, Tom Lane wrote:
Um ... how do you get the subquery result rows to join to only the
correct rows of the other tables?
The subquery just restricts the set of rows that the function has to
evaluate. The main query is supposed to perform the join.
I understand, such a join ca
On Sat, Mar 10, 2012 at 02:05, Tom Lane wrote:
> Marti Raudsepp writes:
>> [ cacheexpr-v8.patch ]
>
> A few comments
Whoa, that's quite a few. Thanks for the review.
> * There's a lot of stuff that seems wrong in detail in
> eval_const_expressions_mutator, eg it'll try to wrap a plain vanilla
>
On Sat, Mar 10, 2012 at 11:38:51AM -0500, Tom Lane wrote:
> Shigeru Hanada writes:
> > Thanks for the review. Agreed to write own depraser for pgsql_fdw
> > which handles nodes which can be pushed down. Every SQL-based FDW
> > which constructs SQL statement for each local query would need such
>
Marti Raudsepp writes:
> On Sat, Mar 10, 2012 at 02:05, Tom Lane wrote:
>> * There's a lot of stuff that seems wrong in detail in
>> eval_const_expressions_mutator, eg it'll try to wrap a plain vanilla
>> Const with a CacheExpr. I see you've hacked that case inside
>> insert_cache itself, but th
On Sat, Mar 10, 2012 at 2:55 PM, Robert Haas wrote:
> On Sat, Mar 10, 2012 at 9:04 AM, Simon Riggs wrote:
>> * FOR KEY SHARE locks looks in very good shape and so I'm spending
>> time on that with a view to committing it next week if all goes well
>
> Álvaro is a committer and is perfectly capabl
On Sat, Mar 10, 2012 at 3:47 PM, Tom Lane wrote:
> Simon Riggs writes:
>> * pg_stat_statements looks good also, I hope someone is looking at that
>
> I will take that one, if it ever gets marked RFC, but in the meantime
> I plan to spend my time elsewhere.
>
>> At this stage the CF app isn't help
On Fri, Mar 9, 2012 at 9:07 AM, Robert Haas wrote:
> On Fri, Mar 9, 2012 at 12:47 AM, Jaime Casanova wrote:
>>> Sorry, here's the patch rebased and with the suggestion from Alex.
>>> Which reminds me, I never thank him for the review (shame on me) :D
>>
>> with the patch this time
>
> This may be
On Sat, Mar 10, 2012 at 2:38 PM, Jaime Casanova wrote:
> On Fri, Mar 9, 2012 at 9:07 AM, Robert Haas wrote:
>> On Fri, Mar 9, 2012 at 12:47 AM, Jaime Casanova
>> wrote:
Sorry, here's the patch rebased and with the suggestion from Alex.
Which reminds me, I never thank him for the revie
Hi list,
Per Tom's request, I split out this refactoring from my CacheExpr patch.
Basically I'm just centralizing the eval_const_expressions_mutator()
call on function arguments, from multiple different places to a single
location. Without this, it would be a lot harder to implement argument
cach
On Mar 9, 2012, at 2:34 PM, Robert Haas wrote:
> On Fri, Mar 9, 2012 at 5:42 AM, Hans-Jürgen Schönig
> wrote:
>> we had some different idea here in the past: what if we had a procedure /
>> method to allow people to save the list of current buffers / cached blocks
>> to be written to disk (sort
Hi Robert,
Just recently I asked on postgres-performance "PG as in-memory db? How
to warm up and re-populate buffers? How to read in all tuples into
memory?"
Somehow open was, what's the best practice of configuration and
relationship between disk/OS cache vs. Portgres cache
The main conclusion
On 2012-03-10 14:06, Robert Haas wrote:
On Sat, Mar 10, 2012 at 4:39 AM, Yeb Havinga wrote:
As a separate but related note, the label management here seems to be
excessively complicated. In particular, it seems to me that the
semantics of sepgsql_get_client_label() become quite muddled under
t
We currently have
void EncodeDateTime(struct pg_tm * tm, fsec_t fsec, int *tzp, char **tzn, int
style, char *str)
but tzn isn't used anywhere, only *tzn is used everywhere. Wouldn't it
be clearer to remove that one level of indirection and instead have the
signature be
void EncodeDateTime(stru
On 10 March 2012 15:47, Tom Lane wrote:
> Simon Riggs writes:
>> * pg_stat_statements looks good also, I hope someone is looking at that
>
> I will take that one, if it ever gets marked RFC, but in the meantime
> I plan to spend my time elsewhere.
It has been marked RFC now.
--
Peter Geoghegan
On 03/09/2012 07:50 PM, Tom Lane wrote:
Andrew Dunstan writes:
Buildfarm member mussel (OS X 10.7.3, llvm-gcc 4.2.1, x86_64)seems to be
getting consistent warnings when running the pgcrypto regression tests,
that look like this:
WARNING: detected write past chunk end in ExprContext 0x7fe
On Mar 10, 2012, at 4:19 PM, Andrew Dunstan wrote:
>
> On 03/09/2012 07:50 PM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> Buildfarm member mussel (OS X 10.7.3, llvm-gcc 4.2.1, x86_64)seems to be
>>> getting consistent warnings when running the pgcrypto regression tests,
>>> that look like th
Peter Eisentraut writes:
> We currently have
> void EncodeDateTime(struct pg_tm * tm, fsec_t fsec, int *tzp, char **tzn, int
> style, char *str)
> but tzn isn't used anywhere, only *tzn is used everywhere. Wouldn't it
> be clearer to remove that one level of indirection and instead have the
> s
Robert Creager writes:
> On Mar 10, 2012, at 4:19 PM, Andrew Dunstan wrote:
>> On 03/09/2012 07:50 PM, Tom Lane wrote:
>>> I suspect that mussel has an ABI-incompatible openssl library hanging
>>> around someplace. On my machine "otool -L pgcrypto.so" shows
>>> /usr/lib/libcrypto.0.9.8.dylib (co
On Mar 10, 2012, at 5:01 PM, Tom Lane wrote:
> What's really odd though is that there is nothing in the configuration
> script that injects any of those switches. I think you've got some
> screwy global configuration on that machine, which you'd be well advised
> to try to get rid of --- it's t
Robert Creager writes:
> On Mar 10, 2012, at 5:01 PM, Tom Lane wrote:
>> What's really odd though is that there is nothing in the configuration
>> script that injects any of those switches. I think you've got some
>> screwy global configuration on that machine, which you'd be well advised
>> to
On Mar 10, 2012, at 7:15 PM, Tom Lane wrote:
> Robert Creager writes:
>> On Mar 10, 2012, at 5:01 PM, Tom Lane wrote:
>>> What's really odd though is that there is nothing in the configuration
>>> script that injects any of those switches. I think you've got some
>>> screwy global configurati
On 03/10/2012 09:15 PM, Tom Lane wrote:
(I wonder whether it'd be a good idea for the buildfarm script to
explicitly clear anything that autoconf pays attention to from its
startup environment, so that you have to set these variables in the
buildfarm config to make them have effect. If not th
On Mar 10, 2012, at 7:54 PM, Andrew Dunstan wrote:
>
>
> On 03/10/2012 09:15 PM, Tom Lane wrote:
>>
>> (I wonder whether it'd be a good idea for the buildfarm script to
>> explicitly clear anything that autoconf pays attention to from its
>> startup environment, so that you have to set these
On Sat, Mar 10, 2012 at 4:35 PM, Stefan Keller wrote:
> The main conclusion was:
> * Do a "tar cf /dev/zero $PG_DATA/base either shortly before or
> shortly after the database is created"
> * Do a seq scan "SELECT * FROM osm_point".
>
> Is your tool a replacement of those above?
It can be used th
I've finally been able to run some more tests of the effect of
adjusting wal_buffers to values higher than 16MB. I ran the test on
the 16 core (x 4 hw threads/core) IBM POWER7 machine, with my usual
configuration settings:
shared_buffers = 8GB
maintenance_work_mem = 1GB
synchronous_commit = off
c
Robert Creager writes:
> On Mar 10, 2012, at 7:15 PM, Tom Lane wrote:
>> I don't believe autoconf would insert such stuff on its own authority.
>> I'm wondering about CPPFLAGS, CFLAGS, LDFLAGS or similar variables being
>> set in the environment that the buildfarm script is running in.
>> Take a
Andrew Dunstan writes:
> On 03/10/2012 09:15 PM, Tom Lane wrote:
>> (I wonder whether it'd be a good idea for the buildfarm script to
>> explicitly clear anything that autoconf pays attention to from its
>> startup environment, so that you have to set these variables in the
>> buildfarm config to
44 matches
Mail list logo
