public inbox for [email protected]  
help / color / mirror / Atom feed
[PATCH v5 1/2] Let ALTER TABLE exec routines deal with the relation
4+ messages / 3 participants
[nested] [flat]

* [PATCH v5 1/2] Let ALTER TABLE exec routines deal with the relation
@ 2020-07-14 00:15 Alvaro Herrera <[email protected]>
  0 siblings, 0 replies; 4+ messages in thread

From: Alvaro Herrera @ 2020-07-14 00:15 UTC (permalink / raw)

This means that ATExecCmd relies on AlteredRelationInfo->rel instead of
keeping the relation as a local variable; this is useful if the
subcommand needs to modify the relation internally.  For example, a
subcommand that internally commits its transaction needs this.
---
 src/backend/commands/tablecmds.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 993da56d43..a8528a3423 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -156,6 +156,8 @@ typedef struct AlteredTableInfo
 	Oid			relid;			/* Relation to work on */
 	char		relkind;		/* Its relkind */
 	TupleDesc	oldDesc;		/* Pre-modification tuple descriptor */
+	/* Transiently set during Phase 2, normally set to NULL */
+	Relation	rel;
 	/* Information saved by Phase 1 for Phase 2: */
 	List	   *subcmds[AT_NUM_PASSES]; /* Lists of AlterTableCmd */
 	/* Information saved by Phases 1/2 for Phase 3: */
@@ -353,7 +355,7 @@ static void ATPrepCmd(List **wqueue, Relation rel, AlterTableCmd *cmd,
 					  AlterTableUtilityContext *context);
 static void ATRewriteCatalogs(List **wqueue, LOCKMODE lockmode,
 							  AlterTableUtilityContext *context);
