Re: Transactions involving multiple postgres foreign servers, take 2

On Fri, Jun 12, 2020 at 9:54 AM Masahiko Sawada wrote: > > On Fri, 12 Jun 2020 at 12:40, Amit Kapila wrote: > > > > On Fri, Jun 12, 2020 at 7:59 AM Masahiko Sawada > > wrote: > > > > > > On Thu, 11 Jun 2020 at 22:21, Amit Kapila wrote: > > > > > > > > > > > I have another question about > > >

Re: new heapcheck contrib module

On Fri, Jun 12, 2020 at 12:40 AM Mark Dilger wrote: > > > > > On Jun 11, 2020, at 9:14 AM, Dilip Kumar wrote: > > > > I have just browsed through the patch and the idea is quite > > interesting. I think we can expand it to check that whether the flags > > set in the infomask are sane or not w.r.

RE: BUG #16481: Stored Procedure Triggered by Logical Replication is Unable to use Notification Events

Just to help those who find themselves in the same situation, there is a simple application-level workaround which consists in listening to the notifications in the replica when they are issued by the master and vice versa. We are programming in .NET and we use a code like this: Code in the rep

Re: Internal key management system

On Thu, 11 Jun 2020 at 20:03, Fabien COELHO wrote: > > > Hello Masahiko-san, > > >> If the KEK is ever present in pg process, it presumes that the threat > >> model being addressed allows its loss if the process is compromised, i.e. > >> all (past, present, future) security properties are void onc

Re: Resetting spilled txn statistics in pg_stat_replication

On Fri, 12 Jun 2020 at 12:21, Amit Kapila wrote: > > On Thu, Jun 11, 2020 at 7:39 PM Masahiko Sawada > wrote: > > > > On Thu, 11 Jun 2020 at 20:02, Amit Kapila wrote: > > > > > > On Thu, Jun 11, 2020 at 3:07 PM Masahiko Sawada > > > wrote: > > > > > > > > On Thu, 11 Jun 2020 at 18:11, Amit Kapi

Re: Parallel copy

On Thu, Jun 4, 2020 at 12:44 AM Andres Freund wrote > > > Hm. you don't explicitly mention that in your design, but given how > small the benefits going from 0-1 workers is, I assume the leader > doesn't do any "chunk processing" on its own? > Yes you are right, the leader does not do any process

Re: Resetting spilled txn statistics in pg_stat_replication

On Fri, 12 Jun 2020 at 12:56, Fujii Masao wrote: > > > > On 2020/06/12 12:21, Amit Kapila wrote: > > On Thu, Jun 11, 2020 at 7:39 PM Masahiko Sawada > > wrote: > >> > >> On Thu, 11 Jun 2020 at 20:02, Amit Kapila wrote: > >>> > >>> On Thu, Jun 11, 2020 at 3:07 PM Masahiko Sawada > >>> wrote: > >

Re: Transactions involving multiple postgres foreign servers, take 2

On Fri, 12 Jun 2020 at 12:40, Amit Kapila wrote: > > On Fri, Jun 12, 2020 at 7:59 AM Masahiko Sawada > wrote: > > > > On Thu, 11 Jun 2020 at 22:21, Amit Kapila wrote: > > > > > > > > I have another question about > > > this field, why can't it be one of the status ('preparing', > > > 'prepared'

Re: Hybrid Hash/Nested Loop joins and caching results from subplans

On Wed, Jun 3, 2020 at 10:36 AM Andy Fan wrote: > >> Thanks for running those tests. I had a quick look at the results and >> I think to say that all 4 are better is not quite right. One is >> actually a tiny bit slower and one is only faster due to a plan >> change. >> >> > Yes.. Thanks for po

Re: Resetting spilled txn statistics in pg_stat_replication

