Re: shared-memory based stats collector

At Sat, 6 Mar 2021 00:32:07 +0900, Fujii Masao wrote in > > > On 2021/03/05 17:18, Kyotaro Horiguchi wrote: > > At Thu, 21 Jan 2021 12:03:48 +0900 (JST), Kyotaro Horiguchi > > wrote in > >> Commit 960869da08 (database statistics) conflicted with this. Rebased. > >> > >> I'm concerned about th

Re: [HACKERS] Custom compression methods

On Tue, Mar 09, 2021 at 01:04:10PM +0530, Dilip Kumar wrote: > On Tue, Mar 9, 2021 at 2:45 AM Robert Haas wrote: > > > > On Mon, Mar 8, 2021 at 3:59 PM Justin Pryzby wrote: > > > > It would be nice to have a way to force > > > > anything compressed with the old method to be re-compressed with the

Re: [HACKERS] Custom compression methods

On Tue, Mar 9, 2021 at 2:45 AM Robert Haas wrote: > > On Mon, Mar 8, 2021 at 3:59 PM Justin Pryzby wrote: > > > It would be nice to have a way to force > > > anything compressed with the old method to be re-compressed with the > > > new method, but not having that doesn't preclude allowing the >

Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

út 9. 3. 2021 v 7:57 odesílatel Joel Jacobson napsal: > On Mon, Mar 8, 2021, at 21:46, Pavel Stehule wrote: > > so what about? > > CREATE OR REPLACE FUNCTION unnest_slice(anyarray, int) > RETURNS SETOF anyarray AS $$ > DECLARE r $1%type; > BEGIN > FOREACH r SLICE $2 IN ARRAY $1 --- now $2 shoul

Re: pg_upgrade fails with non-standard ACL

On Thu, Feb 11, 2021 at 08:16:30PM +0300, Anastasia Lubennikova wrote: > On 28.01.2021 09:55, Noah Misch wrote: > >On Wed, Jan 27, 2021 at 07:32:42PM +0300, Anastasia Lubennikova wrote: > >>On 27.01.2021 14:21, Noah Misch wrote: > >>>On Mon, Jan 25, 2021 at 10:14:43PM +0300, Anastasia Lubennikova w

RE: [PoC] Non-volatile WAL buffer

From: Takashi Menjo > > The other question is whether simply placing WAL on DAX (without any > > code changes) is safe. If it's not, then all the "speedups" are > > computed with respect to unsafe configuration and so are useless. And > > BTT should be used instead, which would of course produce v

Re: [HACKERS] Custom compression methods

On Mon, Mar 08, 2021 at 03:32:39PM +0530, Dilip Kumar wrote: > On Sun, Mar 7, 2021 at 1:27 AM Justin Pryzby wrote: > > > > On Sat, Mar 06, 2021 at 08:59:16PM +0530, Dilip Kumar wrote: > > > - Alter table set compression, will not rewrite the old data, so only > > > the new tuple will be compressed

RE: Parallel INSERT (INTO ... SELECT ...)

> > > > I've attached an updated set of patches with the suggested locking changes. > > > > Amit L, others, do let me know if you have still more comments on > 0001* patch or if you want to review it further? I took a look into the latest 0001 patch, and it looks good to me. Best regards, houzj

Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

On Mon, Mar 8, 2021, at 21:46, Pavel Stehule wrote: > so what about? > > CREATE OR REPLACE FUNCTION unnest_slice(anyarray, int) > RETURNS SETOF anyarray AS $$ > DECLARE r $1%type; > BEGIN > FOREACH r SLICE $2 IN ARRAY $1 --- now $2 should be constant > LOOP > RETURN NEXT r; > END LOOP; >

Re: [PoC] Non-volatile WAL buffer

Hi Tomas, > Hello Takashi-san, > > On 3/5/21 9:08 AM, Takashi Menjo wrote: > > Hi Tomas, > > > > Thank you so much for your report. I have read it with great interest. > > > > Your conclusion sounds reasonable to me. My patchset you call "NTT / > > segments" got as good performance as "NTT / buffe

Re: Make stream_prepare an optional callback

On Mon, Mar 8, 2021 at 2:43 PM Ajin Cherian wrote: > > Hi Hackers, > > As part of commit 0aa8a0 , new plugin methods (callbacks) were defined for > enabling two_phase commits. > 5 callbacks were required: > * begin_prepare > * prepare > * commit_prepared > * rollback_prepared > * stream_prepare >

Re: [PATCH] pg_permissions

On Tue, Mar 9, 2021, at 04:01, Chapman Flack wrote: > On Sat, Mar 06, 2021 at 08:03:17PM +0100, Joel Jacobson wrote: > >regclass | obj_desc | grantor | grantee | > privilege_type | is_grantable > > > --+-+-+-+-

