On Thu, May 11, 2017 at 10:15 PM, Amit Langote
wrote:
> On 2017/05/12 10:42, Robert Haas wrote:
>> On Thu, May 11, 2017 at 12:02 PM, Dilip Kumar wrote:
>>> We need to add PARTITION_STRATEGY_HASH as well, we don't support NULL
>>> for hash also, right?
>>
>> I think it should.
>>
>> Actually, I th
On Thu, May 11, 2017 at 6:16 PM, Petr Jelinek
wrote:
> On 11/05/17 10:10, Masahiko Sawada wrote:
>> On Thu, May 11, 2017 at 4:06 PM, Michael Paquier
>> wrote:
>>> On Wed, May 10, 2017 at 11:57 AM, Masahiko Sawada
>>> wrote:
Barring any objections, I'll add these two issues to open item.
>>
On Fri, May 12, 2017 at 12:56 AM, Tom Lane wrote:
> Neha Khatri writes:
> > [In case forgotten] pg_controdata and pg_waldump interfaces should also
> be
> > considered for this standardization.
>
> > Following are pg_controldata interfaces that might require change:
>
> > Latest checkpoint loc
On 2017/05/12 11:20, Robert Haas wrote:
> On Thu, May 11, 2017 at 10:15 PM, Amit Langote
> wrote:
>> On 2017/05/12 10:42, Robert Haas wrote:
>>> On Thu, May 11, 2017 at 12:02 PM, Dilip Kumar wrote:
We need to add PARTITION_STRATEGY_HASH as well, we don't support NULL
for hash also, righ
On Thu, May 11, 2017 at 10:07 AM, Rahila Syed wrote:
> Please find attached an updated patch with review comments and bugs reported
> till date implemented.
You haven't done anything about the repeated suggestion that this
should also cover range partitioning.
+/*
+ * If
On Thu, May 11, 2017 at 10:48 AM, Michael Paquier
wrote:
> Hi all,
>
> I had my eyes on the WAL sender code this morning, and I have noticed
> that walsender.c is not completely consistent with the PID lookups it
> does in walsender.c. In two code paths, the PID value is checked
> without holding
Alvaro Herrera writes:
> Hmm, yeah, makes sense. Here's a patch for this approach.
I did some code review on this patch. The attached update makes the
following hopefully-uncontroversial changes:
* fix inconsistencies in the set of fields in CreateStatsStmt
* get rid of struct CreateStatsArgu
On Thu, May 11, 2017 at 5:41 PM, Amit Khandekar wrote:
> On 11 May 2017 at 17:23, Amit Kapila wrote:
>> On Fri, Mar 17, 2017 at 4:07 PM, Amit Khandekar
>> wrote:
>>> On 4 March 2017 at 12:49, Robert Haas wrote:
On Thu, Mar 2, 2017 at 11:53 AM, Amit Khandekar
wrote:
> I think it
Neha Khatri writes:
> On Fri, May 12, 2017 at 12:56 AM, Tom Lane wrote:
>> Neha Khatri writes:
>>> Following are pg_controldata interfaces that might require change:
>>> Latest checkpoint location:
>>> Prior checkpoint location:
>>> Latest checkpoint's REDO location:
>>> Minimum recovery ending
On Wed, May 10, 2017 at 10:21 PM, Amit Langote
wrote:
>> Next update on this issue by Thursday 5/11.
>
> Attached updated patches.
Thanks. 0001, at least, really needs a pgindent run. Also, my
compiler has this apparently-justifiable complaint:
partition.c:1767:5: error: variable 'cur_op_intp'
On Mon, May 8, 2017 at 10:50 PM, Bruce Momjian wrote:
> [other stuff]
Bruce, the release notes do not mention yet that support for cleartext
passwords is removed. This has been done recently by Heikki in
eb61136d. This has as consequence that CREATE ROLE PASSWORD
UNENCRYPTED returns an error, and
Robert Haas writes:
> On Wed, May 10, 2017 at 8:39 PM, Masahiko Sawada
> wrote:
>> ... I'd like to propose to change relation
>> extension lock management so that it works using LWLock instead.
> That's not a good idea because it'll make the code that executes while
> holding that lock noninter
Michael Paquier writes:
> Bruce, the release notes do not mention yet that support for cleartext
> passwords is removed. This has been done recently by Heikki in
> eb61136d. This has as consequence that CREATE ROLE PASSWORD
> UNENCRYPTED returns an error, and that password_encryption loses its
> v
On Thu, May 11, 2017 at 5:45 PM, Amit Khandekar wrote:
> On 11 May 2017 at 17:24, Amit Kapila wrote:
>> Few comments:
>> 1.
>> Operating directly on partition doesn't allow update to move row.
>> Refer below example:
>> create table t1(c1 int) partition by range(c1);
>> create table t1_part_1 par
Andres Freund writes:
> On 2017-05-11 17:21:18 -0400, Tom Lane wrote:
>> I doubt my machine is 6X faster than yours,
>> so this indicates that the subtransaction overhead is pretty real.
> Isn't that pretty much the point? The whole open_share_lock()
> optimization looks like it really only can
On 5/11/17, 7:20 PM, "Michael Paquier" wrote:
> Browsing the code
Thanks for taking a look.
> It seems to me that you don't need those extra square brackets around
> the column list. Same remark for vacuum.sgml.
I’ll remove them. My intent was to ensure that we didn’t accidentally suggest
https://www.postgresql.org/message-id/camp0ubeo3fzzefie1vmc1ajkkrpxlnzqooaseu6o-c+...@mail.gmail.com
In that thread, I pointed out some important considerations for the
hash functions themselves. This is a follow-up, after I looked more
carefully.
1. The hash functions as they exist today are
Hello,
I found a problem with libpq connection failover. When libpq cannot connect to
earlier hosts in the host list, it doesn't try to connect to other hosts. For
example, when you specify a wrong port that some non-postgres program is using,
or some non-postgres program is using PG's port u
Hi,
When I created a subscription with copydata option that corresponds to
a publication that includes several tables, I got the following log
messages.
[7019] LOG: starting logical replication worker for subscription "hoge_sub"
[7047] LOG: logical replication apply for subscription hoge_sub st
On Fri, May 12, 2017 at 9:27 AM, Amit Kapila wrote:
> On Thu, May 11, 2017 at 5:45 PM, Amit Khandekar
> wrote:
>> On 11 May 2017 at 17:24, Amit Kapila wrote:
>>> Few comments:
>>> 1.
>>> Operating directly on partition doesn't allow update to move row.
>>> Refer below example:
>>> create table
On Fri, May 12, 2017 at 1:28 PM, Tsunakawa, Takayuki
wrote:
> Likewise, when the first host has already reached max_connections, libpq
> doesn't attempt the connection aginst later hosts.
It seems to me that the feature is behaving as wanted. Or in short
attempt to connect to the next host only
On Fri, May 12, 2017 at 7:12 AM, Robert Haas wrote:
> On Thu, May 11, 2017 at 12:02 PM, Dilip Kumar wrote:
>> We need to add PARTITION_STRATEGY_HASH as well, we don't support NULL
>> for hash also, right?
>
> I think it should.
>
+1
As long as we can hash a NULL value, we should place a value wi
On 12 May 2017 at 08:30, Amit Kapila wrote:
> On Thu, May 11, 2017 at 5:41 PM, Amit Khandekar
> wrote:
>> On 11 May 2017 at 17:23, Amit Kapila wrote:
>>> On Fri, Mar 17, 2017 at 4:07 PM, Amit Khandekar
>>> wrote:
On 4 March 2017 at 12:49, Robert Haas wrote:
> On Thu, Mar 2, 2017 at
On Fri, May 12, 2017 at 8:08 AM, Amit Langote
wrote:
> On 2017/05/12 11:20, Robert Haas wrote:
>> On Thu, May 11, 2017 at 10:15 PM, Amit Langote
>> wrote:
>>> On 2017/05/12 10:42, Robert Haas wrote:
On Thu, May 11, 2017 at 12:02 PM, Dilip Kumar
wrote:
> We need to add PARTITION_ST
On 12 May 2017 at 10:01, Amit Kapila wrote:
> On Fri, May 12, 2017 at 9:27 AM, Amit Kapila wrote:
>> On Thu, May 11, 2017 at 5:45 PM, Amit Khandekar
>> wrote:
>>> On 11 May 2017 at 17:24, Amit Kapila wrote:
Few comments:
1.
Operating directly on partition doesn't allow update to
>> 3.
>> + longer satisfy the partition constraint of the containing partition. In
>> that
>> + case, if there is some other partition in the partition tree for which
>> this
>> + row satisfies its partition constraint, then the row is moved to that
>> + partition. If there isn't such a p
Hi Rahila,
On Thu, May 11, 2017 at 7:37 PM, Rahila Syed wrote:
>
> >3.
> >In following function isDefaultPartitionBound, first statement "return
> false"
> >is not needed.
> It is needed to return false if the node is not DefElem.
>
Please have a look at following code:
+ * Returns true if the
På torsdag 11. mai 2017 kl. 23:37:27, skrev Yaroslav mailto:ladayaros...@yandex.ru>>:
Ilya Shkuratov wrote
> First of all, to such replacement to be valid, the CTE must be
> 1. non-writable (e.g. be of form: SELECT ...),
> 2. do not use VOLATILE or STABLE functions,
> 3. ... (maybe
Hello people,
I was trying to build an extension(Index related) on top of postgres.
During startup (_PG_init), I need to access some meta info of
table/relation (like PK Column Position, FK Column Positions, Index Column
Positions etc...) and load it into memory.
To accomplish that, In _PG_init(
101 - 129 of 129 matches
Mail list logo