On 2020/06/12 12:21, Amit Kapila wrote: On Thu, Jun 11, 2020 at 7:39 PM Masahiko Sawada wrote: On Thu, 11 Jun 2020 at 20:02, Amit Kapila wrote: On Thu, Jun 11, 2020 at 3:07 PM Masahiko Sawada wrote: On Thu, 11 Jun 2020 at 18:11, Amit Kapila wrote: On Thu, Jun 11, 2020 at 1:46 PM Ma

Re: Transactions involving multiple postgres foreign servers, take 2

On Fri, Jun 12, 2020 at 7:59 AM Masahiko Sawada wrote: > > On Thu, 11 Jun 2020 at 22:21, Amit Kapila wrote: > > > > > I have another question about > > this field, why can't it be one of the status ('preparing', > > 'prepared', 'committing', 'aborting', 'in-doubt') rather than having a > > separ

Re: Default setting for enable_hashagg_disk

On Thu, 9 Apr 2020 at 13:24, Justin Pryzby wrote: > On Thu, Apr 09, 2020 at 01:48:55PM +0200, Tomas Vondra wrote: > > > It it really any different from our enable_* GUCs? Even if you do e.g. > > enable_sort=off, we may still do a sort. Same for enable_groupagg etc. > > Those show that the GUC was

Re: Parallel Seq Scan vs kernel read ahead

On Fri, Jun 12, 2020 at 2:24 AM David Rowley wrote: > > On Thu, 11 Jun 2020 at 23:35, Amit Kapila wrote: > > Another point I am thinking is that whatever formula we come up here > > might not be a good fit for every case. For ex. as you mentioned > > above that larger step-size can impact the pe

Re: Resetting spilled txn statistics in pg_stat_replication

On Thu, Jun 11, 2020 at 7:39 PM Masahiko Sawada wrote: > > On Thu, 11 Jun 2020 at 20:02, Amit Kapila wrote: > > > > On Thu, Jun 11, 2020 at 3:07 PM Masahiko Sawada > > wrote: > > > > > > On Thu, 11 Jun 2020 at 18:11, Amit Kapila wrote: > > > > > > > > On Thu, Jun 11, 2020 at 1:46 PM Masahiko Sa

Re: exp() versus the POSIX standard

Hi, On Fri, Jun 12, 2020 at 4:25 AM Tom Lane wrote: > =?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= > writes: > > I've had the same issue with multiplying two tiny numbers. Select > > 2e-300::float * 2e-300::float gives an underflow, and it is not a wanted > > thing. This looks like handm

Re: Default setting for enable_hashagg_disk

On Thu, Jun 11, 2020 at 01:22:57PM -0700, Jeff Davis wrote: > On Wed, 2020-06-10 at 11:39 -0700, Jeff Davis wrote: > > 1. Testing the spilling of hashed grouping sets: I'm inclined to just > > get rid of enable_groupingsets_hash_disk and use Melanie's stats- > > hacking approach instead. > > Fixed

Re: doc review for v13

Some new bits, And some old ones. -- Justin >From b74bef6f9d36a2fac71045ab707ed4be65730ba7 Mon Sep 17 00:00:00 2001 From: Justin Pryzby Date: Wed, 29 Apr 2020 13:13:29 -0500 Subject: [PATCH v5 1/5] Fix comments for WITH OIDs, removed at 578b22971 Previously mentioned here: https://www.postgresq

Re: Transactions involving multiple postgres foreign servers, take 2

On Thu, 11 Jun 2020 at 22:21, Amit Kapila wrote: > > On Fri, Jun 5, 2020 at 3:16 PM Masahiko Sawada > wrote: > > > > On Thu, 4 Jun 2020 at 12:46, Amit Kapila wrote: > > > > > > > > > + > > > + This parameter can be changed at any time; the behavior for any > > > one > > > +

Re: exp() versus the POSIX standard

=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= writes: > I've had the same issue with multiplying two tiny numbers. Select > 2e-300::float * 2e-300::float gives an underflow, and it is not a wanted > thing. This looks like handmade implementation of IEEE754's underflow > exception that should

Re: [PATCH] fix two shadow vars (src/backend/commands/sequence.c)

