Re: [HACKERS] GUC for cleanup indexes threshold.

Hi, On 3/15/17 9:50 AM, Amit Kapila wrote: What about if somebody does manual vacuum and there are no garbage tuples to clean, won't in that case also you want to avoid skipping the lazy_cleanup_index? Another option could be to skip updating the relfrozenxid if we have skipped the index clean

Re: [HACKERS] Measuring replay lag

Hi Thomas, On 3/15/17 8:38 PM, Simon Riggs wrote: On 16 March 2017 at 08:02, Thomas Munro wrote: I agree that these states exist, but we disagree on what 'lag' really means, or, rather, which of several plausible definitions would be the most useful here. My proposal is that the *_lag column

Re: [HACKERS] PATCH: recursive json_populate_record()

On 3/16/17 11:54 AM, David Steele wrote: On 2/1/17 12:53 AM, Michael Paquier wrote: On Thu, Jan 26, 2017 at 6:49 AM, Tom Lane wrote: Nikita Glukhov writes: On 25.01.2017 23:58, Tom Lane wrote: I think you need to take a second look at the code you're producing and realize that it

[HACKERS] Re: [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

On 3/16/17 11:56 AM, David Steele wrote: My recommendation is that we mark this patch "Returned with Feedback" to allow you time to test and refine the patch. You can resubmit once it is ready. This submission has been marked "Returned with Feedback". Please feel f

Re: [HACKERS] PATCH: Configurable file mode mask

On 3/18/17 3:57 PM, Robert Haas wrote: On Wed, Mar 15, 2017 at 3:00 AM, Tsunakawa, Takayuki wrote: I'm on David's side, too. I don't postmaster to always scan all files at startup. +1. Even just doing it during crash recovery, it can take a regrettably long time on machines with tons of re

Re: [HACKERS] perlcritic

Hi Daniel, On 3/6/17 12:02 PM, Dagfinn Ilmari Mannsåker wrote: ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes: Hi Peter, Peter Eisentraut writes: I posted this about 18 months ago but then ran out of steam. [ ] Here is an updated patch. The testing instructions below still apply. Esp

Re: [HACKERS] [WIP] RE: DECLARE STATEMENT setting up a connection in ECPG

Hi Haribabu, On 3/7/17 12:09 AM, Ideriha, Takeshi wrote: I tried applying your patches. But it failed... The error messages are as below. Attached 004_declareStmt_test_v5.patch is a rebased one. The rest of patches are same as older version. Regards, Ideriha, Takeshi You are signed up to

Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC

On 3/7/17 9:42 PM, Pavan Deolasee wrote: Fair point. I'm not going to "persist" with the idea too long. It seemed like a good, low-risk feature to me which can benefit certain use cases quite reasonably. It's not uncommon to create indexes (or reindex existing indexes to remove index bloats) on

Re: [HACKERS] Supporting huge pages on Windows

On 3/8/17 8:36 PM, Tsunakawa, Takayuki wrote: From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Ashutosh Sharma To start with, I ran the regression test-suite and didn't find any failures. But, then I am not sure if huge_pages are getting used or n

Re: [HACKERS] cast result of copyNode()

Hi Mark, On 3/9/17 3:34 PM, Peter Eisentraut wrote: On 3/7/17 18:27, Mark Dilger wrote: You appear to be using a #define macro to wrap a function of the same name with the code: #define copyObject(obj) ((typeof(obj)) copyObject(obj)) Yeah, that's a bit silly. Here is an updated version that

[HACKERS] Re: Declarative partitioning optimization for large amount of partitions

On 3/10/17 7:16 AM, Aleksander Alekseev wrote: Thanks a lot for the review! Anyone want to take a crack at reviewing this new version? Thanks, -- -David da...@pgmasters.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www

Re: [HACKERS] Should we cacheline align PGXACT?

Hi Alexander On 3/10/17 8:08 AM, Alexander Korotkov wrote: Results look good for me. Idea of committing both of patches looks attractive. We have pretty much acceleration for read-only case and small acceleration for read-write case. I'll run benchmark on 72-cores machine as well. Have you h

Re: [HACKERS] PATCH: recursive json_populate_record()

On 3/21/17 2:31 PM, Andrew Dunstan wrote: On 03/21/2017 01:37 PM, David Steele wrote: >> This thread has been idle for months since Tom's review. The submission has been marked "Returned with Feedback". Please feel free to resubmit to a future commitfest. Please rev

Re: [HACKERS] increasing the default WAL segment size

On 3/21/17 3:22 PM, Robert Haas wrote: On Tue, Mar 21, 2017 at 9:04 AM, Stephen Frost wrote: In short, I'm also concerned about this change to make WAL file names no longer match up with LSNs and also about the odd stepping that you get as a result of this change when it comes to WAL file names

[HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

Hi Alexander, On 3/11/17 7:06 AM, Pavel Stehule wrote: I am sending a updated version with separated sort direction in special variable There is a question. Has desc direction sense for columns like schema or table name? Using desc, asc for size is natural. But for tablename? Do you know wh

Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional

On 3/21/17 2:34 PM, Fujii Masao wrote: On Tue, Mar 21, 2017 at 11:03 AM, Tsunakawa, Takayuki wrote: From: David Steele [mailto:da...@pgmasters.net] Well, that's embarrassing. When I recreated the function to add defaults I messed up the AS clause and did not pay attention to the resul

Re: [HACKERS] patch proposal

On 3/21/17 8:45 PM, Venkata B Nagothi wrote: On Tue, Mar 21, 2017 at 8:46 AM, David Steele Backup recovery starts from the checkpoint in the backup_label, not from the checkpoint in pg_control. The original checkpoint that started the backup is generally overwritten in pg_control by the end

Re: [HACKERS] increasing the default WAL segment size

On 3/22/17 3:09 PM, Stephen Frost wrote: * Robert Haas (robertmh...@gmail.com) wrote: On Wed, Mar 22, 2017 at 1:49 PM, Stephen Frost wrote: Then perhaps we do need to be thinking of moving this to PG11 instead of exposing an option that users will start to use which will result in WAL naming t

Re: [HACKERS] increasing the default WAL segment size

On 3/22/17 3:39 PM, Peter Eisentraut wrote: On 3/22/17 15:37, Peter Eisentraut wrote: If changing WAL sizes catches on, I do think we should keep thinking about a new format for a future release, I think that means that I'm skeptical about changing the default size right now. I think if we d

Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional

On 3/22/17 4:42 PM, Peter Eisentraut wrote: On 3/22/17 15:14, Stephen Frost wrote: -SELECT * FROM pg_stop_backup(false); +SELECT * FROM pg_stop_backup(false [, true ]); I think that it's better to get rid of "[" and "]" from the above because IMO this should be the command example that users ac

Re: [HACKERS] increasing the default WAL segment size

Hi Robert, On 3/22/17 3:45 PM, Robert Haas wrote: On Wed, Mar 22, 2017 at 3:24 PM, David Steele wrote: One of the reasons to go with the LSN is that we would actually be maintaining what happens when the WAL files are 16MB in size. David's initial expectation was this for 64MB WAL

Re: [HACKERS] increasing the default WAL segment size

On 3/24/17 12:27 AM, Peter Eisentraut wrote: On 3/23/17 16:58, Stephen Frost wrote: The backup tools need to also get the LSN from the pg_stop_backup and verify that they have the WAL file associated with that LSN. There is a function for that. They also need to make sure that they have all

Re: [HACKERS] increasing the default WAL segment size

On 3/23/17 4:45 PM, Peter Eisentraut wrote: On 3/22/17 17:33, David Steele wrote: I think if we don't change the default size it's very unlikely I would use alternate WAL segment sizes or recommend that anyone else does, at least in v10. I simply don't think it would get the l

Re: [HACKERS] Adding the optional clause 'AS' in CREATE TRIGGER

Hi Naoki, On 3/17/17 11:58 AM, Surafel Temesgen wrote: I am sending the review of this patch This thread has been idle for a week. Please respond and/or post a new patch by 2017-03-28 00:00 AoE (UTC-12) or this submission will be marked "Returned with Feedback". -- -David da...@pgmasters

Re: [HACKERS] [PATCH] kNN for SP-GiST

On 3/21/17 11:45 AM, David Steele wrote: Hi Nikita, On 3/9/17 8:52 AM, Alexander Korotkov wrote: I take a look to this patchset. My first notes are following. This thread has been idle for quite a while. Please respond and/or post a new patch by 2017-03-24 00:00 AoE (UTC-12) or this

Re: [HACKERS] make async slave to wait for lsn to be replayed

Hi Ivan, On 3/21/17 1:06 PM, David Steele wrote: Hi Ivan, On 3/12/17 10:20 PM, Thomas Munro wrote: On Fri, Mar 10, 2017 at 1:49 AM, Ivan Kartyshov wrote: Here I attached rebased patch waitlsn_10dev_v3 (core feature) I will leave the choice of implementation (core/contrib) to the discretion

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

Hi Kaigai, On 3/21/17 1:11 PM, David Steele wrote: On 3/13/17 3:25 AM, Jeevan Chalke wrote: I have reviewed this patch further and here are my comments: This thread has been idle for over a week. Please respond and/or post a new patch by 2017-03-24 00:00 AoE (UTC-12) or this submission

Re: [HACKERS] [PATCH] Generic type subscripting

Hi Dmitry, On 3/21/17 4:42 PM, Dmitry Dolgov wrote: On 21 March 2017 at 18:16, David Steele <mailto:da...@pgmasters.net>> wrote: This thread has been idle for over a week. Yes, sorry for the late reply. I'm still trying to find a better solution for some of the problems, that

Re: [HACKERS] Index usage for elem-contained-by-const-range clauses

Hi Pritam, On 3/17/17 5:41 PM, Pritam Baral wrote: So sorry. I'm attaching the correct version of the original with this, in case you want to test the limited implementation, because I still have to go through Tom's list of suggestions. BTW, the patch is for applying on top of REL9_6_2, and wh

Re: [HACKERS] pg_stat_wal_write statistics view

On 3/16/17 1:54 AM, vinayak wrote: On 2017/03/16 14:46, Haribabu Kommi wrote: As the view name already contains WAL, I am not sure whether is it required to include WAL in every column? I am fine to change if others have the same opinion of adding WAL to column names. Ok. So what is the st

Re: [HACKERS] LWLock optimization for multicore Power machines

Hi Alexander, On 3/16/17 1:35 PM, David Steele wrote: On 2/21/17 9:54 AM, Bernd Helmle wrote: Am Dienstag, den 14.02.2017, 15:53 +0300 schrieb Alexander Korotkov: +1 And you could try to use pg_wait_sampling <https://github.com/postgrespro/pg_wait_sampling> to sampling of wait events.

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

Hi Vaishnavi, On 3/19/17 9:32 PM, Vaishnavi Prabakaran wrote: On Fri, Mar 17, 2017 at 12:37 AM, Daniel Verite Daniel, any input here? > I would also like to hear Craig's opinion on it before applying this fix > to the original patch, just to make sure am not missing anything here.

Re: [HACKERS] cast result of copyNode()

On 3/21/17 6:52 PM, Mark Dilger wrote: On Mar 21, 2017, at 2:13 PM, David Steele wrote: Hi Mark, On 3/9/17 3:34 PM, Peter Eisentraut wrote: On 3/7/17 18:27, Mark Dilger wrote: You appear to be using a #define macro to wrap a function of the same name with the code: #define copyObject(obj

Re: [HACKERS] Supporting huge pages on Windows

Hi Ashutosh, On 3/22/17 8:52 AM, Amit Kapila wrote: On Wed, Mar 22, 2017 at 12:07 AM, David Steele wrote: Amit, Magnus, you are signed up as reviewers for this patch. Do you know when you'll have a chance to take a look? I have provided my feedback and I could not test it on my ma

Re: [HACKERS] increasing the default WAL segment size

Hi Robert, On 3/24/17 3:00 PM, Robert Haas wrote: On Wed, Mar 22, 2017 at 6:05 PM, David Steele wrote: Wait, really? I thought you abandoned this approach because there's then no principled way to handle WAL segments of less than the default size. I did say that, but I thought I had h

Re: [HACKERS] patch proposal

On 3/26/17 7:34 PM, Venkata B Nagothi wrote: > Hi David, > > On Thu, Mar 23, 2017 at 4:21 AM, David Steele <mailto:da...@pgmasters.net>> wrote: > > On 3/21/17 8:45 PM, Venkata B Nagothi wrote: > > On Tue, Mar 21, 2017 at 8:46 AM, David Steele >

Re: [HACKERS] Index usage for elem-contained-by-const-range clauses

On 3/24/17 10:50 AM, David Steele wrote: Hi Pritam, On 3/17/17 5:41 PM, Pritam Baral wrote: So sorry. I'm attaching the correct version of the original with this, in case you want to test the limited implementation, because I still have to go through Tom's list of suggestions. BTW,

Re: [HACKERS] [PATCH] Incremental sort

Hi Alexander, On 3/20/17 10:19 AM, Heikki Linnakangas wrote: On 03/20/2017 11:33 AM, Alexander Korotkov wrote: Please, find rebased patch in the attachment. I had a quick look at this. <...> According to 'perf', 85% of the CPU time is spent in ExecCopySlot(). To alleviate that, it might b

Re: [HACKERS] [WIP] RE: DECLARE STATEMENT setting up a connection in ECPG

Hi Takeshi, On 3/23/17 1:33 AM, Haribabu Kommi wrote: The test patch looks good to me. This thread has been idle for five days. Please respond with a new patch by 2017-03-30 00:00 AoE (UTC-12) or this submission will be marked "Returned with Feedback". -- -David da...@pgmasters.net --

[HACKERS] Re: PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

On 3/23/17 11:27 PM, Peter Eisentraut wrote: On 3/17/17 18:35, Tomas Vondra wrote: On 03/17/2017 05:23 PM, Peter Eisentraut wrote: I'm struggling to find a good way to share code between bt_page_items(text, int4) and bt_page_items(bytea). If we do it via the SQL route, as I had suggested, it m

Re: [HACKERS] GUC for cleanup indexes threshold.

On 3/23/17 1:54 AM, Masahiko Sawada wrote: On Wed, Mar 15, 2017 at 7:51 AM, Peter Geoghegan wrote: On Tue, Mar 14, 2017 at 3:10 PM, Peter Geoghegan wrote: We already have BTPageOpaqueData.btpo, a union whose contained type varies based on the page being dead. We could just do the same with so

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Hi Pavan, On 3/28/17 11:04 AM, Robert Haas wrote: On Mon, Mar 27, 2017 at 10:25 PM, Pavan Deolasee wrote: On Tue, Mar 28, 2017 at 1:59 AM, Robert Haas wrote: On Thu, Mar 23, 2017 at 2:47 PM, Pavan Deolasee wrote: It's quite hard to say that until we see many more benchmarks. As author of t

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

Hi Thomas, On 3/28/17 1:41 AM, Rafia Sabih wrote: On Mon, Mar 27, 2017 at 12:20 PM, Thomas Munro I thought this last point about Windows might be fatal to my design, but it seems that Windows since at least version 2000 has support for Unixoid unlinkability via the special flag FILE_SHARE_DELE

Re: [HACKERS] Supporting huge pages on Windows

On 3/24/17 12:51 PM, Ashutosh Sharma wrote: Hi, On Fri, Mar 24, 2017 at 9:00 PM, David Steele wrote: Hi Ashutosh, On 3/22/17 8:52 AM, Amit Kapila wrote: On Wed, Mar 22, 2017 at 12:07 AM, David Steele wrote: Amit, Magnus, you are signed up as reviewers for this patch. Do you know when

Re: [HACKERS] GUC for cleanup indexes threshold.

On 3/29/17 2:23 AM, Masahiko Sawada wrote: On Wed, Mar 29, 2017 at 12:23 AM, David Steele wrote: On 3/23/17 1:54 AM, Masahiko Sawada wrote: On Wed, Mar 15, 2017 at 7:51 AM, Peter Geoghegan wrote: On Tue, Mar 14, 2017 at 3:10 PM, Peter Geoghegan wrote: We already have

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 3/25/17 12:12 AM, Peter Eisentraut wrote: I'm wondering if this is a perl version/platform issue around $tx->pump until $stdout =~ /[[:digit:]]+[\r\n]$/; where we're not recognising the required output from psql when we get it. What's in src/test/recovery/tmp_check/log/regress_log_011*

Re: [HACKERS] BRIN cost estimate

On 3/26/17 7:44 AM, Emre Hasegeli wrote: If we want to have a variable which stores the number of ranges, then I think numRanges is better than numBlocks. I can't imagine many people would disagree there. I renamed it with other two. At the very least please write a comment to explain this in

Re: [HACKERS] Adding support for Default partition in partitioning

On 3/29/17 8:13 AM, Rahila Syed wrote: Thanks for reporting. I have identified the problem and have a fix. Currently working on allowing adding a partition after default partition if the default partition does not have any conflicting rows. Will update the patch with both of these. The CF has

[HACKERS] Re: PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

On 3/29/17 11:08 AM, Tomas Vondra wrote: The attached patch is the best I came up with - it essentially shares just the tuple-forming part, which is exactly the same in both cases. I have marked this submission "Needs Review". -- -David da...@pgmasters.net -- Sent via pgsql-hackers mailing

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

Hi, On 3/30/17 2:12 PM, Daniel Verite wrote: Vaishnavi Prabakaran wrote: Hmm, With batch mode, after sending COPY command to server(and server started processing the query and goes into COPY state) , client does not immediately read the result , but it keeps sending other queries to th

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 3/31/17 10:46 AM, Craig Ringer wrote: Patches 1 and 2 were the key parts and thanks to Robert's helpful review, advice and edits they're committed now. Committed, done. Yay. Excellent. I have marked this a "Committed" by Robert. One down... -- -David da...@pgmasters.net -- Sent via pg

Re: [HACKERS] postgres_fdw: support parameterized foreign joins

Hi Arthur. On 3/23/17 8:45 AM, Etsuro Fujita wrote: On 2017/03/21 18:38, Etsuro Fujita wrote: On 2017/03/16 22:23, Arthur Zakirov wrote: Can you rebase the patch? It is not applied now. Ok, will do. Thanks for the report! Done. Also, I added regression tests and revised code and comment

Re: [HACKERS] Adding support for Default partition in partitioning

On 3/31/17 10:45 AM, David Steele wrote: > On 3/29/17 8:13 AM, Rahila Syed wrote: > >> Thanks for reporting. I have identified the problem and have a fix. >> Currently working on allowing >> adding a partition after default partition if the default partition does >>

Re: [HACKERS] Should we cacheline align PGXACT?

On 4/4/17 8:55 AM, Alexander Korotkov wrote: > On Mon, Apr 3, 2017 at 9:58 PM, Andres Freund > I'm inclined to push this to the next CF, it seems we need a lot more > benchmarking here. > > > No objections. This submission has been moved to CF 2017-07. Thanks, -- -David da...@pgmaste

[HACKERS] Re: PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

Hi Tomas, On 4/1/17 5:40 AM, Ashutosh Sharma wrote: > > Apart from above comments, your patch looks good to me. I have also > marked this patch as 'Waiting for Author' in the commitfest. Thanks. The CF has been extended until April 7 but time is still growing short and this thread has been idle

Re: [HACKERS] New CORRESPONDING clause design

On 4/1/17 1:54 PM, Tom Lane wrote: > > I'll set this back to Waiting on Author, but I think the chances of > getting to a committable patch before the end of the commitfest are > about nil. I think this is especially true now that another three days have passed. This submission has been marked "

Re: [HACKERS] Re: PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

On 4/4/17 9:11 AM, Simon Riggs wrote: > On 4 April 2017 at 09:05, David Steele wrote: >> Hi Tomas, >> >> On 4/1/17 5:40 AM, Ashutosh Sharma wrote: >>> >>> Apart from above comments, your patch looks good to me. I have also >>> marked this patch a

Re: [HACKERS] Re: PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

On 4/4/17 9:43 AM, Robert Haas wrote: > On Tue, Apr 4, 2017 at 9:32 AM, David Steele wrote: >> My goal is to help people focus on patches that have a chance. At this >> point I think that includes poking authors who are not being responsive >> using the limited means at

Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument

Hi Anastasia, On 3/13/17 9:14 PM, Peter Geoghegan wrote: > On Wed, Jan 25, 2017 at 3:11 PM, Peter Geoghegan wrote: >> On Wed, Jan 25, 2017 at 3:11 PM, Tom Lane wrote: >>> Please. You might want to hit the existing ones with a separate patch, >>> but it doesn't much matter; I'd be just as happy

Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional

On 4/4/17 11:42 AM, Stephen Frost wrote: > * David Steele (da...@pgmasters.net) wrote: >> On 3/22/17 4:42 PM, Peter Eisentraut wrote: >>> On 3/22/17 15:14, Stephen Frost wrote: >>>>> -SELECT * FROM pg_stop_backup(false); >>>>> +SELECT * FROM pg_s

Re: [HACKERS] Re: PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

On 4/4/17 12:55 PM, Ashutosh Sharma wrote: > > As I am not seeing any response from Tomas for last 2-3 days and since > the commit-fest is coming towards end, I have planned to work on the > review comments that I had given few days back and submit the updated > patch. PFA new version of patch tha

Re: [HACKERS] increasing the default WAL segment size

On 4/5/17 7:29 AM, Simon Riggs wrote: > On 5 April 2017 at 06:04, Beena Emerson wrote: >> >> The WALfilename - LSN mapping disruption for higher values you mean? Is >> there anything else I have missed? > > I see various issues raised but not properly addressed > > 1. we would need to drop supp

Re: [HACKERS] increasing the default WAL segment size

On 4/6/17 5:05 PM, Tomas Vondra wrote: > On 04/06/2017 08:33 PM, David Steele wrote: >> On 4/5/17 7:29 AM, Simon Riggs wrote: >> >>> 2. It's not clear to me the advantage of being able to pick varying >>> filesizes. I see great disadvantage in having too man

Re: [HACKERS] increasing the default WAL segment size

On 4/6/17 6:52 PM, Tomas Vondra wrote: > On 04/06/2017 11:45 PM, David Steele wrote: >> >> How many people in the field are running custom builds of >> Postgres? And of those, how many have changed the WAL segment size? >> I've never encountered a non-standard

Re: [HACKERS] [PATCH] Warn users about duplicate configuration parameters

On 4/7/17 11:22 AM, Tatsuo Ishii wrote: >>> Recently I've discovered that if there are multiple values of the same >>> parameter in postgresql.conf PostgreSQL will silently use the last one. >>> It looks like not the best approach to me. For instance, user can find >>> the first value in the config

Re: [HACKERS] plpgsql - additional extra checks

> On 1/13/17 6:55 AM, Marko Tiikkaja wrote: >> On Fri, Jan 13, 2017 at 2:46 AM, Jim Nasby > > wrote: >> >> On 1/11/17 5:54 AM, Pavel Stehule wrote: >> >> +too_many_rows >> + >> + >> + When result is assigned to a

Re: [HACKERS] Making clausesel.c Smarter

On 4/7/17 5:33 PM, Claudio Freire wrote: > > Also, can you add a test case? Cost values could make the test > fragile, so if that gives you trouble I'll understand, but it'd be > best to try and test this if possible. This submission has been moved to CF 2017-07. -- -David da...@pgmasters.net

Re: [HACKERS] snapbuild woes

On 3/2/17 7:54 PM, Petr Jelinek wrote: > > Yes the copy patch needs rebase as well. But these ones are fine. This bug has been moved to CF 2017-07. -- -David da...@pgmasters.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http:/

Re: [HACKERS] postgres_fdw bug in 9.6

On 4/7/17 3:24 PM, Robert Haas wrote: > > There's probably more to think about here, but those are my question > on an initial read-through. This bug has been moved to CF 2017-07. -- -David da...@pgmasters.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make chan

Re: [HACKERS] WIP: Covering + unique indexes.

On 4/4/17 2:47 PM, Peter Geoghegan wrote: > > At the very least, you should change comments to note the issue. I > think it's highly unlikely that this could ever result in a failure to > find a split point, which there are many defenses against already, but > I think I would find that difficult t

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

On 3/28/17 1:21 AM, Tsunakawa, Takayuki wrote: > From: Michael Paquier [mailto:michael.paqu...@gmail.com] >> Okay. I got the message, and I agree with what you say here. You are right >> by the way, the error messages just use "two-phase file" and not "two-phase >> STATE file", missed that previous

Re: [HACKERS] increasing the default WAL segment size

On 4/7/17 2:59 AM, Beena Emerson wrote: > I ran tests and following are the details: > > Machine details: > Architecture: ppc64le > Byte Order:Little Endian > CPU(s):192 > On-line CPU(s) list: 0-191 > Thread(s) per core:8 > Core(s) per socket:1 > Sock

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On 4/7/17 10:19 PM, Claudio Freire wrote: > > I rebased the early free patch (patch 3) to apply on top of the v9 > patch 2 (it needed some changes). I recognize the early free patch > didn't get nearly as much scrutiny, so I'm fine with commiting only 2 > if that one's ready to go but 3 isn't. >

Re: [HACKERS] Bug in to_timestamp().

On 2/27/17 4:19 AM, Artur Zakirov wrote: > On 15.02.2017 15:26, Amul Sul wrote: >> >> The new status of this patch is: Ready for Committer >> > > Thank you for your review! This submission has been moved to CF 2017-07. -- -David da...@pgmasters.net -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] Push down more UPDATEs/DELETEs in postgres_fdw

On 3/22/17 6:20 AM, Etsuro Fujita wrote: > On 2017/02/22 19:57, Rushabh Lathia wrote: >> Marked this as Ready for Committer. > > I noticed that this item in the CF app was incorrectly marked as > Committed. This patch isn't committed, so I returned it to the previous > status. I also rebased the

Re: [HACKERS] postgres_fdw: support parameterized foreign joins

On 4/7/17 9:54 AM, Arthur Zakirov wrote: > > Marked the patch as "Ready for Commiter". But the patch should be > commited only after the patch [1]. This submission has been moved to CF 2017-07. -- -David da...@pgmasters.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

[HACKERS] 2017-03 CF Closed

The commitfest has officially ended. I have pushed the remaining patches to the next commitfest or returned then with feedback as appropriate: Features moved to next CF: - new plpgsql extra_checks - Better estimate merging for duplicate vars in clausesel.c - initdb configurable wal_segment_size -

Re: [HACKERS] snapbuild woes

On 4/8/17 10:29 AM, Erik Rijkers wrote: > On 2017-04-08 15:56, Andres Freund wrote: >> On 2017-04-08 09:51:39 -0400, David Steele wrote: >>> On 3/2/17 7:54 PM, Petr Jelinek wrote: >>> > >>> > Yes the copy patch needs rebase as well. But these ones are f

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 4/15/17 12:56 PM, Robert Haas wrote: > On Fri, Apr 14, 2017 at 6:52 PM, Tom Lane wrote: >> Peter Eisentraut writes: >>> If we're talking about making things easier to understand, wouldn't a >>> random user rather know what a WAL "location" is instead of a WAL "LSN"? >> I wouldn't object to sta

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

On 7/23/17 11:48 PM, Masahiko Sawada wrote: On Sat, Jul 22, 2017 at 8:04 AM, Stephen Frost wrote: I started discussing this with David off-list and he'd like a chance to review it in a bit more detail (he's just returning from being gone for a few weeks). That review will be posted to this th

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

