On Tuesday, July 30, 2013 1:17 AM Josh Berkus wrote:
On Tuesday, July 30, 2013 1:17 AM Amit kapila wrote:
> All,
>
> Based on the ongoing discussion of this patch, I have moved it to
> 9.4CF2
> (9-2013).
I had already sent the updated patch based on recent suggestions.
I am really not sure if so
On Mon, Jul 29, 2013 at 12:59:27PM +0930, Tom Dunstan wrote:
> I'm trying to hack a trigger function to evaluate an expression on the
> tuple that the trigger has been fired for, kinda like a check
> constraint. I looked at ExecRelCheck in execMain.c which does
> more-or-less what I want to do, and
On Monday, July 29, 2013 7:15 PM Cédric Villemain wrote:
> Le lundi 29 juillet 2013 13:47:57, Amit Kapila a écrit :
> > On Sunday, July 28, 2013 11:12 AM Amit kapila wrote:
> > > On Friday, July 26, 2013 6:18 PM Tom Lane wrote:
> > >
> > > Alvaro Herrera writes:
> > > >> The main contention point
On Tue, Jul 30, 2013 at 3:56 AM, Noah Misch wrote:
> Agreed. Let's stick an "Updates OS packages daily, regularly acquiring
> bleeding-edge upstream releases" note on the buildfarm status page
FWIW, I added "[updated daily]" to the OS version field.
I haven't changed other configuration yet, wi
On Mon, Jul 29, 2013 at 11:05:52AM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
> >> Hmm? Anchovy is upgrading automatically to newest Arch Linux packages
> >> daily.
> >> I assumed that's a good thing -- the purpose of build farm is to test
>
Hi Jeff,
On Tue, Jul 30, 2013 at 3:25 AM, Jeff Janes wrote:
> On Tue, Jul 23, 2013 at 10:56 PM, Amit Langote
> wrote:
>> On Wed, Jul 24, 2013 at 3:20 AM, Jeff Janes wrote:
>>>
>>> The heap structure used in external sorts is cache-unfriendly. The
>>> bigger the heap used, the more this unfrie
depesz,
* hubert depesz lubaczewski (dep...@depesz.com) wrote:
> On Mon, Jul 29, 2013 at 07:43:53PM -0400, Stephen Frost wrote:
> > * hubert depesz lubaczewski (dep...@depesz.com) wrote:
> > > create table some_data (id int4 primary key, payload text);
> > > create view first as select * from some
On Mon, Jul 29, 2013 at 07:43:53PM -0400, Stephen Frost wrote:
> depesz,
>
> moved to -hackers..
>
> * hubert depesz lubaczewski (dep...@depesz.com) wrote:
> > create table some_data (id int4 primary key, payload text);
> > create view first as select * from some_data where 0 = id % 2 with local
depesz,
moved to -hackers..
* hubert depesz lubaczewski (dep...@depesz.com) wrote:
> create table some_data (id int4 primary key, payload text);
> create view first as select * from some_data where 0 = id % 2 with local
> check option;
> create view second as select * from first where 0 = id wit
* Andrew Dunstan wrote:
I'm toying with the idea of a check_upgrade mode for the buildfarm
client where it wouldn't do a git pull, but would report changes if the
build result was different from the previous result. You'd run this
immediately after pulling new changes into your OS. Other, bright
Everyone,
This patch has been marked "ready for committer" since July 2nd. Can
someone please commit it, and let us close out this CF?
Thanks!
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Mon, Jul 29, 2013 at 2:16 AM, Andrew Tipton wrote:
> The attached patch adds four new SQL functions for the JSON type:
> json_typeof(json) RETURNS text
> json_is_object(json) RETURNS boolean
> json_is_array(json) RETURNS boolean
> json_is_scalar(json) RETURNS boolean
>
> The mot
On 18-07-2013 17:02, Alvaro Herrera wrote:
> I think we should just put the config directives of ALTER SYSTEM into a
> file, not dir, alongside postgresql.conf; I would suggest
> postgresql.auto.conf. This file is parsed automatically after
> postgresql.conf, without requiring an "include" directi
All,
Based on the ongoing discussion of this patch, I have moved it to 9.4CF2
(9-2013).
Mind you, it would be good to commit some version of it before September.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
All:
Because this patch is still being discussed and tinkered with, I have
moved it to 9.4CF2.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mail
On Sun, Jul 28, 2013 at 7:43 PM, Tom Lane wrote:
> I suspect it's likely to come out about the same either way once you
> account for all the uses of WITH. Might be worth trying both to see
> which seems less ugly.
So I'm not really sure how to do it the other way. Once you're in
parser rules I
On Mon, Jul 29, 2013 at 11:45 AM, Andrew Dunstan wrote:
>
> On 07/29/2013 02:26 PM, Marti Raudsepp wrote:
>>>
>>> I'm toying with the idea of a check_upgrade mode for the buildfarm client
>>> where it wouldn't do a git pull, but would report changes if the build
>>> result was different from the p
On Mon, Jul 29, 2013 at 4:05 PM, Tom Lane wrote:
> I can see both sides of this. It's definitely nice to get early warning
> when toolchain changes create new problems for Postgres, but it's not
> clear that the buildfarm is the best way to get such notifications.
Perhaps something as simple as
On 07/29/2013 02:26 PM, Marti Raudsepp wrote:
I'm toying with the idea of a check_upgrade mode for the buildfarm client
where it wouldn't do a git pull, but would report changes if the build
result was different from the previous result. You'd run this immediately
after pulling new changes into
On Mon, Jul 29, 2013 at 9:15 PM, Andrew Dunstan wrote:
> There has to be something between "set in stone and never changes" and
> "auto-updates everything every 24 hours" that would suit us.
Well sure I could change the update frequency. But again, it seems
like delaying the inevitable.
> I'm to
On Tue, Jul 23, 2013 at 10:56 PM, Amit Langote wrote:
> On Wed, Jul 24, 2013 at 3:20 AM, Jeff Janes wrote:
>>
>> The heap structure used in external sorts is cache-unfriendly. The
>> bigger the heap used, the more this unfriendliness becomes apparent.
>> And the bigger maintenance_work_mem, the
On 07/29/2013 11:05 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily.
I assumed that's a good thing -- the purpose of build farm is to test
PostgreSQL in various different real-
On Sat, Jul 27, 2013 at 6:57 PM, Tomonari Katsumata
wrote:
> Hi,
>
>
Yes, it prevents PROMOTE_SIGNAL_FILE from remaining even if
both promote files exist.
>>> The command("unlink(PROMOTE_SIGNAL_FILE)") here is for
>>> unusualy case.
>>> Because the case is when done both procedures
On Sun, Jul 28, 2013 at 7:59 AM, MauMau wrote:
> Hello,
>
> I'm sorry I've been touching several things recently before fixing any of
> them.
>
> I've noticed undesirable disk space increase while performing archive
> recovery with PostgreSQL 9.3. This happens with 9.2, too.
>
> I just performed
> Why not harcode in ParseConfigFp() that we should parse the auto.conf file at
> the end (and/or if USE_AUTO_CONF is not OFF) instead of hacking
> ProcessConfigFile() with data_directory ? (data_directory should be set at
> this
> point) ... just thinking, a very convenient way to enable/dis
On Mon, Jul 29, 2013 at 5:53 PM, Andres Freund wrote:
> Both the
> gcc 4.8 and the bison 3.0 problems are things the project needs to know
> about
Perl 5.18 too:
http://www.postgresql.org/message-id/2825.1370226...@sss.pgh.pa.us
Marti
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
Andrew Dunstan writes:
> On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
>> Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily.
>> I assumed that's a good thing -- the purpose of build farm is to test
>> PostgreSQL in various different real-life environments? Arch Linux is
>
On 2013-07-29 10:52:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > FWIW cherry-picking bf66bfb4cd726b6ddab3fe2718648f65a7106149 and
> > e58f3181fdaacc91d4cc1bd98a4a8ad7d286544c fixes the issue for me
> > (After fixing trivial conflicts in the latter).
>
> I've already spent more time on th
On 2013-07-29 10:46:41 -0400, Andrew Dunstan wrote:
>
> On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
> >Hi,
> >
> >>On 07/29/2013 01:05 AM, Tom Lane wrote:
> >>>Buildfarm member anchovy has been failing for the last couple of days,
> >>>evidently because its owner just couldn't wait to adopt biso
Andres Freund writes:
> FWIW cherry-picking bf66bfb4cd726b6ddab3fe2718648f65a7106149 and
> e58f3181fdaacc91d4cc1bd98a4a8ad7d286544c fixes the issue for me
> (After fixing trivial conflicts in the latter).
I've already spent more time on this than I wanted to, but just for
the archives' sake: neit
On 07/29/2013 03:16 AM, Andrew Tipton wrote:
The attached patch adds four new SQL functions for the JSON type:
json_typeof(json) RETURNS text
json_is_object(json) RETURNS boolean
json_is_array(json) RETURNS boolean
json_is_scalar(json) RETURNS boolean
Please add to the next
On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
Hi,
On 07/29/2013 01:05 AM, Tom Lane wrote:
Buildfarm member anchovy has been failing for the last couple of days,
evidently because its owner just couldn't wait to adopt bison 3.0,
which is all of 3 days old.
Hmm? Anchovy is upgrading automatica
On 07/29/2013 08:02 PM, Greg Stark wrote:
>> > Unless LATERAL provides a way to do lock-step iteration through a pair
>> > (or more) of functions I don't think we can get rid of SRFs [in select
>> > target lists] yet
> You don't even need lateral. This works fine:
>
> postgres=# select * from gen
Hi,
> On 07/29/2013 01:05 AM, Tom Lane wrote:
>> Buildfarm member anchovy has been failing for the last couple of days,
>> evidently because its owner just couldn't wait to adopt bison 3.0,
>> which is all of 3 days old.
Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily.
On 2013-07-29 08:44:56 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-07-29 08:17:46 -0400, Tom Lane wrote:
> >> I'm not excited about breaking code in order to fix optimization bugs
> >> that are purely hypothetical (and for which there's no particular reason
> >> to believe that the
On 07/29/2013 01:05 AM, Tom Lane wrote:
Buildfarm member anchovy has been failing for the last couple of days,
evidently because its owner just couldn't wait to adopt bison 3.0,
which is all of 3 days old. The failures look like
Reminder to buildfarm animal owners: if you upgrade software pl
Le lundi 29 juillet 2013 13:47:57, Amit Kapila a écrit :
> On Sunday, July 28, 2013 11:12 AM Amit kapila wrote:
> > On Friday, July 26, 2013 6:18 PM Tom Lane wrote:
> >
> > Alvaro Herrera writes:
> > >> The main contention point I see is where conf.d lives;
> > >> the two options are in $PGDATA o
2013/7/29 Stephen Frost :
> Szymon,
>
> * Szymon Guz (mabew...@gmail.com) wrote:
>> On 29 July 2013 11:25, Pavel Stehule wrote:
>> > In 9.3 super user can cancel all queries or user can cancel own sessions.
>> >
>> > Is possible enhance this possibility to database owners? So owner can
>> > cancel
Andres Freund writes:
> On 2013-07-29 08:17:46 -0400, Tom Lane wrote:
>> I'm not excited about breaking code in order to fix optimization bugs
>> that are purely hypothetical (and for which there's no particular reason
>> to believe that the proposed change would fix them anyway). If we were
>> s
Szymon,
* Szymon Guz (mabew...@gmail.com) wrote:
> On 29 July 2013 11:25, Pavel Stehule wrote:
> > In 9.3 super user can cancel all queries or user can cancel own sessions.
> >
> > Is possible enhance this possibility to database owners? So owner can
> > cancel or can terminate sessions related t
On 2013-07-29 08:17:46 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
> >> If we turn off the optimization, that will fix any other cases as well,
> >> no? So why would we risk breaking third-party code by back-porting the
> >> struct declaration
Andres Freund writes:
> On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
>> If we turn off the optimization, that will fix any other cases as well,
>> no? So why would we risk breaking third-party code by back-porting the
>> struct declaration changes?
> The -fno-agressive-loop thingie afaics only
On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
> >> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >>> The bottom line was:
> >>> It looks like our choices are (1) teach configure to enable
> >>> -fno-aggressive-loop-optimizat
On Mon, Jul 29, 2013 at 8:56 AM, Craig Ringer wrote:
> Unless LATERAL provides a way to do lock-step iteration through a pair
> (or more) of functions I don't think we can get rid of SRFs [in select target
> lists] yet
You don't even need lateral. This works fine:
postgres=# select * from gener
Andres Freund writes:
> On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> The bottom line was:
>>> It looks like our choices are (1) teach configure to enable
>>> -fno-aggressive-loop-optimizations if the compiler recognizes it,
>>> or (2) back-port c
On Sunday, July 28, 2013 11:12 AM Amit kapila wrote:
> On Friday, July 26, 2013 6:18 PM Tom Lane wrote:
> Alvaro Herrera writes:
> >> The main contention point I see is where conf.d lives;
> >> the two options are in $PGDATA or together with postgresql.conf.
> Tom
> >> and Robert, above, say it sh
On 29 July 2013 13:20, Pavel Stehule wrote:
> 2013/7/29 Szymon Guz :
> > On 29 July 2013 11:25, Pavel Stehule wrote:
> >>
> >> Hello
> >>
> >> In 9.3 super user can cancel all queries or user can cancel own
> sessions.
> >>
> >> Is possible enhance this possibility to database owners? So owner c
On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > However, I comment on this mainly because anchovy has had issues with
> > > 9.1 and older for some time, which looks like an issue with GCC 4.8.0.
> > > Did you happen to res
2013/7/29 Szymon Guz :
> On 29 July 2013 11:25, Pavel Stehule wrote:
>>
>> Hello
>>
>> In 9.3 super user can cancel all queries or user can cancel own sessions.
>>
>> Is possible enhance this possibility to database owners? So owner can
>> cancel or can terminate sessions related to owned database
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > However, I comment on this mainly because anchovy has had issues with
> > 9.1 and older for some time, which looks like an issue with GCC 4.8.0.
> > Did you happen to resolve or identify what is happening there..?
>
> Yeah, we kno
On 29 July 2013 11:25, Pavel Stehule wrote:
> Hello
>
> In 9.3 super user can cancel all queries or user can cancel own sessions.
>
> Is possible enhance this possibility to database owners? So owner can
> cancel or can terminate sessions related to owned databases?
>
>
But this means that a db o
Hello
In 9.3 super user can cancel all queries or user can cancel own sessions.
Is possible enhance this possibility to database owners? So owner can
cancel or can terminate sessions related to owned databases?
Regards
Pavel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On 07/29/2013 04:31 PM, Vik Fearing wrote:
> On 07/29/2013 09:56 AM, Craig Ringer wrote:
>> Unless LATERAL provides a way to do lock-step iteration through a pair
>> (or more) of functions I don't think we can get rid of SRFs-in-FROM just
>> yet.
>
> I don't think anyone was arguing for that; we'r
On 07/29/2013 09:56 AM, Craig Ringer wrote:
> Unless LATERAL provides a way to do lock-step iteration through a pair
> (or more) of functions I don't think we can get rid of SRFs-in-FROM just
> yet.
I don't think anyone was arguing for that; we're talking about
deprecating SRFs-in-SELECT.
--
Se
Szymon Guz wrote:
> today on IRC there was a strange problem shown. The small working example
> looks like this:
>
> x=# with x as (insert into a(t) values('1') returning *) select * from x;
> t
> ---
> 1
> (1 row)
>
> x=# with x (insert into a(t) values('1') returning *) select * from x;
> ER
On 07/25/2013 02:01 AM, Andres Freund wrote:
> And much of that can trivially/centrally be rewritten to LATERAL, not
> to speak of the cross-version compatibility problem.
An interesting example of that can be found here:
http://stackoverflow.com/q/12414750/398670
where someone's looking for a w
Hi Satoshi,
I was wondering about this problem. Please tell us about your system enviroment
which is postgresql version ,OS, raid card, and file system.
Best regards,
--
Mitsumasa KONDO
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
The attached patch adds four new SQL functions for the JSON type:
json_typeof(json) RETURNS text
json_is_object(json) RETURNS boolean
json_is_array(json) RETURNS boolean
json_is_scalar(json) RETURNS boolean
The motivating use-case for this patch is the ability to easily create a
do
Hi,
today on IRC there was a strange problem shown. The small working example
looks like this:
x=# with x as (insert into a(t) values('1') returning *) select * from x;
t
---
1
(1 row)
x=# with x (insert into a(t) values('1') returning *) select * from x;
ERROR: syntax error at or near "into"
59 matches
Mail list logo
