Re: Problems around compute_query_id

Hi, On Mon, Apr 12, 2021 at 02:56:59PM +0800, Julien Rouhaud wrote: > On Mon, Apr 12, 2021 at 03:12:40PM +0900, Michael Paquier wrote: > > Fujii-san has reported on Twitter that enabling the computation of > > query IDs does not work properly with log_statement as the query ID is > > calculated at

Re: Problems around compute_query_id

On Mon, Apr 12, 2021 at 09:20:07AM +0200, Michael Banck wrote: > > What about log_statement_sample_rate ? Does compute_query_id have the > same problem with that? No, log_statement_sample_rate samples log_min_duration_statements, not log_statements so it works as expected.

回复：Bug on update timing of walrcv->flushedUpto variable

Hi. I still feel confused about some point, hope to get your answer: 1) You said that "We shouldn't rewind flushedUpto to backward. The variable notifies how far recovery (or startup process) can read WAL content safely. " This fix only rewinds flushedUpto when req

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

On Mon, Apr 12, 2021 at 6:20 AM Alvaro Herrera wrote: > On 2021-Mar-31, Tom Lane wrote: > > > diff -U3 > > /home/buildfarm/trilobite/buildroot/HEAD/pgsql.build/src/test/isolation/expected/detach-partition-concurrently-4.out > > > > /home/buildfarm/trilobite/buildroot/HEAD/pgsql.build/src/test/i

Re: Wired if-statement in gen_partprune_steps_internal

On Thu, Apr 8, 2021 at 7:59 PM Amit Langote wrote: > On Thu, Apr 8, 2021 at 7:41 PM David Rowley wrote: > > On Thu, 8 Apr 2021 at 21:04, Amit Langote > wrote: > > > Maybe, we should also updated the description of node struct as > > > follows to consider that last point: > >> > > > * Partition

Re: pgsql: Move tablespace path re-creation from the makefiles to pg_regres

Re: Michael Paquier > http://commitfest.cputube.org/michael-paquier.html > > So it looks like this could be a different answer. The mkdir() function looks like a sane and clean approach to me. Christoph

vacuum freeze - possible improvements

Hi Postgres Community, Regarding anti wraparound vacuums (to freeze tuples), I see it has to scan all the pages which are not frozen-all (looking at visibility map). That means even if we want to freeze less transactions only (For ex - by increasing parameter vacuum_freeze_min_age to 1B), still it

Re: Problems around compute_query_id

On Mon, Apr 12, 2021 at 03:26:33PM +0800, Julien Rouhaud wrote: > On Mon, Apr 12, 2021 at 09:20:07AM +0200, Michael Banck wrote: > > > > What about log_statement_sample_rate ? Does compute_query_id have the > > same problem with that? > > No, log_statement_sample_rate samples log_min_duration_sta

Re: Replication slot stats misgivings

On Mon, Apr 12, 2021 at 10:27 AM Masahiko Sawada wrote: > > On Sat, Apr 10, 2021 at 9:53 PM Amit Kapila wrote: > > > > > > It seems Vignesh has changed patches based on the latest set of > > comments so you might want to rebase. > > I've merged my patch into the v6 patch set Vignesh submitted. >

Re: Replication slot stats misgivings

On Sat, Mar 20, 2021 at 9:26 AM Amit Kapila wrote: > > On Sat, Mar 20, 2021 at 12:22 AM Andres Freund wrote: > > > > And then more generally about the feature: > > - If a slot was used to stream out a large amount of changes (say an > > initial data load), but then replication is interrupted be

RE: Could you help testing logical replication?

> Then I get timeout error occurs and the subscriber worker keep re-launching > over and over (you did not mention see such errors?) I test again and get errors, too. I didn't check log after timeout in the previous test. Regards, Tang

RE: Could you help testing logical replication?

Sorry for sending a wrong mail. Please ignore it. > -Original Message- > From: Shi, Yu/侍 雨 > Sent: Monday, April 12, 2021 6:51 PM > To: Tang, Haiying/唐 海英 > Cc: pgsql-hackers@lists.postgresql.org > Subject: RE: Could you help testing logical replication? > > > Then I get timeout error o

Re: Replication slot stats misgivings

On Mon, Apr 12, 2021 at 6:19 PM Amit Kapila wrote: > > On Mon, Apr 12, 2021 at 10:27 AM Masahiko Sawada > wrote: > > > > On Sat, Apr 10, 2021 at 9:53 PM Amit Kapila wrote: > > > > > > > > > It seems Vignesh has changed patches based on the latest set of > > > comments so you might want to rebas