Em qui., 11 de jun. de 2020 às 19:54, Tom Lane escreveu: > Ranier Vilela writes: > > elog and errmsg_internal, permits use as proposed by the patch, > > does it mean that errmsg, does not allow and does not do the same job as > > snprintf? > > Yes. errmsg() strings are captured for translation.

Infinities in type numeric

We had a discussion recently about how it'd be a good idea to support infinity values in type numeric [1]. Here's a draft patch enabling that, using the idea suggested in that thread of commandeering some unused bits in the representation of numeric NaNs. AFAICT we've been careful to ensure those

Re: exp() versus the POSIX standard

пт, 12 чэр 2020, 02:57 карыстальнік Tom Lane напісаў: > I wrote: > > The POSIX standard says this about the exp(3) function: > > If x is -Inf, +0 shall be returned. > > At least on my Linux box, our version does no such thing: > > regression=# select exp('-inf'::float8); > > ERROR: value o

Re: exp() versus the POSIX standard

I wrote: > The POSIX standard says this about the exp(3) function: > If x is -Inf, +0 shall be returned. > At least on my Linux box, our version does no such thing: > regression=# select exp('-inf'::float8); > ERROR: value out of range: underflow Now that I look, power() has similar issues:

exp() versus the POSIX standard

The POSIX standard says this about the exp(3) function: If x is -Inf, +0 shall be returned. At least on my Linux box, our version does no such thing: regression=# select exp('-inf'::float8); ERROR: value out of range: underflow Does anyone disagree that that's a bug? Should we back-pa

Re: [PATCH] fix two shadow vars (src/backend/commands/sequence.c)

Ranier Vilela writes: > elog and errmsg_internal, permits use as proposed by the patch, > does it mean that errmsg, does not allow and does not do the same job as > snprintf? Yes. errmsg() strings are captured for translation. If they contain platform-dependent substrings, that's a problem, bec

Re: [PATCH] Leading minus for negative time interval in ISO 8601

On Tue, Jun 9, 2020 at 11:18:20PM -0500, Mikhail Titov wrote: > On Wed, Jun 3, 2020 at 11:25 PM, Tom Lane wrote: > > ... > > Maybe we should just take the position that negative intervals aren't > > standardized, and if you want to transport them using ISO format then > > you first need to lobby

Re: [PATCH] fix two shadow vars (src/backend/commands/sequence.c)

Em qui., 11 de jun. de 2020 às 17:19, Alvaro Herrera < alvhe...@2ndquadrant.com> escreveu: > On 2020-Jun-11, Ranier Vilela wrote: > > > Hi, > > src/backend/commands/sequence.c > > Has two shadows (buf var), with two unnecessary variables declared. > > These are not unnecessary -- removing them bre

Re: Recording test runtimes with the buildfarm

Andrew Dunstan writes: > On 6/11/20 12:32 PM, Tom Lane wrote: >> Yeah, I don't see why we can't scrape this data from the existing >> buildfarm output, at least for the core regression tests. New >> infrastructure could make it easier/cheaper, but I don't think we >> should invest in that until w

Re: Find query characters in respect of optimizer for develop purpose

On Mon, May 18, 2020 at 1:30 AM Andy Fan wrote: > Hello: > > Before I want to pay attention to some optimizer features, I want to > estimate how much benefits it can create for customers, at least for our > current > running customer. So I want to have some basic idea what kind of the query > is

Re: Recording test runtimes with the buildfarm

On 6/11/20 12:32 PM, Tom Lane wrote: > Magnus Hagander writes: >> On Thu, Jun 11, 2020 at 4:56 PM Andrew Dunstan < >> andrew.duns...@2ndquadrant.com> wrote: >>> Yeah, we'll need to work out where to stash the file. The client will >>> pick up anything in src/regress/log for "make check", but wou

Re: Parallel Seq Scan vs kernel read ahead

On Thu, 11 Jun 2020 at 23:35, Amit Kapila wrote: > Another point I am thinking is that whatever formula we come up here > might not be a good fit for every case. For ex. as you mentioned > above that larger step-size can impact the performance based on > qualification, similarly there could be ot

extensible options syntax for replication parser?

Hi, It seems to me that we're making the same mistake with the replication parser that we've made in various placesin the regular parser: using a syntax for options that requires that every potential option be a keyword, and every potential option requires modification of the grammar. In particula

Re: Default setting for enable_hashagg_disk

On Wed, 2020-06-10 at 11:39 -0700, Jeff Davis wrote: > 1. Testing the spilling of hashed grouping sets: I'm inclined to just > get rid of enable_groupingsets_hash_disk and use Melanie's stats- > hacking approach instead. Fixed in 92c58fd9. > think the names you suggested quite fit, but the idea t

Re: [PATCH] fix two shadow vars (src/backend/commands/sequence.c)

On 2020-Jun-11, Ranier Vilela wrote: > Hi, > src/backend/commands/sequence.c > Has two shadows (buf var), with two unnecessary variables declared. These are not unnecessary -- removing them breaks translatability of those messages. If these were ssize_t you could use '%zd' (see commit ac4ef637ad

Re: Atomic operations within spinlocks

On Thu, Jun 11, 2020 at 1:26 PM Andres Freund wrote: > Well, pss_barrierCheckMask member is just 32bit, so it seems odd to > declare the local variable 64bit? > > uint64 flagbit = UINT64CONST(1) << (uint64) type; > ... > pg_atomic_fetch_or_u32(&slot->pss_barrierChe

Re: new heapcheck contrib module

> On Jun 11, 2020, at 9:14 AM, Dilip Kumar wrote: > > I have just browsed through the patch and the idea is quite > interesting. I think we can expand it to check that whether the flags > set in the infomask are sane or not w.r.t other flags and xid status. > Some examples are > > - If HEAP_X

Re: jsonpath versus NaN

Alexander Korotkov writes: > On Thu, Jun 11, 2020 at 3:45 PM Tom Lane wrote: >> It is entirely clear from the code, the documentation, >> and the relevant RFCs that JSONB does not allow NaNs as numeric >> values. > The JSONB itself doesn't store number NaNs. It stores the string "NaN". Yeah, b

Re: jsonpath versus NaN

Hi Tom, Thank you for raising this issue. On Thu, Jun 11, 2020 at 3:45 PM Tom Lane wrote: > Commit 72b646033 inserted this into convertJsonbScalar: > > break; > > case jbvNumeric: > + /* replace numeric NaN with string "NaN" */ > +

Re: hashagg slowdown due to spill changes

On Thu, 2020-06-11 at 10:45 -0700, Andres Freund wrote: > Did you run any performance tests? Yes, I reproduced your ~12% regression from V12, and this patch nearly eliminated it for me. Regards, Jeff Davis

Definitional issue: stddev_pop (and related) for 1 input

Before v12, stddev_pop() had the following behavior with just a single input value: regression=# SELECT stddev_pop('42'::float8); stddev_pop 0 (1 row) regression=# SELECT stddev_pop('inf'::float8); stddev_pop NaN (1 row) regression=# SELECT stddev_

Re: hashagg slowdown due to spill changes

Hi, On June 10, 2020 6:15:39 PM PDT, Jeff Davis wrote: >On Fri, 2020-06-05 at 21:11 -0700, Andres Freund wrote: >> Hi, >> >> While preparing my pgcon talk I noticed that our hash-agg performance >> degraded noticeably. Looks to me like it's due to the spilling- >> hashagg >> changes. > >Attache

Re: WIP/PoC for parallel backup

As far I understand, parallel backup is not a mandatory performance feature, rather, one at user's discretion. This IMHO indicates that it will benefit some users and it may not others. Taking a backup is an I/O intensive workload. So by parallelizing it through multiple worker threads/processes,

Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)

Hi, On 2020-06-10 13:37:59 -0400, Robert Haas wrote: > On Tue, Jun 9, 2020 at 6:54 PM Andres Freund wrote: > > What do you think about my idea of having a BEGIN/END_SIGNAL_HANDLER? > > That'd make it much easier to write assertions forbidding palloc, 64bit > > atomics, ... > > I must have missed

Re: Atomic operations within spinlocks

Hi, On 2020-06-10 07:26:32 -0400, Robert Haas wrote: > On Fri, Jun 5, 2020 at 8:19 PM Andres Freund wrote: > > Randomly noticed while looking at the code: > > uint64 flagbit = UINT64CONST(1) << (uint64) type; > > > > that shouldn't be 64bit, right? > > I'm going to admit ignoran

Re: pg_upgrade fails with non-standard ACL

On 08.06.2020 19:31, Alvaro Herrera wrote: On 2020-Jun-08, Anastasia Lubennikova wrote: In this version I rebased test patches,  added some more comments, fixed memory allocation issue and also removed code that handles ACLs on languages. They require a lot of specific handling, while I doubt t

Re: Recording test runtimes with the buildfarm

On Thu, Jun 11, 2020 at 6:32 PM Tom Lane wrote: > Magnus Hagander writes: > > On Thu, Jun 11, 2020 at 4:56 PM Andrew Dunstan < > > andrew.duns...@2ndquadrant.com> wrote: > >> Yeah, we'll need to work out where to stash the file. The client will > >> pick up anything in src/regress/log for "make

Re: Recording test runtimes with the buildfarm

Magnus Hagander writes: > On Thu, Jun 11, 2020 at 4:56 PM Andrew Dunstan < > andrew.duns...@2ndquadrant.com> wrote: >> Yeah, we'll need to work out where to stash the file. The client will >> pick up anything in src/regress/log for "make check", but would need >> adjusting for other steps that inv

Re: new heapcheck contrib module

On Mon, May 11, 2020 at 10:51 PM Mark Dilger wrote: > > Here is v5 of the patch. Major changes in this version include: > > 1) A new module, pg_amcheck, which includes a command line client for > checking a database or subset of a database. Internally it functions by > querying the database fo

pg_dump, gzwrite, and errno

While testing Pavel's patch for pg_dump --filter, I got: pg_dump: error: could not write to output file: Success [pryzbyj@database postgresql]$ echo $? 1 I see we tried to fix it few years ago: https://www.postgresql.org/message-id/flat/1498120508308.9826%40infotecs.ru https://www.postgresql.org/

Re: how to create index concurrently on partitioned table

On Sun, Jun 07, 2020 at 01:04:48PM -0500, Justin Pryzby wrote: > On Sat, Jun 06, 2020 at 09:23:32AM -0500, Justin Pryzby wrote: > > On Wed, Jun 03, 2020 at 08:22:29PM +0800, 李杰(慎追) wrote: > > > Partitioning is necessary for very large tables. However, I found that > > > postgresql does not support

Re: Recording test runtimes with the buildfarm

On Thu, Jun 11, 2020 at 4:56 PM Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote: > > On 6/11/20 10:21 AM, Stephen Frost wrote: > > Greetings, > > > > * David Rowley (dgrowle...@gmail.com) wrote: > >> On Thu, 11 Jun 2020 at 10:02, Tom Lane wrote: > >>> Thomas Munro writes: > I've been

Re: Windows regress fails (latest HEAD)

> "Ranier" == Ranier Vilela writes: Ranier> Hi, Ranier> Latest HEAD, fails with windows regress tests. Ranier> three | f1 |sqrt_f1 Ranier> ---+--+--- Ranier> | 1004.3 | 31.6906926

Re: Recording test runtimes with the buildfarm

On 6/11/20 10:21 AM, Stephen Frost wrote: > Greetings, > > * David Rowley (dgrowle...@gmail.com) wrote: >> On Thu, 11 Jun 2020 at 10:02, Tom Lane wrote: >>> Thomas Munro writes: I've been doing that in a little database that pulls down the results and analyses them with primitive rege