On 7/24/17 12:28 PM, Stephen Frost wrote: * David Steele (da...@pgmasters.net) wrote: While this patch brings pg_stop_backup() in line with the documentation, it also introduces a behavioral change compared to 9.6. Currently, the default 9.6 behavior on a standby is to return immediately

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

On 7/24/17 3:28 PM, David Steele wrote: Yes, and this is another behavioral change to consider -- one that is more likely to impact users than the change to pg_stop_backup(). If pg_basebackup is not currently waiting for WAL on a standby (but does on a primary) then that's pretty se

[HACKERS] Update low-level backup documentation to match actual behavior

As discussed in [1] our low-level backup documentation does not quite match the actual behavior of the functions on primary vs. standby. Since it appears we have decided that the remaining behavioral differences after 52f8a59dd953c68 are bugs in the documentation, the attached is a first pass at br

Re: [HACKERS] Update low-level backup documentation to match actual behavior

Robert, Thanks for reviewing! On 8/18/17 2:45 PM, Robert Haas wrote: > - the next WAL segment. The reason for the switch is to arrange for > + the next WAL segment when run on a primary. On a standby you can call > + pg_switch_wal on the primary to perform a manual > + switch. >

Re: [HACKERS] Update low-level backup documentation to match actual behavior

On 8/18/17 3:00 PM, Robert Haas wrote: > > If you update the patch I'll apply it to 11 and 10. Attached is the updated patch. I didn't like the vague "there can be some issues on the server if it crashes during the backup" so I added a new paragraph at the appropriate step to give a more detaile

