# ISSUE: Inserting to a table hangs and brings down the node

**URL:** <https://forum.yugabyte.com/t/issue-inserting-to-a-table-hangs-and-brings-down-the-node/571>\
**Category:** General\
**Created:** [December 2, 2019, 6:53pm UTC](https://forum.yugabyte.com/t/issue-inserting-to-a-table-hangs-and-brings-down-the-node/571 "2019-12-02T18:53:16Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Rahul\_Patel](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/rahul_patel/32/174_2.png) [@Rahul\_Patel](https://forum.yugabyte.com/u/Rahul_Patel)\
**Post date:** [December 2, 2019, 6:53pm UTC](https://forum.yugabyte.com/t/issue-inserting-to-a-table-hangs-and-brings-down-the-node/571/1 "2019-12-02T18:53:16Z")

</div>

Hi I have 3 node yugabyte cluster on AWS with i3.4xlarge instance type and replication factor of 3.  
I have been trying to do simple copy with a csv file but it hangs every time and I am not sure what I am doing wrong.

The csv is 6.6 GB in size and has 58566067 count of rows.

Also there is no errors logs but the COPY command did exit unexpectedly with error:

```auto
You are now connected to database "pdns" as user "yugabyte".
ysqlsh:copy.sql:2: WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and repeat your command.
ysqlsh:copy.sql:2: server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.

```

I retried but no luck and I know the writes are not happening because I went to the UI and write ops/sec is staying at 0. If anyone could help that would be great. Thanks

---

<div class="post-metadata">

**Author:** ![neha](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/neha/32/231_2.png) [@neha](https://forum.yugabyte.com/u/neha)\
**Post date:** [December 2, 2019, 7:26pm UTC](https://forum.yugabyte.com/t/issue-inserting-to-a-table-hangs-and-brings-down-the-node/571/2 "2019-12-02T19:26:39Z")

</div>

Hi @Rahul_Patel,

Since the COPY command is transactional, it tries to import all 58M rows in 1 large transaction and that’s leading to the issue that you’re seeing. This is something that we are actively looking to fix in 2.1 release:

> <https://github.com/yugabyte/yugabyte-db/issues/1906>
>
> After inserting 1M rows using a single distributed transaction (e.g. YSQL COPY) …it was observed that the IntentsDB and RegularDB memtables were much larger than the configured memstore size limit. The memstore size limit was 128MB, but the IntentsDB memtable was 793MB and the RegularDB memtable was 477MB. 
> 
> The issue has two causes:
> 1. Intents are applied in a single rocksdb write batch, meaning the memtable can grow as large as the size of the write batch which could exceed the memstore size limit. The fix for this will be to batch the regular record writes when intents are applied, and similarly to batch the deletion of the intents on distributed txn cleanup.
> 1. Memtables are only checked for whether they exceed the memstore size limit (forcing a flush) before a write is performed, meaning if a large single write is processed it could leave the memtables larger than the configured maximum memstore size until another write on the rocksdb is processed. The fix for this will be to move this check until after the write is performed, to ensure it is flushed if the current write exceeded the memstore size limit.

> <https://github.com/yugabyte/yugabyte-db/issues/2855>
>
> Today for improving COPY performance, we have a non-txn-copy gflag that can be u…sed to run copy in non transactional mode. However, this does not take effect if table requires transactions (for example, if table has an index).
> 
> We should add a copy\_txn\_batch\_size option to improve COPY performance for such transactional tables. This will reduce the batch size for transactions instead of loading all the data in a single large transaction.

In the meantime, there are 2 options to work around this issue:

1. If your schema does not have any indexes, then you can restart yb-tserver with gflag `ysql_non_txn_copy=true` and import the schema using `COPY`.

2. If your schema has secondary indexes, then the above non-transactional copy won’t work. So, in this case, you can use multiple insert statements instead of using `COPY` for loading the data. How did you create the csv file? If you have this data in another postgres cluster, then you can use `ysql_dump` to dump the DB contents into SQL statements and then import that into yugabyteDB.