On Fri, Jul 4, 2014 at 7:29 PM, MauMau wrote:
>
> Hello,
>
> "When requesting synchronous replication, each commit of a write
transaction will wait until confirmation is received that the commit has
been written to the transaction log on disk of both the primary and standby
server.
> ...
> Read on
Kaigai,
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> > Can you clarify where this is coming from..? It sounds like you're
> > referring to an existing implementation and, if so, it'd be good to get
> > more information on how that works exactly.
>
> Oracle VPD - Multiple Policies for Each Tab
On Sat, Jul 5, 2014 at 8:22 PM, Tom Lane wrote:
>
> Amit Kapila writes:
> > Please find the patch attached to address the above concern. I have
> > updated docs, so that users can be aware of such behaviour.
>
> I'm in the camp that says that we need to do something about this, not
> just claim
* Greg Stark (st...@mit.edu) wrote:
> On Thu, Jul 3, 2014 at 11:40 AM, Atri Sharma wrote:
> > IIRC, last time when we tried doing bloom filters, I was short of some real
> > world useful hash functions that we could use for building the bloom filter.
>
> Last time was we wanted to use bloom filte
On 5 July 2014 02:03, Vik Fearing wrote:
> [1] http://wiki.postgresql.org/wiki/Loose_indexscan
Thanks. It talks about DISTINCT, and also about using index when you
don't have the leading column in your WHERE clause (as well as MySQL
("loose"), at least Oracle ("skip"), SQLite ("skip"), DB2 ("jump
On 6 July 2014 03:20, Tom Lane wrote:
> David Rowley writes:
> > Attached is a delta patch between version 1.2 and 1.3, and also a
> > completely updated patch.
>
> Just to note that I've started looking at this, and I've detected a rather
> significant omission: there's no check that the join o
Spent some time analyzing a severe performance regression on 9.1->9.3
upgrade for a user on IRC. Narrowed it down to this:
commit 807a40c5 fixed a bug in handling of (new in 9.2) functionality
of ScalarArrayOpExpr in btree index quals, forcing the results of
scans including such a qual to be treat
Hi,
while reading the logical decoding docs, I came across a duplicated
paragraph in doc/src/sgml/logicaldecoding.sgml - in the current
master branch, lines 108 to 115 are the same as lines 117 to 124.
I've attached a patch which removes the second instance of that
paragraph.
In case it is intende
Tom Lane wrote:
> Kevin Grittner writes:
>> typeStruct in plpy_spi.c
> No objection to removing the dead variable.
Done.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
David Rowley writes:
> Attached is a delta patch between version 1.2 and 1.3, and also a
> completely updated patch.
Just to note that I've started looking at this, and I've detected a rather
significant omission: there's no check that the join operator has anything
to do with the subquery's grou
Kevin Grittner writes:
> Commit 8b6010b8350a1756cd85595705971df81b5ffc07 eliminated the only
> usage of a variable called typeStruct in plpy_spi.c, but left the
> declaration and the code that sets a value for it. This is
> generating a warning when I build. I would have just pushed a fix,
> but
Amit Kapila writes:
> Please find the patch attached to address the above concern. I have
> updated docs, so that users can be aware of such behaviour.
I'm in the camp that says that we need to do something about this, not
just claim that it's operating as designed. AFAICS, the *entire* argumen
Kevin Grittner wrote:
> Because this review advances the patch so far, it may be feasible
> to get it committed in this CF. I'll see what is needed to get
> there and maybe have a patch toward that end in a few days.
It appears that I need to create a new execution node and a way for
SPI calls
Commit 8b6010b8350a1756cd85595705971df81b5ffc07 eliminated the only
usage of a variable called typeStruct in plpy_spi.c, but left the
declaration and the code that sets a value for it. This is
generating a warning when I build. I would have just pushed a fix,
but I was concerned that it might hav
Hello,
I'm reviewing this patch. I find this feature useful, so keep good work.
I've just begun the review of pg_hibernate.c, and finished reviewing other
files. pg_hibernate.c will probably take some time to review, so let me
give you the result of my review so far. I'm sorry for trivial c
On Wed, Jul 2, 2014 at 9:25 PM, Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
>
> On Sun, Jun 29, 2014 at 4:18 PM, David Rowley
> wrote:
>
>> I think I'm finally ready for a review again, so I'll update the
>> commitfest app.
>>
>>
> I have reviewed this on code level.
>
> 1. Patch gets
16 matches
Mail list logo
