Re: [HACKERS] Proposal : For Auto-Prewarm.

On Wed, Jul 5, 2017 at 6:25 PM, Mithun Cy wrote: > On Mon, Jul 3, 2017 at 3:34 PM, Amit Kapila wrote: >> >> Few comments on the latest patch: >> >> 1. >> + LWLockRelease(_state->lock); >> + if (!is_bgworker) >> + ereport(ERROR, >> +

Re: [HACKERS] pgsql 10: hash indexes testing

On Thu, Jul 6, 2017 at 2:40 AM, AP wrote: > On Wed, Jul 05, 2017 at 05:52:32PM +0530, Amit Kapila wrote: >> >> > version | bucket_pages | overflow_pages | bitmap_pages | unused_pages >> >> > | live_items | dead_items | free_percent >> >> >

Re: [HACKERS] hash index on unlogged tables doesn't behave as expected

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

Re: [HACKERS] Multi column range partition table

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

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

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] <@ fkcol FOR SHARE OF x; but since we have

Re: [HACKERS] SCRAM auth and Pgpool-II

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

Re: [HACKERS] SCRAM auth and Pgpool-II

On Thu, Jul 6, 2017 at 10:03 AM, Tatsuo Ishii wrote: > For Pgpool-II, things would go as follows: > > 1) clients sends user name to Pgpool-II. > 2) Pgpool-II forwards it to PostgreSQL servers. > 3) Each PostgreSQL server sends their own salt to Pgpool-II. > 4) Pgpool-II is

Re: [HACKERS] Suspicious place in heap_prepare_freeze_tuple()

Masahiko Sawada wrote: > On Thu, Jul 6, 2017 at 1:36 AM, Alvaro Herrera > wrote: > > Teodor Sigaev wrote: > > > >> Playing around freezing tuple I found suspicious piece of code: > >> > >> heap_prepare_freeze_tuple(): > >> ... > >> frz->t_infomask = tuple->t_infomask; >

[HACKERS] SCRAM auth and Pgpool-II

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

Re: [HACKERS] Suspicious place in heap_prepare_freeze_tuple()

On Thu, Jul 6, 2017 at 1:36 AM, Alvaro Herrera wrote: > Teodor Sigaev wrote: > >> Playing around freezing tuple I found suspicious piece of code: >> >> heap_prepare_freeze_tuple(): >> ... >> frz->t_infomask = tuple->t_infomask; >> ... >> frz->t_infomask &=

Re: [HACKERS] Re: pg_ctl wait exit code (was Re: [COMMITTERS] pgsql: Additional tests for subtransactions in recovery)

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

Re: [HACKERS] Re: Error-like LOG when connecting with SSL for password authentication

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 >

Re: [HACKERS] WIP patch: distinguish selectivity of < from <= and > from >=

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

Re: [HACKERS] pgsql 10: hash indexes testing

On Wed, Jul 05, 2017 at 05:52:32PM +0530, Amit Kapila wrote: > >> > version | bucket_pages | overflow_pages | bitmap_pages | unused_pages | > >> > live_items | dead_items | free_percent > >> >

Re: [HACKERS] Re: pg_ctl wait exit code (was Re: [COMMITTERS] pgsql: Additional tests for subtransactions in recovery)

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.

Re: [HACKERS] More race conditions in logical replication

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

