Re: Re: \describe*

On 2/25/19 9:44 PM, Robert Haas wrote: On Sat, Feb 23, 2019 at 7:19 PM Andres Freund wrote: Sure, but it was late, and we have far more patches than we can deal with. Many of them much much older than this. More importantly, at least in my opinion, is that this is one of those questions that

Re: psql show URL with help

On 2019-03-04 17:55, Magnus Hagander wrote: > If the first thing we do when we move from devel to some other state > (beta, RC, etc.) is to publish the docs under the major version > number, then maybe this test should be more along the lines of looking > for anything that's

Re: speeding up planning with partitions

Imai-san, Thanks for checking. On 2019/03/05 15:03, Imai, Yoshikazu wrote: > I've also done code review of 0001 and 0002 patch so far. > > [0001] > 1. Do we need to open/close a relation in add_appendrel_other_rels()? > > + if (rel->part_scheme) > { > - ListCell *l; >

Re: Patch to document base64 encoding

Hello Karl, Doc patch, against master. Documents encode() and decode() base64 format. It is already documented. Enhance documentation, though. Builds for me. For me as well. Looks ok. Attached: doc_base64_v1.patch References RFC2045 section 6.8 to define base64. Did you consider

Re: Inheriting table AMs for partitioned tables

Hi, On 2019-03-05 16:01:50 +1300, David Rowley wrote: > On Tue, 5 Mar 2019 at 12:47, Andres Freund wrote: > > CREATE TABLE tableam_parted_heap2 (a text, b int) PARTITION BY list (a) > > USING heap2; > > > > SET default_table_access_method = 'heap'; > > CREATE TABLE tableam_parted_a_heap2

RE: speeding up planning with partitions

Amit-san, On Tue, Mar 5, 2019 at 0:51 AM, Amit Langote wrote: > Hi Jesper, > > Thanks for the review. I've made all of the changes per your comments > in my local repository. I'll post the updated patches after diagnosing > what I'm suspecting a memory over-allocation bug in one of the

Re: Delay locking partitions during query execution

On Sat, 2 Feb 2019 at 02:52, Robert Haas wrote: > I think the key question here is whether or not you can cope with > someone having done arbitrary AEL-requiring modifications to the > delaylocked partitions. If you can, the fact that the plan might > sometimes be out-of-date is an inevitable

Re: [bug fix] Produce a crash dump before main() on Windows

On Mon, Mar 4, 2019 at 3:23 PM Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello. > > At Tue, 6 Nov 2018 15:53:37 +1100, Haribabu Kommi < > kommi.harib...@gmail.com> wrote in < > cajrrpgcxzi4z_sttnuuvyoaw+sadk7+cjgypuf7ao43vujl...@mail.gmail.com> > > Thanks for confirmation of

Re: Inheriting table AMs for partitioned tables

On Tue, Mar 5, 2019 at 10:47 AM Andres Freund wrote: > Hi, > > In the pluggable storage patch [1], one thing that I'm wondering about > is how exactly to inherit the storage AM across partitions. I think > that's potentially worthy of a discussion with a wider audience than I'd > get in that

Re: Inheriting table AMs for partitioned tables

On 2019/03/05 11:59, Amit Langote wrote: > On 2019/03/05 8:47, Andres Freund wrote: >> Hi, >> >> In the pluggable storage patch [1], one thing that I'm wondering about >> is how exactly to inherit the storage AM across partitions. I think >> that's potentially worthy of a discussion with a wider

Re: Fix memleaks and error handling in jsonb_plpython

On Fri, Mar 01, 2019 at 05:24:39AM +0300, Nikita Glukhov wrote: > Unfortunately, contrib/jsonb_plpython still contain a lot of problems in error > handling that can lead to memory leaks: > - not all Python function calls are checked for the success > - not in all places PG exceptions are caught

Re: libpq debug log

On Mon, Mar 4, 2019 at 10:25 PM Tom Lane wrote: > Robert Haas writes: > > The basic idea being: > > - Each line is a whole message. > > - The line begins with <<< for a message received and >>> for a message > > sent. > > +1, though do we really need to repeat the direction marker thrice?

