Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

On Mon, Nov 26, 2018 at 5:40 PM Vik Fearing wrote: > > On 23/11/2018 00:09, Haribabu Kommi wrote: > > > > On Fri, Nov 23, 2018 at 1:54 AM Peter Eisentraut > > > > wrote: > > > > On 19/11/2018 06:18, Haribabu Kommi wrote: > > > Amit suggested

RE: idle-in-transaction timeout error does not give a hint

>From: Tatsuo Ishii [mailto:is...@sraoss.co.jp] >Sent: Wednesday, November 28, 2018 12:18 PM >To: pgsql-hackers@lists.postgresql.org >Subject: idle-in-transaction timeout error does not give a hint > >idle-in-transaction timeout error closed the session. I think in this case the >error >message

psql --csv and other parameters

I don't know if this really is a bug but it seems wrong to me: psql -A --csv -Xc "select * from pg_namespace order by 1" gives a difference result than psql --csv -A -Xc "select * from pg_namespace order by 1" I would say both should give the same result, and that result should be the same

Unnecessary asterisk in comment in postgres_fdw.c

Here is a small patch for removing $SUBJECT. Best regards, Etsuro Fujita diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c index a5830bb..d22c974 100644 --- a/contrib/postgres_fdw/postgres_fdw.c +++ b/contrib/postgres_fdw/postgres_fdw.c @@ -2887,7 +2887,7 @@

Re: Minor typo

This is a noise from a Japanese having poor English skill.. At Wed, 28 Nov 2018 10:01:36 +0900, Michael Paquier wrote in <20181128010136.gu1...@paquier.xyz> > On Tue, Nov 27, 2018 at 07:51:03PM -0500, Stephen Frost wrote: > > That isn't at all what I got from that. > > > > A rewrite of this

Re: Planning time of Generic plan for a table partitioned into a lot

On 2018/11/28 13:46, Amit Langote wrote: > It's cheaper than using a cached generic plan (without re-planning), > because the latter has to pay the cost of AcquireExecutorLocks which takes > longer as the number of partitions increases. Perhaps something to try > fix fixing too. Not planning

Re: "pg_ctl: the PID file ... is empty" at end of make check

Thomas Munro writes: > On Wed, Nov 28, 2018 at 5:28 PM Tom Lane wrote: >> So my theory is we broke something in HEAD a couple weeks ago. But what? > Hmm. Not seeing it. I'm trying to do it again, with a make check loop. >> The fsync changes you made are suspiciously close to this issue (ie

Re: Tab completion for ALTER INDEX|TABLE ALTER COLUMN SET STATISTICS

On 2018/11/28 13:14, Kyotaro HORIGUCHI wrote: Hello. At Wed, 28 Nov 2018 11:27:23 +0900, Tatsuro Yamada wrote in Hi, On 2018/11/26 11:05, Tatsuro Yamada wrote: I couldn't write patches details on previous email, so I write more explanation for that on this email. *

RE: Copy data to DSA area

Hi >From: Thomas Munro [mailto:thomas.mu...@enterprisedb.com] >Sent: Wednesday, November 14, 2018 9:50 AM >To: Ideriha, Takeshi/出利葉 健 > >On Tue, Nov 13, 2018 at 10:59 PM Ideriha, Takeshi > >wrote: >> Can I check my understanding? >> The situation you are talking about is the following: >> Data

Re: vacuum and autovacuum - is it good to configure the threshold at TABLE LEVEL?

On Wed, Nov 28, 2018 at 9:11 AM rajan wrote: > > Thanks, amul. I have already gone through this. What I would like to > understand is the performance impact on autovacuum launcher and worker > process when autovacuum is running from configurations done by > *ALTER TABLE autvac_test SET

Re: Planning time of Generic plan for a table partitioned into a lot

Hi Kato-san, On 2018/11/27 19:05, Kato, Sho wrote: > Of course, in case of plan_cache_mode = force_custom_plan, it is not problem > because unnecessary paths are pruned by speeding up planning with partitions > patch[1]. > > However, if plan_cachemode is force_generic_plan, generic plan is

Re: postgres_fdw: oddity in costing aggregate pushdown paths

(2018/11/27 21:55), Etsuro Fujita wrote: > While working on [1], I noticed that since we don't set the selectivity > and cost of the local_conds (i.e., fpinfo->local_conds_sel and > fpinfo->local_conds_cost) properly in add_foreign_grouping_paths and > foreign_grouping_ok, estimate_path_cost_size