Re: [HACKERS] renaming "transaction log"

On 5/2/17 9:09 PM, Peter Eisentraut wrote: > Most documentation and error messages still uses the term "transaction > log" to refer to the write-ahead log. Here is a patch to rename that, > which I think should be done, to match the xlog -> wal renaming in APIs. +1 for the idea. The documentatio

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 5/9/17 10:00 AM, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: #2: Rename all these functions and columns to "lsn", as in this patch. +1 <...> #2 strikes me as the best option, though that's probably not much of a surprise to anyone whose been following my comments on thi

Re: [HACKERS] Update low-level backup documentation to match actual behavior

Hi Michael, Thanks for reviewing! Sorry for the late response, those eclipses don't just chase themselves... On 8/20/17 10:22 PM, Michael Paquier wrote: > On Fri, Aug 18, 2017 at 3:35 AM, David Steele wrote: > > + Prior to PostgreSQL 9.6, this > Markup ? Fixed. > +

Re: [HACKERS] Update low-level backup documentation to match actual behavior

On 8/24/17 7:36 PM, Michael Paquier wrote: > > True as well. The patch looks good to me. If a committer does not show > up soon, it may be better to register that in the CF and wait. I am > not sure that adding an open item is suited, as docs have the same > problem on 9.6. Robert said he would c

