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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

  1   2   >