Re: "pg_ctl: the PID file ... is empty" at end of make check

Thomas Munro writes: > Today I saw a one-off case of $SUBJECT, on macOS. I can't reproduce > it, but I noticed exactly the same thing on longfin the other day: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin=2018-11-25%2005%3A39%3A04 I trawled the buildfarm logs and discovered

Re: Planning time of Generic plan for a table partitioned into a lot

On Tue, 27 Nov 2018 at 23:05, Kato, Sho wrote: > I found that making a generic plan of SELECT/UPDATE/DELETE for a table > partitioned into thousands is slow. > Especially, UPDATE/DELETE statement is too slow. It's quite well known and also documented [1] that this is slow. The manual reads:

Re: Tab completion for ALTER INDEX|TABLE ALTER COLUMN SET STATISTICS

Hello. At Wed, 28 Nov 2018 11:27:23 +0900, Tatsuro Yamada wrote in > Hi, > > On 2018/11/26 11:05, Tatsuro Yamada wrote: > I couldn't write patches details on previous email, so I write > more explanation for that on this email. > > > * tab_completion_alter_index_set_statistics.patch >

Re: vacuum and autovacuum - is it good to configure the threshold at TABLE LEVEL?

Thanks, amul. I have already gone through this. What I would like to understand is the performance impact on autovacuum launcher and worker process when autovacuum is running from configurations done by *ALTER TABLE autvac_test SET (autovacuum_vacuum_scale_factor = 0, autovacuum_vacuum_threshold =

Re: "pg_ctl: the PID file ... is empty" at end of make check

On Wed, Nov 28, 2018 at 4:10 PM Tom Lane wrote: > Thomas Munro writes: > > Today I saw a one-off case of $SUBJECT, on macOS. I can't reproduce > > it, but I noticed exactly the same thing on longfin the other day: > >

idle-in-transaction timeout error does not give a hint

idle-in-transaction timeout error closed the session. I think in this case the error message should give a hint something like other errors (for example ERRCODE_CRASH_SHUTDOWN or ERRCODE_T_R_SERIALIZATION_FAILURE) to ask users to reconnect. Attached patch does that. Best regards, -- Tatsuo Ishii

Re: "pg_ctl: the PID file ... is empty" at end of make check

Thomas Munro writes: > Today I saw a one-off case of $SUBJECT, on macOS. I can't reproduce > it, but I noticed exactly the same thing on longfin the other day: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin=2018-11-25%2005%3A39%3A04 > Anyone know what that's about? No :-(. I

Re: logical decoding vs. VACUUM FULL / CLUSTER on table with TOAST-ed data

Hi, On 2018-11-28 03:06:58 +0100, Petr Jelinek wrote: > On 28/11/2018 02:14, Andres Freund wrote: > > On 2018-11-28 02:04:18 +0100, Tomas Vondra wrote: > >> Pushed and backpatched to 9.4- (same as e9edc1ba). > > > > Backpatching seems on the more aggressive end of things for an > > optimization.

Re: Tab completion for ALTER INDEX|TABLE ALTER COLUMN SET STATISTICS

Hi, On 2018/11/26 11:05, Tatsuro Yamada wrote: Hi, Attached patches are following: * tab_completion_alter_index_set_statistics.patch     - Add column name completion after ALTER COLUMN     - Avoid schema completion after SET STATISTICS * fix_manual_of_alter_index.patch     - ALTER INDEX

Re: logical decoding vs. VACUUM FULL / CLUSTER on table with TOAST-ed data

Hi, On 28/11/2018 02:14, Andres Freund wrote: > Hi, > > On 2018-11-28 02:04:18 +0100, Tomas Vondra wrote: >> >> On 11/24/18 12:20 AM, Tomas Vondra wrote: >>> ... >>> >>> OK, here's an updated patch, tweaking the reorderbuffer part. I plan >>> to push this sometime mid next week. >>> >> >> Pushed

"pg_ctl: the PID file ... is empty" at end of make check

Hello, Today I saw a one-off case of $SUBJECT, on macOS. I can't reproduce it, but I noticed exactly the same thing on longfin the other day: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin=2018-11-25%2005%3A39%3A04 Anyone know what that's about? -- Thomas Munro

Re: More issues with pg_verify_checksums and checksum verification in base backups

On Tue, Nov 27, 2018 at 08:17:12PM -0500, Stephen Frost wrote: > * Michael Paquier (mich...@paquier.xyz) wrote: >> Please see 0002 attached, which moves the call to skipfile() where I >> think it should go. > > Alright, on a quick glance that seems ok. Thanks. >> Base backups are impacted as

Re: More issues with pg_verify_checksums and checksum verification in base backups

Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Tue, Nov 27, 2018 at 06:27:57PM -0500, Stephen Frost wrote: > > * Michael Paquier (mich...@paquier.xyz) wrote: > >> Believe me or not, but we have spent so much energy on this stuff that I > >> am ready to give up on the whitelist

Re: logical decoding vs. VACUUM FULL / CLUSTER on table with TOAST-ed data

Hi, On 2018-11-28 02:04:18 +0100, Tomas Vondra wrote: > > On 11/24/18 12:20 AM, Tomas Vondra wrote: > > ... > > > > OK, here's an updated patch, tweaking the reorderbuffer part. I plan > > to push this sometime mid next week. > > > > Pushed and backpatched to 9.4- (same as e9edc1ba).

Re: Function to promote standby servers

On Wed, Nov 28, 2018 at 10:06:34AM +0900, Ian Barwick wrote: > Thanks, looks good (and apologies for the delay in responding from my > side). Thanks for double-checking, Ian. I took my time as well ;) (Hope to see you face-to-face in a couple of days around Akihabara.) -- Michael

Re: Function to promote standby servers

On 11/19/2018 01:22 PM, Michael Paquier wrote: On Fri, Oct 26, 2018 at 01:51:24PM +0900, Michael Paquier wrote: Or we could use "the function returns true immediately after initiating the promotion by sending the promotion signal to the postmaster"? As a native speaker which one feels more

Re: logical decoding vs. VACUUM FULL / CLUSTER on table with TOAST-ed data

On 11/24/18 12:20 AM, Tomas Vondra wrote: > ... > > OK, here's an updated patch, tweaking the reorderbuffer part. I plan > to push this sometime mid next week. > Pushed and backpatched to 9.4- (same as e9edc1ba). regards -- Tomas Vondra http://www.2ndQuadrant.com

Re: MERGE SQL statement for PG12

Hi Pavan, Thanks for continuing to work on this. On 2018/11/27 20:18, Pavan Deolasee wrote: > Ok. I will try that approach again. In the meanwhile, I am posting a > rebased version. There had been quite a lot changes on partitioning side > and that caused non-trivial conflicts. I noticed a

Re: Handling of REGRESS_OPTS in MSVC for regression tests

On Tue, Nov 27, 2018 at 05:59:34PM -0500, Andrew Dunstan wrote: > I think you should just proceed with the changes above. I just had a quick > look at the patch you posted before, and it looks sane enough. Thanks for the feedback, Andrew. Let's wait a couple of days and see if anybody has any

Re: More issues with pg_verify_checksums and checksum verification in base backups

On Tue, Nov 27, 2018 at 06:27:57PM -0500, Stephen Frost wrote: > * Michael Paquier (mich...@paquier.xyz) wrote: >> Believe me or not, but we have spent so much energy on this stuff that I >> am ready to give up on the whitelist patch and focus on other business. > > I would have hoped that you'd

Re: Minor typo

Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Tue, Nov 27, 2018 at 07:18:39PM -0500, Tom Lane wrote: > > * When wal_compression is enabled and a "hole" is removed from a full > > * page image, the page image is compressed using PGLZ compression. > > > > (BTW, is this trying

Re: Minor typo

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Daniel Gustafsson writes: > >> On 28 Nov 2018, at 00:43, Stephen Frost wrote: > >> Sending it here in case anyone feels that we should do more than just > >> correct the word..? Perhaps for non-native English speakers seeing > >> "whose" used

Re: Minor typo

On Tue, Nov 27, 2018 at 07:18:39PM -0500, Tom Lane wrote: > * When wal_compression is enabled and a "hole" is removed from a full > * page image, the page image is compressed using PGLZ compression. > > (BTW, is this trying to say that we don't apply compression if the page > contains no

Re: Minor typo

Daniel Gustafsson writes: >> On 28 Nov 2018, at 00:43, Stephen Frost wrote: >> Sending it here in case anyone feels that we should do more than just >> correct the word..? Perhaps for non-native English speakers seeing >> "whose" used here is confusing? > Being a non-native English speaker I

Re: [PATCH] Tiny CREATE STATISTICS tab-completion cleanup

On 11/27/18 12:55 AM, Tomas Vondra wrote: > Hi, > > On 11/26/18 5:49 PM, Dagfinn Ilmari Mannsåker wrote: >> Hi Hackers, >> >> As I was hacking on the CREATE TABLE tab completions, I noticed that the >> CREATE STATISTICS completion was checking manually for the start and end >> of the

Re: Minor typo

> On 28 Nov 2018, at 00:43, Stephen Frost wrote: > Sending it here in case anyone feels that we should do more than just > correct the word..? Perhaps for non-native English speakers seeing > "whose" used here is confusing? Being a non-native English speaker I think it’s fine and, in my own

Minor typo

Greetings, While reviewing a bit of code around full page images, I came across a typo and fixed it in the attach. Sending it here in case anyone feels that we should do more than just correct the word..? Perhaps for non-native English speakers seeing "whose" used here is confusing? If I don't

Re: More issues with pg_verify_checksums and checksum verification in base backups

Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Tue, Nov 27, 2018 at 05:45:41PM -0500, Stephen Frost wrote: > > This doesn't exactly change my opinion regarding this discussion and I'd > > rather we revert the "whitelist" patch and use the very minimal patch > > from here: > > > >

Re: More issues with pg_verify_checksums and checksum verification in base backups

On Tue, Nov 27, 2018 at 05:45:41PM -0500, Stephen Frost wrote: > This doesn't exactly change my opinion regarding this discussion and I'd > rather we revert the "whitelist" patch and use the very minimal patch > from here: > >

Re: Handling of REGRESS_OPTS in MSVC for regression tests

On 11/27/18 4:10 PM, Michael Paquier wrote: On Tue, Nov 27, 2018 at 10:27:17AM +0900, Michael Paquier wrote: Okay, let's do so by supporting correctly NO_INSTALLCHECK. My other refactoring work can also live with that. Returning an empty list via fetchTests() and bypass a run if nothing is

Re: More issues with pg_verify_checksums and checksum verification in base backups

Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Mon, Nov 19, 2018 at 10:17:19PM -0500, Stephen Frost wrote: > > Let's try to not conflate these two issues though, they're quite > > independent. > > This is a poke about a recent issue raised by Michael Banck here: >

Re: Remove Deprecated Exclusive Backup Mode

Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Tue, Nov 27, 2018 at 09:45:04AM -0500, Stephen Frost wrote: > > If you don't consider your recovery scripts and your backup scripts to > > be related then I've really got to wonder how you're regularly testing > > your backups to make

Re: Remove Deprecated Exclusive Backup Mode

On 11/27/18 4:25 PM, Michael Paquier wrote: > On Tue, Nov 27, 2018 at 09:45:04AM -0500, Stephen Frost wrote: >> If you don't consider your recovery scripts and your backup scripts to >> be related then I've really got to wonder how you're regularly testing >> your backups to make sure that they're

Re: Use durable_unlink for .ready and .done files for WAL segment removal

On Tue, Nov 27, 2018 at 09:49:29PM +, Bossart, Nathan wrote: > That sounds good to me. I was actually thinking of using the same > retry counter that we use for pgarch_archiveXlog(), but on second > thought, it is probably better to have two independent retry counters > for these two

Re: Use durable_unlink for .ready and .done files for WAL segment removal

On 11/27/18, 3:20 PM, "Michael Paquier" wrote: > On Tue, Nov 27, 2018 at 08:43:06PM +, Bossart, Nathan wrote: >> IIUC any time that the file does not exist, we will attempt to unlink >> it. Regardless of whether unlinking fails or succeeds, we then >> proceed to give up archiving for now,

Re: pg11b1 from outside a txn: "VACUUM cannot run inside a transaction block": should be: ...or multi-command string

I'm resending a mail from June: https://www.postgresql.org/message-id/flat/87sh5doya9.fsf%40news-spur.riddles.org.uk#83c3d1a183217204939252d56804f247 This is maybe a trivial change in ERROR string which maybe worth changing. On PG10: |[pryzbyj@database ~]$ psql postgres -c 'DROP DATABASE x;

Re: More issues with pg_verify_checksums and checksum verification in base backups

On Mon, Nov 19, 2018 at 10:17:19PM -0500, Stephen Frost wrote: > Let's try to not conflate these two issues though, they're quite > independent. This is a poke about a recent issue raised by Michael Banck here: https://www.postgresql.org/message-id/f1543332405.17247.9.ca...@credativ.de And for

Re: pgsql: Add TAP tests for pg_verify_checksums

On Tue, Nov 27, 2018 at 04:26:45PM +0100, Michael Banck wrote: > Oh, I kinda followed that thread a bit, but I think that patch fixes > things more by matter of moving code around, at least I haven't noticed > that tablespaces were explicitly claimed to be fixed in that thread. That may have been

Re: tab-completion debug print

On Tue, Nov 27, 2018 at 03:54:55PM -0500, Tom Lane wrote: > David Fetter writes: > > Do we still want this as a compile-time option, or does it make more > > sense as a run-time option? I'm thinking that with \L, it might make > > sense as a run-time option. > > This seems to me to be strictly a

Re: Remove Deprecated Exclusive Backup Mode

On Tue, Nov 27, 2018 at 09:45:04AM -0500, Stephen Frost wrote: > If you don't consider your recovery scripts and your backup scripts to > be related then I've really got to wonder how you're regularly testing > your backups to make sure that they're actually valid. Base backups can be perfectly

Re: Use durable_unlink for .ready and .done files for WAL segment removal

On Tue, Nov 27, 2018 at 08:43:06PM +, Bossart, Nathan wrote: > Don't we also need to check that errno is ENOENT here? Yep. > IIUC any time that the file does not exist, we will attempt to unlink > it. Regardless of whether unlinking fails or succeeds, we then > proceed to give up archiving

Re: Handling of REGRESS_OPTS in MSVC for regression tests

On Tue, Nov 27, 2018 at 10:27:17AM +0900, Michael Paquier wrote: > Okay, let's do so by supporting correctly NO_INSTALLCHECK. My other > refactoring work can also live with that. Returning an empty list via > fetchTests() and bypass a run if nothing is present looks fine to me. > One extra thing

Re: SSL tests failing with "ee key too small" error on Debian SID

On Tue, Nov 27, 2018 at 09:37:17AM -0500, Tom Lane wrote: > Peter Eisentraut writes: >> On 01/10/2018 14:18, Kyotaro HORIGUCHI wrote: >>> The attached second patch just changes key size to 2048 bits and >>> "ee key too small" are eliminated in 001_ssltests_master, but >>> instead I got "ca md too

Re: tab-completion debug print

David Fetter writes: > Do we still want this as a compile-time option, or does it make more > sense as a run-time option? I'm thinking that with \L, it might make > sense as a run-time option. This seems to me to be strictly a developer debugging feature. regards, tom

Re: Use durable_unlink for .ready and .done files for WAL segment removal

On 11/27/18, 2:46 PM, "Andres Freund" wrote: > On 2018-11-27 20:43:06 +, Bossart, Nathan wrote: >> I don't have exact figures to share, but yes, a huge number of calls >> to sync_file_range() and fsync() can use up a lot of time. Presumably >> Postgres processes files individually instead of

Re: tab-completion debug print

On Tue, Nov 27, 2018 at 06:06:06PM +0900, Kyotaro HORIGUCHI wrote: > Hello. > > At Mon, 26 Nov 2018 07:08:53 +0100, David Fetter wrote in > <20181126060853.gp...@fetter.org> > > On Sun, Nov 25, 2018 at 11:21:51PM -0500, Tom Lane wrote: > > > Kyotaro HORIGUCHI writes: > > > >> On Fri, Nov 23,

Re: Use durable_unlink for .ready and .done files for WAL segment removal

Hi, On 2018-11-27 20:43:06 +, Bossart, Nathan wrote: > I don't have exact figures to share, but yes, a huge number of calls > to sync_file_range() and fsync() can use up a lot of time. Presumably > Postgres processes files individually instead of using sync() because > sync() may return

Re: Use durable_unlink for .ready and .done files for WAL segment removal

On 11/21/18, 10:16 PM, "Michael Paquier" wrote: >> At Fri, 02 Nov 2018 14:47:08 +, Nathan Bossart >> wrote in >> <154117002849.5569.14588306221618961668.p...@coridan.postgresql.org>: >>> Granted, any added delay from this patch is unlikely to be noticeable >>> unless your archiver is way

jit comments typos (Re: pg11.1 jit segv)

On Tue, Nov 27, 2018 at 10:24:52AM -0800, Andres Freund wrote: > And pushed. Justin, thanks again for reporting the bug and then > narrowing it down to a reproducible test case! Would've been much harder > to diagnose without that. > > I'll look into your comments patch in a bit. Thanks for

Re: pg11.1 jit segv

On 2018-11-27 00:26:55 -0800, Andres Freund wrote: > Hi, > > On 2018-11-26 22:56:09 -0600, Justin Pryzby wrote: > > On Mon, Nov 26, 2018 at 07:00:35PM -0800, Andres Freund wrote: > > > Could you check that the attached patch this also fixes your original > > > issue? Going through the code to see

Re: Python versions (was Re: RHEL 8.0 build)

Hi, On 2018-11-27 14:14:24 +0100, Peter Eisentraut wrote: > On 25/11/2018 23:14, Tom Lane wrote: > > Andres Freund writes: > >> On 2018-11-24 15:49:25 -0500, Tom Lane wrote: > >>> There's been some preliminary discussion about starting to default to > >>> python3, but given this project's

Re: Continue work on changes to recovery.conf API

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2018-11-27 15:36:59 +0100, Peter Eisentraut wrote: > > That might be a useful facility, but it wouldn't really address the > > pg_basebackup -R issue, because that creates settings that you don't > > want going away in this manner. > >

Re: Sequential UUID Generation

On 11/19/18 2:08 PM, Uday Bhaskar V wrote: I tried below function as which can be used as default to column. But every time we need to created 2 sequences, 1st one takes care of the first 8 bytes and 2nd takes care of the 2nd part of the UUID. I have not tested index and space utilization. I

Re: Continue work on changes to recovery.conf API

Hi, On 2018-11-27 15:36:59 +0100, Peter Eisentraut wrote: > That might be a useful facility, but it wouldn't really address the > pg_basebackup -R issue, because that creates settings that you don't > want going away in this manner. Why is that / which are those? It's not like it worked like

Re: Remove Deprecated Exclusive Backup Mode

Hi, On 2018-11-26 23:04:35 -0500, Robert Haas wrote: > It's not like the problems with exclusive backup are so serious that > you can't work around them. If you know which machine is your master, > you can arrange to remove backup_label on reboot (only) on the master > (only). Sure, a lot of

Re: Remove Deprecated Exclusive Backup Mode

Greetings, * Andreas Karlsson (andr...@proxel.se) wrote: > On 11/27/18 4:11 PM, Stephen Frost wrote: > >>I agree with your larger point, but in this case the two breakages do not > >>seem equal. As far as I gather the removal of recovery.conf will in practice > >>result in a longer downtime when

Re: Remove Deprecated Exclusive Backup Mode

On Tue, 27 Nov 2018 at 14:45, Stephen Frost wrote: > Greetings, > > * Michael Paquier (mich...@paquier.xyz) wrote: > > On Tue, Nov 27, 2018 at 02:21:49PM +0100, Peter Eisentraut wrote: > > > On 27/11/2018 04:46, Andres Freund wrote: > > >> That was my gut reaction as well, but I think David's

Re: Remove Deprecated Exclusive Backup Mode

Greetings, * David Steele (da...@pgmasters.net) wrote: > On 11/27/18 10:29 AM, Peter Eisentraut wrote: > > On 27/11/2018 16:02, Stephen Frost wrote: > >> They're also the sort of installations which don't have reliable backups > >> and don't have any clue about the danger they are in due to the

Re: Remove Deprecated Exclusive Backup Mode

On 11/27/18 8:56 AM, Simon Riggs wrote: > On Tue, 27 Nov 2018 at 03:13, David Steele > wrote: >   > > The deprecated exclusive mode promises to make a difficult problem > simple but doesn't live up to that promise. That's why it was replaced > externally

Re: Remove Deprecated Exclusive Backup Mode

On 11/27/18 10:29 AM, Peter Eisentraut wrote: > On 27/11/2018 16:02, Stephen Frost wrote: >> They're also the sort of installations which don't have reliable backups >> and don't have any clue about the danger they are in due to the current >> bug/issue/whatever we have with exclusive backups. >>

Re: shared-memory based stats collector

On 11/27/18 9:59 AM, Kyotaro HORIGUCHI wrote: >> >> ...>> For the main workload there's pretty much no difference, but for selects from the stats catalogs there's ~20% drop in throughput. In absolute numbers this means drop from ~670tps to ~550tps. I haven't investigated this, but I suppose this

Re: Remove Deprecated Exclusive Backup Mode

On 11/27/18 9:54 AM, Peter Eisentraut wrote: > On 27/11/2018 15:45, Stephen Frost wrote: But backup scripts are not affected by the recovery.conf changes. >>> In any of my own backup scripts (yeah!), I don't have any dependency to >>> that either. Or perhaps pgBackRest has a dependency in

Re: Continue work on changes to recovery.conf API

Greetings, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 27/11/2018 13:21, David Steele wrote: > > I would prefer a specific file that will be auto-included into > > postgresql.conf when present but be ignored when not present. Some > > settings are generally ephemeral

Re: Remove Deprecated Exclusive Backup Mode

On 27/11/2018 16:02, Stephen Frost wrote: > They're also the sort of installations which don't have reliable backups > and don't have any clue about the danger they are in due to the current > bug/issue/whatever we have with exclusive backups. > > No, I don't agree that it's sensible to continue

Re: pgsql: Add TAP tests for pg_verify_checksums

Hi, Am Dienstag, den 27.11.2018, 22:52 +0900 schrieb Michael Paquier: > On Tue, Nov 27, 2018 at 02:09:05PM +0100, Michael Banck wrote: > > I had a quick look at fixing this but did not manage to immediately come > > up with a solution, so posting here for now. > > If you look at another thread,

Re: Remove Deprecated Exclusive Backup Mode

On 11/27/18 4:11 PM, Stephen Frost wrote: I agree with your larger point, but in this case the two breakages do not seem equal. As far as I gather the removal of recovery.conf will in practice result in a longer downtime when your recovery scripts breaks but not any data loss. While if we remove

Re: Remove Deprecated Exclusive Backup Mode

Greetings, * Andreas Karlsson (andr...@proxel.se) wrote: > On 11/27/18 3:46 PM, Stephen Frost wrote: > >I'm concerned, seriously, that people don't have anywhere near the > >concern about the recovery side of things as they do about the backup > >side of things and that's really concerning. > >

Re: Remove Deprecated Exclusive Backup Mode

On 11/27/18 3:46 PM, Stephen Frost wrote: I'm concerned, seriously, that people don't have anywhere near the concern about the recovery side of things as they do about the backup side of things and that's really concerning. I agree with your larger point, but in this case the two breakages do

Re: Remove Deprecated Exclusive Backup Mode

Greetings, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 27/11/2018 15:45, Stephen Frost wrote: > >>> But backup scripts are not affected by the recovery.conf changes. > >> In any of my own backup scripts (yeah!), I don't have any dependency to > >> that either. Or perhaps

Re: Remove Deprecated Exclusive Backup Mode

On 27/11/2018 15:45, Stephen Frost wrote: >>> But backup scripts are not affected by the recovery.conf changes. >> In any of my own backup scripts (yeah!), I don't have any dependency to >> that either. Or perhaps pgBackRest has a dependency in this area? > If you don't consider your recovery

Re: Remove Deprecated Exclusive Backup Mode

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > There must be hundreds or thousands of backup scripts written by > individual users that still use exclusive mode floating around out > there. Forcing all of those to be updated or scrapped will annoy > users to no benefit. How about

Re: Remove Deprecated Exclusive Backup Mode

Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Tue, Nov 27, 2018 at 02:21:49PM +0100, Peter Eisentraut wrote: > > On 27/11/2018 04:46, Andres Freund wrote: > >> That was my gut reaction as well, but I think David's argument about > >> existing scripts / workflows being broken due

Re: SSL tests failing with "ee key too small" error on Debian SID

Peter Eisentraut writes: > On 01/10/2018 14:18, Kyotaro HORIGUCHI wrote: >> The attached second patch just changes key size to 2048 bits and >> "ee key too small" are eliminated in 001_ssltests_master, but >> instead I got "ca md too weak" error. This is eliminated by using >> sha256 instead of

Re: Continue work on changes to recovery.conf API

On 27/11/2018 13:21, David Steele wrote: > I would prefer a specific file that will be auto-included into > postgresql.conf when present but be ignored when not present. Some > settings are generally ephemeral (recovery_target_time) and it would be > nice for them to go away. When recovery is

Re: SSL tests failing with "ee key too small" error on Debian SID

On 01/10/2018 14:18, Kyotaro HORIGUCHI wrote: > By the way I got (with both 1.0.2k and 1.1.1) a "tlsv1 alert > unknown ca" error from 002_scram.pl. It is fixed for me by the > forth attached, but I'm not sure why we haven't have such a > complain. (It happens only for me?) I haven't seen it. Do

Re: SSL tests failing with "ee key too small" error on Debian SID

On 01/10/2018 14:18, Kyotaro HORIGUCHI wrote: > The attached second patch just changes key size to 2048 bits and > "ee key too small" are eliminated in 001_ssltests_master, but > instead I got "ca md too weak" error. This is eliminated by using > sha256 instead of sha1 in cas.config. (third

Re: pgsql: Integrate recovery.conf into postgresql.conf

Hi > The attached seems to be the simplest way to fix this. (Needs > documentation updates, test updates, error message refinement.) Thank you! I add documentation change, tests and rephrased error message. regards, Sergeidiff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index

Re: Remove Deprecated Exclusive Backup Mode

On Tue, 27 Nov 2018 at 03:13, David Steele wrote: > The deprecated exclusive mode promises to make a difficult problem > simple but doesn't live up to that promise. That's why it was replaced > externally in 9.6 and why pg_basebackup has not used exclusive backups > since it was introduced in

Re: Remove Deprecated Exclusive Backup Mode

On Tue, Nov 27, 2018 at 02:21:49PM +0100, Peter Eisentraut wrote: > On 27/11/2018 04:46, Andres Freund wrote: >> That was my gut reaction as well, but I think David's argument about >> existing scripts / workflows being broken due the the recovery.conf >> is a good reason to be more aggressive

Re: pgsql: Add TAP tests for pg_verify_checksums

On Tue, Nov 27, 2018 at 02:09:05PM +0100, Michael Banck wrote: > I had a quick look at fixing this but did not manage to immediately come > up with a solution, so posting here for now. If you look at another thread, the patch posted on the top would actually solve this issue:

Re: SSL tests failing with "ee key too small" error on Debian SID

On 26/11/2018 01:35, Michael Paquier wrote: > When going up to 2k, it takes longer to generate the keys than to run > the tests, so keeping them in the tree looks like a pretty good gain to > me. Another concern might be that repeatedly generating certificates might drain entropy unnecessarily.

Re: Remove Deprecated Exclusive Backup Mode

On 27/11/2018 04:46, Andres Freund wrote: > That was my gut reaction as well, but I think David's argument about > existing scripts / workflows being broken due the the recovery.conf > is a good reason to be more aggressive here. But backup scripts are not affected by the recovery.conf changes.

Re: Python versions (was Re: RHEL 8.0 build)

On 25/11/2018 23:14, Tom Lane wrote: > Andres Freund writes: >> On 2018-11-24 15:49:25 -0500, Tom Lane wrote: >>> There's been some preliminary discussion about starting to default to >>> python3, but given this project's inherent conservatism, I don't expect >>> that to happen for some years

Re: [RFC] Removing "magic" oids

On 11/26/18 5:50 PM, Andres Freund wrote: With some adjustments to the tests to remove problematic cases (e.g. postgres_fdw's ft_pg_type) the tests pass. The exception is HEAD->HEAD. The change is that the LOs are not dumped in the same order pre and post upgrade. I can change the tests to

Re: pgsql: Add TAP tests for pg_verify_checksums

Hi, Am Freitag, den 19.10.2018, 22:50 +0900 schrieb Michael Paquier: > On Wed, Oct 17, 2018 at 05:30:05PM -0400, Andrew Dunstan wrote: > Thanks. This is now committed after some tweaks to the comments, a bit > earlier than I thought first. I found an issue with this [d55241af7, "Use whitelist

postgres_fdw: oddity in costing aggregate pushdown paths

Hi, While working on [1], I noticed that since we don't set the selectivity and cost of the local_conds (i.e., fpinfo->local_conds_sel and fpinfo->local_conds_cost) properly in add_foreign_grouping_paths and foreign_grouping_ok, estimate_path_cost_size produces considerably underestimated results

Re: Inadequate executor locking of indexes

On Tue, 27 Nov 2018 at 19:00, Amit Langote wrote: > On 2018/11/27 6:19, David Rowley wrote: > > On Mon, 26 Nov 2018 at 18:57, Amit Langote > >> That's an interesting point. Although, considering the concerns that Tom > >> raised about the same index relation being locked such that lock-strength

Re: pgsql: Integrate recovery.conf into postgresql.conf

On 27/11/2018 13:29, Peter Eisentraut wrote: > On 27/11/2018 10:10, Sergei Kornilov wrote: >> Hello >>  - recovery_target = immediate was replaced with recovery_target_immediate bool GUC >>> >>> Why? >> Due this comment: >>

  1   2   >