Re: [HACKERS] Update low-level backup documentation to match actual behavior

On 8/25/17 3:13 PM, Robert Haas wrote: > On Fri, Aug 25, 2017 at 3:10 PM, David Steele wrote: >> >> Robert said he would commit this so I expect he'll do that if he doesn't >> have any objections to the changes. >> >> Robert, if you would prefer me

Re: [HACKERS] Update low-level backup documentation to match actual behavior

On 8/25/17 3:26 PM, Robert Haas wrote: On Fri, Aug 25, 2017 at 3:21 PM, David Steele wrote: No problem. I'll base it on your commit to capture any changes you made. Thanks, but you incorporated everything I wanted in response to my first review -- so I didn't tweak it any furthe

Re: [HACKERS] Update low-level backup documentation to match actual behavior

Hi Robert, On 8/25/17 4:03 PM, David Steele wrote: > On 8/25/17 3:26 PM, Robert Haas wrote: >> On Fri, Aug 25, 2017 at 3:21 PM, David Steele >> wrote: >>> No problem.  I'll base it on your commit to capture any changes you >>> made. >> >> T

[HACKERS] OpenFile() Permissions Refactor

Hackers, While working on the patch to allow group reads of $PGDATA I refactored the various OpenFile() functions to use default/global permissions rather than permissions defined in each call. I think the patch stands on its own regardless of whether we accept the patch to allow group permission

Re: [HACKERS] Update low-level backup documentation to match actual behavior

Hi Michael, Thanks for reviewing! On 8/29/17 9:44 PM, Michael Paquier wrote: > On Tue, Aug 29, 2017 at 10:59 PM, David Steele wrote: >> >> Attached is the 9.6 patch. It required a bit more work in func.sgml >> than I was expecting so have a close look at that. The rest w

Re: [HACKERS] Update low-level backup documentation to match actual behavior

On 8/31/17 4:04 PM, Robert Haas wrote: > On Wed, Aug 30, 2017 at 8:37 PM, Michael Paquier > wrote: >> Thanks for the new version. This looks fine to me. > > Committed to REL9_6_STABLE with minor wordsmithing. The edits look good to me. Thanks, Robert! -- -David da...@pgmasters.net -- Sent v

[HACKERS] Rename RECOVERYXLOG to RECOVERYWAL?

I searched the various threads on the xlog -> wal rename and I couldn't find any specific mention of why this was not renamed. I have attached a patch in case it was an oversight rather than left as-is on purpose. Thanks, -- -David da...@pgmasters.net diff --git a/src/backend/access/transam/xlog

Re: [HACKERS] OpenFile() Permissions Refactor

On 9/1/17 1:15 PM, Peter Eisentraut wrote: > On 8/29/17 12:15, David Steele wrote: > > I wonder whether we even need that much flexibility. We already set a > global umask, so we could just open all files with 0666 and let the > umask sort it out. Then we don't need all

Re: [HACKERS] Rename RECOVERYXLOG to RECOVERYWAL?

On 9/1/17 2:06 PM, Robert Haas wrote: > On Fri, Sep 1, 2017 at 12:57 PM, David Steele wrote: >> I searched the various threads on the xlog -> wal rename and I couldn't >> find any specific mention of why this was not renamed. >> >> I have attached a patch in c

Re: [HACKERS] Rename RECOVERYXLOG to RECOVERYWAL?

On 9/1/17 7:53 PM, Michael Paquier wrote: > On Sat, Sep 2, 2017 at 3:06 AM, Robert Haas wrote: >> I don't think this really buys us anything. If we'd applied it to v10 >> maybe, but what do we get out of whacking it around now? >> >> "Consistency", I hear you cry! Fair point. But we never had a

[HACKERS] Exclude pg_internal.init from base backup

Hackers, The cache in pg_internal.init was reused in days of yore but has been rebuilt on postmaster startup since v8.1. It appears there is no reason for this file to be backed up. I also moved the RELCACHE_INIT_FILENAME constant to relcache.h to avoid duplicating the string. I'll add this to

<    1   2   3   4   5   6   >