Re: Potential memory leak in contrib/intarray's g_intbig_compress

On Thu, Jul 13, 2023 at 06:28:39PM +0200, Matthias van de Meent wrote: > There are similar pfree calls in the _int_gist.c file's g_int_compress > function, which made me think we do need to clean up after use, but > indeed these pfrees are useless (or even harmful if bug #17888 can be > trusted)

16beta2 SQL parser: different defaults on absent_on_null

While adapting a Java implementation of the SQL parser, I noticed that in structures JsonArrayAgg, JsonArrayConstructor, JsonArrayQueryConstructor and JsonObjectConstrutor, the absent_on_null field defaults to TRUE. But in JsonObjectAgg, absent_on_null defaults to FALSE. Is that intentionally?

Re: add non-option reordering to in-tree getopt_long

On Thu, Jul 13, 2023 at 09:38:42PM -0700, Nathan Bossart wrote: > I did notice this, but I had the opposite reaction. Ahah, well ;) > Take the following examples of client programs that accept one non-option: > > ~$ pg_resetwal a b c > pg_resetwal: error: too many command-line

Re: Autogenerate some wait events code and documentation

On Thu, Jul 13, 2023 at 10:26:54AM +0900, Michael Paquier wrote: > I would like to apply 0001 and 0002 to improve the format if there are > no objections. 0003 and 0004 are still here for discussion, as it > does not seem like a consensus has been reached for that yet. Getting > more opinions

Re: add non-option reordering to in-tree getopt_long

On Fri, Jul 14, 2023 at 01:27:26PM +0900, Michael Paquier wrote: > Indeed, it looks like I've fat-fingered a rebase here. I am able to > get a clean CI run when running this patch, sorry for the noise. > > Anyway, this introduces a surprising behavior when specifying too many > subcommands. On

Re: add non-option reordering to in-tree getopt_long

On Thu, Jul 13, 2023 at 07:57:12AM -0700, Nathan Bossart wrote: > Assuming you are referring to [0], it looks like you are missing 411b720. > > [0] https://github.com/michaelpq/postgres/commits/getopt_test Indeed, it looks like I've fat-fingered a rebase here. I am able to get a clean CI run

Re: Preventing non-superusers from altering session authorization

On Wed, Jul 12, 2023 at 09:37:57PM -0700, Nathan Bossart wrote: > On Mon, Jul 10, 2023 at 01:49:55PM -0700, Nathan Bossart wrote: >> Great. I'm going to wait a few more days in case anyone has additional >> feedback, but otherwise I intend to commit this shortly. > > I've committed 0001 for now.

Re: In Postgres 16 BETA, should the ParseNamespaceItem have the same index as it's RangeTableEntry?

On Fri, Jul 14, 2023 at 7:12 AM Tom Lane wrote: > Farias de Oliveira writes: > > With further inspection in AGE's code, after executing the SET query, > > it goes inside transform_cypher_clause_as_subquery() function and the > > ParseNamespaceItem has the following values: > > > {p_names =

Re: 'ERROR: attempted to update invisible tuple' from 'ALTER INDEX ... ATTACH PARTITION' on parent index

On Thu, Jul 13, 2023 at 02:01:49PM +0530, Shruthi Gowda wrote: > While analyzing the issue I did notice that validatePartitionedIndex() is > the only place where the index tuple was copied from rel->rd_indextuple > however was not clear about the motive behind it. No idea either. Anyway, I've

Re: Add hint message for check_log_destination()

On Thu, 13 Jul 2023 at 16:19, Masahiko Sawada wrote: > On Tue, Jul 11, 2023 at 10:24 AM Japin Li wrote: >> >> >> On Mon, 10 Jul 2023 at 14:23, Masahiko Sawada wrote: >> > On Mon, Jul 10, 2023 at 2:07 PM Kyotaro Horiguchi >> > wrote: >> >> >> >> At Mon, 10 Jul 2023 09:04:42 +0800, Japin Li

Re: CommandStatus from insert returning when using a portal.

