[ 
https://issues.apache.org/jira/browse/IMPALA-14307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18014075#comment-18014075
 ] 

ASF subversion and git services commented on IMPALA-14307:
----------------------------------------------------------

Commit a68f7164589b5d554d7f9a948badbc414e6b944e in impala's branch 
refs/heads/master from stiga-huang
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=a68f71645 ]

IMPALA-14307: Correctly update createEventId and DeleteEventLog in 
AlterTableRename

When EventProcessor is paused, e.g. due to a global INVALIDATE METADATA
operation, in alterTableOrViewRename() we don't fetch the event id of
the ALTER_TABLE event. This causes the createEventId of the new table
being -1 and the DeleteEventLog entry of the old table is missing. So
stale ALTER_TABLE RENAME events could incorrectly remove the new table
or add the old table.

The other case is in the fallback invalidation added in IMPALA-13989
that handles rename failure inside catalog (but succeeds in HMS). The
createEventId is also set as -1.

This patch fixes these by always setting a correct/meaningful
createEventId. When fetching the ALTER_TABLE event fails, we try to use
the event id before the HMS operation. It could be a little bit stale
but much better than -1.

Modified CatalogServiceCatalog#isEventProcessingActive() to just check
if event processing is enabled and renamed it to
isEventProcessingEnabled(). Note that this method is only used in DDLs
that check their self events. We should allow these checks even when
EventProcessor is not in the ACTIVE state. So when EventProcessor is
recovered, fields like createEventId in tables are still correct.

Removed the code of tracking in-flight events at the end of rename since
the new table is in unloaded state and only the createEventId is useful.
The catalog version used is also incorrect since it's not used in
CatalogServiceCatalog#renameTable() so it doesn't make sence to use it.
Removed the InProgressTableModification parameter of
alterTableOrViewRename() since it's not used anymore.

This patch also fixes a bug in getRenamedTableFromEvents() that it
always returns the first event id in the list. It should use the rename
event it finds.

Tests
 - Added e2e test and ran it 40 times.

Change-Id: Ie7c305e5aaafc8bbdb85830978182394619fad08
Reviewed-on: http://gerrit.cloudera.org:8080/23291
Reviewed-by: Riza Suminto <[email protected]>
Reviewed-by: Michael Smith <[email protected]>
Tested-by: Impala Public Jenkins <[email protected]>


