Retry in pgbench

Currently standard pgbench scenario produces transaction serialize errors "could not serialize access due to concurrent update" if PostgreSQL runs in REPEATABLE READ or SERIALIZABLE level, and the session aborts. In order to achieve meaningful results even in these transaction isolation levels, I

Re: Extensions not dumped when --schema is used

On Sun, Apr 04, 2021 at 03:08:02PM -0700, Noah Misch wrote: > I noticed the patch's behavior for relations that are members of non-dumped > extensions and are also registered using pg_extension_config_dump(). It > depends on the schema: > > - If extschema='public', "pg_dump -e plpgsql" makes no

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

On Mon, Apr 12, 2021 at 02:25:53PM +0900, Michael Paquier wrote: > On Fri, Apr 09, 2021 at 08:07:10PM -0700, Noah Misch wrote: > > "pg_regress --outputdir" is not a great location for a file or directory > > created by a user other than the user running pg_regress. If one does "make > > check"

Re: PG Docs - logical decoding output plugins - fix typo

On 2021/04/13 13:23, Peter Smith wrote: PSA a patch to fix a typo found on this page [1], "preapre_end_lsn" -> "prepare_end_lsn" Pushed. Thanks! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION

Re: TRUNCATE on foreign table

2021年4月9日(金) 23:49 Kohei KaiGai : > > 2021年4月9日(金) 22:51 Fujii Masao : > > > > On 2021/04/09 12:33, Kohei KaiGai wrote: > > > 2021年4月8日(木) 22:14 Fujii Masao : > > >> > > >> On 2021/04/08 22:02, Kohei KaiGai wrote: > > Anyway, attached is the updated version of the patch. This is still > >

Re: Replication slot stats misgivings

On Mon, Apr 12, 2021 at 9:16 PM vignesh C wrote: > > 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 > > +

Re: doc review for v14

On Fri, Apr 09, 2021 at 02:03:27PM +0900, Michael Paquier wrote: > On Thu, Apr 08, 2021 at 11:40:08AM -0500, Justin Pryzby wrote: > > Another round of doc review, not yet including all of yesterday's commits. > > Thanks for compiling all that. I got through the whole set and > applied the most

PG Docs - logical decoding output plugins - fix typo

PSA a patch to fix a typo found on this page [1], "preapre_end_lsn" -> "prepare_end_lsn" -- [1] https://www.postgresql.org/docs/devel/logicaldecoding-output-plugin.html Kind Regards, Peter Smith. Fujitsu Australia fix_typo.patch Description: Binary data

Re: TRUNCATE on foreign table

On Tue, Apr 13, 2021 at 12:38:35PM +0900, Fujii Masao wrote: > + Relation data structures for each > + foreign tables to be truncated. > > "foreign tables" should be "foreign table" because it follows "each"? Yes, you're right. > + > + behavior is either > + DROP_RESTRICT or

Re: TRUNCATE on foreign table

On 2021/04/13 10:21, Bharath Rupireddy wrote: I agree to convert to bits and pass it as int value which is extensible i.e. we can pass more extra parameters across if required. Looks good to me. Also I'm not in favour of removing relids_extra altogether, we might need this to send some

Re: [PATCH] Identify LWLocks in tracepoints

Hi, On 2021-04-13 10:34:18 +0800, Craig Ringer wrote: > > But it's near trivial to add that. > > Really? Yes. > Each backend can have different tranche IDs (right?) No, they have to be the same in each. Note how the tranche ID is part of struct LWLock. Which is why LWLockNewTrancheId() has

Re: pg_amcheck contrib application

> On Apr 9, 2021, at 1:51 PM, Robert Haas wrote: > > On Fri, Apr 9, 2021 at 2:50 PM Mark Dilger > wrote: >> I think #4, above, requires some clarification. If there are missing >> chunks, the very definition of how large we expect subsequent chunks to be >> is ill-defined. I took a

Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)

On Sun, Jan 26, 2020 at 11:21 PM Kyotaro Horiguchi wrote: > At Sun, 26 Jan 2020 12:22:03 -0800, Andres Freund wrote > in > > On 2020-01-26 16:20:03 +0100, Magnus Hagander wrote: > > > On Sun, Jan 26, 2020 at 1:44 AM Andres Freund wrote: > > > > On 2020-01-25 15:43:41 +0100, Magnus Hagander

Re: [PATCH] Identify LWLocks in tracepoints

On Tue, 13 Apr 2021 at 02:23, Andres Freund wrote: [I've changed the order of the quoted sections a little to prioritize the key stuff] > > On 2021-04-12 14:31:32 +0800, Craig Ringer wrote: > > > It's annoying that we have to pay the cost of computing the tranche name > > though. It never used

RE: WIP: WAL prefetch (another approach)

Hi, Thank you for developing a great feature. I tested this feature and checked the documentation. Currently, the documentation for the pg_stat_prefetch_recovery view is included in the description for the pg_stat_subscription view.

Re: vacuum freeze - possible improvements

On Mon, Apr 12, 2021 at 5:38 PM Virender Singla wrote: > > 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

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

On Mon, Apr 12, 2021 at 6:23 AM Justin Pryzby wrote: > On Sun, Apr 11, 2021 at 05:20:35PM -0400, 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: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Thu, Apr 8, 2021 at 01:01:42PM -0400, Bruce Momjian wrote: > On Thu, Apr 8, 2021 at 12:51:06PM -0400, Álvaro Herrera wrote: > > On 2021-Apr-08, Bruce Momjian wrote: > > > > > pg_stat_activity.queryid is new, but I can imagine cases where you would > > > join pg_stat_activity to

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

On Mon, Apr 12, 2021 at 7:49 PM David Rowley wrote: > > 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

Re: PANIC: wrong buffer passed to visibilitymap_clear

On Mon, Apr 12, 2021 at 6:33 PM Tom Lane wrote: > Thanks for looking it over. Do you have an opinion on whether or not > to back-patch? As far as we know, these bugs aren't exposed in the > back branches for lack of code that would set the all-visible flag > without superexclusive lock. But

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

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

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

Re: Possible SSI bug in heap_update

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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 =

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

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

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

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

[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

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

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

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

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

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

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

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

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

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

"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

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

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

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

  1   2   >