# Pgsql invalid column\_length

**URL:** <https://discuss.elastic.co/t/pgsql-invalid-column-length/48624>\
**Category:** Beats\
**Tags:** packetbeat\
**Created:** [April 28, 2016, 4:59am UTC](https://discuss.elastic.co/t/pgsql-invalid-column-length/48624 "2016-04-28T04:59:45Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![ceekay](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ceekay/32/5687_2.png) [@ceekay](https://discuss.elastic.co/u/ceekay)\
**Post date:** [April 28, 2016, 4:59am UTC](https://discuss.elastic.co/t/pgsql-invalid-column-length/48624/1 "2016-04-28T04:59:45Z")

</div>

Hi there,

I'm running Packetbeat 5.0.0~alpha1, and getting a lot of entries like the following in syslog:

> Apr 28 16:04:08 cat-pg92 /usr/bin/packetbeat[30951]: parse.go:531: Pgsql invalid column\_length=4294967295, buffer\_length=234, i=5  
> Apr 28 16:04:08 cat-pg92 /usr/bin/packetbeat[30951]: parse.go:531: Pgsql invalid column\_length=4294967295, buffer\_length=558, i=11

I can't find any reference to this message online, other than in the source on github. I'm not sure if this is an issue with Postgres or Packetbeat. This is a new error since upgrading Packetbeat from 1.1.2, however the previous version was giving me "Slice bounds out of range" errors as per [this thread](https://discuss.elastic.co/t/slice-bounds-out-of-range/39049).

Config is as follows:

```
interfaces:
  device: any
protocols:
  pgsql:
    ports: [5432]
output:
  logstash:
    hosts: ["ingress1:10514", "ingress2:10514"]
    tls:
      certificate_authorities: ["/etc/ssl/certs/beats-ca.pem"]
      insecure: false

```

System is Ubuntu 12.04.5  
Packetbeat 5.0.0~alpha1  
Postgres 9.2.15-1.pgdg12.4+1

---

<div class="post-metadata">

**Author:** ![steffens](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/steffens/32/79630_2.png) [@steffens](https://discuss.elastic.co/u/steffens)\
**Post date:** [April 28, 2016, 3:04pm UTC](https://discuss.elastic.co/t/pgsql-invalid-column-length/48624/2 "2016-04-28T15:04:22Z")

</div>

the parser has been hardened not to generate the 'Slice bounds out of range' panic. You're likely experiencing packet loss? On packet-loss (or on startup), the parser/analyzer must try to 'sync' with the TCP stream. It will fail parsing until it manages to find a valid pgsql messages indicating parser to be in sync with actual TCP stream. Problem with packet loss is, the parser is out of sync again and must resync.

---

<div class="post-metadata">

**Author:** ![ceekay](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ceekay/32/5687_2.png) [@ceekay](https://discuss.elastic.co/u/ceekay)\
**Post date:** [May 2, 2016, 11:19pm UTC](https://discuss.elastic.co/t/pgsql-invalid-column-length/48624/3 "2016-05-02T23:19:54Z")

</div>

Hi @steffens, I'm assuming this packet loss at the client end. It's pretty unlikely the issue is with the server, and our monitoring shows nothing. Is there anything I can do with packetbeat to identify the actual cause here?

I sent you a trace file back in January to help with investigating the "slice bounds out of range issue", and this is the same PGSQL server from that issue. Do you know if the issue identified there was also packet loss?

---

<div class="post-metadata">

**Author:** ![steffens](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/steffens/32/79630_2.png) [@steffens](https://discuss.elastic.co/u/steffens)\
**Post date:** [May 3, 2016, 11:24am UTC](https://discuss.elastic.co/t/pgsql-invalid-column-length/48624/4 "2016-05-03T11:24:46Z")

</div>

yes, the stack trace was due to packetloss. packetbeat is a passive network sniffer bypassing some of the network stack. Even if your servers do not experience packet loss, packetbeat still might not see all packets.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 5, 2017, 9:52pm UTC](https://discuss.elastic.co/t/pgsql-invalid-column-length/48624/5 "2017-07-05T21:52:30Z")

</div>