Re: libpq debug log

Robert Haas writes: > The basic idea being: > - Each line is a whole message. > - The line begins with <<< for a message received and >>> for a message sent. +1, though do we really need to repeat the direction marker thrice? > - Strings in single quotes are those sent/received as a fixed

Re: bgwriter_lru_maxpages limits in PG 10 sample conf

On 2019-Mar-04, Bruce Momjian wrote: > On Thu, Feb 28, 2019 at 10:28:44AM +0300, Sergei Kornilov wrote: > > Hello > > > > postgresql.conf.sample was changed recently in REL_10_STABLE (commit > > ab1d9f066aee4f9b81abde6136771debe0191ae8) > > So config will be changed in next minor release

Re: Online verification of checksums

On Mon, Mar 04, 2019 at 03:08:09PM +0100, Tomas Vondra wrote: > I still don't understand what issue you see in how basebackup verifies > checksums. Can you point me to the explanation you've sent after 11 was > released? The history is mostly on this thread:

Re: Inheriting table AMs for partitioned tables

On Tue, 5 Mar 2019 at 16:01, David Rowley wrote: > I'd suggest it's made to work the same way as ca4103025dfe26 made > tablespaces work. i.e. if they specify the storage type when creating > the partition, then always use that, unless they mention otherwise. If > nothing was mentioned when they

Re: libpq debug log

On Mon, Mar 4, 2019 at 3:13 AM Iwata, Aya wrote: > 2. Prepare "output level". There are 3 type of levels; > - TRADITIONAL : if set, outputs protocol messages > - LEVEL1: if set, outputs phase and time > - LEVEL2: if set, outputs both

Re: monitoring CREATE INDEX [CONCURRENTLY]

Hi Rahila, Thanks for looking. On 2019-Mar-04, Rahila wrote: > 1. Thank you for incorporating review comments. > Can you please rebase the latest 0001-Report-progress-of- > CREATE-INDEX-operations.patch on master? Currently it does not apply on > 754b90f657bd54b482524b73726dae4a9165031c Hmm,

Re: Inheriting table AMs for partitioned tables

On Tue, 5 Mar 2019 at 12:47, Andres Freund wrote: > CREATE TABLE tableam_parted_heap2 (a text, b int) PARTITION BY list (a) USING > heap2; > > SET default_table_access_method = 'heap'; > CREATE TABLE tableam_parted_a_heap2 PARTITION OF tableam_parted_heap2 FOR > VALUES IN ('a'); > But for

Re: Inheriting table AMs for partitioned tables

On 2019/03/05 8:47, Andres Freund wrote: > Hi, > > In the pluggable storage patch [1], one thing that I'm wondering about > is how exactly to inherit the storage AM across partitions. I think > that's potentially worthy of a discussion with a wider audience than I'd > get in that thread. It

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On Tue, Mar 5, 2019 at 5:11 AM Andres Freund wrote: > > Hi, > > On 2019-03-04 20:03:37 +, Bossart, Nathan wrote: > > On 3/3/19, 9:23 PM, "Masahiko Sawada" wrote: > > > FWIW, I agree that we have options for vacuum as vacuum > > > command options. But for reloptions, I think if the

Re: [HACKERS] CLUSTER command progress monitor

On Mon, Mar 4, 2019 at 5:38 AM Tatsuro Yamada wrote: > === Current design === > > CLUSTER command uses Index Scan or Seq Scan when scanning the heap. > Depending on which one is chosen, the command will proceed in the > following sequence of phases: > >* Scan method: Seq Scan > 0.

Re: Inheriting table AMs for partitioned tables

On Tue, Mar 5, 2019 at 5:17 AM Andres Freund wrote: > > Hi, > > In the pluggable storage patch [1], one thing that I'm wondering about > is how exactly to inherit the storage AM across partitions. I think > that's potentially worthy of a discussion with a wider audience than I'd > get in that

Re: psql display of foreign keys