-static void ATExecCmd(List **wqueue, AlteredTableInfo *tab, Relation rel,
+static void ATExecCmd(List **wqueue, AlteredTableInfo *tab,
 					  AlterTableCmd *cmd, LOCKMODE lockmode, int cur_pass,
 					  AlterTableUtilityContext *context);
 static AlterTableCmd *ATParseTransformCmd(List **wqueue, AlteredTableInfo *tab,
@@ -4405,7 +4407,6 @@ ATRewriteCatalogs(List **wqueue, LOCKMODE lockmode,
 		{
 			AlteredTableInfo *tab = (AlteredTableInfo *) lfirst(ltab);
 			List	   *subcmds = tab->subcmds[pass];
-			Relation	rel;
 			ListCell   *lcmd;
 
 			if (subcmds == NIL)
@@ -4414,10 +4415,10 @@ ATRewriteCatalogs(List **wqueue, LOCKMODE lockmode,
 			/*
 			 * Appropriate lock was obtained by phase 1, needn't get it again
 			 */
-			rel = relation_open(tab->relid, NoLock);
+			tab->rel = relation_open(tab->relid, NoLock);
 
 			foreach(lcmd, subcmds)
-				ATExecCmd(wqueue, tab, rel,
+				ATExecCmd(wqueue, tab,
 						  castNode(AlterTableCmd, lfirst(lcmd)),
 						  lockmode, pass, context);
 
@@ -4429,7 +4430,11 @@ ATRewriteCatalogs(List **wqueue, LOCKMODE lockmode,
 			if (pass == AT_PASS_ALTER_TYPE)
 				ATPostAlterTypeCleanup(wqueue, tab, lockmode);
 
-			relation_close(rel, NoLock);
+			if (tab->rel)
+			{
+				relation_close(tab->rel, NoLock);
+				tab->rel = NULL;
+			}
 		}
 	}
 
@@ -4455,11 +4460,12 @@ ATRewriteCatalogs(List **wqueue, LOCKMODE lockmode,
  * ATExecCmd: dispatch a subcommand to appropriate execution routine
  */
 static void
-ATExecCmd(List **wqueue, AlteredTableInfo *tab, Relation rel,
+ATExecCmd(List **wqueue, AlteredTableInfo *tab,
 		  AlterTableCmd *cmd, LOCKMODE lockmode, int cur_pass,
 		  AlterTableUtilityContext *context)
 {
 	ObjectAddress address = InvalidObjectAddress;
+	Relation	rel = tab->rel;
 
 	switch (cmd->subtype)
 	{
@@ -5562,6 +5568,7 @@ ATGetQueueEntry(List **wqueue, Relation rel)
 	 */
 	tab = (AlteredTableInfo *) palloc0(sizeof(AlteredTableInfo));
 	tab->relid = relid;
+	tab->rel = NULL;			/* set later */
 	tab->relkind = rel->rd_rel->relkind;
 	tab->oldDesc = CreateTupleDescCopyConstr(RelationGetDescr(rel));
 	tab->newrelpersistence = RELPERSISTENCE_PERMANENT;
-- 
2.20.1


--/04w6evG8XlLl3ft
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
 filename="v5-0002-ALTER-TABLE-.-DETACH-CONCURRENTLY.patch"



^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: configure failures on chipmunk
@ 2024-08-21 06:29 Heikki Linnakangas <[email protected]>
  2024-08-26 04:00 ` Re: configure failures on chipmunk Alexander Lakhin <[email protected]>
  0 siblings, 1 reply; 4+ messages in thread

From: Heikki Linnakangas @ 2024-08-21 06:29 UTC (permalink / raw)
  To: Thomas Munro <[email protected]>; Alvaro Herrera <[email protected]>; +Cc: Heikki Linnakangas <[email protected]>; pgsql-hackers

On 21/08/2024 01:42, Thomas Munro wrote:
> On Wed, Aug 21, 2024 at 9:48 AM Alvaro Herrera <[email protected]> wrote:
>> Hi.  I noticed chipmunk is failing in configure:
>>
>> checking whether the C compiler works... no
>> configure: error: in `/home/pgbfarm/buildroot/HEAD/pgsql.build':
>> configure: error: C compiler cannot create executables
> 
> One of the runs shows:
> 
> ./configure: line 4202: 28268 Bus error               $CC -c $CFLAGS
> $CPPFLAGS conftest.$ac_ext 1>&5

Yeah, I've been slowly upgrading it to a new debian/raspbian version, 
and "ccache" started segfaulting, not sure why. I compiled ccache from 
sources, and now it seems to work when I run it on its own. Not sure why 
the buildfarm run still failed.

-- 
Heikki Linnakangas
Neon (https://neon.tech)







^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: configure failures on chipmunk
  2024-08-21 06:29 Re: configure failures on chipmunk Heikki Linnakangas <[email protected]>
@ 2024-08-26 04:00 ` Alexander Lakhin <[email protected]>
  2024-08-30 04:00   ` Re: configure failures on chipmunk Alexander Lakhin <[email protected]>
  0 siblings, 1 reply; 4+ messages in thread

From: Alexander Lakhin @ 2024-08-26 04:00 UTC (permalink / raw)
  To: Heikki Linnakangas <[email protected]>; +Cc: pgsql-hackers

Hello Heikki,

21.08.2024 09:29, Heikki Linnakangas wrote:
> Yeah, I've been slowly upgrading it to a new debian/raspbian version, and "ccache" started segfaulting, not sure why. 
> I compiled ccache from sources, and now it seems to work when I run it on its own. Not sure why the buildfarm run 
> still failed.
>

Could you also take a look at the kerberos setup on chipmunk? Now that
chipmunk goes beyond configure (on HEAD and REL_17_STABLE), it fails on the
kerberosCheck stage, with the following error:
Can't exec "/usr/sbin/kdb5_util": No such file or directory at 
/home/pgbfarm/buildroot/HEAD/pgsql.build/src/test/kerberos/../../../src/test/perl/PostgreSQL/Test/Utils.pm line 349.

Best regards,
Alexander






^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: configure failures on chipmunk
  2024-08-21 06:29 Re: configure failures on chipmunk Heikki Linnakangas <[email protected]>
  2024-08-26 04:00 ` Re: configure failures on chipmunk Alexander Lakhin <[email protected]>
@ 2024-08-30 04:00   ` Alexander Lakhin <[email protected]>
  0 siblings, 0 replies; 4+ messages in thread

From: Alexander Lakhin @ 2024-08-30 04:00 UTC (permalink / raw)
  To: Heikki Linnakangas <[email protected]>; +Cc: pgsql-hackers

Hello Heikki,

26.08.2024 07:00, Alexander Lakhin wrote:
> Could you also take a look at the kerberos setup on chipmunk? Now that
> chipmunk goes beyond configure (on HEAD and REL_17_STABLE), it fails on the
> kerberosCheck stage, ...

I see that chipmunk turned green.

Thank you for taking care of that!

Best regards,
Alexander






^ permalink  raw  reply  [nested|flat] 4+ messages in thread


end of thread, other threads:[~2024-08-30 04:00 UTC | newest]

Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-07-14 00:15 [PATCH v5 1/2] Let ALTER TABLE exec routines deal with the relation Alvaro Herrera <[email protected]>
2024-08-21 06:29 Re: configure failures on chipmunk Heikki Linnakangas <[email protected]>
2024-08-26 04:00 ` Re: configure failures on chipmunk Alexander Lakhin <[email protected]>
2024-08-30 04:00   ` Re: configure failures on chipmunk Alexander Lakhin <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox