Re: dsa_allocate() faliure

On Tue, Nov 27, 2018 at 4:00 PM Thomas Munro wrote: > Hmm. I will see if I can come up with a many-partition torture test > reproducer for this. No luck. I suppose one theory that could link both failure modes would a buffer overrun, where in the non-shared case it trashes a pointer that is lat

Re: Tid scan improvements

On Thu, 22 Nov 2018 at 20:41, David Rowley wrote: > I've now had a look over the latest patches and I've found a few more > things. Many of these are a bit nitpicky, but certainly not all. I > also reviewed 0004 this time. Whew! A lot more things to look at. I've tried to address most of what

Re: pg11.1 jit segv

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 if there's other occurances of > > this. > > Confirmed that fi

Re: Remove Deprecated Exclusive Backup Mode

On Tue, Nov 27, 2018 at 4:46 AM Andres Freund wrote: > Hi, > > On 2018-11-27 12:20:13 +0900, Michael Paquier wrote: > > On Mon, Nov 26, 2018 at 10:13:34PM -0500, David Steele wrote: > > > Non-exclusive backups have been available since 9.6 and several > third-party > > > solutions support this mo

RE: Protect syscache from bloating with negative cache entries

>From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com] >I haven't looked into the code but I'm going to do it later. Hi, I've taken a look at 0001 patch. Reviewing the rest of patch will be later. if (!IsParallelWorker())

Re: Continue work on changes to recovery.conf API

On 25/11/2018 21:39, Andres Freund wrote: > On 2018-11-25 13:24:15 -0500, Stephen Frost wrote: >> - User performs a backup with pg_basebackup -R >> - Replica is then promoted to be a primary >> - User performs a backup with pg_basebackup -R on the new primary >> - Duplicate entries end up in postgr

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

On 26/11/2018 21:30, Sergei Kornilov wrote: > - recovery_target = immediate was replaced with recovery_target_immediate > bool GUC Why? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: tab-completion debug print

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, 2018 at 04:32:31PM -0500, Tom Lane wrote: > > >>> Hm. I can see the value of instr

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

Hello >>  - recovery_target = immediate was replaced with recovery_target_immediate >> bool GUC > > Why? Due this comment: https://www.postgresql.org/message-id/20181126172118.GY3415%40tamriel.snowman.net > I've not been following this very closely, but seems like > recovery_target_string is a b

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

Hi, 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. I'm afraid that I could not come up with a good idea, but how can I shorten the creation time of a generic plan? The results are as fol

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

Hopefully, this[1] will help you. 1] https://www.percona.com/blog/2018/08/10/tuning-autovacuum-in-postgresql-and-autovacuum-internals/ regards, Amul On Tue, Nov 27, 2018 at 11:50 AM rajan wrote: > > Hi, > > Please suggest me on the following, > > 1. Is it better to configure autovacuum threshol

Re: Protect syscache from bloating with negative cache entries

Thank you for reviewing. At Thu, 15 Nov 2018 11:02:10 +, "Ideriha, Takeshi" wrote in <4E72940DA2BF16479384A86D54D0988A6F1F4165@G01JPEXMBKW04> > Hello, thank you for updating the patch. > > > >From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp] > >At Thu, 4 Oct 2018 04:27:04 +

Re: Remove Deprecated Exclusive Backup Mode

On 11/26/18 11:04 PM, Robert Haas wrote: > On Mon, Nov 26, 2018 at 10:13 PM David Steele wrote: >> I propose we remove the deprecated exclusive backup mode of >> pg_start_backup()/pg_stop_backup() for Postgres 12. > > -1. I don't have a problem with deprecating exclusive backup mode > eventually,

Re: csv format for psql

Tom Lane wrote: > what I did instead was just to make > csv_print_field force field quoting if any of these cases could > possibly apply. That will result in excess quoting in some > cases, but I think that's fine, since they're all pretty uncommon. Indeed. > (BTW, it seems only chance

Re: Continue work on changes to recovery.conf API

On 11/27/18 3:59 AM, Peter Eisentraut wrote: > On 25/11/2018 21:39, Andres Freund wrote: >> On 2018-11-25 13:24:15 -0500, Stephen Frost wrote: >>> - User performs a backup with pg_basebackup -R >>> - Replica is then promoted to be a primary >>> - User performs a backup with pg_basebackup -R on the

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

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: > https://www.postgresql.org/message-id/20181126172118.GY3415%40tamriel.snowman.net >> I've not been following this ver

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

On Thu, Nov 22, 2018 at 01:16:09PM +0900, Michael Paquier wrote: > No, pgarch_readyXLog() should still look after .ready files as those are > here for this purpose, but we could have an additional check to see if > the segment linked with it actually exists and can be archived. This > check could

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: >> https://www.postgresql.org/message-id/20181126172118.GY3415%40t

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 >

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

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 al

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 yet.

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: 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: 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: https://www.postgresq

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 here

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 9.

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 db1

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 attache

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 t

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 com

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 sh

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

Greetings, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 27/11/2018 13:29, Peter Eisentraut wrote: > > On 27/11/2018 10:10, Sergei Kornilov wrote: >  - recovery_target = immediate was replaced with > recovery_target_immediate bool GUC > >>> > >>> Why? > >> Due this c

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 t

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 auto

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 scri

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 pgB

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, * 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. > > I

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: 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, t

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 t

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 (recove

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 thi

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

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 cu

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 arg

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 y

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 peop

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 tha

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 ha

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. > > W

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 inheren

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

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 imple

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 behi

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 befor

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

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

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 lan

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

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 se

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

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; CREAT

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

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 unrelated

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: 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: 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: > https://www.post

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 p

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: > > https://www.postgresql.org/message-id/20181012013918.GA30064%40paquier.

Re: Accounting of zero-filled buffers in EXPLAIN (BUFFERS)

On Tue, Nov 27, 2018 at 2:53 PM Haribabu Kommi wrote: > Thanks for the updated patch. It looks good. > I marked it in the commitfest as ready for committer. Pushed. Thanks for the reviews! -- Thomas Munro http://www.enterprisedb.com

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

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

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 parenthesised

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 th

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 hole?

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

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 t

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 s

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 obj

Re: Minor typo

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 really should avoid talking about removing the hole as > if it's 'compression' because, first of all, it isn't, and second, now > that we have *actual* compression happeni

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 couple

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 PostgreSQL

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 natu

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 signature.asc

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). Backpatc

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 patc

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 wel

"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&dt=2018-11-25%2005%3A39%3A04 Anyone know what that's about? -- Thomas Munro http://www.

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

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 AL

  1   2   >