Re: Replication slot stats misgivings

On Mon, Apr 12, 2021 at 4:34 PM Masahiko Sawada wrote: > > On Mon, Apr 12, 2021 at 6:19 PM Amit Kapila wrote: > > > > On Mon, Apr 12, 2021 at 10:27 AM Masahiko Sawada > > wrote: > > > > > > On Sat, Apr 10, 2021 at 9:53 PM Amit Kapila > > > wrote: > > > > > > > > > > > > It seems Vignesh has c

Re: Replication slot stats misgivings

On Mon, Apr 12, 2021 at 4:34 PM Masahiko Sawada wrote: > > On Mon, Apr 12, 2021 at 6:19 PM Amit Kapila wrote: > > > > On Mon, Apr 12, 2021 at 10:27 AM Masahiko Sawada > > wrote: > > > > > > On Sat, Apr 10, 2021 at 9:53 PM Amit Kapila > > > wrote: > > > > > > > > > > > > It seems Vignesh has c

Re: Replication slot stats misgivings

On Sat, Apr 10, 2021 at 6:51 PM vignesh C wrote: > Thanks, 0001 and 0002 look good to me. I have a minor comment for 0002. +total_bytesbigint + + +Amount of decoded transactions data sent to the decoding output plugin +while decoding the changes from WAL fo

Re: TRUNCATE on foreign table

On 2021/04/11 19:15, Bharath Rupireddy wrote: On Sun, Apr 11, 2021 at 9:47 AM Justin Pryzby wrote: Find attached language fixes. Thanks for the patches. Thanks for the patches! 0001 patch basically looks good to me. + behavior must be specified as + DROP_RESTRICT or DROP_CASCAD

撤回: Could you help testing logical replication?

Shi, Yu/侍 雨 将撤回邮件“Could you help testing logical replication?”。

撤回: Could you help testing logical replication?

Shi, Yu/侍 雨 将撤回邮件“Could you help testing logical replication?”。

Re: Replication slot stats misgivings

On Mon, Apr 12, 2021 at 8:08 PM Amit Kapila wrote: > > On Mon, Apr 12, 2021 at 4:34 PM Masahiko Sawada wrote: > > > > On Mon, Apr 12, 2021 at 6:19 PM Amit Kapila wrote: > > > > > > On Mon, Apr 12, 2021 at 10:27 AM Masahiko Sawada > > > wrote: > > > > > > > > On Sat, Apr 10, 2021 at 9:53 PM Ami

Re: allow partial union-all and improve parallel subquery costing

Hi David, On 15-03-2021 14:09, David Steele wrote: Hi Luc, On 12/30/20 8:54 AM, Luc Vlaming wrote: Created a commitfest entry assuming this is the right thing to do so that someone can potentially pick it up during the commitfest. Providing an updated patch based on latest master. Looks

Re: Lazy JIT IR code generation to increase JIT speed with partitions

On 18-01-2021 08:47, Luc Vlaming wrote: Hi everyone, Andres, On 03-01-2021 11:05, Luc Vlaming wrote: On 30-12-2020 14:23, Luc Vlaming wrote: On 30-12-2020 02:57, Andres Freund wrote: Hi, Great to see work in this area! I would like this topic to somehow progress and was wondering what othe

Re: Replication slot stats misgivings

On Mon, Apr 12, 2021 at 4:46 PM Amit Kapila wrote: > > On Sat, Apr 10, 2021 at 6:51 PM vignesh C wrote: > > > > Thanks, 0001 and 0002 look good to me. I have a minor comment for 0002. > > > +total_bytesbigint > + > + > +Amount of decoded transactions data sent to th

"could not find pathkey item to sort" for TPC-DS queries 94-96

Hi, When trying to run on master (but afaik also PG-13) TPC-DS queries 94, 95 and 96 on a SF10 I get the error "could not find pathkey item to sort". When I disable enable_gathermerge the problem goes away and then the plan for query 94 looks like below. I tried figuring out what the problem i

interaction between csps with dummy tlists and set_customscan_references

Hi, Whilst developing a CSP that potentially sits (directly) above e.g. any union or anything with a dummy tlist we observed some problems as the set_customscan_references cannot handle any dummy tlists and will give invalid varno errors. I was wondering how we can fix this, and I was wonderi

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