On 2019/03/05 4:41, Alvaro Herrera wrote: > Here's the patch I'm really interested about :-) Thanks for the updated patch. I applied it and rebased the foreign-keys-referencing-partitioned-tables patch on top. Here's something I think you may have missed: -- partitioned primary key table

Re: Ordered Partitioned Table Scans

Thanks a lot for taking the time to look at this. On Tue, 5 Mar 2019 at 03:03, Antonin Houska wrote: > As for the latest version (v8-0001-...) I've only caught a small typo: "When > the first subpath needs sorted ...". It was probably meant "... needs sort > ...". That was a sort of short way

Re: speeding up planning with partitions

Hi Jesper, Thanks for the review. I've made all of the changes per your comments in my local repository. I'll post the updated patches after diagnosing what I'm suspecting a memory over-allocation bug in one of the patches. If you configure build with --enable-cassert, you'll see that

Re: POC: converting Lists into arrays

David Rowley writes: > On Tue, 5 Mar 2019 at 12:54, Andres Freund wrote: >> Yes, I think you have a point that progress here would be good and that >> it's worth some pain. But the names will make even less sense if we just >> shunt in an array based approach under the already obscure list >>

Re: POC: converting Lists into arrays

David Rowley writes: > ... With list_concat() I find that pretty scary > anyway. Using it means we can have a valid list that does not get it's > length updated when someone appends a new item. Most users of that do > list_copy() to sidestep that and other issues... which likely is > something

Re: Allowing extensions to supply operator-/function-specific info

Paul Ramsey writes: >> On Mar 4, 2019, at 2:52 PM, Tom Lane wrote: >> BTW, if you'd like me to review the code you added for this, I'd be happy >> to do so. I've never looked at PostGIS' innards, but probably I can make >> sense of the code for this despite that. > I would be ecstatic for a

Re: POC: converting Lists into arrays

On Tue, 5 Mar 2019 at 12:54, Andres Freund wrote: > Yes, I think you have a point that progress here would be good and that > it's worth some pain. But the names will make even less sense if we just > shunt in an array based approach under the already obscure list > API. If we feel strongly

Re: Should we increase the default vacuum_cost_limit?

On Mon, Feb 25, 2019 at 8:48 AM Robert Haas wrote: > +1 for raising the default substantially. In my experience, and it > seems others are in a similar place, nobody ever gets into trouble > because the default is too high, but sometimes people get in trouble > because the default is too low.

GSoC 2019 - TOAST'ing in slices idea

Hello everyone, I am currently writing my proposal for GSoC 2019 for the TOAST'ing in slices idea. I already have a sketch of the description and approach outline, which I am sending in this e-mail. I would be happy

Re: pg_dump multi VALUES INSERT

Thanks for looking at this again. On Sat, 2 Mar 2019 at 20:01, Fabien COELHO wrote: > Although I'm all in favor of checking the int associated to the option, I > do not think that it warrants three checks and messages. I would suggest > to factor them all as just one check and one (terse)

RE: pgbench - doCustom cleanup

Hi Fabien, >> See the attached latest patch. >> The attached patch applies, builds cleanly, and passes the regression >> tests. > > No problems on my part as I find the changes logical. > This also needs a confirmation from Alvaro. > > Ok. > > You switched the patch to "waiting on author": What

Re: POC: converting Lists into arrays

Hi, On 2019-03-05 12:42:47 +1300, David Rowley wrote: > So you think targetlists are the only case to benefit from an array > based list? (Ignoring the fact that I already showed another case) No, that's not what I'm trying to say at all. I think there's plenty cases where it'd be beneficial. In

Re: bgwriter_lru_maxpages limits in PG 10 sample conf

On Thu, Feb 28, 2019 at 10:28:44AM +0300, Sergei Kornilov wrote: > Hello > > postgresql.conf.sample was changed recently in REL_10_STABLE (commit > ab1d9f066aee4f9b81abde6136771debe0191ae8) > So config will be changed in next minor release anyway. We have another > reason to not fix

Inheriting table AMs for partitioned tables

Hi, In the pluggable storage patch [1], one thing that I'm wondering about is how exactly to inherit the storage AM across partitions. I think that's potentially worthy of a discussion with a wider audience than I'd get in that thread. It seems also related to the recent discussion in [2]