On Thu, 13 Jul 2023 at 10:24, David G. Johnston wrote: > On Thursday, July 13, 2023, Dave Cramer wrote: > >> >> Any comment on why the CommandComplete is incorrect ? >> It returns INSERT 0 0 if a cursor is used >> > > Looking at DECLARE it is surprising that what you describe is even >

Re: WAL Insertion Lock Improvements

Hi, On 2023-07-13 14:04:31 -0700, Andres Freund wrote: > From b74b6e953cb5a7e7ea1a89719893f6ce9e231bba Mon Sep 17 00:00:00 2001 > From: Bharath Rupireddy > Date: Fri, 19 May 2023 15:00:21 + > Subject: [PATCH v8] Optimize WAL insertion lock acquisition and release > > This commit optimizes

Re: Fix search_path for all maintenance commands

On Thu, 2023-07-13 at 13:37 -0700, David G. Johnston wrote: > If this is limited to MAINT, which I'm in support of, there is no > need for an "escape hatch".  A prerequisite for leveraging the new > feature is that you fix the code so it conforms to the new way of > doing things. The current

Re: In Postgres 16 BETA, should the ParseNamespaceItem have the same index as it's RangeTableEntry?

Farias de Oliveira writes: > With further inspection in AGE's code, after executing the SET query, > it goes inside transform_cypher_clause_as_subquery() function and the > ParseNamespaceItem has the following values: > {p_names = 0x1205638, p_rte = 0x11edb70, p_rtindex = 1, p_perminfo = >

Re: Allowing parallel-safe initplans

I wrote: > Eventually I noticed that all the failing cases were instances of > optimizing MIN()/MAX() aggregates into indexscans, and then I figured > out what the problem is: we substitute Params for the optimized-away > Aggref nodes in setrefs.c, *after* SS_finalize_plan has been run. > That

Re: psql: Add role's membership options to the \du+ command