On Mon, Apr 12, 2021 at 4:42 PM Amit Langote wrote: > On Mon, Apr 12, 2021 at 6:20 AM Alvaro Herrera > wrote: > > On 2021-Mar-31, Tom Lane wrote: > > > > > diff -U3 > > > /home/buildfarm/trilobite/buildroot/HEAD/pgsql.build/src/test/isolation/expected/detach-partition-concurrently-4.out > > >

Re: TRUNCATE on foreign table

On 2021/04/09 23:10, Bharath Rupireddy wrote: On Fri, Apr 9, 2021 at 7:06 PM Fujii Masao wrote: > 4. Tab-completion for TRUNCATE should be updated so that also foreign tables are displayed. It will be good to have. Patch attached. Tab completion patch LGTM and it works as ex

Re: Replication slot stats misgivings

On Mon, Apr 12, 2021 at 5:29 PM Masahiko Sawada wrote: > > On Mon, Apr 12, 2021 at 8:08 PM Amit Kapila wrote: > > > > On Mon, Apr 12, 2021 at 4:34 PM Masahiko Sawada > > wrote: > > > > > > On Mon, Apr 12, 2021 at 6:19 PM Amit Kapila > > > wrote: > > > > > > > > On Mon, Apr 12, 2021 at 10:27 A

Re: "could not find pathkey item to sort" for TPC-DS queries 94-96

On 4/12/21 2:24 PM, Luc Vlaming wrote: > Hi, > > When trying to run on master (but afaik also PG-13) TPC-DS queries 94, > 95 and 96 on a SF10 I get the error "could not find pathkey item to sort". > When I disable enable_gathermerge the problem goes away and then the > plan for query 94 looks like

Re: multi-install PostgresNode fails with older postgres versions

Hi, On Wed, 7 Apr 2021 20:07:41 +0200 Jehan-Guillaume de Rorthais wrote: [...] > > > Let me know if it worth that I work on an official patch. > > > > Let's give it a try ... > > OK So, as promised, here is my take to port my previous work on PostgreSQL source tree. Make check pass with

pg_upgrade check for invalid role-specific default config

Hi all, While troubleshooting a failed upgrade from v11 -> v12 I realised I had encountered a bug previously reported on the pgsql-bugs mailing list: #14242 Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail https://www.postgresql.org/message-id/20160711223641.1

Re: Replication slot stats misgivings

On Mon, Apr 12, 2021 at 9:36 PM Amit Kapila wrote: > > On Mon, Apr 12, 2021 at 5:29 PM Masahiko Sawada wrote: > > > > On Mon, Apr 12, 2021 at 8:08 PM Amit Kapila wrote: > > > > > > On Mon, Apr 12, 2021 at 4:34 PM Masahiko Sawada > > > wrote: > > > > > > > > On Mon, Apr 12, 2021 at 6:19 PM Amit

Re: multi-install PostgresNode fails with older postgres versions

On 4/12/21 8:59 AM, Jehan-Guillaume de Rorthais wrote: > Hi, > > On Wed, 7 Apr 2021 20:07:41 +0200 > Jehan-Guillaume de Rorthais wrote: > [...] Let me know if it worth that I work on an official patch. >>> Let's give it a try ... >> OK > So, as promised, here is my take to port my pre

[GSoC 2021 proposal] pl/julia extension

Hello community, I’m Konstantina, a GSoC candidate for the project “Create Procedural language extension for the Julia programming language”. The mentors have already looked at my proposal and I’m attaching the finalized document. There is still some time for corrections, in case anyone would like

Re: psql - add SHOW_ALL_RESULTS option

Hello Tom, It's right: this is dead code because all paths through the if-nest starting at line 1373 now leave results = NULL. Hence, this patch has broken the autocommit logic; Do you mean yet another feature without a single non-regression test? :-( I tend to rely on non regression tests

Re: multi-install PostgresNode fails with older postgres versions

On Mon, 12 Apr 2021 09:52:24 -0400 Andrew Dunstan wrote: > On 4/12/21 8:59 AM, Jehan-Guillaume de Rorthais wrote: > > Hi, > > > > On Wed, 7 Apr 2021 20:07:41 +0200 > > Jehan-Guillaume de Rorthais wrote: > > [...] > Let me know if it worth that I work on an official patch. > >>> Let'

Contribution to PostgreSQL - please give an advice

Hi all! I would like to contribute my time and efforts to the PostgreSQL project development. I have some [hope not too bad] experience in software development primarily for Linux/BSD/Windows platforms with C/C++ though almost no experience in RDBMS internals. I have read the "Development Informat

