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

Robert, On Fri, Aug 4, 2017 at 23:17 Robert Haas wrote: > On Thu, Aug 3, 2017 at 9:49 PM, Stephen Frost wrote: > > Thanks for the patches. I'm planning to push them tomorrow morning > > after a bit more review and testing. I'll provide an update

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

On Thu, Aug 3, 2017 at 9:49 PM, Stephen Frost wrote: > Thanks for the patches. I'm planning to push them tomorrow morning > after a bit more review and testing. I'll provide an update tomorrow. Obviously, the part about pushing them Friday morning didn't happen, and you're

Re: [HACKERS] pgsql 10: hash indexes testing

On Fri, Aug 4, 2017 at 2:45 PM, Amit Kapila wrote: > I have not done anything for this comment as it doesn't sound wrong to > me. I think it is not making much sense in the current code and we > can remove it or change it as part of the separate patch if you or > others

Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()

On Thu, Aug 3, 2017 at 8:45 PM, Amit Langote wrote: >> 0003 needs a rebase. > > Rebased patch attached. Committed. I think 0004 is a new feature, so I'm leaving that for v11. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL

Re: [HACKERS] Subscription code improvements

On 8/4/17 12:02, Masahiko Sawada wrote: > To make ALTER SUBSCRIPTION REFRESH being transactional, I prefer > Petr's proposal. Because it can make ALTER SUBSCRIPTION and DROP > SUBSCRIPTION stop the table sync workers that are in progress of > copying data. I'm not sure killing table sync workers

Re: [HACKERS] [WIP] Zipfian distribution in pgbench

On Fri, Jul 21, 2017 at 4:51 AM, Alik Khilazhev wrote: > (Latest version of pgbench Zipfian patch) While I'm +1 on this idea, I think that it would also be nice if there was an option to make functions like random_zipfian() actually return a value that has undergone

[HACKERS] Draft release notes up for review

I've committed the first-draft release notes for 9.6.4 at https://git.postgresql.org/pg/commitdiff/03378c4da598840b0520a53580dd7713c95f21c8 (If you prefer to read nicely-marked-up copy, they should be up at https://www.postgresql.org/docs/devel/static/release-9-6-4.html in a couple hours from

Re: LP_DEAD hinting and not holding on to a buffer pin on leaf page (Was: [HACKERS] [WIP] Zipfian distribution in pgbench)

On Mon, Jul 31, 2017 at 10:54 AM, Peter Geoghegan wrote: > Let's wait to see what difference it makes if Alik's zipfian > distribution pgbench test case uses unlogged tables. That may gives us a > good sense of the problem for cases with contention/concurrency. Yura Sokolov of

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

Shay Rojansky writes: > Great. Do you think it's possible to backport to the other maintained > branches as well, seeing as how this is quite trivial and low-impact? Already done, will be in next week's minor releases. (You timed this bug report well.)

Re: [HACKERS] pgsql 10: hash indexes testing

On Fri, Aug 4, 2017 at 2:49 PM, Amit Kapila wrote: > On Fri, Aug 4, 2017 at 10:59 PM, Robert Haas wrote: >> On Fri, Aug 4, 2017 at 6:22 AM, Amit Kapila wrote: >>> I have increased the number of hash bitmap pages as a

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

> > > Doing SSL_CTX_set_session_cache_mode(context, SSL_SESS_CACHE_OFF) > doesn't > > have any effect whatsoever - I still have the same issue (session id > > context uninitialized). I suspect session caching is an entirely > different > > feature from session tickets/RFC5077 (although it might

Re: [HACKERS] pgsql 10: hash indexes testing

On Fri, Aug 4, 2017 at 10:59 PM, Robert Haas wrote: > On Fri, Aug 4, 2017 at 6:22 AM, Amit Kapila wrote: >> I have increased the number of hash bitmap pages as a separate patch. >> I am not completely sure if it is a good idea to directly increase

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

> > On 2017-08-04 07:22:42 +0300, Shay Rojansky wrote: > > I'm still not convinced of the risk/problem of simply setting the session > > id context as I explained above (rather than disabling the optimization), > > but of course either solution resolves my problem. > > How would that do anything?

Re: [HACKERS] pgsql 10: hash indexes testing

On Fri, Aug 4, 2017 at 11:45 PM, Amit Kapila wrote: > On Fri, Aug 4, 2017 at 11:15 PM, Robert Haas wrote: >> On Fri, Aug 4, 2017 at 6:22 AM, Amit Kapila wrote: >>> I have implemented the patch with this approach as other