> AlterTableRename not setting createEventId and DeleteEventLog correctly
> -----------------------------------------------------------------------
>
>                 Key: IMPALA-14307
>                 URL: https://issues.apache.org/jira/browse/IMPALA-14307
>             Project: IMPALA
>          Issue Type: Bug
>          Components: Catalog
>            Reporter: Quanlong Huang
>            Assignee: Quanlong Huang
>            Priority: Critical
>         Attachments: 
> catalogd.impala-ec2-rhel88-m7g-4xlarge-ondemand-1d9e.vpc.cloudera.com.jenkins.log.INFO.20250811-162241.3607803.gz,
>  
> impalad.impala-ec2-rhel88-m7g-4xlarge-ondemand-1d9e.vpc.cloudera.com.jenkins.log.INFO.20250811-162241.3607834.gz
>
>
> Saw a failure in TestConcurrentDdls.test_ddls_with_invalidate_metadata:
> {code:python}
> custom_cluster/test_concurrent_ddls.py:50: in 
> test_ddls_with_invalidate_metadata
>     self._run_ddls_with_invalidation(unique_database, sync_ddl=False)
> custom_cluster/test_concurrent_ddls.py:179: in _run_ddls_with_invalidation
>     worker[i].get(timeout=100)
> /data/jenkins/workspace/impala-asf-master-core-ubsan-arm/Impala-Toolchain/toolchain-packages-gcc10.4.0/python-2.7.16/lib/python2.7/multiprocessing/pool.py:572:
>  in get
>     raise self._value
> E   AssertionError: Query b148f272b5821772:ace4369900000000 failed:
> E     AnalysisException: Table does not exist: 
> test_ddls_with_invalidate_metadata_9525e717.test_6
> E     
> E     
> E   assert <bound method type.is_acceptable_error of <class 
> 'test_concurrent_ddls.TestConcurrentDdls'>>('Query 
> b148f272b5821772:ace4369900000000 failed:\nAnalysisException: Table does not 
> exist: test_ddls_with_invalidate_metadata_9525e717.test_6\n\n', False)
> E    +  where <bound method type.is_acceptable_error of <class 
> 'test_concurrent_ddls.TestConcurrentDdls'>> = 
> <test_concurrent_ddls.TestConcurrentDdls object at 
> 0xffff1ff7d810>.is_acceptable_error{code}
> The test runs in legacy catalog mode. Coordinator logs show that it receives 
> a deletion update on the table before analying the REFRESH statement on it:
> {noformat}
> I20250811 16:22:58.429529 3608823 ImpaladCatalog.java:227] Deleting: 
> TABLE:test_ddls_with_invalidate_metadata_9525e717.test_6 version: 8523 size: 
> 97
> ...
> I20250811 16:22:58.540377 3609121 Frontend.java:2398] 
> b148f272b5821772:ace4369900000000] Analyzing query: refresh 
> test_ddls_with_invalidate_metadata_9525e717.test_6 db: default
> ...
> I20250811 16:22:58.542122 3609121 jni-util.cc:321] 
> b148f272b5821772:ace4369900000000] 
> org.apache.impala.common.AnalysisException: Table does not exist: 
> test_ddls_with_invalidate_metadata_9525e717.test_6
>         at 
> org.apache.impala.analysis.ResetMetadataStmt.analyze(ResetMetadataStmt.java:173)
>         at 
> org.apache.impala.analysis.AnalysisContext$AnalysisDriverImpl.analyze(AnalysisContext.java:576)
>         at 
> org.apache.impala.analysis.AnalysisContext.analyzeAndAuthorize(AnalysisContext.java:496)
>         at 
> org.apache.impala.service.Frontend.doCreateExecRequest(Frontend.java:2938)
>         at 
> org.apache.impala.service.Frontend.getTExecRequest(Frontend.java:2505)
>         at 
> org.apache.impala.service.Frontend.getTExecRequestWithFallback(Frontend.java:2374)
>         at 
> org.apache.impala.service.Frontend.createExecRequest(Frontend.java:2063)
>         at 
> org.apache.impala.service.JniFrontend.createExecRequest(JniFrontend.java:176){noformat}
> Catalogd logs show that invalidateTable triggered by alterTableOrViewRename() 
> is running concurrently with a catalog reset (i.e. global INVALIDATE 
> METADATA):
> {noformat}
> I20250811 16:22:58.129398 3609170 JniUtil.java:167] 
> f548d67b72570890:626780e200000000] execDdl request: ALTER_TABLE 
> test_ddls_with_invalidate_metadata_9525e717.test_6_2 RENAME_TABLE issued by 
> jenkins
> I20250811 16:22:58.144670 3608935 JniUtil.java:167] 
> 1d4918bff853c0ec:c5646e4a00000000] resetMetadata request: INVALIDATE ALL 
> issued by jenkins
> I20250811 16:22:58.173722 3608935 CatalogServiceCatalog.java:2339] 
> 1d4918bff853c0ec:c5646e4a00000000] Loaded table list (12) and functions (0) 
> for database: test_ddls_with_invalidate_metadata_9525e717. Fetch duration: 2 
> ms.
> I20250811 16:22:58.177870 3609170 CatalogServiceCatalog.java:3283] 
> f548d67b72570890:626780e200000000] Invalidating table metadata: 
> test_ddls_with_invalidate_metadata_9525e717.test_6
> I20250811 16:22:58.178402 3608935 JniUtil.java:178] 
> 1d4918bff853c0ec:c5646e4a00000000] Finished resetMetadata request: INVALIDATE 
> ALL issued by jenkins. Time spent: 34ms
> I20250811 16:22:58.181602 3609170 Table.java:246] 
> f548d67b72570890:626780e200000000] createEventId_ for table: 
> test_ddls_with_invalidate_metadata_9525e717.test_6 set to: -1
> I20250811 16:22:58.181922 3609170 JniUtil.java:178] 
> f548d67b72570890:626780e200000000] Finished execDdl request: ALTER_TABLE 
> test_ddls_with_invalidate_metadata_9525e717.test_6_2 RENAME_TABLE issued by 
> jenkins. Time spent: 52ms
> {noformat}
> Then the catalog update collector thread saw the table disappears and sent 
> the deletion update:
> {noformat}
> I20250811 16:22:58.247798 3608258 JniUtil.java:167] getCatalogDelta request: 
> Getting catalog delta from version 8517
> I20250811 16:22:58.250062 3608258 catalog-server.cc:1615] Collected update: 
> 1:TABLE:test_ddls_with_invalidate_metadata_9525e717.test_6_2, version=8524, 
> original size=106, compressed size=105
> I20250811 16:22:58.250487 3608258 catalog-server.cc:1615] Collected deletion: 
> 1:TABLE:test_ddls_with_invalidate_metadata_9525e717.test_6, version=8523, 
> original size=97, compressed size=95
> I20250811 16:22:58.250890 3608258 catalog-server.cc:1615] Collected update: 
> 1:CATALOG_SERVICE_ID, version=8532, original size=60, compressed size=58
> I20250811 16:22:58.250959 3608258 JniUtil.java:178] Finished getCatalogDelta 
> request: Getting catalog delta from version 8517. Time spent: 3ms{noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to