[PATCH] psql: add tab completion for \df slash command suffixes

Hi I just noticed "\df[TAB]" fails to offer any tab-completion for the possible suffixes ("\dfa", "\dfn", "\dfp", "\dft" and "\dfw"). Trivial patch attached, which applies back to Pg96, and separate patches for Pg95 and Pg94. I'll add this to the next commitfest. Regards Ian Barwick -- Ian

Re: Improve error detections in TAP tests by spreading safe_psql

On Wed, Aug 28, 2019 at 09:44:58PM -0400, Tom Lane wrote: > Well, it's useful if you just want the stdout back. But its name > is a bit misleading if the default behavior of psql is just as > safe. Not sure whether renaming it is worthwhile. It is not that complicated enough to capture stdout

Re: Yet another fast GiST build

On Thu, Aug 29, 2019 at 8:22 PM Alexander Korotkov wrote: > Alternatively you can encode size in Z-value. But this increases > dimensionality of space and decreases efficiency of join. Also, > spatial join can be made using two indexes, even just current GiST > without Z-values. We've

Re: Consolidate 'unique array values' logic into a reusable function?

Hello, I'm reviving a thread from 2016, because I wanted this thing again today. Tom Lane wrote: > Thomas Munro writes: > > Here's a sketch patch that creates a function array_unique which takes > > the same arguments as qsort or qsort_arg and returns the new length. > > Hmm ... I'd be against

Re: Yet another fast GiST build

On Fri, Aug 30, 2019 at 2:34 AM Peter Geoghegan wrote: > On Thu, Aug 29, 2019 at 3:48 PM Alexander Korotkov > wrote: > > > As you can see, Z-order build is on order of magnitude faster. Select > > > performance is roughly the same. Also, index is significantly smaller. > > > > Cool! These

Re: A problem about partitionwise join

On Fri, Aug 30, 2019 at 2:08 AM Etsuro Fujita wrote: > On Thu, Aug 29, 2019 at 6:45 PM Richard Guo wrote: > > On Wed, Aug 28, 2019 at 6:49 PM Etsuro Fujita > wrote: > >> On Tue, Aug 27, 2019 at 4:57 PM Richard Guo wrote: > >> > Check the query below as a more illustrative example: > >> > > >>

Re: Wrong value in metapage of GIN INDEX.

Hi Moon-san. Thank you for posting. We are testing the GIN index onJSONB type. The default maintenance_work_mem (64MB) was fine in usually cases. However, this problem occurs when indexing very large JSONB data. best regards, Keisuke Kuroda 2019年8月29日(木) 17:20 Moon, Insung : > Dear Hackers. >

Re: Yet another fast GiST build

On Thu, Aug 29, 2019 at 3:48 PM Alexander Korotkov wrote: > > As you can see, Z-order build is on order of magnitude faster. Select > > performance is roughly the same. Also, index is significantly smaller. > > Cool! These experiments bring me to following thoughts. Can we not > only build,

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On Thu, Aug 29, 2019 at 5:13 AM Anastasia Lubennikova wrote: > Your explanation helped me to understand that this approach can be > extended to > the case of insertion into posting list, that doesn't trigger posting > split, > and that nbtsplitloc indeed doesn't need to know about posting tuples

Re: REINDEX filtering in the backend

On Thu, Aug 29, 2019 at 10:52:55AM +0200, Julien Rouhaud wrote: > That was already suggested by Thomas and seconded by Peter E., see > https://www.postgresql.org/message-id/2b1504ac-3d6c-11ec-e1ce-3daf132b3d37%402ndquadrant.com. > > I personally think that it's a sensible approach, and I'll be

Re: Yet another fast GiST build

On Mon, Aug 26, 2019 at 10:59 AM Andrey Borodin wrote: > In many cases GiST index can be build fast using z-order sorting. > > I've looked into proof of concept by Nikita Glukhov [0] and it looks very > interesting. > So, I've implemented yet another version of B-tree-like GiST build. > It's

Re: BUG #15977: Inconsistent behavior in chained transactions

> The usual approach is to send self-contained and numbered patches, > eg "chain-fix-1.patch", "chain-fix-2.patch", and so on, unless there are > complex patches designed to be committed in stages. Thanks, I got it. I have never made a patch before so I'll keep it in my mind. Self-contained patch

Re: pg_upgrade: Error out on too many command-line arguments

On 2019-08-26 17:45, Ibrar Ahmed wrote: > On Mon, Aug 26, 2019 at 9:46 AM Michael Paquier > wrote: > > On Sun, Aug 25, 2019 at 05:10:47PM +0200, Julien Rouhaud wrote: > > I did some searching, and oid2name.c is also missing this. > > And pgbench, no? > >

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Thu, Aug 29, 2019 at 05:37:45PM +0300, Alexey Kondratov wrote: On 28.08.2019 22:06, Tomas Vondra wrote: Interesting. Any idea where does the extra overhead in this particular case come from? It's hard to deduce that from the single flame graph, when I don't have anything to compare it