Re: [HACKERS] Small code improvement for btree

On Fri, Aug 4, 2017 at 11:12 AM, Alvaro Herrera wrote: > Interesting. We learned elsewhere that it's better to integrate the > "!= 0" test as part of the macro definition; so a > better formulation of this patch would be to change the > P_INCOMPLETE_SPLIT macro and omit

Re: [HACKERS] pgsql 10: hash indexes testing

On Fri, Aug 4, 2017 at 11:15 PM, Robert Haas wrote: > On Fri, Aug 4, 2017 at 6:22 AM, Amit Kapila wrote: >> I have implemented the patch with this approach as other approach >> require quite extensive changes which I am not sure is the right thing

Re: [HACKERS] Small code improvement for btree

Masahiko Sawada wrote: > While hacking the btree code I found two points we can improve in nbtxlog.c. > > @@ -135,7 +135,7 @@ _bt_clear_incomplete_split(XLogReaderState > *record, uint8 block_id) > Pagepage = (Page) BufferGetPage(buf); > BTPageOpaque

Re: [HACKERS] Page Scan Mode in Hash Index

On Fri, Aug 4, 2017 at 9:44 AM, Amit Kapila wrote: > There is no need to use Parentheses around opaque. I mean there is no > problem with that, but it is redundant and makes code less readable. Amit, I'm sure you know this, but just for the benefit of anyone who

Re: [HACKERS] pgsql 10: hash indexes testing

Robert Haas wrote: > I think this approach is actually better anyway. There's no guarantee > that VACUUM can be responsive enough to get the job done in time, work > items or no work items, Yeah, autovacuum work items don't have a guaranteed response time. They're okay for things that "ought to

Re: [HACKERS] pgsql 10: hash indexes testing

On Fri, Aug 4, 2017 at 6:22 AM, Amit Kapila wrote: > I have implemented the patch with this approach as other approach > require quite extensive changes which I am not sure is the right thing > to do at this stage. I think this approach is actually better anyway.

Re: [HACKERS] pgsql 10: hash indexes testing

On Fri, Aug 4, 2017 at 6:22 AM, Amit Kapila wrote: > I have increased the number of hash bitmap pages as a separate patch. > I am not completely sure if it is a good idea to directly increase it > to 1024 as that will increase the size of hashmetapagedata from 960 > bytes

Re: [HACKERS] expanding inheritance in partition bound order

On Fri, Aug 4, 2017 at 3:38 AM, Amit Langote wrote: > The current way to expand inherited tables, including partitioned tables, > is to use either find_all_inheritors() or find_inheritance_children() > depending on the context. They return child table OIDs in the

Re: [HACKERS] UPDATE of partition key

> > Below are the TODOS at this point : > > Fix for bug reported by Rajkumar about update with join. I had explained the root issue of this bug here : [1] Attached patch includes the fix, which is explained below. Currently in the patch, there is a check if the tuple is concurrently deleted by

Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL

On Fri, Aug 4, 2017 at 5:50 PM, Tom Lane wrote: > Michael Paquier writes: >> So I think that the attached patch is able to do the legwork. > > I've pushed this into HEAD. It seems like enough of a behavioral > change that we wouldn't want to

Re: [HACKERS] Subscription code improvements

On Fri, Aug 4, 2017 at 2:17 AM, Peter Eisentraut wrote: > On 7/13/17 23:53, Masahiko Sawada wrote: >> To summary, I think we now have only one issue; ALTER SUBSCRIPTION is >> not transactional, 0004 patch is addressing this issue . > > We have two competing

Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL

Michael Paquier writes: > So I think that the attached patch is able to do the legwork. I've pushed this into HEAD. It seems like enough of a behavioral change that we wouldn't want to back-patch, but IMO it's not too late to be making this type of change in v10. If

Re: [HACKERS] Default Partition for Range

On Mon, Jul 31, 2017 at 8:28 AM, Beena Emerson wrote: > Thanks for informing. > PFA the updated patch. > I have changed the numbering of enum PartitionRangeDatumKind since I > have to include DEFAULT as well. If you have better ideas, let me > know. Why do we need to

Re: [HACKERS] Page Scan Mode in Hash Index

On Sun, Jul 30, 2017 at 2:07 PM, Ashutosh Sharma wrote: > Hi, > > On Wed, May 10, 2017 at 2:28 PM, Ashutosh Sharma > wrote: >> While doing the code coverage testing of v7 patch shared with - [1], I >> found that there are few lines of code in

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