Re: Removing vacuum_cleanup_index_scale_factor

On Tue, Mar 9, 2021 at 7:35 AM Peter Geoghegan wrote: > > On Mon, Mar 8, 2021 at 1:38 PM Tom Lane wrote: > > As you say, the history here is a bit convoluted, but it seems like > > a good principle to avoid interconnections between VACUUM and ANALYZE > > as much as we can. I haven't been paying

Re: [HACKERS] logical decoding of two-phase transactions

On Tue, Mar 9, 2021 at 11:01 AM Amit Kapila wrote: > > On Mon, Mar 8, 2021 at 8:09 PM vignesh C wrote: > > > > On Mon, Mar 8, 2021 at 6:25 PM Amit Kapila wrote: > > > > > > > I think in case of two_phase option, replicatedPtr and sentPtr never > > becomes the same which causes this process to ha

Re: Tablesync early exit

On Sun, Mar 7, 2021 at 1:33 PM Amit Kapila wrote: > > On Sun, Mar 7, 2021 at 7:26 AM Peter Smith wrote: > > > > Hi hackers. > > > > I propose a small optimization can be added to the tablesync replication > > code. > > > > This proposal (and simple patch) was first discussed here [1]. > > > > It

Re: Improvements and additions to COPY progress reporting

On Mon, Mar 08, 2021 at 05:33:40PM +0100, Matthias van de Meent wrote: > Seems reasonable. PFA updated patches. I've renamed the previous 0003 > to 0002 to keep git-format-patch easy. Thanks for updating the patch. 0001 has been applied, after tweaking a bit comments, indentation and the docs. >

Re: [HACKERS] logical decoding of two-phase transactions

On Mon, Mar 8, 2021 at 8:09 PM vignesh C wrote: > > On Mon, Mar 8, 2021 at 6:25 PM Amit Kapila wrote: > > > > I think in case of two_phase option, replicatedPtr and sentPtr never > becomes the same which causes this process to hang. > The reason is that because on subscriber you have created a s

Re: Replace buffer I/O locks with condition variables (reviving an old patch)

On Mon, Mar 08, 2021 at 06:10:36PM +1300, Thomas Munro wrote: > On Fri, Mar 5, 2021 at 12:12 PM Thomas Munro wrote: > > On Fri, Feb 26, 2021 at 7:08 PM Thomas Munro wrote: > > > Back in 2016, Robert Haas proposed to replace I/O locks with condition > > > variables[1]. Condition variables went in

Re: New IndexAM API controlling index vacuum strategies

On Tue, Mar 2, 2021 at 8:49 PM Masahiko Sawada wrote: > On Tue, Mar 2, 2021 at 2:34 PM Peter Geoghegan wrote: > > lazy_vacuum_table_and_indexes() should probably not skip index > > vacuuming when we're close to exceeding the space allocated for the > > LVDeadTuples array. Maybe we should not skip

Re: [HACKERS] logical decoding of two-phase transactions

On Tue, Mar 9, 2021 at 9:15 AM Peter Smith wrote: > > On Mon, Mar 8, 2021 at 4:58 PM vignesh C wrote: > > > > LOGICAL_REP_MSG_TYPE = 'Y', > > + LOGICAL_REP_MSG_BEGIN_PREPARE = 'b', > > + LOGICAL_REP_MSG_PREPARE = 'P', > > + LOGICAL_REP_MSG_COMMIT_PREPARED = 'K', > > +

Re: [HACKERS] logical decoding of two-phase transactions

On Tue, Mar 9, 2021 at 9:14 AM Peter Smith wrote: > > On Mon, Mar 8, 2021 at 4:58 PM vignesh C wrote: > > > > LOGICAL_REP_MSG_TYPE = 'Y', > > + LOGICAL_REP_MSG_BEGIN_PREPARE = 'b', > > + LOGICAL_REP_MSG_PREPARE = 'P', > > + LOGICAL_REP_MSG_COMMIT_PREPARED = 'K', > > +

Re: POC: converting Lists into arrays

Hello, here some macros for list_make, now we can using list_make(...), not list_make1/2/3 ... #define MACRO_ARGS(...) __VA_ARGS__ #define LIST_MAKE_1_(narg_, postfix_, ...) list_make ## narg_ ## postfix_(__VA_ARGS__) #define LIST_MAKE_2_(...) LIST_MAKE_1_(__VA_ARGS__) #define LIST_MAKE_3_(...) L

Re: [HACKERS] logical decoding of two-phase transactions

