On Mon, Jul 03, 2017 at 09:12:01AM +0530, Amit Kapila wrote:
> While discussing the behavior of hash indexes with Bruce in the nearby
> thread [1], it has been noticed that hash index on unlogged tables
> doesn't behave as expected. Prior to 10, it has the different set of
> problems (mainly

Hi Dean,
On 2017/07/05 23:18, Dean Rasheed wrote:
> On 5 July 2017 at 10:43, Amit Langote wrote:
>> In retrospect, that sounds like something that was implemented in the
>> earlier versions of the patch, whereby there was no ability to specify
>> UNBOUNDED on a

To make the queries fired by the RI triggers GIN indexed. We need to ‒ as
Tom Lane has previously suggested[1] ‒ to replace the query
SELECT 1 FROM ONLY fktable x WHERE $1 = ANY (fkcol) FOR SHARE OF x;
with
SELECT 1 FROM ONLY fktable x WHERE ARRAY[$1]

Michael,
> Couldn't you cache one single SASL exchange status for each
> connection, meaning one PGconn saved for each? As the challenge sent
> by the server and the response generated by the client are different
> by design, I am afraid you would need to do that anyway in this
> context (Isn't

Hi PostgreSQL hackers,
I would like to hear ideas how Pgpool-II can deal with SCRAM auth
which will be in PostgreSQL 10.
For those who are not familiar with Pgpool-II[1], it is an external
OSS project to provide some additional features to PostgreSQL,
including load balancing and automatic

On Thu, Jul 6, 2017 at 2:41 AM, Peter Eisentraut
wrote:
> On 7/2/17 20:28, Michael Paquier wrote:
>>> I was going to hold this back for PG11, but since we're now doing some
>>> other tweaks in pg_ctl, it might be useful to add this too. Thoughts?
>>
>> The use

On Thu, Jul 6, 2017 at 12:45 AM, Ryan Murphy wrote:
> I tried to apply your patch to HEAD and it failed.
> But I think that's because some version of it has already been committed,
> correct? I see some of your ECONNRESET and "SSL connection has been closed
>

I wrote:
> (Pokes at it some more...) Oh, interesting: it behaves that way except
> when p is exactly the lowest histogram entry.
Here's a revised version that addresses that point and cleans up some
other minor details about treatment of cases near the histogram endpoints.
I'm still pretty

On 7/2/17 20:28, Michael Paquier wrote:
>> I was going to hold this back for PG11, but since we're now doing some
>> other tweaks in pg_ctl, it might be useful to add this too. Thoughts?
>
> The use of 0 as exit code for the new promote -w if timeout is reached
> looks like an open item to me.

Noah Misch wrote:
> The above-described topic is currently a PostgreSQL 10 open item. Peter,
> since you committed the patch believed to have created it, you own this open
> item.
I volunteer to own this item. My next update is going to be on or
before Friday 7th at 19:00 Chilean time, though

On 5 July 2017 at 10:43, Amit Langote wrote:
> In retrospect, that sounds like something that was implemented in the
> earlier versions of the patch, whereby there was no ability to specify
> UNBOUNDED on a per-column basis. So the syntax was:
>
> FROM { (x [,

On 2017/07/05 15:28, Michael Paquier wrote:
I have finally been able to look at this patch.
Thanks for reviewing and the new version of the patch.
(Surprised to see that generate_unaccent_rules.py is inconsistent on
MacOS, runs fine on Linux).
def get_plain_letter(codepoint, table):

Hi Michael,
I tried to apply your patch to HEAD and it failed. But I think that's because
some version of it has already been committed, correct? I see some of your
ECONNRESET and "SSL connection has been closed unexpectedly" code already in
HEAD.
Best,
Ryan
The new status of this patch

On 5 July 2017 at 10:43, Amit Langote wrote:
>> So the more I think about this, the more I think that a cleaner design
>> would be as follows:
>>
>> 1). Don't allow UNBOUNDED, except in the first column, where it can
>> keep it's current meaning.
>>
>> 2). Allow

On Wed, Jul 05, 2017 at 03:33:45PM +1000, AP wrote:
> > Do you have any deletes? How have you verified whether autovacuum has
>
> No DELETEs. Just the initial COPY, then SELECTs, then a DB rename to get it
> out of the way of other testing, then the REINDEX.
>
> > been triggered or not?
>
> I

On Wed, Jul 05, 2017 at 10:29:09AM +0530, Amit Kapila wrote:
> >> bitmappages. Can you try to use pgstattuple extension and get us the
> >> results of Select * from pgstathashindex('index_name');? If the
> >> number of bitmappages is 128 and total overflow pages are 128 * 4096,
> >> then that

Hi,
On Wed, Jul 5, 2017 at 3:58 PM, Ashutosh Bapat
wrote:
> On Wed, Jul 5, 2017 at 3:48 PM, Ashutosh Sharma wrote:
>> Hi All,
>>
>> Today while exploring a bit on Range table partitioning, I could see
>> that even if scan is performed on a

On 3 Jul. 2017 23:01, "K S, Sandhya (Nokia - IN/Bangalore)" <
sandhya@nokia.com> wrote:
Hi Craig,
Thanks for the response.
Scenario tried here is restart of the system multiple times. sh-QUIT core
is generated when Postgres is invoking the shell to exit and may not be due
to kernel or file

On Wed, Jul 5, 2017 at 11:03 AM, AP wrote:
> On Wed, Jul 05, 2017 at 10:29:09AM +0530, Amit Kapila wrote:
>> >> bitmappages. Can you try to use pgstattuple extension and get us the
>> >> results of Select * from pgstathashindex('index_name');? If the
>> >> number of bitmappages

On Wed, Jul 5, 2017 at 3:48 PM, Ashutosh Sharma wrote:
> Hi All,
>
> Today while exploring a bit on Range table partitioning, I could see
> that even if scan is performed on a single partition, the plan node
> has Append node in it. Isn't it a bug?
No. See following

Hi All,
Today while exploring a bit on Range table partitioning, I could see
that even if scan is performed on a single partition, the plan node
has Append node in it. Isn't it a bug?
As per the usage of Append Node, it should only be seen in the
queryplan when scan is performed on multiple

Hi Dean,
On 2017/07/04 16:49, Dean Rasheed wrote:
> On 3 July 2017 at 10:32, Amit Langote wrote:
>> On 2017/07/03 17:36, Dean Rasheed wrote:
>>> The bigger question is do we want this for PG10? If so, time is
>>> getting tight. My feeling is that we do, because

On Wed, Jul 5, 2017 at 10:19 AM, Masahiko Sawada wrote:
> I feel that since we cannot switch the WAL forcibly on the standby
> server we need to find a new way to do so. I'm not sure but it might
> be a hard work and be late for PG10. Or you meant that you have a idea
> for

On Wed, Jul 5, 2017 at 2:57 PM, Ryan Murphy wrote:
> I tried to apply your patch to test it (though reading Robert's last comment
> it seems we wish to have it adjusted before committing)... but in any case I
> was not able to apply your patch to the tip of the master

Thanks guys!
The expectation is that the patch will be applied to HEAD, so it should
> apply to HEAD. If not, the custom is to ask the author for a rebase.
>
>
Makes sense! I'll do that.
(I've taken to running a cronjob that tells me when patches I've
> posted no longer apply, so I can rebase