[MCOL-1323] cpimport Splitter has incorrect SIGPIPE mapping Created: 2018-04-04  Updated: 2020-08-25  Resolved: 2018-04-17

Status: Closed
Project: MariaDB ColumnStore
Component/s: cpimport
Affects Version/s: 1.0.12
Fix Version/s: 1.1.4

Type: Bug Priority: Major
Reporter: David Hall (Inactive) Assignee: Daniel Lee (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Sprint: 2018-07, 2018-08

 Description   

WESplitterApp::setupSignalHandlers() has an incorrect mapping of SIGPIPE to the SIGHUP handler. SIGPIPE is intended to be ignored and SIGHUP causes an immediate kill. The incorrect mapping causes SIGPIPE to incorrectly kill the process.



 Comments   
Comment by David Hall (Inactive) [ 2018-04-04 ]

This problem only arises if the UM is under extreme load and is slow to process the EOD responses. The PM's cpimport might have already closed the socket, causing a SIGPIPE that should be ignored.

By killing the process, the table lock is left on, which causes some consternation.

Test: I'm not sure how to force the UM to slow to the point this becomes an issue. Obviously a customer has succeeded in doing so.

Comment by Daniel Lee (Inactive) [ 2018-04-17 ]

Build verified: 1.1.4-1 source

/root/columnstore/mariadb-columnstore-server
commit 6b8a6745bd84b0230875fb94b526d9426ba999f7
Merge: 5199dd1 2089aad
Author: benthompson15 <ben.thompson@mariadb.com>
Date: Mon Apr 16 18:50:35 2018 -0500

Merge pull request #110 from mariadb-corporation/MCOL-1293

MCOL-1293

/root/columnstore/mariadb-columnstore-server/mariadb-columnstore-engine
commit 3e8fed91704effff5e442148916d1c3611dd38c4
Merge: 1586394 f2d748c
Author: benthompson15 <ben.thompson@mariadb.com>
Date: Mon Apr 16 18:50:05 2018 -0500

Merge pull request #447 from mariadb-corporation/MCOL-1293

MCOL-1293

Using the following steps:

1. start cpimport for 10g lineitem
2. kill -13 cpimport process

Reproduced the issue in 1.0.12-1. Cpimport aborted and left the lineitem tabled locked.

In 1.1.4-1, cpimport did not abort and kept going and finished.

Generated at Thu Feb 08 02:27:52 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.