Re: POC: converting Lists into arrays

On Tue, 5 Mar 2019 at 11:11, Andres Freund wrote: > On 2019-03-04 16:28:40 -0500, Tom Lane wrote: > > Andres Freund writes: > > > I don't buy this. I think e.g. redisgning the way we represent > > > targetlists would be good (it's e.g. insane that we recompute > > > descriptors out of them all

Re: New vacuum option to do only freezing

On 2/28/19, 12:13 AM, "Masahiko Sawada" wrote: > Attached the updated version patch. I've incorporated all review > comments I got and have changed the number of tuples being reported as > 'removed tuples'. With this option, tuples completely being removed is > only tuples marked as unused during

Re: jsonpath

A bunch of additional comments, after looking at the patch a bit today. All are mostly minor, and sometime perhaps a matter of preference. 1) There's a mismatch between the comment and actual function name for jsonb_path_match_opr and jsonb_path_exists_opr(). The comments say "_novars" instead.

Re: Rare SSL failures on eelpout

On Tue, Mar 5, 2019 at 11:35 AM Tom Lane wrote: > Thomas Munro writes: > > OK, here's something. I can reproduce it quite easily on this > > machine, and I can fix it like this: > > >libpq_gettext("could not send startup packet: %s\n"), > >SOCK_STRERROR(SOCK_ERRNO, sebuf,

Re: Allowing extensions to supply operator-/function-specific info

> On Mar 4, 2019, at 2:52 PM, Tom Lane wrote: > > Paul Ramsey writes: >> Gotcha, done and now have an implementation that passes all our regression >> tests. > > Very cool! So the next step, I guess, is to address your original problem > by cranking up the cost estimates for these

Re: Allowing extensions to supply operator-/function-specific info

Paul Ramsey writes: > Gotcha, done and now have an implementation that passes all our regression > tests. Very cool! So the next step, I guess, is to address your original problem by cranking up the cost estimates for these functions --- have you tried that yet? In principle you should be

Re: pg_partition_tree crashes for a non-defined relation

On Mon, Mar 04, 2019 at 03:56:00PM -0300, Alvaro Herrera wrote: > I added tests to immortalize the current behavior for legacy inheritance > relations too. Thanks! Makes sense, thanks. -- Michael signature.asc Description: PGP signature

Re: Remove Deprecated Exclusive Backup Mode

On Thu, Feb 28, 2019 at 05:08:24PM +0200, David Steele wrote: > On 2/28/19 4:44 PM, Fujii Masao wrote: > > On Wed, Feb 27, 2019 at 4:35 PM Laurenz Albe > > wrote: > > > > > > Fujii Masao wrote: > > > > So, let me clarify the situations; > > > > > > > > (3) If backup_label.pending exists but

Patch to document base64 encoding

Hi, Doc patch, against master. Documents encode() and decode() base64 format. Builds for me. Attached: doc_base64_v1.patch References RFC2045 section 6.8 to define base64. Because encode() and decode() show up in both the string functions section and the binary string functions section I

Re: Rare SSL failures on eelpout

Thomas Munro writes: > On Tue, Mar 5, 2019 at 10:08 AM Tom Lane wrote: >> It's all very confusing, but I think there's a nontrivial chance >> that this is an OpenSSL bug, especially since we haven't been able >> to replicate it elsewhere. > Hmm. Yes, it is strange that we haven't seen it

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On 3/4/19, 2:05 PM, "Andres Freund" wrote: > On 2019-03-04 22:00:47 +, Bossart, Nathan wrote: >> On 3/4/19, 1:44 PM, "Andres Freund" wrote: >> > Yea, I do think that's a danger. But we allow disabling autovacuum, so >> > I'm not sure it matters that much... And for indexes you'd still have

Re: patch to allow disable of WAL recycling

Alvaro, Thanks for taking a look at the new patch. I'll update the patch to change the name of the tunable to match your suggestion and I'll also go through the cleanup you suggested. Finally, I'll try to rewrite the doc to eliminate the confusion around the wording about allocating new blocks on