On 13.07.2023 11:26, Pavel Luzanov wrote: And for versions <16 I forget to simplify expression for 'Options' column after removing LEFT JOIN on pam: SELECT m.rolname AS "Role name", r.rolname AS "Member of",   pg_catalog.concat_ws(', ',     CASE WHEN pam.admin_option THEN 'ADMIN' END,     CASE

Re: Fix search_path for all maintenance commands

On Thu, Jul 13, 2023 at 2:00 PM Gurjeet Singh wrote: > On Thu, Jul 13, 2023 at 1:37 PM David G. Johnston > wrote: > > > > I'm against simply breaking the past without any recourse as what we > did for pg_dump/pg_restore still bothers me. > > I'm sure this is tangential, but can you please

Re: WAL Insertion Lock Improvements

On 2023-07-11 09:20:45 +0900, Michael Paquier wrote: > On Mon, Jun 05, 2023 at 08:00:00AM +0530, Bharath Rupireddy wrote: > > On Wed, May 31, 2023 at 5:05 PM Michael Paquier wrote: > >> @Andres: Were there any extra tests you wanted to be run for more > >> input? > > > > @Andres Freund please

Re: Fix search_path for all maintenance commands

On Thu, Jul 13, 2023 at 1:37 PM David G. Johnston wrote: > > I'm against simply breaking the past without any recourse as what we did for > pg_dump/pg_restore still bothers me. I'm sure this is tangential, but can you please provide some context/links to the change you're referring to here.

Re: DROP DATABASE is interruptible

Hi, On 2023-07-12 11:54:18 +0200, Daniel Gustafsson wrote: > > On 12 Jul 2023, at 03:59, Andres Freund wrote: > > On 2023-07-07 14:09:08 +0200, Daniel Gustafsson wrote: > >>> On 25 Jun 2023, at 19:03, Andres Freund wrote: > >>> On 2023-06-21 12:02:04 -0700, Andres Freund wrote: > > >>> There

Re: vac_truncate_clog()'s bogus check leads to bogusness

On 2023-06-22 22:29:12 -0700, Noah Misch wrote: > On Thu, Jun 22, 2023 at 09:45:18AM -0700, Andres Freund wrote: > > On 2023-06-21 21:50:39 -0700, Noah Misch wrote: > > > On Wed, Jun 21, 2023 at 03:12:08PM -0700, Andres Freund wrote: > > > > When vac_truncate_clog() returns early > > > ... > > > >

Re: Fix search_path for all maintenance commands

On Thu, Jul 13, 2023 at 12:54 PM Gurjeet Singh wrote: > > The approach seems good to me. My concern is with this change's > potential to cause an extended database outage. Hence sending it out > as part of v16, without any escape hatch for the DBA, is my objection. > > If this is limited to

Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication

Hi Peter, Peter Smith , 11 Tem 2023 Sal, 05:59 tarihinde şunu yazdı: > Even if patches 0003 and 0002 are to be combined, I think that should > not happen until after the "reuse" design is confirmed which way is > best. > > e.g. IMO it might be easier to compare the different PoC designs for >

Re: Fix search_path for all maintenance commands

On Thu, Jul 13, 2023 at 11:56 AM Jeff Davis wrote: > > The current approach seemed to get support from Noah, Nathan, and Greg > Stark. > > Concerns were raised by Gurjeet, Tom, and Robert in the 16 cycle; but I didn't see Tom's or Robert's concerns raised in this thread. I see now that for some

Re: MERGE ... RETURNING

On Thu, 2023-07-13 at 18:01 +0100, Dean Rasheed wrote: > For some use cases, I can imagine allowing OLD/NEW.colname would mean > you wouldn't need pg_merge_action() (if the column was NOT NULL), so > I > think the features should work well together. For use cases where a user could do it either

In Postgres 16 BETA, should the ParseNamespaceItem have the same index as it's RangeTableEntry?

Hello, my name is Matheus Farias and this is the first time that I'm sending an email to the pgsql-hackers list. I'm a software developer intern at Bitnine Global Inc. and, along with other interns, we've been working on updating Apache AGE with the latest version of Postgres, the REL_16_BETA

Re: Fix search_path for all maintenance commands

On Thu, 2023-07-06 at 18:39 -0700, Jeff Davis wrote: > * The fix might not go far enough or might be in the wrong place. I'm > open to suggestion here, too. Maybe we can make it part of the > general > function call mechanism, and can be overridden by explicitly setting > the function search

Re: MERGE ... RETURNING

On Thu, 13 Jul 2023 at 17:43, Vik Fearing wrote: > > There is also the WITH ORDINALITY and FOR ORDINALITY examples. > True. I just think "number" is a friendlier, more familiar word than "ordinal". > So perhaps pg_merge_when_clause_number() would > > be a better name. It's still quite long, but

Re: MERGE ... RETURNING

On Thu, 13 Jul 2023 at 17:01, Jeff Davis wrote: > > MERGE can end up combining old and new values in a way that doesn't > happen with INSERT/UPDATE/DELETE. For instance, a "MERGE ... RETURNING > id" would return a mix of NEW.id (for INSERT/UPDATE actions) and OLD.id > (for DELETE actions). >

Re: remaining sql/json patches

I looked at your 0001. My 0001 are some trivial comment cleanups to that. I scrolled through all of jsonfuncs.c to see if there was a better place for the new function than the end of the file. Man, is that one ugly file. There are almost no comments! I almost wish you would create a new file

Re: MERGE ... RETURNING

On 7/13/23 17:38, Dean Rasheed wrote: On Tue, 11 Jul 2023 at 21:43, Gurjeet Singh wrote: I think the name of function pg_merge_when_clause() can be improved. How about pg_merge_when_clause_ordinal(). That's a bit of a mouthful, but I don't have a better idea right now. I've left the names

Re: MERGE ... RETURNING

On Thu, Jul 13, 2023 at 8:38 AM Dean Rasheed wrote: > > On Tue, 11 Jul 2023 at 21:43, Gurjeet Singh wrote: > > { oid => '9499', descr => 'command type of current MERGE action', > > - proname => 'pg_merge_action', provolatile => 'v', > > + proname => 'pg_merge_action', provolatile => 'v',

Re: MERGE ... RETURNING

On Mon, 2023-01-09 at 12:29 +, Dean Rasheed wrote: > > Would it be useful to have just the action? Perhaps "WITH ACTION"? > > My idea is that this would return an enum of INSERT, UPDATE, DELETE > > (so is "action" the right word?). It seems to me in many situations > > I would be more likely

Re: psql: Add role's membership options to the \du+ command

Pavel Luzanov writes: > On 13.07.2023 18:01, Tom Lane wrote: >> That does not seem right. Is it impossible for pam.set_option >> to be false? Even if it is, should this code assume that? > For versions before 16, including one role to another automatically > gives possibility to issue SET

Re: Potential memory leak in contrib/intarray's g_intbig_compress

On Thu, 13 Jul 2023 at 17:20, Tom Lane wrote: > > Matthias van de Meent writes: > > My collegue Konstantin (cc-ed) noticed that the GiST code of intarray > > may leak memory in certain index operations: > > Can you demonstrate an actual problem here, that is a query-lifespan leak? > > IMO, the

Re: Potential memory leak in contrib/intarray's g_intbig_compress

I wrote: > Matthias van de Meent writes: >> My collegue Konstantin (cc-ed) noticed that the GiST code of intarray >> may leak memory in certain index operations: > Can you demonstrate an actual problem here, that is a query-lifespan leak? > IMO, the coding rule in the GiST and GIN AMs is that

Re: logical decoding and replication of sequences, take 2

On 7/13/23 16:24, Ashutosh Bapat wrote: > Thanks for the updated patches. I haven't looked at the patches yet > but have some responses below. > > On Thu, Jul 13, 2023 at 12:35 AM Tomas Vondra > wrote: > >> >> >> 3) simplify the replicated state >> >> As suggested by Ashutosh, it may not be

Re: sslinfo extension - add notbefore and notafter timestamps

I had another look at this today and I think this patch is in pretty good shape, below are a few comments on this revision: - 'sslinfo--1.2.sql', + 'sslinfo--1.2--1.3.sql', + 'sslinfo--1.3.sql', The way we typically ship extensions in contrib/ is to not create a new base version .sql file for

Re: MERGE ... RETURNING

On Mon, 2023-01-09 at 12:29 +, Dean Rasheed wrote: > > Would it be feasible to allow specifying old.column or new.column? > > These would always be NULL for INSERT and DELETE respectively but > > more useful with UPDATE. Actually I've been meaning to ask this > > question about UPDATE …

Re: psql: Add role's membership options to the \du+ command

On 13.07.2023 18:01, Tom Lane wrote: The idea with that, IMO, is to do something at least minimally sane if there's a bogus role OID in pg_auth_members. With plain joins, the output row would disappear and you'd have no clue that anything is wrong. With left joins, you get a row with a null

Re: logical decoding and replication of sequences, take 2

On 7/5/23 16:51, Ashutosh Bapat wrote: > 0005, 0006 and 0007 are all related to the initial sequence sync. [3] > resulted in 0007 and I think we need it. That leaves 0005 and 0006 to > be reviewed in this response. > > I followed the discussion starting [1] till [2]. The second one > mentions the

Re: psql: Add role's membership options to the \du+ command

On Thu, Jul 13, 2023 at 8:01 AM Tom Lane wrote: > > I plan to replace it to: > > >pg_catalog.concat_ws(', ', > > CASE WHEN pam.admin_option THEN 'ADMIN' END, > > CASE WHEN m.rolinherit THEN 'INHERIT' END, > > 'SET' > >) AS "Options", > > That does not seem right. Is it

Re: MERGE ... RETURNING

On Tue, 11 Jul 2023 at 21:43, Gurjeet Singh wrote: > > > > I think the name of function pg_merge_when_clause() can be improved. > > > How about pg_merge_when_clause_ordinal(). > > > > That's a bit of a mouthful, but I don't have a better idea right now. > > I've left the names alone for now, in

Re: MERGE ... RETURNING

On Sun, 2023-01-08 at 12:28 +, Dean Rasheed wrote: > I considered allowing a separate RETURNING list at the end of each > action, but rapidly dismissed that idea. One potential benefit of that approach is that it would be more natural to specify output specific to the action, e.g. WHEN

Re: Potential memory leak in contrib/intarray's g_intbig_compress

Matthias van de Meent writes: > My collegue Konstantin (cc-ed) noticed that the GiST code of intarray > may leak memory in certain index operations: Can you demonstrate an actual problem here, that is a query-lifespan leak? IMO, the coding rule in the GiST and GIN AMs is that the AM code is

Re: psql: Add role's membership options to the \du+ command

Pavel Luzanov writes: > On 08.07.2023 20:07, Tom Lane wrote >> 3. Not sure about use of LEFT JOIN in the query. That will mean we >> get a row out even for roles that have no grants, which seems like >> clutter. The LEFT JOINs to r and g are fine, but I suggest changing >> the first join to a

Re: logical decoding and replication of sequences, take 2

On 6/23/23 15:18, Ashutosh Bapat wrote: > ... > > I reviewed 0001 and related parts of 0004 and 0008 in detail. > > I have only one major change request, about > typedef struct xl_seq_rec > { > RelFileLocator locator; > + bool created; /* creates a new relfilenode (CREATE/ALTER) */ > > I am not

Re: add non-option reordering to in-tree getopt_long

On Thu, Jul 13, 2023 at 02:39:32PM +0900, Michael Paquier wrote: > Something does not seem to be right seen from here, a CI run with > Windows 2019 fails when using pg_ctl at the beginning of most of the > tests, like: > [04:56:07.404] - 8< >

Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL

Hi Amit, Hayato, all > +1 for the readability. I think we can as you suggest or I feel it > > would be better if we return false as soon as we found any condition > > is false. The current patch has a mixed style such that for > > InvalidStrategy, it returns immediately but for others, it does a

Re: CommandStatus from insert returning when using a portal.

On Thursday, July 13, 2023, Dave Cramer wrote: > > Any comment on why the CommandComplete is incorrect ? > It returns INSERT 0 0 if a cursor is used > Looking at DECLARE it is surprising that what you describe is even possible. Can you share a psql reproducer? David J.

Re: logical decoding and replication of sequences, take 2

Thanks for the updated patches. I haven't looked at the patches yet but have some responses below. On Thu, Jul 13, 2023 at 12:35 AM Tomas Vondra wrote: > > > 3) simplify the replicated state > > As suggested by Ashutosh, it may not be a good idea to replicate the > (last_value, log_cnt,

Re: cataloguing NOT NULL constraints

On Wed, 12 Jul 2023 at 18:11, Alvaro Herrera wrote: > > v13, because a conflict was just committed to alter_table.sql. > > Here I also call out the relcache.c change by making it a separate > commit. I'm likely to commit it that way, too. To recap: the change is > to have a partitioned table's

Re: CommandStatus from insert returning when using a portal.

On Wed, 12 Jul 2023 at 21:31, David G. Johnston wrote: > On Wed, Jul 12, 2023 at 5:57 PM Dave Cramer wrote: > >> On Wed, 12 Jul 2023 at 20:00, wrote: >> >>> Dave Cramer writes: >>> > Obviously I am biased by the JDBC API which would like to have >>> > PreparedStatement.execute() return the

Re: Incremental sort for access method with ordered scan support (amcanorderbyop)

On 7/5/23 2:15 AM, Richard Guo wrote: On Tue, Jul 4, 2023 at 7:15 PM David Rowley > wrote: On Tue, 4 Jul 2023 at 20:12, Richard Guo mailto:guofengli...@gmail.com>> wrote: > The v4 patch looks good to me (maybe some cosmetic tweaks are still > needed

Re: doc: clarify the limitation for logical replication when REPILICA IDENTITY is FULL

On Tue, Jul 11, 2023 at 2:17 PM Sergei Kornilov wrote: > > I think it's appropriate to add on the restrictions page. (But mentioning > that this restriction is only for subscriber) > > If the list were larger, then the restrictions page could be divided into > publisher and subscriber

Potential memory leak in contrib/intarray's g_intbig_compress

Hi, My collegue Konstantin (cc-ed) noticed that the GiST code of intarray may leak memory in certain index operations: > g_intbig_compress(...): > [...] > ArrayType *in = DatumGetArrayTypeP(entry->key); > [...] > if (in != DatumGetArrayTypeP(entry->key)) > pfree(in);

Re: Better help output for pgbench -I init_steps

On 12.07.23 19:47, Gurjeet Singh wrote: If you end up with variant 3 or 4, please use double quotes instead of single quotes. Will do. I believe you're suggesting this because in the neighboring help text the string literals use double quotes. I see that other utilities, such as psql also

Re: Consistent coding for the naming of LR workers

On 13.07.23 11:29, Alvaro Herrera wrote: On 2023-Jul-13, Peter Eisentraut wrote: I suppose we could just say "logical replication worker" in all cases. That should be enough precision for the purpose of these messages. Agreed. IMO the user doesn't care about specifics. Ok, committed.

Re: Configurable FP_LOCK_SLOTS_PER_BACKEND

On 7/13/23 07:02, Nikolay Samokhvalov wrote: > We're observing a few cases with lockmanager spikes in a few quite > loaded systems. > > These cases are different; queries are different, Postgres versions are > 12, 13, and 14. > > But in all cases, servers are quite beefy (96-128 vCPUs,

Re: Check lateral references within PHVs for memoize cache keys

On Sun, Jul 9, 2023 at 12:17 PM David Rowley wrote: > I just pushed a fix for this. Thanks for reporting it. BTW, I noticed a typo in the comment inside paraminfo_get_equal_hashops. foreach(lc, innerrel->lateral_vars) { Node *expr = (Node *) lfirst(lc);

Re: Consistent coding for the naming of LR workers

On 2023-Jul-13, Peter Eisentraut wrote: > I suppose we could just say "logical replication worker" in all cases. That > should be enough precision for the purpose of these messages. Agreed. IMO the user doesn't care about specifics. -- Álvaro Herrera 48°01'N 7°57'E —

Re: Check lateral references within PHVs for memoize cache keys

On Sun, Jul 9, 2023 at 1:28 AM Tom Lane wrote: > More generally, it's not clear to me why we should need to look inside > lateral PHVs in the first place. Wouldn't the lateral PHV itself > serve fine as a cache key? Do you mean we use the lateral PHV directly as a cache key? Hmm, it seems to

Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL

On Thu, Jul 13, 2023 at 8:51 AM Amit Kapila wrote: > > On Wed, Jul 12, 2023 at 8:14 PM Önder Kalacı wrote: > > > >> > >> > - return is_btree && !is_partial && !is_only_on_expression; > >> > + /* Check whether the index is supported or not */ > >> > + is_suitable_type =

About `GetNonHistoricCatalogSnapshot`: does it allow developers to use catalog snapshot to scan non-catalog tables?

Hi, I have a question about the routine "GetNonHistoricCatalogSnapshot".​ It has a param "Oid relid​​". It firstly checks if the relation has systemcache or ​if it is in "RelationInvalidatesSnapshotsOnly" related relations. If yes, it will invalidate the CatalogSnapshot. I just wonder in which

Re: Consistent coding for the naming of LR workers

On Thu, Jul 13, 2023 at 4:07 PM Peter Eisentraut wrote: > > On 13.07.23 06:59, Peter Smith wrote: > > On Wed, Jul 12, 2023 at 9:35 PM Peter Eisentraut > > wrote: > >> > >> On 21.06.23 09:18, Alvaro Herrera wrote: > >>> That is a terrible pattern in relatively new code. Let's get rid of it >

Re: 'ERROR: attempted to update invisible tuple' from 'ALTER INDEX ... ATTACH PARTITION' on parent index

On Thu, Jul 13, 2023 at 1:40 PM Michael Paquier wrote: > On Thu, Jul 13, 2023 at 02:26:42PM +0900, Michael Paquier wrote: > > On Thu, Jul 13, 2023 at 09:35:17AM +0530, Dilip Kumar wrote: > >> Or do we actually need to update all the tuple header information as > >> well in

Re: psql: Add role's membership options to the \du+ command

On 08.07.2023 20:07, Tom Lane wrote 3. Not sure about use of LEFT JOIN in the query. That will mean we get a row out even for roles that have no grants, which seems like clutter. The LEFT JOINs to r and g are fine, but I suggest changing the first join to a plain join. Hm. Can you explain

Re: add non-option reordering to in-tree getopt_long

At Thu, 13 Jul 2023 14:39:32 +0900, Michael Paquier wrote in > [04:56:07.404] pg_ctl: too many command-line arguments (first is "-D") Mmm. It checks, for example, for "pg_ctl initdb -D $tempdir/data -o -N". This version of getopt_long() returns -1 as soon as it meets the first non-option

Re: Add hint message for check_log_destination()

On Tue, Jul 11, 2023 at 10:24 AM Japin Li wrote: > > > On Mon, 10 Jul 2023 at 14:23, Masahiko Sawada wrote: > > On Mon, Jul 10, 2023 at 2:07 PM Kyotaro Horiguchi > > wrote: > >> > >> At Mon, 10 Jul 2023 09:04:42 +0800, Japin Li wrote in > >> > > >> > On Sat, 08 Jul 2023 at 12:48, Michael

Re: 'ERROR: attempted to update invisible tuple' from 'ALTER INDEX ... ATTACH PARTITION' on parent index

On Thu, Jul 13, 2023 at 02:26:42PM +0900, Michael Paquier wrote: > On Thu, Jul 13, 2023 at 09:35:17AM +0530, Dilip Kumar wrote: >> Or do we actually need to update all the tuple header information as >> well in RelationReloadIndexInfo() in order to fix that invariant so >> that it can be used for

Re: [PoC] Improve dead tuple storage for lazy vacuum

On Sat, Jul 8, 2023 at 11:54 AM John Naylor wrote: > > > On Fri, Jul 7, 2023 at 2:19 PM Masahiko Sawada wrote: > > > > On Wed, Jul 5, 2023 at 8:21 PM John Naylor > > wrote: > > > Well, it's going to be a bit of a mess until I can demonstrate it working > > > (and working well) with bitmap

Re: \di+ cannot show the same name indexes

Hi, On Thu, Jul 13, 2023 at 03:17:17PM +0800, フブキダイスキ wrote: > After I create the same name index on the heap table and the temporary > table, I can only get the temporary table's index by \di+. > > create table t1(c1 int); > create temp table t2(c1 int); > > create index idx1 on t1(c1); >

\di+ cannot show the same name indexes

Hi, After I create the same name index on the heap table and the temporary table, I can only get the temporary table's index by \di+. create table t1(c1 int); create temp table t2(c1 int); create index idx1 on t1(c1); \di+ List of relations Schema | Name | Type |

Re: Check lateral references within PHVs for memoize cache keys

On Sun, Jul 9, 2023 at 1:28 AM Tom Lane wrote: > Richard Guo writes: > > Rebase the patch on HEAD as cfbot reminds. > > This fix seems like a mess. The function that is in charge of filling > RelOptInfo.lateral_vars is extract_lateral_references; or at least > that was how it was done up to

Re: Consistent coding for the naming of LR workers

On 13.07.23 06:59, Peter Smith wrote: On Wed, Jul 12, 2023 at 9:35 PM Peter Eisentraut wrote: On 21.06.23 09:18, Alvaro Herrera wrote: That is a terrible pattern in relatively new code. Let's get rid of it entirely rather than continue to propagate it. So, I don't think it is fair to say

Re: CREATE INDEX CONCURRENTLY on partitioned index

Justin Pryzby писал 2023-07-13 05:27: On Mon, Mar 27, 2023 at 01:28:24PM +0300, Alexander Pyhalov wrote: Justin Pryzby писал 2023-03-26 17:51: > On Sun, Dec 04, 2022 at 01:09:35PM -0600, Justin Pryzby wrote: > > This currently handles partitions with a loop around the whole CIC > >