Re: Recording test runtimes with the buildfarm

Greetings, * David Rowley (dgrowle...@gmail.com) wrote: > On Thu, 11 Jun 2020 at 10:02, Tom Lane wrote: > > Thomas Munro writes: > > > I've been doing that in a little database that pulls down the results > > > and analyses them with primitive regexes. First I wanted to know the > > > pass/fail

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Wed, Jun 10, 2020 at 01:23:37PM +0900, Michael Paquier wrote: > > Okay. After sleeping on it, it looks like would be better to move > > this new fe_archive.c to src/fe_utils/. I'll try to do that tomorrow, > > and added an open item

Re: Resetting spilled txn statistics in pg_stat_replication

On Thu, 11 Jun 2020 at 20:02, Amit Kapila wrote: > > On Thu, Jun 11, 2020 at 3:07 PM Masahiko Sawada > wrote: > > > > On Thu, 11 Jun 2020 at 18:11, Amit Kapila wrote: > > > > > > On Thu, Jun 11, 2020 at 1:46 PM Masahiko Sawada > > > wrote: > > > > > > > > On Thu, 11 Jun 2020 at 12:30, Amit Kapi

Re: Windows regress fails (latest HEAD)

Em qui., 11 de jun. de 2020 às 11:00, Andrew Dunstan < andrew.duns...@2ndquadrant.com> escreveu: > > On 6/11/20 9:40 AM, Ranier Vilela wrote: > > Em qui., 11 de jun. de 2020 às 10:36, Andrew Dunstan > > > > escreveu: > > > > > > > > > > > > > > > >

Re: Windows regress fails (latest HEAD)

On 6/11/20 9:40 AM, Ranier Vilela wrote: > Em qui., 11 de jun. de 2020 às 10:36, Andrew Dunstan > > escreveu: > > > > > > > > >       * which configuration settings you're using > > > > None. Only build with default configuration (release is

Re: Terminate the idle sessions