Re: POC: converting Lists into arrays

On Mon, Mar 4, 2019 at 2:04 PM Bruce Momjian wrote: > On Mon, Mar 4, 2019 at 12:44:41PM -0500, Robert Haas wrote: > > I think that's a separate but also promising thing to attack, and I > > agree that it'd take a lot of work to get there. I don't think that > > the problem with either

Re: POC: converting Lists into arrays

On Mon, Mar 4, 2019 at 01:11:35PM -0500, Tom Lane wrote: > Robert Haas writes: > > I think the reason why you're not seeing a performance benefit is > > because the problem is not that lists are generically a more expensive > > data structure than arrays, but that there are cases when they are >

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

Hi, On 2019-03-04 22:00:47 +, Bossart, Nathan wrote: > On 3/4/19, 1:44 PM, "Andres Freund" wrote: > > Yea, I do think that's a danger. But we allow disabling autovacuum, so > > I'm not sure it matters that much... And for indexes you'd still have > > the index page-level vacuum that'd

Re: POC: converting Lists into arrays

On Mon, Mar 4, 2019 at 12:44:41PM -0500, Robert Haas wrote: > I think that's a separate but also promising thing to attack, and I > agree that it'd take a lot of work to get there. I don't think that > the problem with either parse-tree-copying or list usage is that no > performance benefits are

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On 3/4/19, 1:44 PM, "Andres Freund" wrote: > On 2019-03-04 21:40:53 +, Bossart, Nathan wrote: >> On 3/4/19, 12:11 PM, "Andres Freund" wrote: >> > I'm not quite convinced this is right. There's plenty sites that >> > practically can't use autovacuum because it might decide to vacuum the >> >

Re: Rare SSL failures on eelpout

On Tue, Mar 5, 2019 at 10:08 AM Tom Lane wrote: > I wrote: > > Thomas Munro writes: > >> That suggests that we could perhaps handle ECONNRESET both at startup > >> packet send time (for certificate rejection, eelpout's case) and at > >> initial query send (for idle timeout, bug #15598's case) by

[Proposal] TOAST'ing in slices

Hello Hackers, I'm intending to optimize some varlena data types as my GSoC proposal. That would be done by a smarter way of splitting the TOAST table chunks, depending on its data type. A JSONB would be split considering its internal tree structure, keeping track of which keys are in each

Re: Making all nbtree entries unique by having heap TIDs participate in comparisons

On Sun, Mar 3, 2019 at 10:02 PM Heikki Linnakangas wrote: > Some comments on > v13-0002-make-heap-TID-a-tie-breaker-nbtree-index-column.patch below. > Mostly about code comments. In general, I think a round of copy-editing > the comments, to use simpler language, would do good. The actual code >

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

Hi, On 2019-03-04 21:40:53 +, Bossart, Nathan wrote: > On 3/4/19, 12:11 PM, "Andres Freund" wrote: > > I'm not quite convinced this is right. There's plenty sites that > > practically can't use autovacuum because it might decide to vacuum the > > 5TB index because of 300 dead tuples in the

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On 3/4/19, 12:11 PM, "Andres Freund" wrote: > I'm not quite convinced this is right. There's plenty sites that > practically can't use autovacuum because it might decide to vacuum the > 5TB index because of 300 dead tuples in the middle of busy periods. And > without an reloption that's not

Re: POC: converting Lists into arrays

Andres Freund writes: > I don't buy this. I think e.g. redisgning the way we represent > targetlists would be good (it's e.g. insane that we recompute > descriptors out of them all the time), and would reduce their allocator > costs. Maybe we're not on the same page here, but it seems to me that

Re: Allowing extensions to supply operator-/function-specific info

Paul Ramsey writes: > I had what seemed to be working code except for a couple rare cases, > but when I fixed those cases it turned out that I had a major problem: > building a OP expression works fine, but building a > OP expression returns me an error. Yup, you're not supposed to do that.

Re: Rare SSL failures on eelpout

