RE: libpq debug log

Hi, Thank you for your comments and advice. I'd like to consider your suggestions. I am planning to change libpq logging like this; 1. Expand PQtrace() facility and improve libpq logging. 2. Prepare "output level". There are 3 type of levels; - TRADITIONAL : if set, outputs protocol

Re: Minimal logical decoding on standbys

On Fri, 14 Dec 2018 at 06:25, Andres Freund wrote: > I've a prototype attached, but let's discuss the details in a separate > thread. This also needs to be changed for pluggable storage, as we don't > know about table access methods in the startup process, so we can't call > can't determine which

Re: Minimal logical decoding on standbys

On 03/04/2019 04:54 PM, tushar wrote: .)Perform pg_basebackup using --slot=decoding_standby  with option -R . modify port= , start the server set primary_slot_name = 'decoding_standby'  in the postgresql.conf file of slave. -- regards,tushar EnterpriseDB https://www.enterprisedb.com/

Re: amcheck verification for GiST

On 04/03/2019 17:53, Heikki Linnakangas wrote: I tested this patch with your testing patch from the other thread (after fixing the above), to leave behind incompletely split pages [1]. It seems that the amcheck code doesn't expect incomplete splits: postgres=# SELECT

RE: speeding up planning with partitions

Amit-san, On Fri, Mar 1, 2019 at 1:02 PM, Amit Langote wrote: > Thanks for testing and sorry it took me a while to reply. Thanks for working about this late at night. I know you have a lot of things to do. > On 2019/02/25 15:24, Imai, Yoshikazu wrote: > >

Re: [HACKERS] CLUSTER command progress monitor

On 2019/03/02 4:15, Robert Haas wrote: On Thu, Feb 28, 2019 at 11:54 PM Tatsuro Yamada wrote: Attached patch is wip patch. Thanks for your comments! :) I revised the code and the document. + CLUSTER and VACUUM FULL, showing current progress. and -> or Fixed. + certain

Re: libpq debug log

Hello. I came up with some random comments. At Mon, 4 Mar 2019 08:13:00 +, "Iwata, Aya" wrote in <71E660EB361DF14299875B198D4CE5423DEF1844@g01jpexmbkw25> > Hi, > > Thank you for your comments and advice. > > I'd like to consider your suggestions. > I am planning to change libpq logging

RE: pgbench - doCustom cleanup

Hello Kirk, so I tried to apply the patch, but part of the chunk failed, because of the unused line below which was already removed in the recent related commit. PGResult*res; I removed the line and fixed the other trailing whitespaces. Indeed. Thanks for the fix. See

Re: GiST VACUUM

On 04/01/2019 21:26, Andrey Borodin wrote: 3 янв. 2019 г., в 23:47, Andrey Borodin написал(а): * Bitmapset stores 32 bit signed integers, but BlockNumber is unsigned. So this will fail with an index larger than 2^31 blocks. That's perhaps academical, I don't think anyone will try to create a

Re: unconstify equivalent for volatile

On 2019-02-25 09:29, Peter Eisentraut wrote: > On 2019-02-22 21:31, Andres Freund wrote: >> On 2019-02-22 12:38:35 +0100, Peter Eisentraut wrote: >>> On 2019-02-19 18:02, Andres Freund wrote: But even if we were to decide we'd want to keep a volatile in SetLatch() - which I think really

Re: speeding up planning with partitions

Imai-san, Thanks for the review. On 2019/03/04 18:14, Imai, Yoshikazu wrote: > I've taken at glance the codes and there are some minor comments about the > patch. > > * You changed a usage/arguments of get_relation_info, but why you did it? I > made those codes back to the original code and

Re: [HACKERS] Weaker shmem interlock w/o postmaster.pid

Hello. At Sun, 2 Dec 2018 16:41:06 -0800, Noah Misch wrote in <20181203004106.ga2860...@rfd.leadboat.com> > On Thu, Nov 29, 2018 at 10:51:40PM -0800, Noah Misch wrote: > > On Thu, Nov 29, 2018 at 01:10:57PM +0100, Dmitry Dolgov wrote: > > > As a side note, with this patch recovery tests are

Re: amcheck verification for GiST

There's a little copy-pasto in gist_check_page_keys(): + for (o = FirstOffsetNumber; o <= parent_maxoff; o = OffsetNumberNext(i)) Should be "OffsetNumberNext(o)". I tested this patch with your testing patch from the other thread (after fixing the above), to leave

Re: speeding up planning with partitions

Hi, On 2019/03/01 22:01, Amit Langote wrote: > Please find attached updated patches. Will update source code comments, > commit message and perform other fine-tuning over the weekend if possible. I realized when "fine-tuning" that the patch 0001 contained too many changes that seem logically

Re: [HACKERS] CLUSTER command progress monitor

On 2019/03/02 4:15, Robert Haas wrote: On Thu, Feb 28, 2019 at 11:54 PM Tatsuro Yamada wrote: Attached patch is wip patch. I rewrote the current design of the progress monitor and also wrote discussion points in the middle of this email. I'd like to get any feedback from -hackers. ===

Re: Minimal logical decoding on standbys

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 enabled. Does having that fix the issue? Ok, This time

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: 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: [HACKERS] Incomplete startup packet errors

Re: Andrew Dunstan 2019-03-04 <7cc6d2c1-bd87-9890-259d-36739c247...@2ndquadrant.com> > Looks good to me. +1. Christoph

RE: SQL statement PREPARE does not work in ECPG

Hi Meskes-san Thank you for your advice. I attach a patch. I didn't add additional tests to regression yet. The patch allows the following: exec sql prepare(int) as select $1; 　exec sql execute st(1) into :out; exec sql prepare(text, text) as select $1 || $2; 　exec sql execute st('aaa',

Re: [HACKERS] Incomplete startup packet errors

On 3/3/19 3:52 PM, Tom Lane wrote: > I wrote: >> Andrew Dunstan writes: >>> Patch proposed by Christoph Berg is here: >>> https://www.postgresql.org/message-id/20190228151336.GB7550%40msg.df7cb.de >> Meh. That doesn't silence only the zero-bytes case, and I'm also >> rather afraid of the fact

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: \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: 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: GiST VACUUM

On 04/01/2019 02:47, Andrey Borodin wrote: 2 янв. 2019 г., в 20:35, Heikki Linnakangas написал(а): In patch #1, to do the vacuum scan in physical order: ... I think this is ready to be committed, except that I didn't do any testing. We discussed the need for testing earlier. Did you write

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,

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

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

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

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

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

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

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

  1   2   >