On Sun, Jul 20, 2014 at 10:41 PM, Craig Ringer wrote:
> I'd be very keen to see atomic upsert in Pg. Please Cc me on any patches
> / discussion, I'll be an eager tester.
Great. Thanks Craig.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
Currently \pset is supported without any argument also, so same is updated in
documentation.
\pset option [ value ]
Changed to
\pset [ option [ value ] ]
This patch does update the documentation as stated, and make it consistent
with the reality and the embedded psql help. This is an impro
During internals tests, it is observed that checkpointer
is getting crashed on slave with below log on slave in
windows:
LOG: checkpointer process (PID 4040) was terminated by exception 0xC005
HINT: See C include file "ntstatus.h" for a description of the hexadecimal
value.
LOG: terminating
On Sun, Jul 20, 2014 at 7:44 AM, Amit Kapila wrote:
> On Fri, Jul 18, 2014 at 7:08 PM, MauMau wrote:
>>
>> From: "Magnus Hagander"
>>
>>> On Fri, Jul 18, 2014 at 5:33 AM, Amit Kapila
>>> wrote:
On Thu, Jul 17, 2014 at 4:51 PM, Magnus Hagander
wrote:
>
>
> Did anyone
Re: Fabrízio de Royes Mello 2014-07-16
> Anyway I think all is ok now. Is this ok for you?
Hi Fabrízio,
it's ok for me now, though Andres' concerns seem valid.
> > > +SET TABLESPACE class="PARAMETER">new_tablespace
> > > RESET ( class="PARAMETER">storage_parameter [, ... ] )
> > >
On 2014-07-16 20:45:15 -0300, Fabrízio de Royes Mello wrote:
> > The rewrite will read in the 'old' contents - but because it's done
> > after the pg_class.relpersistence is changed they'll all not be marked
> > as BM_PERMANENT in memory. Then the ALTER TABLE is rolled back,
> > including the relpe
Re: Noah Misch 2014-07-18 <20140718052625.ga2231...@tornado.leadboat.com>
> Installing a new version of one Perl module is well within the capabilities of
> buildfarm owners. Saving them the trouble, which in turn means more of them
> actually activating the TAP tests, might justify the loss. I'd
The first two shapes on src/test/regress/sql/polygon.sql do not make
sense to me. They look more like polygons with some more tabs,
but still did not match the coordinates. I changed them to make
consistent with the shapes. I believe this was the intention of
the original author. Patch attached
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > That it's more-or-less a bulk 'ALTER TABLE' operation is why I had been
> > > trying to think of a way to put it under that command. What if we had a
> > > more general way to reference 'all objects in a
On Mon, Jul 21, 2014 at 10:06 AM, Christoph Berg wrote:
> Re: Noah Misch 2014-07-18 <20140718052625.ga2231...@tornado.leadboat.com>
>> Installing a new version of one Perl module is well within the capabilities
>> of
>> buildfarm owners. Saving them the trouble, which in turn means more of them
--On 12. Juli 2014 15:08:01 +0200 Magnus Hagander
wrote:
Before doing that, however, I'd like to ask for opinions :) The hack
currently exposes a separate view that you can join to
pg_stat_activity (or pg_stat_replication) on the pid -- this is sort
of the same way that pg_stat_replication
On Fri, Jul 18, 2014 at 7:01 PM, Brightwell, Adam
wrote:
>> I think we do want a way to modify policies. However, we tend to
>> avoid syntax that involves unnatural word order, as this certainly
>> does. Maybe it's better to follow the example of CREATE RULE and
>> CREATE TRIGGER and do somethin
For some reason, or possibly just through my carelessness and for no
real reason, json_object() currently disallows empty strings as object
keys. However silly empty string keys might be, they are apparently
allowed by the JSON rfcs, and this behaviour by json_object() is
inconsistent with what
On Mon, Jul 21, 2014 at 8:21 AM, Robert Haas wrote:
> The tests weren't running for me at all on MacOS X, because I was
> missing some prerequisite. So I installed it, and now they promptly
> fail:
>
> ok 2 - initdb --version
> 1..2
> ok 1 - initdb with invalid option nonzero exit code
>
On Mon, Jul 21, 2014 at 9:51 AM, Andres Freund
wrote:
>
> On 2014-07-16 20:45:15 -0300, Fabrízio de Royes Mello wrote:
> > > The rewrite will read in the 'old' contents - but because it's done
> > > after the pg_class.relpersistence is changed they'll all not be marked
> > > as BM_PERMANENT in mem
Fundamental issue:
PostgreSQL is different than Oracle in how it stores BLOBs
http://www.postgresql.org/docs/9.1/static/catalog-pg-largeobject.html.
In PostgreSQL ...
In the particular tables BLOBS are stored as OID's (unique numbers).
There is one table for all BLOB data (see pg_largeobject under
On Mon, Jul 21, 2014 at 12:00 PM, Thomas Fanghaenel
wrote:
> On Mon, Jul 21, 2014 at 8:21 AM, Robert Haas wrote:
>> The tests weren't running for me at all on MacOS X, because I was
>> missing some prerequisite. So I installed it, and now they promptly
>> fail:
>>
>> ok 2 - initdb --version
>>
Robert Haas writes:
> Mmph. Well, I don't want to install a non-default Perl on my system
> just to make these tests pass, and I don't think that should be a
> requirement.
I had the same feeling about the Perl on RHEL6 ;-). The TAP tests
will need to be a great deal more portable than they've
On 07/21/2014 02:40 PM, Tom Lane wrote:
Robert Haas writes:
Mmph. Well, I don't want to install a non-default Perl on my system
just to make these tests pass, and I don't think that should be a
requirement.
I had the same feeling about the Perl on RHEL6 ;-). The TAP tests
will need to be a
Hi, hackers!
There are new results of my work on GSoC project "Index-only scans for
GIST".
Previous post is here:
http://postgresql.1045698.n5.nabble.com/Index-only-scans-for-GIST-td5804892.html
Repository is
https://github.com/lubennikovaav/postgres/tree/indexonlygist2
Patch is in attachments.
It
Tom Lane wrote:
> Josh Berkus writes:
> >> 2. *Then*, in a second pass, enforce requirements like "can't be
> >> changed except at server start".
>
> > This would also make conf.d much more useful; I wouldn't have to worry
> > as much about overlapping config settings.
>
> > Sounds like a 9.5 f
Alvaro Herrera writes:
> Tom Lane wrote:
>> No, ALTER SYSTEM is there now and it needs to work right in its first
>> release. I will go fix this if nobody else does.
> Just checking -- you didn't get around to dealing with this, right?
Not yet... do you want it?
regards
Hi again,
Here's a patch which allows you to notice those annoying bugs with INTO
slightly more quickly. Adding to the next commit phest.
.marko
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
***
*** 4730,4736 a_output := a_output || $$ if v_$$ || referrer_k
Hi,
I'm curious if there is a reason why "IS NOT DISTINCT FROM" is not an indexable
operation in a B-tree index, as it is effectively testing for equality albeit
with some "magic" for NULLs? Here is an example of what I mean, running tests
on 9.3.4:
-- create a table of integers
On Mon, Jul 21, 2014 at 4:16 PM, Jonathan S. Katz
wrote:
> With NULLs being indexable, I was wondering if there was some reason why IS
> NOT DISTINCT FROM could not use the index?
FWIW this works:
postgres=# explain analyze select * from orders where orderid in (5, null);
On 2014-07-21 16:51:32 -0700, Peter Geoghegan wrote:
> On Mon, Jul 21, 2014 at 4:16 PM, Jonathan S. Katz
> wrote:
> > With NULLs being indexable, I was wondering if there was some reason why IS
> > NOT DISTINCT FROM could not use the index?
>
> FWIW this works:
>
> postgres=# explain analyze se
On Mon, Jul 21, 2014 at 4:57 PM, Andres Freund wrote:
> I rather doubt it will. x in (y1, ... yn) is essentially expanded to x =
> y1 OR x = y2, ... OR x = yn. I.e. the NULL comparison will be done using
> normal equality comparison and thus not return a row with a NULL
> orderid. Am I missing som
From: "Andres Freund"
On 2014-07-18 23:38:09 +0900, MauMau wrote:
So, I propose a simple fix to change the LOG level to DEBUG1. I don't
know
which of DEBUG1-DEBUG5 is appropriate, and any level is OK. Could you
include this in 9.2.9?
Surely that's the wrong end to tackle this from. Hiding
"Jonathan S. Katz" writes:
> I'm curious if there is a reason why "IS NOT DISTINCT FROM" is not an
> indexable operation in a B-tree index,
The short reason why not is that it's not an operator (where "operator"
is defined as "something with a pg_operator entry"), and all our indexing
infrastruct
Hi Asif,
On Wed, Jul 9, 2014 at 6:51 PM, Haribabu Kommi
wrote:
> On Mon, Jul 7, 2014 at 6:59 PM, Asif Naeem wrote:
> > Hi Haribabu,
> >
> > Thank you for sharing the patch. I have spent some time to review the
> > changes. Overall patch looks good to me, make check and manual testing
seems
> > r
Andrew Dunstan writes:
> On 07/21/2014 02:40 PM, Tom Lane wrote:
>> I had the same feeling about the Perl on RHEL6 ;-). The TAP tests
>> will need to be a great deal more portable than they've proven so far
>> before they'll really be useful for anything much. I trust we're
>> committed to makin
On 21 July 2014 13:39, Fabien COELHO Wrote
> This patch does update the documentation as stated, and make it
> consistent with the reality and the embedded psql help. This is an
> improvement and I recommand its inclusion.
>
> I would also suggest to move the sentence at the end of the descriptio
On Jul 21, 2014, at 9:51 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> I'm curious if there is a reason why "IS NOT DISTINCT FROM" is not an
>> indexable operation in a B-tree index,
>
> The short reason why not is that it's not an operator (where "operator"
> is defined as "something wit
According to
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2014-07-21%2022%3A36%3A55
prairiedog saw a crash in "make check" on the 9.4 branch earlier tonight;
but there's not a lot of evidence as to why in the buildfarm report,
because the postmaster log file is truncated wel
"Jonathan S. Katz" writes:
> On Jul 21, 2014, at 9:51 PM, Tom Lane wrote:
>> The short reason why not is that it's not an operator (where "operator"
>> is defined as "something with a pg_operator entry"), and all our indexing
>> infrastructure is built around the notion that indexable clauses are
On Tue, May 27, 2014 at 1:52 AM, Peter Geoghegan wrote:
>
> While talking to various people during pgCon, I was reminded that the
> nbtree README does a poor job of explaining the actual practical
> advantages of L&Y from a high level. The "move right" trick is
> initially mentioned only as an adj
This patch does update the documentation as stated, and make it
consistent with the reality and the embedded psql help. This is an
improvement and I recommand its inclusion.
I would also suggest to move the sentence at the end of the description:
"\pset without any arguments displays the curre
Hi
I looked on this patch and I am thinking so it is not a good idea. It
introduce early dependency between functions and pg_class based objects.
This check should not be integrated to function validation directly.
We can integrate it to plpgsql_check
Regards
Pavel
2014-07-21 22:56 GMT+02:0
How do I modify PostgreSQL 9.3 source to skip certain join combinations
(skip building certain paths in path tree) by checking some condition
On Tue, Jul 22, 2014 at 10:53 AM, Rajmohan C wrote:
> How do I modify PostgreSQL 9.3 source to skip certain join combinations
> (skip building certain paths in path tree) by checking some condition
>
have a look at joinpaths.c
On Thu, 2014-07-10 at 23:43 -0700, Jeff Davis wrote:
> On Mon, 2014-07-07 at 01:21 -0700, Jeff Davis wrote:
> > On Sun, 2014-07-06 at 21:11 -0700, Jeff Davis wrote:
> > > On Wed, 2014-04-16 at 12:50 +0100, Nicholas White wrote:
> > > > Thanks for the detailed feedback, I'm sorry it took so long to
Please find attached 2 patches, which are a split of the patch discussed in
this thread.
Please find attached a very minor improvement to apply a code (variable
name) simplification directly in patch A so as to avoid a change in patch
B. The cumulated patch is the same as previous.
(A) ad
On 2014-07-22 10:09:04 +0900, MauMau wrote:
> >From: "Andres Freund"
> >>On 2014-07-18 23:38:09 +0900, MauMau wrote:
> >>>So, I propose a simple fix to change the LOG level to DEBUG1. I don't
> >>>know
> >>>which of DEBUG1-DEBUG5 is appropriate, and any level is OK. Could you
> >>>include this i
On 7/22/14, 7:06 AM, Pavel Stehule wrote:
I looked on this patch and I am thinking so it is not a good idea. It
introduce early dependency between functions and pg_class based objects.
What dependency? The patch only looks at the raw parser output, so it
won't e.g. know whether SELECT * INT
On 07/21/2014 10:47 PM, Anastasia Lubennikova wrote:
Hi, hackers!
There are new results of my work on GSoC project "Index-only scans for
GIST".
Previous post is here:
http://postgresql.1045698.n5.nabble.com/Index-only-scans-for-GIST-td5804892.html
Repository is
https://github.com/lubennikovaav/p
45 matches
Mail list logo