On Jun 10, 2020, at 10:27 PM, Adam Brusselback mailto:adambrusselb...@gmail.com>> wrote: My use case is, I have a primary application that connects to the DB, most users work through that (setting is useless for this scenario, app manages it's connections well enough). I also have a number of

Re: remove some STATUS_* symbols

On 2020-01-16 13:56, Robert Haas wrote: On Thu, Jan 16, 2020 at 12:50 AM Michael Paquier wrote: Thanks, that looks fine. I am still not sure whether the second patch adding an enum via ProcWaitStatus improves the code readability though, so my take would be to discard it for now. Perhaps othe

Re: Windows regress fails (latest HEAD)

Em qui., 11 de jun. de 2020 às 10:36, Andrew Dunstan < andrew.duns...@2ndquadrant.com> escreveu: > > On 6/11/20 9:28 AM, Ranier Vilela wrote: > > Em qui., 11 de jun. de 2020 às 10:01, Andrew Dunstan > > > > escreveu: > > > > > > On 6/11/20 8:52 AM, Ranie

Re: Windows regress fails (latest HEAD)

On 6/11/20 9:28 AM, Ranier Vilela wrote: > Em qui., 11 de jun. de 2020 às 10:01, Andrew Dunstan > > escreveu: > > > On 6/11/20 8:52 AM, Ranier Vilela wrote: > > Hi, > > Latest HEAD, fails with windows regress tests. > > > >  float8      

Re: Windows regress fails (latest HEAD)

Em qui., 11 de jun. de 2020 às 10:01, Andrew Dunstan < andrew.duns...@2ndquadrant.com> escreveu: > > On 6/11/20 8:52 AM, Ranier Vilela wrote: > > Hi, > > Latest HEAD, fails with windows regress tests. > > > > float8 ... FAILED 517 ms > > partition_prune ..

Re: Transactions involving multiple postgres foreign servers, take 2

On Fri, Jun 5, 2020 at 3:16 PM Masahiko Sawada wrote: > > On Thu, 4 Jun 2020 at 12:46, Amit Kapila wrote: > > > > > > + > > + This parameter can be changed at any time; the behavior for any > > one > > + transaction is determined by the setting in effect when it > > comm

Re: Windows regress fails (latest HEAD)

On 6/11/20 8:52 AM, Ranier Vilela wrote: > Hi, > Latest HEAD, fails with windows regress tests. > >  float8                       ... FAILED      517 ms >  partition_prune              ... FAILED     3085 ms > > Ranier, The first thing you should do when you find this is to see if there is a b

Windows regress fails (latest HEAD)

Hi, Latest HEAD, fails with windows regress tests. float8 ... FAILED 517 ms partition_prune ... FAILED 3085 ms regards, Ranier VIlela regression.diffs Description: Binary data regression.out Description: Binary data

[PATCH] fix two shadow vars (src/backend/commands/sequence.c)

Hi, src/backend/commands/sequence.c Has two shadows (buf var), with two unnecessary variables declared. For readability reasons, the declaration of variable names in the prototypes was also corrected. regards, Ranier Vilela fix_shadows_buf_var.patch Description: Binary data

jsonpath versus NaN

Commit 72b646033 inserted this into convertJsonbScalar: break; case jbvNumeric: + /* replace numeric NaN with string "NaN" */ + if (numeric_is_nan(scalarVal->val.numeric)) + { +

Re: Parallel Seq Scan vs kernel read ahead

On Thu, Jun 11, 2020 at 10:13 AM David Rowley wrote: > > On Thu, 11 Jun 2020 at 16:03, Amit Kapila wrote: > > I think something on these lines would be a good idea especially > > keeping step-size proportional to relation size. However, I am not > > completely sure if doubling the step-size with

Re: Recording test runtimes with the buildfarm

On 6/10/20 6:00 PM, Andres Freund wrote: > On June 10, 2020 2:13:51 PM PDT, David Rowley wrote: >>On Thu, 11 Jun 2020 at 02:13, Tom Lane wrote: >>> I have in the past scraped the latter results and tried to make sense >>of >>> them. They are *mighty* noisy, even when considering just one animal

Re: Internal key management system

Hello Masahiko-san, If the KEK is ever present in pg process, it presumes that the threat model being addressed allows its loss if the process is compromised, i.e. all (past, present, future) security properties are void once the process is compromised. Why we should not put KEK in pg proces

Re: Resetting spilled txn statistics in pg_stat_replication

On Thu, Jun 11, 2020 at 3:07 PM Masahiko Sawada wrote: > > On Thu, 11 Jun 2020 at 18:11, Amit Kapila wrote: > > > > On Thu, Jun 11, 2020 at 1:46 PM Masahiko Sawada > > wrote: > > > > > > On Thu, 11 Jun 2020 at 12:30, Amit Kapila wrote: > > > > > > > > > > > > Now, thinking about this again, I a

Re: typos in comments referring to macros

On Wed, Jun 10, 2020 at 3:19 PM Amit Kapila wrote: > > On Wed, Jun 10, 2020 at 2:47 PM John Naylor > wrote: > > > > It should be BLCKSZ and LOBLKSIZE, as in the attached. > > > > LGTM on first look. I'll push either later today or tomorrow. > Pushed. -- With Regards, Amit Kapila. EnterpriseDB

Re: Resetting spilled txn statistics in pg_stat_replication

On Thu, 11 Jun 2020 at 18:11, Amit Kapila wrote: > > On Thu, Jun 11, 2020 at 1:46 PM Masahiko Sawada > wrote: > > > > On Thu, 11 Jun 2020 at 12:30, Amit Kapila wrote: > > > > > > > > > Now, thinking about this again, I am not sure if these stats are > > > directly related to slots. These are sta

Re: Resetting spilled txn statistics in pg_stat_replication

On Thu, Jun 11, 2020 at 1:46 PM Masahiko Sawada wrote: > > On Thu, 11 Jun 2020 at 12:30, Amit Kapila wrote: > > > > > > Now, thinking about this again, I am not sure if these stats are > > directly related to slots. These are stats for logical decoding which > > can be performed either via WALSen

problem with RETURNING and update row movement

Hi, While working on [1], I came across a bug. Reproduction steps: create table foo (a int, b int) partition by list (a); create table foo1 (c int, b int, a int); alter table foo1 drop c; alter table foo attach partition foo1 for values in (1); create table foo2 partition of foo for values in (2

Re: Add support for INDEX_CLEANUP and TRUNCATE to vacuumdb

On Thu, 11 Jun 2020 at 09:41, Bossart, Nathan wrote: > > Hi hackers, > > I quickly put together a patch to add INDEX_CLEANUP and TRUNCATE to > vacuumdb before noticing a previous thread for it [0]. My take on it > was to just name the options --skip-index-cleanup and --skip-truncate. > While tha

Re: Internal key management system

On Thu, 11 Jun 2020 at 16:07, Fabien COELHO wrote: > > > Hello Bruce, > > Sorry for the length (yet again) of this answer, I'm trying to make my > point as clear as possible. Thank you for your explanation! > > >> Obviously it requires some more thinking and design, but my point is that > >> pos

Re: Resetting spilled txn statistics in pg_stat_replication

On Thu, 11 Jun 2020 at 12:30, Amit Kapila wrote: > > On Thu, Jun 11, 2020 at 12:35 AM Magnus Hagander wrote: > > > > On Wed, Jun 10, 2020 at 9:01 AM Masahiko Sawada > > wrote: > >> > > > >> If we move these values to replication slots, I think we can change > >> the code so that these statistic

Re: Index Skip Scan (new UniqueKeys)

On Tue, Jun 9, 2020 at 6:20 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > Hi, > > Here is a new version of index skip scan patch, based on v8 patch for > UniqueKeys implementation from [1]. I want to start a new thread to > simplify navigation, hopefully I didn't forget anyone who actively > p

Re: proposal: possibility to read dumped table's name from file

st 10. 6. 2020 v 0:30 odesílatel Justin Pryzby napsal: > On Tue, Jun 09, 2020 at 11:46:24AM +0200, Pavel Stehule wrote: > > po 8. 6. 2020 v 23:30 odesílatel Justin Pryzby > napsal: > > > I still wonder if a better syntax would use a unified --filter option, > whose > > > argument would allow inc

Re: Add tap test for --extra-float-digits option

On Thu, Jun 11, 2020 at 02:25:37PM +0900, Dong Wook Lee wrote: > Hi hackers! I added tap test code for pg_dump --extra-float-digits option > because it hadn't tested it. There was no problem when writing test code > and running TAP tests. If we go down to that (there is a test for --compression),

Re: Add support for INDEX_CLEANUP and TRUNCATE to vacuumdb

On Thu, Jun 11, 2020 at 12:41:17AM +, Bossart, Nathan wrote: > I quickly put together a patch to add INDEX_CLEANUP and TRUNCATE to > vacuumdb before noticing a previous thread for it [0]. My take on it > was to just name the options --skip-index-cleanup and --skip-truncate. > While that does

Re: Internal key management system

Hello Bruce, Sorry for the length (yet again) of this answer, I'm trying to make my point as clear as possible. Obviously it requires some more thinking and design, but my point is that postgres should not hold a KEK, ever, nor presume how DEK are to be managed by a DMS, and that is not ver

Re: Asynchronous Append on postgres_fdw nodes.

On 6/10/20 8:05 AM, Kyotaro Horiguchi wrote: Hello, Andrey. At Tue, 9 Jun 2020 14:20:42 +0500, Andrey Lepikhov wrote in On 6/4/20 11:00 AM, Kyotaro Horiguchi wrote: 2. Total cost of an Append node is a sum of the subplans. Maybe in the case of asynchronous append we need to use some reduce fa