On Mon, Mar 8, 2021 at 4:58 PM vignesh C wrote: > > LOGICAL_REP_MSG_TYPE = 'Y', > + LOGICAL_REP_MSG_BEGIN_PREPARE = 'b', > + LOGICAL_REP_MSG_PREPARE = 'P', > + LOGICAL_REP_MSG_COMMIT_PREPARED = 'K', > + LOGICAL_REP_MSG_ROLLBACK_PREPARED = 'r', > LOGICAL_REP_

Re: New IndexAM API controlling index vacuum strategies

On Mon, Mar 8, 2021 at 10:57 AM Robert Haas wrote: > Yes, I agree that it's good to postpone this to a future release, and > that thinking through the consequences is not so easy. The current plan is to commit something like Masahiko's skip_index_vacuum.patch for Postgres 14. The latest version o

Re: [PATCH] pg_permissions

On Sat, Mar 06, 2021 at 08:03:17PM +0100, Joel Jacobson wrote: >regclass | obj_desc | grantor | grantee | privilege_type | is_grantable > --+-+-+-++-- 1. Is there a reason not to make 'gran

Re: TRUNCATE on foreign table

On Tue, Mar 9, 2021 at 2:24 AM Ibrar Ahmed wrote: > The patch (pgsql14-truncate-on-foreign-table.v2.patch) does not apply > successfully. > > http://cfbot.cputube.org/patch_32_2972.log > > patching file contrib/postgres_fdw/expected/postgres_fdw.out > Hunk #2 FAILED at 9179. > 1 out of 2 hunks FA

Re: pg_stat_statements oddity with track = all

On Mon, Mar 08, 2021 at 06:03:59PM +0100, Magnus Hagander wrote: > On Sun, Mar 7, 2021 at 8:39 AM Julien Rouhaud wrote: > > > > Yes I was a bit worried about the possible extra text entry. I kept things > > simple until now as the general opinion was that entries existing for both > > top > > le

Re: Disallow SSL compression?

On Sat, Mar 06, 2021 at 10:39:52AM +0900, Michael Paquier wrote: > Okay, cool. I'd rather wait more for Peter before doing anything, so > if there are no objections, I'll look at that stuff again at the > beginning of next week and perhaps apply it. If you wish to take care > of that yourself, pl

Re: 64-bit XIDs in deleted nbtree pages

On Sun, Mar 7, 2021 at 8:52 PM Masahiko Sawada wrote: > Yeah, I think that's right. > > Perhaps we can do something so that autovacuums triggered by > autovacuum_vacuum_insert_scale_factor are triggered on only a true > insert-only case (e.g., by checking if n_dead_tup is 0). Right -- that's real

Re: cleanup temporary files after crash

Hi, Let's move this patch forward. Based on the responses, I agree the default behavior should be to remove the temp files, and I think we should have the GUC (on the off chance that someone wants to preserve the temporary files for debugging or whatever other reason). I propose to rename the GUC

Re: Boundary value check in lazy_tid_reaped()

On Mon, Mar 8, 2021 at 7:16 PM Peter Eisentraut wrote: > > On 21.01.21 14:11, Masahiko Sawada wrote: > > Agreed. bsearch with bound check showed a reasonable improvement in my > > evaluation in terms of performance. Regarding memory efficiency, we > > can experiment with other methods later. > > >

Re: Proposal: Save user's original authenticated identity for logging

On Sat, 2021-03-06 at 18:33 +0100, Magnus Hagander wrote: > In fact, if we're storing it in the Port, why > are we even passing it as a separate parameter to check_usermap -- > shouldn't that one always use this same value? Ah, and now I remember why I didn't consolidate this to begin with. Severa

Re: Let people set host(no)ssl settings from initdb

On Mon, Mar 08, 2021 at 06:13:14PM -0500, Andrew Dunstan wrote: > What is the point of doing that if we're going to reject the patch as > discussed upthread? I have read again this thread, and still understand that this is the consensus that has been reached. The CF entry has been updated to refl

RE: Implementing Incremental View Maintenance

From: Thomas Munro > It's probably time to move forward with the plan of pushing the > results into a commitfest.postgresql.org API, and then making Magnus > et al write the email spam code with a preferences screen linked to > your community account :-D +1 I wish to see all the patch status info

Re: Implementing Incremental View Maintenance

On Tue, Mar 9, 2021 at 1:22 PM Yugo NAGATA wrote: > On Mon, 8 Mar 2021 15:42:00 -0500 > Andrew Dunstan wrote: > > (A useful feature of the cfbot might be to notify the authors and > > reviewers when it detects bitrot for a previously passing entry.) > > +1 > The feature notifying it authors seems

Re: Implementing Incremental View Maintenance