Re: SQL/JSON: JSON_TABLE

> On 2021.03.27. 02:12 Nikita Glukhov wrote: > Attached 47th version of the patches. We're past feature freeze for 14 and alas, JSON_TABLE has not made it. I have tested quite a bit with it and because I didn't find any trouble with functionality or speed, I wanted to at least mention that here

Core dump happens when execute sql CREATE VIEW v1(c1) AS (SELECT ('4' COLLATE "C")::INT FROM generate_series(1, 10));

HI hackers, I found it could cause a crash when executing sql statement: `CREATE VIEW v1(c1) AS (SELECT ('4' COLLATE "C")::INT FROM generate_series(1, 10)); ` in postgres 13.2 release. The crash happens at view.c:89 and I did some analysis: ``` ColumnDef *def = makeColumnDef(tle->resn

Re: Replication slot stats misgivings

On Mon, Apr 12, 2021 at 7:03 PM Masahiko Sawada wrote: > > On Mon, Apr 12, 2021 at 9:36 PM Amit Kapila wrote: > > > > On Mon, Apr 12, 2021 at 5:29 PM Masahiko Sawada > > wrote: > > > > > > On Mon, Apr 12, 2021 at 8:08 PM Amit Kapila > > > wrote: > > > > > > > > On Mon, Apr 12, 2021 at 4:34 PM

Re: Contribution to PostgreSQL - please give an advice

Hi po 12. 4. 2021 v 17:22 odesílatel Ian Zagorskikh napsal: > Hi all! > > I would like to contribute my time and efforts to the PostgreSQL project > development. I have some [hope not too bad] experience in software > development primarily for Linux/BSD/Windows platforms with C/C++ though > almo

Re: Have I found an interval arithmetic bug?

On Sun, Apr 11, 2021 at 07:33:34PM -0700, Zhihong Yu wrote: > Among previous examples given by Bryn, the following produces correct result > based on Bruce's patch. > > # select interval '-1.7 years 29.4 months'; >     interval > >  9 mons 12 days Yes, that changed is caused by t

Re: PANIC: wrong buffer passed to visibilitymap_clear

Peter Geoghegan writes: > On Sun, Apr 11, 2021 at 11:16 AM Tom Lane wrote: >> It wasn't very clear, because I hadn't thought it through very much; >> but what I'm imagining is that we discard most of the thrashing around >> all-visible rechecks and have just one such test somewhere very late >> i

Re: psql - add SHOW_ALL_RESULTS option

Fabien COELHO writes: >> Between this and the known breakage of control-C, it seems clear >> to me that this patch was nowhere near ready for prime time. >> I think shoving it in on the last day before feature freeze was >> ill-advised, and it ought to be reverted. We can try again later. > The

Re: Contribution to PostgreSQL - please give an advice

On Mon, Apr 12, 2021 at 03:21:41PM +, Ian Zagorskikh wrote: > I would like to contribute my time and efforts to the PostgreSQL project > development. I have some [hope not too bad] experience in software > development primarily for Linux/BSD/Windows platforms with C/C++ though > almost no exper

Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c)

Em seg., 12 de abr. de 2021 às 03:04, Tom Lane escreveu: > Michael Paquier writes: > > On Sun, Apr 11, 2021 at 07:42:20PM -0300, Ranier Vilela wrote: > >> Em dom., 11 de abr. de 2021 às 16:25, Justin Pryzby < > pry...@telsasoft.com> > >>> I think it's cleanest to write: > >>> |HeapTupleData tmpt

Re: Core dump happens when execute sql CREATE VIEW v1(c1) AS (SELECT ('4' COLLATE "C")::INT FROM generate_series(1, 10));

Yulin PEI writes: > I found it could cause a crash when executing sql statement: `CREATE VIEW > v1(c1) AS (SELECT ('4' COLLATE "C")::INT FROM generate_series(1, 10)); ` in > postgres 13.2 release. Nice catch. I don't think the code in DefineVirtualRelation is wrong: exprCollation shouldn't

Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c)

On 4/12/21 6:55 PM, Ranier Vilela wrote: > > > Em seg., 12 de abr. de 2021 às 03:04, Tom Lane > escreveu: > > Michael Paquier mailto:mich...@paquier.xyz>> > writes: > > On Sun, Apr 11, 2021 at 07:42:20PM -0300, Ranier Vilela wrote: > >> Em dom., 11

Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c)

Ranier Vilela writes: > Em seg., 12 de abr. de 2021 às 03:04, Tom Lane escreveu: >> It would be wrong, though, or at least not have the same effect. > I think that you speak about fill pointers with 0 is not the same as fill > pointers with NULL. No, I mean that InvalidBlockNumber isn't 0. > I

Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c)

On Mon, Apr 12, 2021 at 01:55:13PM -0300, Ranier Vilela wrote: > Em seg., 12 de abr. de 2021 às 03:04, Tom Lane escreveu: > > Michael Paquier writes: > > > On Sun, Apr 11, 2021 at 07:42:20PM -0300, Ranier Vilela wrote: > > >> Em dom., 11 de abr. de 2021 às 16:25, Justin Pryzby < > > pry...@telsas

Proposal for working on open source with PostgreSQL

Hello Sir/Madam, I'm Nandni Mehla, a sophomore currently pursuing B.Tech in IT from Indira Gandhi Delhi Technical University for Women, Delhi. I've recently started working on open source and I think I will be a positive addition to your organization for working on projects using C and SQL, as I ha

Re: PANIC: wrong buffer passed to visibilitymap_clear

On Mon, Apr 12, 2021 at 9:19 AM Tom Lane wrote: > So I think we have to stick with the current basic design, and just > tighten things up to make sure that visibility pins are accounted for > in the places that are missing it. > > Hence, I propose the attached. It passes check-world, but that pro

Re: [PATCH] Identify LWLocks in tracepoints

Hi, On 2021-04-12 14:31:32 +0800, Craig Ringer wrote: > * There is no easy way to look up the tranche name by ID from outside the > backend But it's near trivial to add that. > It's annoying that we have to pay the cost of computing the tranche name > though. It never used to matter, but now th

Re: Proposal for working on open source with PostgreSQL

On Mon, 2021-04-12 at 23:26 +0530, Nandni Mehla wrote: > I'm Nandni Mehla, a sophomore currently pursuing B.Tech in IT from Indira > Gandhi > Delhi Technical University for Women, Delhi. I've recently started working on > open source and I think I will be a positive addition to your organization

Re: psql - add SHOW_ALL_RESULTS option

On 4/12/21, 9:25 AM, "Tom Lane" wrote: > Fabien COELHO writes: >>> Between this and the known breakage of control-C, it seems clear >>> to me that this patch was nowhere near ready for prime time. >>> I think shoving it in on the last day before feature freeze was >>> ill-advised, and it ought to

Re: psql - add SHOW_ALL_RESULTS option

On 2021-Apr-12, Bossart, Nathan wrote: > The following patch seems to resolve the issue, although I'll admit I > haven't dug into this too deeply. In any case, +1 for reverting the > patch for now. Please note that there's no "for now" about it -- if the patch is reverted, the only way to get it

Re: Proposal for working on open source with PostgreSQL

On 2021-Apr-12, Laurenz Albe wrote: > I couldn't see any detail information about the project in your proposal, > except > that the project is called "plsample". Is there more information somewhere? > > If it is a procedural language as the name suggests, you probably don't have > to modify Pos

Allowing to create LEAKPROOF functions to non-superuser

Hi hackers! This thread continues discussion of allowing something to non-superuser, AFAIK previous was [0]. Currently only superuser is allowed to create LEAKPROOF functions because leakproof functions can see tuples which have not yet been filtered out by security barrier views or row level

Re: Allowing to create LEAKPROOF functions to non-superuser

Andrey Borodin writes: > Currently only superuser is allowed to create LEAKPROOF functions because > leakproof functions can see tuples which have not yet been filtered out by > security barrier views or row level security policies. Yeah. > But managed cloud services typically do not provide s

Re: PANIC: wrong buffer passed to visibilitymap_clear

Hi, On 2021-04-11 13:55:30 -0400, Tom Lane wrote: > Either way, it's hard to argue that heap_update hasn't crossed the > complexity threshold where it's impossible to maintain safely. We > need to simplify it. Yea, I think we're well beyond that point. I can see a few possible steps to wrangle t

Re: Allowing to create LEAKPROOF functions to non-superuser

On 4/12/21 10:37 PM, Tom Lane wrote: > Andrey Borodin writes: >> Currently only superuser is allowed to create LEAKPROOF functions >> because leakproof functions can see tuples which have not yet been >> filtered out by security barrier views or row level security >> policies. > > Yeah. > >> B

Re: Allowing to create LEAKPROOF functions to non-superuser

Thanks for so quick response, Tom! > 12 апр. 2021 г., в 23:37, Tom Lane написал(а): > >> But managed cloud services typically do not provide superuser roles. > > This is not a good argument for relaxing superuser requirements. Ok, let's put aside question about relaxing requirements in upstream

Re: Allowing to create LEAKPROOF functions to non-superuser

Hi, On 2021-04-12 16:37:01 -0400, Tom Lane wrote: > Andrey Borodin writes: > > Currently only superuser is allowed to create LEAKPROOF functions > > because leakproof functions can see tuples which have not yet been > > filtered out by security barrier views or row level security > > policies. >

Re: Allowing to create LEAKPROOF functions to non-superuser

Hi, On 2021-04-12 22:42:03 +0200, Tomas Vondra wrote: > It's unfortunate that we tie the this capability to being superuser, > so maybe the right solution would be to introduce a separate role with > this privilege? Perhaps DB owner + BYPASSRLS would be enough? Greetings, Andres Freund

Curious test case added by collation version tracking patch

I am wondering what was the intent of this test case added by commit 257836a75: CREATE INDEX icuidx16_mood ON collate_test(id) WHERE mood > 'ok' COLLATE "fr-x-icu"; where "mood" is of an enum type, which surely does not respond to collations. The reason I ask is that this case started failing a

Re: Allowing to create LEAKPROOF functions to non-superuser

Thanks, Tomas! > 12 апр. 2021 г., в 23:42, Tomas Vondra > написал(а): > > I guess for the cloud services it's not an issue - they're mostly > concerned about manageability and restricting access to the OS. In fact, we would happily give a client access to an OS too. It's a client's VM after al

Re: Allowing to create LEAKPROOF functions to non-superuser

Hi, On 2021-04-12 23:51:02 +0300, Andrey Borodin wrote: > Do I risk having some extra superusers in my installation if I allow > everyone to create LEAKPROOF functions? I think that depends on what you define "superuser" to exactly be. Defining it as "has a path to executing arbitrary native code

Re: Allowing to create LEAKPROOF functions to non-superuser

> 13 апр. 2021 г., в 00:01, Andres Freund написал(а): > > Hi, > > On 2021-04-12 23:51:02 +0300, Andrey Borodin wrote: >> Do I risk having some extra superusers in my installation if I allow >> everyone to create LEAKPROOF functions? > > I think that depends on what you define "superuser" to

Re: Allowing to create LEAKPROOF functions to non-superuser

Andres Freund writes: > On 2021-04-12 23:51:02 +0300, Andrey Borodin wrote: >> Do I risk having some extra superusers in my installation if I allow >> everyone to create LEAKPROOF functions? > I think that depends on what you define "superuser" to exactly > be. Defining it as "has a path to execu

Re: pg_upgrade check for invalid role-specific default config

On Mon, Apr 12, 2021 at 01:28:19PM +, Charlie Hornsby wrote: > Hi all, > > While troubleshooting a failed upgrade from v11 -> v12 I realised I had > encountered a bug previously reported on the pgsql-bugs mailing list: > > #14242 Role with a setconfig "role" setting to a nonexistent role caus

Re: pg_upgrade check for invalid role-specific default config

Bruce Momjian writes: > On Mon, Apr 12, 2021 at 01:28:19PM +, Charlie Hornsby wrote: >> While troubleshooting a failed upgrade from v11 -> v12 I realised I had >> encountered a bug previously reported on the pgsql-bugs mailing list: >> #14242 Role with a setconfig "role" setting to a nonexiste

Re: Allowing to create LEAKPROOF functions to non-superuser

Hi, On 2021-04-12 17:14:20 -0400, Tom Lane wrote: > I doubt that falsely labeling a function LEAKPROOF can get you more > than the ability to read data you're not supposed to be able to read > ... but that ability is then available to all users, or at least all > users who can execute the function

Re: pg_upgrade check for invalid role-specific default config

I wrote: > I'm not sure I buy the premise that "it is possible to write a query > to identify these cases". It seems to me that the general problem is > that ALTER ROLE/DATABASE SET values might have become incorrect since > they were installed and would thus fail when reloaded in dump/restore. >

Re: Curious test case added by collation version tracking patch

On Tue, Apr 13, 2021 at 8:59 AM Tom Lane wrote: > I am wondering what was the intent of this test case added by commit > 257836a75: > > CREATE INDEX icuidx16_mood ON collate_test(id) WHERE mood > 'ok' COLLATE > "fr-x-icu"; > > where "mood" is of an enum type, which surely does not respond to > co

Re: Have I found an interval arithmetic bug?

br...@momjian.us wrote: > > z...@yugabyte.com wrote: >> Among previous examples given by Bryn, the following produces correct result >> based on Bruce's patch. >> >> # select interval '-1.7 years 29.4 months'; >> interval >> >> 9 mons 12 days > > Yes, that changed is cause

Re: Curious test case added by collation version tracking patch

Thomas Munro writes: > On Tue, Apr 13, 2021 at 8:59 AM Tom Lane wrote: >> The reason I ask is that this case started failing after I fixed >> a parse_coerce.c bug that allowed a CollateExpr node to survive >> in this WHERE expression, which by rights it should not. I'm >> inclined to think that

Teaching users how they can get the most out of HOT in Postgres 14

Recent work from commit 5100010e taught VACUUM that it doesn't have to do index vacuuming in cases where there are practically zero (not necessarily exactly zero) tuples to delete from indexes. It also surfaces the information used to decide whether or not we skip index vacuuming in the logs, via t

Re: Have I found an interval arithmetic bug?

On Mon, Apr 12, 2021 at 03:09:48PM -0700, Bryn Llewellyn wrote: > I showed you all this example a long time ago: > > select ( > ' > 3.853467 years > '::interval > )::text as i; > > This behavior is the same in the env. of Bruce’s patch as in unpatched PG > 13.2. This is the resul

Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays

On Sun, 11 Apr 2021 at 10:38, Tomas Vondra wrote: > I wonder what's the relationship between the length of the IN list and > the minimum number of rows needed for the hash to start winning. I made the attached spreadsheet which demonstrates the crossover point using the costs that I coded into co

Re: Teaching users how they can get the most out of HOT in Postgres 14

Hi, On 2021-04-12 16:11:59 -0700, Peter Geoghegan wrote: > Recent work from commit 5100010e taught VACUUM that it doesn't have to > do index vacuuming in cases where there are practically zero (not > necessarily exactly zero) tuples to delete from indexes. FWIW, I'd not at all be surprised if thi

Re: psql - add SHOW_ALL_RESULTS option

On Mon, Apr 12, 2021 at 07:08:21PM +, Bossart, Nathan wrote: > I think I've found another issue with this patch. If AcceptResult() > returns false in SendQueryAndProcessResults(), it seems to result in > an infinite loop of "unexpected PQresultStatus" messages. This can be > reproduced by try

Re: pg_upgrade check for invalid role-specific default config

I wrote: > Another answer is that maybe the processing of the "role" case > in particular is just broken. After digging around a bit more, I think that that is indeed the right answer. Most of the GUC check functions that have database-state-dependent behavior are programmed to behave specially w

Re: Teaching users how they can get the most out of HOT in Postgres 14

On Mon, Apr 12, 2021 at 4:30 PM Andres Freund wrote: > As far as I can see there's no reasonable way to disable this > "optimization", which scares me. I'm fine with adding a simple 'off' switch. What I'd like to avoid doing is making the behavior tunable, since it's likely to change in Postgres

Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays

On Fri, 9 Apr 2021 at 00:00, David Rowley wrote: > I push this with some minor cleanup from the v6 patch I posted earlier. I realised when working on something unrelated last night that we can also do hash lookups for NOT IN too. We'd just need to check if the operator's negator operator is hash

Re: Have I found an interval arithmetic bug?

Bruce Momjian writes: > On Mon, Apr 12, 2021 at 03:09:48PM -0700, Bryn Llewellyn wrote: >> After all, you've bitten the bullet now and changed the behavior. This means >> that the semantics of some extant applications will change. So... in for a >> penny, in for a pound? > The docs now say: >

Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays

David Rowley writes: > I realised when working on something unrelated last night that we can > also do hash lookups for NOT IN too. ... and still get the behavior right for nulls? regards, tom lane

Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays

On Tue, 13 Apr 2021 at 11:42, Tom Lane wrote: > > David Rowley writes: > > I realised when working on something unrelated last night that we can > > also do hash lookups for NOT IN too. > > ... and still get the behavior right for nulls? Yeah, it will. There are already some special cases for NU

Re: Teaching users how they can get the most out of HOT in Postgres 14

On Mon, Apr 12, 2021 at 04:35:13PM -0700, Peter Geoghegan wrote: > On Mon, Apr 12, 2021 at 4:30 PM Andres Freund wrote: > > As far as I can see there's no reasonable way to disable this > > "optimization", which scares me. > > I'm fine with adding a simple 'off' switch. What I'd like to avoid > d

Re: Teaching users how they can get the most out of HOT in Postgres 14

On Mon, Apr 12, 2021 at 4:52 PM Michael Paquier wrote: > While going through this commit a couple of days ago, I really got to > wonder why you are controlling this stuff with a hardcoded value and I > found that scary, while what you should be using are two GUCs with the > reloptions that come wi

Re: Have I found an interval arithmetic bug?

On Mon, Apr 12, 2021 at 07:38:21PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Mon, Apr 12, 2021 at 03:09:48PM -0700, Bryn Llewellyn wrote: > >> After all, you've bitten the bullet now and changed the behavior. This > >> means that the semantics of some extant applications will change.

Re: Have I found an interval arithmetic bug?

> t...@sss.pgh.pa.us wrote: > > br...@momjian.us writes: >> b...@yugabyte.com wrote: >>> After all, you've bitten the bullet now and changed the behavior. This >>> means that the semantics of some extant applications will change. So... in >>> for a penny, in for a pound? > >> The docs now say:

Re: Have I found an interval arithmetic bug?

> On 12-Apr-2021, at 17:00, Bruce Momjian wrote: > > On Mon, Apr 12, 2021 at 07:38:21PM -0400, Tom Lane wrote: >> Bruce Momjian writes: >>> On Mon, Apr 12, 2021 at 03:09:48PM -0700, Bryn Llewellyn wrote: After all, you've bitten the bullet now and changed the behavior. This means that

Re: Have I found an interval arithmetic bug?

On Mon, Apr 12, 2021 at 05:20:43PM -0700, Bryn Llewellyn wrote: > I’d argue that the fact that this: > > ('0.3 months'::interval) + ('0.7 months'::interval) > > Is reported as '30 days' and not '1 month' is yet another > bug—precisely because of what I said in my previous email (sorry > that I fork

Re: wal stats questions

On 2021/03/30 20:37, Masahiro Ikeda wrote: OK, I added the condition to the fast-return check. I noticed that I misunderstood that the purpose is to avoid expanding a clock check using WAL stats counters. But, the purpose is to make the conditions stricter, right? Yes. Currently if the follo

Re: Teaching users how they can get the most out of HOT in Postgres 14

Hi, On 2021-04-12 16:53:47 -0700, Peter Geoghegan wrote: > On Mon, Apr 12, 2021 at 4:52 PM Michael Paquier wrote: > > While going through this commit a couple of days ago, I really got to > > wonder why you are controlling this stuff with a hardcoded value and I > > found that scary, while what y

Re: TRUNCATE on foreign table

On Sun, Apr 11, 2021 at 03:45:36PM +0530, Bharath Rupireddy wrote: > On Sun, Apr 11, 2021 at 9:47 AM Justin Pryzby wrote: > > Also, you currently test: > > > + if (extra & TRUNCATE_REL_CONTEXT_ONLY) > > > > but TRUNCATE_REL_ aren't indepedent bits, so shouldn't be tested with "&". > >

Re: Possible SSI bug in heap_update

On Mon, Apr 12, 2021 at 10:36 AM Thomas Munro wrote: > Yeah. Patch attached. Pushed.

Re: Teaching users how they can get the most out of HOT in Postgres 14

On Mon, Apr 12, 2021 at 5:37 PM Andres Freund wrote: > Well, one argument is that you made a fairly significant behavioural > change, with hard-coded logic for when the optimization kicks in. It's > not at all clear that your constants are the right ones for every > workload. (Apparently nobody w

Re: TRUNCATE on foreign table

On Tue, Apr 13, 2021 at 6:27 AM Justin Pryzby wrote: > > On Sun, Apr 11, 2021 at 03:45:36PM +0530, Bharath Rupireddy wrote: > > On Sun, Apr 11, 2021 at 9:47 AM Justin Pryzby wrote: > > > Also, you currently test: > > > > + if (extra & TRUNCATE_REL_CONTEXT_ONLY) > > > > > > but TRUNCAT

Re: PANIC: wrong buffer passed to visibilitymap_clear

Peter Geoghegan writes: > On Mon, Apr 12, 2021 at 9:19 AM Tom Lane wrote: >> Hence, I propose the attached. It passes check-world, but that proves >> absolutely nothing of course :-(. I wonder if there is any way to >> exercise these code paths deterministically. > This approach seems reasonab

  1   2   >