I wrote: > Thomas Munro writes: >> That suggests that we could perhaps handle ECONNRESET both at startup >> packet send time (for certificate rejection, eelpout's case) and at >> initial query send (for idle timeout, bug #15598's case) by attempting >> to read. Does that make sense? > Hmm ...

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

Hi, On 2019-03-04 20:03:37 +, Bossart, Nathan wrote: > On 3/3/19, 9:23 PM, "Masahiko Sawada" wrote: > > FWIW, I agree that we have options for vacuum as vacuum > > command options. But for reloptions, I think if the persistence the > > setting could be problematic we should not. According to

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On 3/3/19, 9:23 PM, "Masahiko Sawada" wrote: > FWIW, I agree that we have options for vacuum as vacuum > command options. But for reloptions, I think if the persistence the > setting could be problematic we should not. According to the > discussions so far, I think VACUUM_SHRINK_ENABLED is the

Re: psql display of foreign keys

On 2019-Feb-28, Michael Paquier wrote: > On Wed, Feb 27, 2019 at 03:37:23PM -0300, Alvaro Herrera wrote: > > +pg_partition_ancestors(PG_FUNCTION_ARGS) > > +{ > > + Oid relid = PG_GETARG_OID(0); > > + FuncCallContext *funcctx; > > + ListCell **next; > > + > > + if

Re: Checksum errors in pg_stat_database

On Fri, Feb 22, 2019 at 3:01 PM Magnus Hagander wrote: > > It tracks things that happen in the general backends. Possibly we should also > consider counting the errors actually found when running base backups? OTOH, > that part of the code doesn't really track things like databases (as it >

Re: Allowing extensions to supply operator-/function-specific info

So I am getting much closer to a working implementation in PostGIS, but have just run into an issue which I am assuming is my misunderstanding something... https://github.com/pramsey/postgis/blob/92268c94f3aa1fc63a2941f2b451be15b28662cf/postgis/gserialized_supportfn.c#L287 I had what seemed to

Re: POC: converting Lists into arrays

Hi, On 2019-03-04 13:11:35 -0500, Tom Lane wrote: > The concern I have is mostly about the use of lists as core infrastructure > in parsetree, plantree, etc data structures. I think any idea that we'd > replace those piecemeal is borderline insane: it's simply not worth it > from a notational

Re: POC: converting Lists into arrays

Hi, On 2019-03-03 13:29:04 -0500, Tom Lane wrote: > The cases I've been looking at suggest to me that we'd make far > more progress on the excessive-palloc'ing front if we could redesign > things to reduce unnecessary copying of parsetrees. Right now the > planner does an awful lot of copying

Re: POC: converting Lists into arrays

Hi, On 2019-03-02 18:11:43 -0500, Tom Lane wrote: > On test cases like "pg_bench -S" it seems to be pretty much within the > noise level of being the same speed as HEAD. I think that might be because it's bottleneck is just elsewhere (e.g. very context switch heavy, very few lists of any

Re: pg_partition_tree crashes for a non-defined relation

On 2019-Feb-28, Alvaro Herrera wrote: > What about legacy inheritance? I see that pg_partition_tree handles > that case perfectly well -- it seems to return the complete hierarchy > rooted at the given relation. However, it seems odd that it works at > all, don't you think? Consider this: >

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 3/4/19 6:40 AM, Masahiko Sawada wrote: > On Sat, Mar 2, 2019 at 5:27 AM Robert Haas wrote: >> >> On Thu, Feb 7, 2019 at 3:28 AM Masahiko Sawada wrote: >>> WAL encryption will follow as an additional feature. >> >> I don't think WAL encryption is an optional feature. You can argue >> about

Re: \describe*

> > >> - Tab completion for \descibe-verbose. >> I know that \d+ tab completion is also not there, but I think we must >> have tab completion for \descibe-verbose. >> >> postgres=# \describe- >> \describe-extension >> \describe-replication-publication \describe-user-mapping >>

Re: query logging of prepared statements

On Mon, Mar 04, 2019 at 06:53:31PM +0300, Arthur Zakirov wrote: > Hello Justin, > > On 27.02.2019 21:06, Justin Pryzby wrote: > >I'm attaching a v2 patch which avoids repeated logging of PREPARE, rather > >than > >making such logs conditional on log_error_verbosity=VERBOSE, since >

Re: Segfault when restoring -Fd dump on current HEAD

Hi, On 2019-03-04 13:25:40 -0500, Tom Lane wrote: > Andres Freund writes: > > One thing I want to bring up here rather than in the pluggable storage > > thread is that currently the pg_dump support for access methods deals > > with table access methods in a manner similar to the way we deal with

Re: GiST VACUUM

Hi! Thanks for fixing gist amcheck! The idea of using these two patches together seems so obvious now, but never actually visited my mind before. > 4 марта 2019 г., в 18:04, Heikki Linnakangas написал(а): > Thanks! As I noted at >

Re: Segfault when restoring -Fd dump on current HEAD

Andres Freund writes: > One thing I want to bring up here rather than in the pluggable storage > thread is that currently the pg_dump support for access methods deals > with table access methods in a manner similar to the way we deal with > tablespaces. Instead of specifying the AM on every table

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 3/4/19 6:55 PM, Laurenz Albe wrote: > Masahiko Sawada wrote: >> Why do people want to just encrypt everything? For satisfying some >> security compliance? > > I'd say that TDE primarily protects you from masked ninjas that > break into your server room and rip out the disks with your database

Re: Segfault when restoring -Fd dump on current HEAD

Hi, On 2019-02-27 09:32:17 -0300, Alvaro Herrera wrote: > On 2019-Feb-27, Dmitry Dolgov wrote: > > But I hope there are no objections if I'll then submit the original > > changes with more consistent null handling separately to make decision > > about them more consciously. > > I think we should

Re: POC: converting Lists into arrays

Robert Haas writes: > I think the reason why you're not seeing a performance benefit is > because the problem is not that lists are generically a more expensive > data structure than arrays, but that there are cases when they are > more expensive than arrays. If you only ever push/pop at the

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Or on your laptop On 3/4/19 11:55 AM, Laurenz Albe wrote: Masahiko Sawada wrote: Why do people want to just encrypt everything? For satisfying some security compliance? I'd say that TDE primarily protects you from masked ninjas that break into your server room and rip out the disks with

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Masahiko Sawada wrote: > Why do people want to just encrypt everything? For satisfying some > security compliance? I'd say that TDE primarily protects you from masked ninjas that break into your server room and rip out the disks with your database on them. Or from people stealing your file

Re: POC: converting Lists into arrays

On Sun, Mar 3, 2019 at 1:29 PM Tom Lane wrote: > > My main observation was from when the expression evaluation was using > > lists all over. List iteration overhead was very substantial there. But > > that's not a problem anymore, because all of those are gone now due to > > the expression

Re: Problem with default partition pruning

Hi Yuzuko Hosoya, Ignore my last message, I think this is also a legitimate scan on default partition. On Mon, Mar 4, 2019 at 10:29 PM Ibrar Ahmed wrote: > Hi > > Patch work fine to me, but I have one test case where default partition > still scanned. > > postgres=# explain select * from

Re: Problem with default partition pruning

Hi Patch work fine to me, but I have one test case where default partition still scanned. postgres=# explain select * from test1 where (id < 10) and true; QUERY PLAN ---

Re: Minimal logical decoding on standbys

Hi, On 2019-03-04 16:54:32 +0530, tushar wrote: > On 03/01/2019 11:16 PM, Andres Freund wrote: > > So, if I understand correctly you do*not* have a phyiscal replication > > slot for this standby? For the feature to work reliably that needs to > > exist, and you need to have hot_standby_feedback

Re: psql show URL with help

On Sun, Mar 3, 2019 at 10:48 PM David Fetter wrote: > On Sun, Mar 03, 2019 at 09:57:25PM +0100, Magnus Hagander wrote: > > On Sun, Mar 3, 2019 at 7:14 PM David Fetter wrote: > > > > > On Wed, Feb 27, 2019 at 09:14:59AM +0100, Peter Eisentraut wrote: > > > > +

Re: speeding up planning with partitions

Hi Amit, Passes check-world. On 3/4/19 5:38 AM, Amit Langote wrote: See patch 0001. +* members of any appendrels we find here are added built later when s/built// See patch 0002. + grouping_planner(root, false, 0.0 /* retrieve all tuples */); Move comment out of

Re: monitoring CREATE INDEX [CONCURRENTLY]

Hi Alvaro, Resending the email as earlier one didn't get sent on pgsql-hackers. On 2/23/19 3:24 AM, Alvaro Herrera wrote: On 2019-Feb-13, Amit Langote wrote: Doesn't the name amphasename sound a bit too generic, given that it can only describe the phases of ambuild? Maybe ambuildphase?

Re: monitoring CREATE INDEX [CONCURRENTLY]

Hi Alvaro, > On 2019-Feb-13, Amit Langote wrote: > > > Doesn't the name amphasename sound a bit too generic, given that it can > > only describe the phases of ambuild? Maybe ambuildphase? > > Hmm, yeah, maybe it does. I renamed it "ambuildphasename", since it's > not about reporting the phase

Re: Online verification of checksums

On Mon, Mar 4, 2019 at 3:02 PM Tomas Vondra wrote: > > > On 3/4/19 4:09 AM, Michael Paquier wrote: > > On Sun, Mar 03, 2019 at 07:58:26AM +0100, Fabien COELHO wrote: > >> I agree that having a server function (extension?) to do a full checksum > >> verification, possibly bandwidth-controlled,

Re: query logging of prepared statements

Hello Justin, On 27.02.2019 21:06, Justin Pryzby wrote: I'm attaching a v2 patch which avoids repeated logging of PREPARE, rather than making such logs conditional on log_error_verbosity=VERBOSE, since log_error_verbosity is documented to control whether these are output:

Re: pg_dump multi VALUES INSERT

On 2019-Mar-02, Fabien COELHO wrote: > Although I'm all in favor of checking the int associated to the option, I do > not think that it warrants three checks and messages. I would suggest to > factor them all as just one check and one (terse) message. I suggest ("rows-per-insert must be in range

Re: insensitive collations

Peter Eisentraut wrote: [v7-0001-Collations-with-nondeterministic-comparison.patch] +GenericMatchText(const char *s, int slen, const char *p, int plen, Oid collation) { + if (collation && !lc_ctype_is_c(collation) && collation != DEFAULT_COLLATION_OID) + { +pg_locale_tlocale =

Re: Re: proposal: variadic argument support for least, greatest function

On 3/1/19 3:59 AM, Chapman Flack wrote: The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed For completeness, I'll

Re: Online verification of checksums

On 3/4/19 2:00 AM, Michael Paquier wrote: > On Sun, Mar 03, 2019 at 03:12:51AM +0100, Tomas Vondra wrote: >> You and Andres may be right that trying to verify checksums online >> without close interaction with the server is ultimately futile (or at >> least overly complex). But I'm not sure

Re: \describe*

Hi Corey, Here is the modified patch (sample). On Mon, Mar 4, 2019 at 7:02 PM Ibrar Ahmed wrote: > The following review has been posted through the commitfest application: > make installcheck-world: not tested > Implements feature: not tested > Spec compliant: not tested >

Re: Ordered Partitioned Table Scans

David Rowley wrote: > On Mon, 5 Nov 2018 at 10:46, David Rowley > wrote: > > On 1 November 2018 at 22:05, Antonin Houska wrote: > > > I think these conditions are too restrictive: > > > > > > /* > > > * Determine if these pathkeys match the partition order, or > > > reverse

Re: \describe*

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested Thanks for the patch, I have reviewed the patch and have some comments about

Re: Online verification of checksums

On 3/4/19 4:09 AM, Michael Paquier wrote: > On Sun, Mar 03, 2019 at 07:58:26AM +0100, Fabien COELHO wrote: >> I agree that having a server function (extension?) to do a full checksum >> verification, possibly bandwidth-controlled, would be a good thing. However >> it would have side effects,

  1   2   >