On Mon, 8 Mar 2021 15:42:00 -0500 Andrew Dunstan wrote: > > On 2/18/21 9:01 PM, Yugo NAGATA wrote: > > On Thu, 18 Feb 2021 19:38:44 +0800 > > Andy Fan wrote: > > > >> On Tue, Feb 16, 2021 at 9:33 AM Yugo NAGATA wrote: > >> > >>> Hi, > >>> > >>> Attached is a rebased patch (v22a). > >>> > >> Th

Re: Optimising latch signals

On Tue, Mar 9, 2021 at 12:20 PM Alvaro Herrera wrote: > On 2021-Mar-03, Thomas Munro wrote: > > On Mon, Mar 1, 2021 at 2:29 PM Thomas Munro wrote: > > > Time to watch the buildfarm to find out if my speculation about > > > illumos is correct... > > > > I just heard that damselfly's host has been

Re: Proposal: Save user's original authenticated identity for logging

On Mon, 2021-03-08 at 22:16 +, Jacob Champion wrote: > On Sat, 2021-03-06 at 18:33 +0100, Magnus Hagander wrote: > > With this we store the same value as the authn and as > > port->gss->princ, and AFAICT it's only used once. Seems we could just > > use the new field for the gssapi usage as well

Re: documentation fix for SET ROLE

On Mon, Mar 8, 2021 at 4:41 PM David G. Johnston wrote: > On Thu, Feb 18, 2021 at 6:18 PM Bossart, Nathan > wrote: > >> On 2/17/21 2:12 PM, David G. Johnston wrote: >> > On Wednesday, February 17, 2021, Bossart, Nathan > > > wrote: >> > >> > >> > postgres=# AL

Re: documentation fix for SET ROLE

On Thu, Feb 18, 2021 at 6:18 PM Bossart, Nathan wrote: > On 2/17/21 2:12 PM, David G. Johnston wrote: > > On Wednesday, February 17, 2021, Bossart, Nathan > > wrote: > > > > > > postgres=# ALTER ROLE test1 SET ROLE test2; > > ALTER ROLE > > > > > > I w

Re: cursor sensitivity misunderstanding

On Thu, Feb 25, 2021 at 8:37 AM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > On 18.02.21 19:14, Peter Eisentraut wrote: > > On 18.02.21 17:11, David G. Johnston wrote: > >> The OP was doing a course based on Oracle and was confused regarding > >> our behavior. The documentation

Re: Optimising latch signals

On 2021-Mar-03, Thomas Munro wrote: > On Mon, Mar 1, 2021 at 2:29 PM Thomas Munro wrote: > > Time to watch the buildfarm to find out if my speculation about > > illumos is correct... > > I just heard that damselfly's host has been decommissioned with no > immediate plan for a replacement. That

Re: non-HOT update not looking at FSM for large tuple update

On Mon, 8 Mar 2021 at 16:25, Floris Van Nee wrote: > > > I've added this to the commitfest as a bug fix and added you as an author. > > Thanks. Patch looks good to me, but I guess there needs to be someone else > reviewing too? > Also, would this be a backpatchable bugfix? > > -Floris > This pat

Re: Let people set host(no)ssl settings from initdb

On 3/8/21 11:23 AM, Ibrar Ahmed wrote: > > > On Thu, Mar 4, 2021 at 7:25 AM Michael Paquier > wrote: > > On Wed, Mar 03, 2021 at 03:07:30PM +0100, Peter Eisentraut wrote: > > I think there is enough sustained opposition to this patch that > we can mark >

Re: PATCH: Batch/pipelining support for libpq

On 2021-Mar-03, 'Alvaro Herrera' wrote: > I wonder if it would make sense to get rid of conn->last_query > completely and just rely always on conn->cmd_queue_head, where the > normal (non-pipeline) would use the first entry of the command queue. > That might end up being simpler than pipeline mode

Re: proposal - operators ? and ->> for type record, and functions record_keys and record_each_text

po 8. 3. 2021 v 23:12 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > I found an interesting idea to have some basic functions and operators > for > > record type (similar to json, jsonb or hstore). > > I think this is a pretty bad idea, because there's no way to know what > data type th

Re: PATCH: Batch/pipelining support for libpq

On Wed, Mar 3, 2021 at 5:45 PM Justin Pryzby wrote: > I'm proposing some minor changes. > > Some additional tweaks/comments for the documentation with the edit proposed edits: (edit) + PQresultStatus, will report a Remove the comma (orig) + the failed operation are skipped entirely. Th

Re: Removing vacuum_cleanup_index_scale_factor

On Mon, Mar 8, 2021 at 1:38 PM Tom Lane wrote: > As you say, the history here is a bit convoluted, but it seems like > a good principle to avoid interconnections between VACUUM and ANALYZE > as much as we can. I haven't been paying enough attention to this > thread to have more insight than that.