Re: A problem about partitionwise join

On Thu, Aug 29, 2019 at 6:45 PM Richard Guo wrote: > On Wed, Aug 28, 2019 at 6:49 PM Etsuro Fujita wrote: >> On Tue, Aug 27, 2019 at 4:57 PM Richard Guo wrote: >> > Check the query below as a more illustrative example: >> > >> > create table p (k int, val int) partition by range(k); >> > create

Re: block-level incremental backup

Due to the inherent nature of pg_basebackup, the incremental backup also allows taking backup in tar and compressed format. But, pg_combinebackup does not understand how to restore this. I think we should either make pg_combinebackup support restoration of tar incremental backup or restrict taking

Re: BUG #15977: Inconsistent behavior in chained transactions

Thanks, I got it. I have never made a patch before so I'll keep it in my mind. Self-contained patch is now attached. v3 applies, compiles, "make check" ok. I turned it ready on the app. -- Fabien

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On 28.08.2019 22:06, Tomas Vondra wrote: Interesting. Any idea where does the extra overhead in this particular case come from? It's hard to deduce that from the single flame graph, when I don't have anything to compare it with (i.e. the flame graph for the "normal" case). I guess that

Re: RFC: seccomp-bpf support

On 8/29/19 10:00 AM, Tom Lane wrote: > Joe Conway writes: >> Clearly Joshua and I disagree, but understand that the consensus is not >> on our side. It is our assessment that PostgreSQL will be subject to >> seccomp willingly or not (e.g., via docker, systemd, etc.) and the >> community might be

Re: RFC: seccomp-bpf support

On Thu, Aug 29, 2019 at 10:01 AM Tom Lane wrote: > > Joe Conway writes: > > Clearly Joshua and I disagree, but understand that the consensus is not > > on our side. It is our assessment that PostgreSQL will be subject to > > seccomp willingly or not (e.g., via docker, systemd, etc.) and the > >

Re: RFC: seccomp-bpf support

Joe Conway writes: > Clearly Joshua and I disagree, but understand that the consensus is not > on our side. It is our assessment that PostgreSQL will be subject to > seccomp willingly or not (e.g., via docker, systemd, etc.) and the > community might be better served to get out in front and have

pg_resetwal and --wal-segsize

Hello I hear is not recommended to set pg_resetwal with --wal-segsize for wal increasing. Are any more detailed information exists about it? What an effects could be? Does it possible change it due full offline? Regards, Paul

Re: RFC: seccomp-bpf support

On 8/28/19 4:07 PM, Peter Eisentraut wrote: > On 2019-08-28 21:38, Joshua Brindle wrote: >> I think we need to reign in the thread somewhat. The feature allows >> end users to define some sandboxing within PG. Nothing is being forced >> on anyone > > Features come with a maintenance cost. If we

Re: BUG #15977: Inconsistent behavior in chained transactions

Hello, transaction_read_only must be 'on' because AND CHAIN test sets the default_transaction_read_only to 'on'. Failure of this test means that the transaction was chained from an implicit transaction, which is not our desired behavior. Perhaps you are using a wrong binary? Nope, I

Re: BUG #15977: Inconsistent behavior in chained transactions

Added two kinds of test for the implicit transaction: in single query and in implicit block. The patch file is now created with Unix-style line ending (LF). 2019年8月29日(木) 15:30 Fabien COELHO : > > Hello, > > > COMMIT AND CHAIN in implicit block leaves blockState as TBLOCK_STARTED, > > which

Re: BUG #15977: Inconsistent behavior in chained transactions

transaction_read_only must be 'on' because AND CHAIN test sets the default_transaction_read_only to 'on'. Failure of this test means that the transaction was chained from an implicit transaction, which is not our desired behavior. Perhaps you are using a wrong binary? 2019年8月29日(木) 21:10 Fabien

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

28.08.2019 6:19, Peter Geoghegan wrote: On Fri, Aug 16, 2019 at 8:56 AM Anastasia Lubennikova wrote: Now the algorithm is the following: - In case page split is needed, pass both tuples to _bt_split(). _bt_findsplitloc() is now aware of upcoming replacement of origtup with neworigtup, so it

Re: BUG #15977: Inconsistent behavior in chained transactions

Hello, Added two kinds of test for the implicit transaction: in single query and in implicit block. Ok. The patch file is now created with Unix-style line ending (LF). Thanks. Patch applies and compiles cleanly. However, "make check" is not ok on the added tests. SHOW

Re: Zedstore - compressed in-core columnar storage

On 29/08/2019 14:30, Ashutosh Sharma wrote: On Wed, Aug 28, 2019 at 5:30 AM Alexandra Wang > wrote: You are correct that we currently go through each item in the leaf page that contains the given tid, specifically, the logic to retrieve all the

Re: Email to hackers for test coverage

On Wed, Aug 28, 2019 at 9:43 PM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-08-22 11:46, movead...@highgo.ca wrote: > > *1. src/include/utils/float.h:140* > > > > Analyze: > > This is an error report line when converting a big float8 value > > which a float4 can not