On Fri, Aug 4, 2017 at 3:24 AM, Fabien COELHO wrote: > >>> For the CREATE stuff, the script language is SQL, the command to use it >>> is >>> "psql"... >> >> >>> The real and hard part is to fill tables with meaningful pseudo-random >>> test data which do not violate

Re: [HACKERS] expanding inheritance in partition bound order

On Fri, Aug 4, 2017 at 1:08 PM, Amit Langote wrote: > The current way to expand inherited tables, including partitioned tables, > is to use either find_all_inheritors() or find_inheritance_children() > depending on the context. They return child table OIDs in the

Re: [HACKERS] More flexible LDAP auth search filters?

On 01/08/17 23:17, Thomas Munro wrote: > On Wed, Aug 2, 2017 at 5:36 AM, Peter Eisentraut > wrote: >> On 7/16/17 19:09, Thomas Munro wrote: >>> On Mon, Jul 17, 2017 at 10:26 AM, Thomas Munro >>> wrote:

Re: [HACKERS] pgsql 10: hash indexes testing

On Fri, Aug 4, 2017 at 9:19 AM, AP wrote: > On Fri, Aug 04, 2017 at 08:21:01AM +0530, Amit Kapila wrote: >> Note - AP has off list shared the data dump and we (Ashutosh Sharma >> and me) are able to reproduce the problem and we could see that if we >> force vacuum via the

Re: [HACKERS] pgsql 10: hash indexes testing

On Fri, Aug 04, 2017 at 08:21:01AM +0530, Amit Kapila wrote: > Note - AP has off list shared the data dump and we (Ashutosh Sharma > and me) are able to reproduce the problem and we could see that if we > force vacuum via the debugger, then it is able to free overflow pages. > The exact numbers

Re: [HACKERS] pgsql 10: hash indexes testing

On Fri, Aug 4, 2017 at 8:21 AM, Amit Kapila wrote: > On Wed, Aug 2, 2017 at 9:04 PM, Robert Haas wrote: >> On Wed, Jul 12, 2017 at 1:10 AM, Amit Kapila wrote: > Yes, I also think the same idea can be used, in fact, I

Re: [HACKERS] reload-through-the-top-parent switch the partition table

Here is an update patch, now renamed the switch to --load-via-partition-root and also added the documentation for the new switch into pg_dump as well as pg_dumpall. On Fri, Aug 4, 2017 at 7:13 AM, Amit Langote wrote: > On 2017/08/04 1:08, David G. Johnston

[HACKERS] scan on inheritance parent with no children in current session

Hi All, Consider a parent table which has no child in the current session, but has temporary children in other sessions. Session 1 postgres=# create table parent (a int); CREATE TABLE Session 2: postgres=# create temp table temp_child () inherits(parent); CREATE TABLE Before commit

[HACKERS] Small code improvement for btree

Hi, While hacking the btree code I found two points we can improve in nbtxlog.c. @@ -135,7 +135,7 @@ _bt_clear_incomplete_split(XLogReaderState *record, uint8 block_id) Pagepage = (Page) BufferGetPage(buf); BTPageOpaque pageop = (BTPageOpaque)

Re: [HACKERS] UPDATE of partition key

On 2017/08/02 19:49, Amit Khandekar wrote: > On 2 August 2017 at 14:38, Amit Langote wrote: >>> One approach I had considered was to have find_inheritance_children() >>> itself lock the children in bound order, so that everyone will have >>> bound-ordered oids, but

[HACKERS] expanding inheritance in partition bound order

The current way to expand inherited tables, including partitioned tables, is to use either find_all_inheritors() or find_inheritance_children() depending on the context. They return child table OIDs in the (ascending) order of those OIDs, which means the callers that need to lock the child tables

Re: [HACKERS] Support for Secure Transport SSL library on macOS as OpenSSL alternative

On Thu, Aug 3, 2017 at 11:26 PM, Daniel Gustafsson wrote: >> On 03 Aug 2017, at 19:27, Michael Paquier wrote: >> There were no APIs to get the TLS finish message last time I looked at OSX >> stuff, which mattered for tls-unique. It would be nice if we

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Fri, Jul 28, 2017 at 2:24 PM, Noah Misch wrote: > On Thu, Apr 06, 2017 at 08:55:37AM +0200, Petr Jelinek wrote: >> On 06/04/17 03:51, Noah Misch wrote: >> > On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao wrote: >> >> On Wed, Apr 5, 2017 at 3:45 PM, Noah Misch