Re: Proposal: Save user's original authenticated identity for logging

On Sat, 2021-03-06 at 18:33 +0100, Magnus Hagander wrote: > It looks like patch 0001 has some leftover debuggnig code at the end? > Or did you intend for that to be included permanently? I'd intended to keep it -- it works hand-in-hand with the existing "current_logfiles" log line on 219 and might

Re: proposal - operators ? and ->> for type record, and functions record_keys and record_each_text

Pavel Stehule writes: > I found an interesting idea to have some basic functions and operators for > record type (similar to json, jsonb or hstore). I think this is a pretty bad idea, because there's no way to know what data type the result of -> should be. "Smash it all to text" is a hack, not

Re: Removing vacuum_cleanup_index_scale_factor

Peter Geoghegan writes: > I think that a simpler approach would work better: When > ANALYZE/do_analyze_rel() decides whether or not it should call > vac_update_relstats() for each index, it should simply not care > whether or not this is a VACUUM ANALYZE (as opposed to a simple > ANALYZE). This is

proposal - operators ? and ->> for type record, and functions record_keys and record_each_text

Hi When I wrote an reply to questing https://stackoverflow.com/questions/66523737/postgresql-10-pl-pgsql-test-if-column-exits-in-a-record-variable I found an interesting idea to have some basic functions and operators for record type (similar to json, jsonb or hstore). Now we can do almost all

Re: [HACKERS] Custom compression methods

On Mon, Mar 8, 2021 at 3:59 PM Justin Pryzby wrote: > > It would be nice to have a way to force > > anything compressed with the old method to be re-compressed with the > > new method, but not having that doesn't preclude allowing the > > parameter to be changed. > > Doesn't vacuum full/cluster/du

Re: Removing vacuum_cleanup_index_scale_factor

On Tue, Mar 2, 2021 at 6:01 PM Peter Geoghegan wrote: > 1. Any objections to the idea of teaching VACUUM ANALYZE to > distinguish between the cases where VACUUM ran and performed "real > index vacuuming", to make it more intelligent about overwriting > pg_class stats for indexes? I think that a s

Re: [HACKERS] Custom compression methods

On Mon, Mar 08, 2021 at 03:26:04PM -0500, Robert Haas wrote: > On Mon, Mar 8, 2021 at 5:02 AM Dilip Kumar wrote: > > So now only pending point is, how do we handle the upgrade when you > > are upgrading from --with-lz4 to --without-lz4 binary and a couple of > > options discussed here are > > a)

Re: Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

po 8. 3. 2021 v 21:12 odesílatel Tom Lane napsal: > "Joel Jacobson" writes: > > If I understand it correctly, we don't need to run genbki.pl to compile > PostgreSQL, > > so someone wanting to compile PostgreSQL without having a running > PostgreSQL-instance > > could do so without problems. > >

Re: Confusing behavior of psql's \e

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 Very nice quality-of-life improvement. Thanks! The new status of

Re: Implementing Incremental View Maintenance

On 2/18/21 9:01 PM, Yugo NAGATA wrote: > On Thu, 18 Feb 2021 19:38:44 +0800 > Andy Fan wrote: > >> On Tue, Feb 16, 2021 at 9:33 AM Yugo NAGATA wrote: >> >>> Hi, >>> >>> Attached is a rebased patch (v22a). >>> >> Thanks for the patch. Will you think posting a patch with the latest commit >> at t

Re: pg_amcheck contrib application

> On Mar 8, 2021, at 8:26 AM, Robert Haas wrote: > > On Thu, Mar 4, 2021 at 5:39 PM Mark Dilger > wrote: >> I think Robert mistook why I was doing that. I was thinking about a >> different usage pattern. If somebody thinks a subset of relations have been >> badly corrupted, but doesn't k

Re: [HACKERS] Custom compression methods

On Mon, Mar 8, 2021 at 5:02 AM Dilip Kumar wrote: > So now only pending point is, how do we handle the upgrade when you > are upgrading from --with-lz4 to --without-lz4 binary and a couple of > options discussed here are > a) Should we allow table creation with lz4 even if it is compiled > --with

Re: Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

"Joel Jacobson" writes: > If I understand it correctly, we don't need to run genbki.pl to compile > PostgreSQL, > so someone wanting to compile PostgreSQL without having a running > PostgreSQL-instance > could do so without problems. > A dependency on having a PostgreSQL instance running, > is p

Re: About to add WAL write/fsync statistics to pg_stat_wal view