Re: no mailing list hits in google

On Wed, Aug 28, 2019 at 10:31 PM Alvaro Herrera wrote: > On 2019-Aug-28, Thomas Kellerer wrote: > > > Merlin Moncure schrieb am 28.08.2019 um 18:22: > > > My test case here is the query: pgsql-hackers > > > > That search term is the first hit on DuckDuckGo: > >

Re: Zedstore - compressed in-core columnar storage

On Wed, Aug 28, 2019 at 5:30 AM Alexandra Wang wrote: > You are correct that we currently go through each item in the leaf page > that > contains the given tid, specifically, the logic to retrieve all the > attribute > items inside a ZSAttStream is now moved to decode_attstream() in the latest >

Re: pg_get_databasebyid(oid)

On Thu, Aug 29, 2019 at 3:16 PM Sergei Kornilov wrote: > Hello > > > Is there a need for this function for the user? > > This was feature request from user. I got such comment: > > This function is useful when working with pg_stat_statements. For > obtaining a databаse name for particular query

Re: pg_get_databasebyid(oid)

Hello > Is there a need for this function for the user? This was feature request from user. I got such comment: This function is useful when working with pg_stat_statements. For obtaining a databаse name for particular query you need to join pg_database relation, but for obtaining an username

Re: basebackup.c's sendFile() ignores read errors

Hi Jeevan, On Wed, Aug 28, 2019 at 10:26 PM Jeevan Chalke < jeevan.cha...@enterprisedb.com> wrote: > > > On Tue, Aug 27, 2019 at 10:33 PM Robert Haas > wrote: > >> While reviewing a proposed patch to basebackup.c this morning, I found >> myself a bit underwhelmed by the quality of the code and

Re: A problem about partitionwise join

On Wed, Aug 28, 2019 at 6:49 PM Etsuro Fujita wrote: > Hi, > > On Tue, Aug 27, 2019 at 4:57 PM Richard Guo wrote: > > Check the query below as a more illustrative example: > > > > create table p (k int, val int) partition by range(k); > > create table p_1 partition of p for values from (1) to

Re: REINDEX filtering in the backend

On Thu, Aug 29, 2019 at 2:09 AM Michael Paquier wrote: > > On Wed, Aug 28, 2019 at 10:22:07AM +0200, Julien Rouhaud wrote: > >>> The filtering is done at table level (with and without the > >>> concurrently option), so SCHEMA, DATABASE and SYSTEM automatically > >>> benefit from it. If this

Re: pg_get_databasebyid(oid)

On Wed, Aug 28, 2019 at 6:05 PM Sergei Kornilov wrote: > > Please add that to commitfest. > > Done: https://commitfest.postgresql.org/24/2261/ > > regards, Sergei > Hi, I have checked the code, the function "pg_get_userbyid" is used in many places in code. I am just curious why we need that

Wrong value in metapage of GIN INDEX.

Dear Hackers. Kuroda-san and I are interested in the GIN index and have been testing various things. While testing, we are found a little bug. Some cases, the value of nEntries in the metapage was set to the wrong value. This is a reproduce of bug situation. =# SET maintenance_work_mem TO '1MB';

Re: BUG #15977: Inconsistent behavior in chained transactions

COMMIT AND CHAIN in implicit block leaves blockState as TBLOCK_STARTED, which doesn't trigger the chaining. but ROLLBACK AND CHAIN sets the blockState into TBLOCK_ABORT_PENDING, so the chaining is triggered. I think disabling s->chain beforehand should do the desired behavior. 2019年8月25日(日)

Re: Resume vacuum and autovacuum from interruption and cancellation

On Tue, Aug 27, 2019 at 2:55 PM Jamison, Kirk wrote: > > On Monday, August 19, 2019 10:39 AM (GMT+9), Masahiko Sawada wrote: > > Fixed. > > > > Attached the updated version patch. > > Hi Sawada-san, > > I haven't tested it with heavily updated large tables, but I think the patch > is reasonable

Re: BUG #15977: Inconsistent behavior in chained transactions

Patch works for me, and solution seems appropriate. It should be committed for pg 12.0. I have listed this as an open issue of the upcoming pg 12: https://wiki.postgresql.org/wiki/PostgreSQL_12_Open_Items#Open_Issues -- Fabien.

Re: BUG #15977: Inconsistent behavior in chained transactions

Hello, COMMIT AND CHAIN in implicit block leaves blockState as TBLOCK_STARTED, which doesn't trigger the chaining. but ROLLBACK AND CHAIN sets the blockState into TBLOCK_ABORT_PENDING, so the chaining is triggered. I think disabling s->chain beforehand should do the desired behavior.

Re: refactoring - share str2*int64 functions

Bonjour Michaël, - *ptr && WHATEVER(*ptr) *ptr is redundant, WHATEVER yields false on '\0', and it costs on each char but at the end. It might be debatable in some places, e.g. it is likely that there are no spaces in the string, but likely that there are more than one digit. Still