Re: [HACKERS] Multi column range partition table

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 [,

Re: [HACKERS] Suspicious place in heap_prepare_freeze_tuple()

Teodor Sigaev wrote: > Playing around freezing tuple I found suspicious piece of code: > > heap_prepare_freeze_tuple(): > ... > frz->t_infomask = tuple->t_infomask; > ... > frz->t_infomask &= ~HEAP_XMAX_BITS; > frz->xmax = newxmax; > if (flags &

[HACKERS] Suspicious place in heap_prepare_freeze_tuple()

Hi! Playing around freezing tuple I found suspicious piece of code: heap_prepare_freeze_tuple(): ... frz->t_infomask = tuple->t_infomask; ... frz->t_infomask &= ~HEAP_XMAX_BITS; frz->xmax = newxmax; if (flags & FRM_MARK_COMMITTED)

Re: [HACKERS] Extra Vietnamese unaccent rules

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):

[HACKERS] Re: Error-like LOG when connecting with SSL for password authentication

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

Re: [HACKERS] outfuncs.c utility statement support

On 6/21/17 23:40, Tom Lane wrote: > Peter Eisentraut writes: >> On 6/18/17 10:14, Tom Lane wrote: >>> Doesn't cope with backslash-quoted characters. If we're going to bother >>> to do anything here, I think we ought to make it reversible for all >>> possible

Re: [HACKERS] Multi column range partition table

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

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

> On Jul 5, 2017, at 5:30 AM, Amit Kapila wrote: > > On Wed, Jul 5, 2017 at 9:44 AM, Mark Dilger wrote: >> >>> On Jul 3, 2017, at 10:25 PM, Amit Kapila wrote: >>> >>> On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs

Re: [HACKERS] pgsql 10: hash indexes testing

On Tue, Jul 04, 2017 at 08:23:20PM -0700, Jeff Janes wrote: > On Tue, Jul 4, 2017 at 3:57 AM, AP wrote: > > The data being indexed is BYTEA, (quasi)random and 64 bytes in size. > > The table has over 2 billion entries. The data is not unique. There's > > an average of 10

Re: [HACKERS] pgsql 10: hash indexes testing

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

Re: [HACKERS] pgsql 10: hash indexes testing

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

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Mon, Jul 3, 2017 at 3:34 PM, Amit Kapila wrote: > > Few comments on the latest patch: > > 1. > + LWLockRelease(_state->lock); > + if (!is_bgworker) > + ereport(ERROR, > + (errmsg("could not perform block dump because dump file is being > used by PID %d", > +

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Mon, Jul 3, 2017 at 11:58 AM, Amit Kapila wrote: > On Sun, Jul 2, 2017 at 10:32 PM, Mithun Cy wrote: >> On Tue, Jun 27, 2017 at 11:41 AM, Mithun Cy >> wrote: >>> On Fri, Jun 23, 2017 at 5:45 AM, Thom Brown

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Mon, Jul 3, 2017 at 3:55 PM, Amit Kapila wrote: > On Fri, Jun 23, 2017 at 3:22 AM, Robert Haas wrote: >> On Thu, Jun 15, 2017 at 12:35 AM, Mithun Cy >> wrote: >> >> * Instead of creating our own buffering system via

Re: [HACKERS] Partition : Append node over a single SeqScan

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

Re: [HACKERS] Postgres process invoking exit resulting in sh-QUIT core

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

Re: [HACKERS] [POC] hash partitioning

On Wed, Jul 5, 2017 at 4:50 PM, Dilip Kumar wrote: > On Mon, Jul 3, 2017 at 4:39 PM, amul sul wrote: >> Thanks to catching this, fixed in the attached version. > > Few comments on the latest version. > Thanks for your review, please find my comment

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

On Wed, Jul 5, 2017 at 9:44 AM, Mark Dilger wrote: > >> On Jul 3, 2017, at 10:25 PM, Amit Kapila wrote: >> >> On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs wrote: >>> On 30 June 2017 at 05:14, Amit Kapila

Re: [HACKERS] pgsql 10: hash indexes testing

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

Re: [HACKERS] Parallel Append implementation

On 30 June 2017 at 15:10, Rafia Sabih wrote: > > On Tue, Apr 4, 2017 at 12:37 PM, Amit Khandekar > wrote: >> >> Attached is an updated patch v13 that has some comments changed as per >> your review, and also rebased on latest master. > > >

Re: [HACKERS] [POC] hash partitioning

On Mon, Jul 3, 2017 at 4:39 PM, amul sul wrote: > Thanks to catching this, fixed in the attached version. Few comments on the latest version. 0001 looks fine, for 0002 I have some comments. 1. + hbounds = (PartitionHashBound * *) palloc(nparts * + sizeof(PartitionHashBound

Re: [HACKERS] Partition : Append node over a single SeqScan

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

[HACKERS] Partition : Append node over a single SeqScan

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

Re: [HACKERS] Multi column range partition table

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

Re: [HACKERS] UPDATE of partition key

On 4 July 2017 at 15:23, Amit Khandekar wrote: > On 4 July 2017 at 14:48, Amit Khandekar wrote: >> On 4 July 2017 at 14:38, Amit Langote wrote: >>> On 2017/07/04 17:25, Etsuro Fujita wrote: On 2017/07/03 18:54,

Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server

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

Re: [HACKERS] Small patch for pg_basebackup argument parsing

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

Re: [HACKERS] Extra Vietnamese unaccent rules

On Wed, Jun 7, 2017 at 1:06 AM, Man Trieu wrote: > 2017-06-07 0:31 GMT+09:00 Bruce Momjian : >> >> On Wed, Jun 7, 2017 at 12:10:25AM +0900, Dang Minh Huong wrote: >> > > On Jun 4, 29 Heisei, at 00:48, Bruce Momjian wrote: >> >

Re: [HACKERS] CommitFest 2017-09 - How do I know what commit to apply patches to

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