On Mon, Mar 8, 2021 at 8:48 AM Fujii Masao wrote: > > Thanks for updating the patch! I applied cosmetic changes to that. > Patch attached. Barring any objection, I will commit this version. > Read over the patch and it looks good. One minor "the" omission (in a couple of places, copy-paste styl

Re: automatic analyze: readahead - add "IO read time" log message

Greetings, * Tomas Vondra (tomas.von...@enterprisedb.com) wrote: > On 2/10/21 11:10 PM, Stephen Frost wrote: > > * Heikki Linnakangas (hlinn...@iki.fi) wrote: > >> On 05/02/2021 23:22, Stephen Frost wrote: > >>> Unless there's anything else on this, I'll commit these sometime next > >>> week. > >>

Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

On Mon, Mar 8, 2021, at 19:46, Joel Jacobson wrote: > However, for certain tasks, when a high-level language is preferred, > and when the raw performance of C isn't necessary, then maybe SQL/PLpgSQL > could be a serious alternative to Perl? Before we had jsonb, this would have been totally unreal

Re: Why isn't pg_stat_get_subscription() marked as proretset?

I wrote: > The code in pg_stat_get_subscription() appears to believe that it > can return a set of rows, but its pg_proc entry does not have > proretset set. It may be that this somehow accidentally fails > to malfunction when the function is used via the system views, > but if you try to call it

Re: New IndexAM API controlling index vacuum strategies

On Mon, Feb 1, 2021 at 10:17 PM Peter Geoghegan wrote: > * No need to change MaxHeapTuplesPerPage for now, since that only > really makes sense in cases that heavily involve bottom-up deletion, > where we care about the *concentration* of LP_DEAD line pointers in > heap pages (and not just the abs

Re: SQL/JSON: functions

On Sat, Jan 23, 2021 at 3:37 PM Erik Rijkers wrote: > On 2021-01-20 03:49, Nikita Glukhov wrote: > > > [0001-Add-common-SQL-JSON-clauses-v52.patch.gz] > > [0002-SQL-JSON-constructors-v52.patch.gz] > > [0003-IS-JSON-predicate-v52.patch.gz] > > [0004-SQL-JSON-query-functions-v52.patch.gz] > > [0005

Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

On Mon, Mar 8, 2021, at 18:30, Tom Lane wrote: > FWIW, I personally think that returning a start position and a length > would be the most understandable way to operate. Very good point. I agree. (And then ranges cannot be used, regardless of canonical form.) > Yeah: it's hard. The amount of c

Re: partial heap only tuples

On 3/8/21, 10:16 AM, "Ibrar Ahmed" wrote: > On Wed, Feb 24, 2021 at 3:22 AM Bossart, Nathan wrote: >> On 2/10/21, 2:43 PM, "Bruce Momjian" wrote: >>> I wonder if you should create a Postgres wiki page to document all of >>> this. I agree PG 15 makes sense. I would like to help with this if I >

Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

> On Mar 8, 2021, at 9:20 AM, Joel Jacobson wrote: > > On Mon, Mar 8, 2021, at 18:11, Mark Dilger wrote: >> > On Mar 8, 2021, at 9:05 AM, Joel Jacobson wrote: >> > >> > If a N+1 dimension array could easily be unnested to a N dimension array, >> > I would prefer Tom's idea of a 2-D regexp_po

Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

On 03/08/21 13:29, Chapman Flack wrote: > I think the s-free version is exactly the regexp_instr included in > the other concurrent proposal [1] sorry. [1] https://www.postgresql.org/message-id/fc160ee0-c843-b024-29bb-97b5da61971f%40darold.net

Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

On 03/08/21 12:30, Tom Lane wrote: > I'm inclined to think we should learn from that and provide equivalent > variants regexp_position[s] right off the bat. I think the s-free version is exactly the regexp_instr included in the other concurrent proposal [1], which closely corresponds to the ISO po

Re: partial heap only tuples

On Wed, Feb 24, 2021 at 3:22 AM Bossart, Nathan wrote: > On 2/10/21, 2:43 PM, "Bruce Momjian" wrote: > > I wonder if you should create a Postgres wiki page to document all of > > this. I agree PG 15 makes sense. I would like to help with this if I > > can. I will need to study this email more

Re: cryptohash: missing locking functions for OpenSSL <= 1.0.2?

On Wed, 2021-03-03 at 15:30 +0900, Michael Paquier wrote: > Extra eyes are welcome here, though I feel comfortable with the > approach taken here. I have one suggestion for the new logic: >else >{ >/* > * In the non-SSL case, just remove the crypto

Re: Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

"Joel Jacobson" writes: > I prefer to think of a match as two points. If the points are at the same > position, it's a zero length match. FWIW, I personally think that returning a start position and a length would be the most understandable way to operate. If you report start position and end p

Re: [HACKERS] Custom compression methods

On Sun, Mar 07, 2021 at 06:04:41PM +0530, Dilip Kumar wrote: > On Sun, Mar 7, 2021 at 2:19 PM Justin Pryzby wrote: > > > > Earlier in this thread, I suggested to implement an option to pg_restore to > > avoid outputting compression, in order to allow restoring with a different > > compression (by

Re: TRUNCATE on foreign table

On Thu, Feb 11, 2021 at 6:23 PM Ashutosh Bapat wrote: > On Wed, Feb 10, 2021 at 10:58 PM Kazutaka Onishi > wrote: > > > > That's because using the foreign server is difficult for the user. > > > > For example, the user doesn't always have the permission to login to the > forein server. > > In so

Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

On Mon, Mar 8, 2021, at 18:11, Mark Dilger wrote: > > On Mar 8, 2021, at 9:05 AM, Joel Jacobson wrote: > > > > If a N+1 dimension array could easily be unnested to a N dimension array, > > I would prefer Tom's idea of a 2-D regexp_positions(), since it simple and > > not controversial. > > How

Re: pg_upgrade failing for 200+ million Large Objects

On Mon, Mar 8, 2021 at 5:58 PM Tom Lane wrote: > > Magnus Hagander writes: > > On Mon, Mar 8, 2021 at 5:33 PM Tom Lane wrote: > >> It does seem that --single-transaction is a better idea than fiddling with > >> the transaction wraparound parameters, since the latter is just going to > >> put off

Re: [PATCH] pg_permissions

On Mon, Mar 8, 2021, at 15:35, Joe Conway wrote: > While this is interesting and probably useful for troubleshooting, it does not > provide the complete picture if what you care about is something like "what > stuff can joel do in my database". Good point, I agree. I think that's a different more

Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

> On Mar 8, 2021, at 9:05 AM, Joel Jacobson wrote: > > If a N+1 dimension array could easily be unnested to a N dimension array, > I would prefer Tom's idea of a 2-D regexp_positions(), since it simple and > not controversial. How about proposing some array functions to go along with the reg

Re: Yet another fast GiST build

Thanks, Ibrar! > 8 марта 2021 г., в 21:15, Ibrar Ahmed написал(а): > > > > On Mon, Mar 8, 2021 at 8:59 PM Peter Geoghegan wrote: > On Mon, Mar 8, 2021 at 6:41 AM Ibrar Ahmed wrote: > > The patch (0001-Add-bool-column-for-LP_DEAF-flag-to-GiST-pageinspect.patch) > > does not apply successfully

Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

On Mon, Mar 8, 2021, at 17:20, Mark Dilger wrote: > > On Mar 5, 2021, at 11:46 AM, Joel Jacobson wrote: > > <0003-regexp-positions.patch> > > I did a bit more testing: > > +SELECT regexp_positions('foobarbequebaz', 'b', 'g'); > + regexp_positions > +-- > + {"[3,5)"} > + {"[6,8)"

Re: pg_stat_statements oddity with track = all

On Sun, Mar 7, 2021 at 8:39 AM Julien Rouhaud wrote: > > On Sat, Mar 06, 2021 at 06:56:49PM +0100, Magnus Hagander wrote: > > On Sun, Dec 27, 2020 at 9:39 AM Julien Rouhaud wrote: > > > > > - * > > - * Right now, this structure contains no padding. If you add any, make > > sure > > - * to teach

Re: pg_upgrade failing for 200+ million Large Objects

Magnus Hagander writes: > On Mon, Mar 8, 2021 at 5:33 PM Tom Lane wrote: >> It does seem that --single-transaction is a better idea than fiddling with >> the transaction wraparound parameters, since the latter is just going to >> put off the onset of trouble. However, we'd have to do something a

Re: proposal: psql –help reflecting service or URI usage

> On Mar 8, 2021, at 8:40 AM, Paul Förster wrote: > > Hi Mark, > >> On 08. Mar, 2021, at 16:39, Mark Dilger wrote: >> >> Fortunately, the man pages and html docs are generated from the same >> sources. Those sources are written in sgml, and the tools to build the docs >> must be installe

Re: shared-memory based stats collector

On Fri, Mar 5, 2021 at 8:32 PM Fujii Masao wrote: > > > On 2021/03/05 17:18, Kyotaro Horiguchi wrote: > > At Thu, 21 Jan 2021 12:03:48 +0900 (JST), Kyotaro Horiguchi < > horikyota@gmail.com> wrote in > >> Commit 960869da08 (database statistics) conflicted with this. Rebased. > >> > >> I'm con

Re: [PATCH] New default role allowing to change per-role/database settings

Hi, Am Montag, den 08.03.2021, 20:54 +0500 schrieb Ibrar Ahmed: > On Thu, Dec 31, 2020 at 6:16 PM Michael Banck > wrote: > > in today's world, some DBAs have no superuser rights, but we can > > delegate them additional powers like CREATEDB or the pg_monitor default > > role etc. Usually, the DBA

Re: ResourceOwner refactoring

On Mon, Jan 25, 2021 at 10:15 PM Robert Haas wrote: > On Thu, Jan 21, 2021 at 5:14 AM Heikki Linnakangas > wrote: > > Here you can see that as numsnaps increases, the test becomes slower, > > but then it becomes faster again at 64-66, when it switches to the hash > > table. So 64 seems too much.

Re: proposal: psql –help reflecting service or URI usage

Hi Mark, > On 08. Mar, 2021, at 16:39, Mark Dilger wrote: > > Fortunately, the man pages and html docs are generated from the same sources. > Those sources are written in sgml, and the tools to build the docs must be > installed. From the top directory, execute `make docs` and if it complain

Re: pg_upgrade failing for 200+ million Large Objects

On Mon, Mar 8, 2021 at 5:33 PM Tom Lane wrote: > > Robins Tharakan writes: > > On Mon, 8 Mar 2021 at 23:34, Magnus Hagander wrote: > >> Without looking, I would guess it's the schema reload using > >> pg_dump/pg_restore and not actually pg_upgrade itself. This is a known > >> issue in pg_dump/pg

Re: Improvements and additions to COPY progress reporting

On Mon, 8 Mar 2021 at 09:24, Michael Paquier wrote: > > On Sun, Mar 07, 2021 at 04:50:31PM +0530, Bharath Rupireddy wrote: > > Attaching remaining patches 0001 and 0003 from the v11 patch > > set(posted upthread) here to make cfbot happier. > > Looking at patch 0002, the location of each progress

Re: pg_upgrade failing for 200+ million Large Objects

Robins Tharakan writes: > On Mon, 8 Mar 2021 at 23:34, Magnus Hagander wrote: >> Without looking, I would guess it's the schema reload using >> pg_dump/pg_restore and not actually pg_upgrade itself. This is a known >> issue in pg_dump/pg_restore. And if that is the case -- perhaps just >> running

Re: pg_amcheck contrib application

On Thu, Mar 4, 2021 at 5:39 PM Mark Dilger wrote: > I think Robert mistook why I was doing that. I was thinking about a > different usage pattern. If somebody thinks a subset of relations have been > badly corrupted, but doesn't know which relations those might be, they might > try to find th

Re: Let people set host(no)ssl settings from initdb

On Thu, Mar 4, 2021 at 7:25 AM Michael Paquier wrote: > On Wed, Mar 03, 2021 at 03:07:30PM +0100, Peter Eisentraut wrote: > > I think there is enough sustained opposition to this patch that we can > mark > > this as rejected in the commitfest. > > +1. > -- > Michael > The patch (v5-0001-Enable-s

Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

> On Mar 5, 2021, at 11:46 AM, Joel Jacobson wrote: > > > /Joel > <0003-regexp-positions.patch> I did a bit more testing: +SELECT regexp_positions('foobarbequebaz', 'b', 'g'); + regexp_positions +-- + {"[3,5)"} + {"[6,8)"} + {"[11,13)"} +(3 rows) + I understand that these

Re: Yet another fast GiST build

On Mon, Mar 8, 2021 at 8:59 PM Peter Geoghegan wrote: > On Mon, Mar 8, 2021 at 6:41 AM Ibrar Ahmed wrote: > > The patch > (0001-Add-bool-column-for-LP_DEAF-flag-to-GiST-pageinspect.patch) > > does not apply successfully and has multiple hanks failed. > > That's because it was committed. > > Than

Re: Evaluate expression at planning time for two more cases

On Tue, Nov 24, 2020 at 12:47 PM Surafel Temesgen wrote: > Hi Pavel Borisov, > It's always good to select the optimal way even if it didn't have > performance gain > but in case of this patch i see 4x speed up on my laptop and it will work > on any > table that have NULL constraint > > regards >

Re: [PATCH] pg_ownerships system view

On 3/7/21 1:08 AM, Joel Jacobson wrote: Attached is a suggestion of adding a convenience view, allowing quickly looking up all objects owned by a given user. This definitely seems like a useful feature. I know I am guilty of creating tables as the wrong role more than one time. Andreas

Re: Yet another fast GiST build

On Mon, Mar 8, 2021 at 6:41 AM Ibrar Ahmed wrote: > The patch (0001-Add-bool-column-for-LP_DEAF-flag-to-GiST-pageinspect.patch) > does not apply successfully and has multiple hanks failed. That's because it was committed. -- Peter Geoghegan

  1   2   >