Re: [GENERAL] Inconsistent performance with LIKE and bind variable on long-lived connection

The problem doesn't appear to be specific to the JDBC driver. Tried a quick version of this in Python for grins with a database that was already populated by the Java code (sadly, the psycopg2 library doesn't directly support prepared statements): import psycopg2 import time conn =

[GENERAL] Removing null bytes from a json column

Does anyone have some tips on how to deal with an existing json type column that has some null bytes ( \u) in it? It seems like anything I do that touches any row with a null byte just errors. I'd love to just remove them if I could find some way to find them, but I'm having trouble even

Re: [GENERAL] ERROR: unexpected chunk number 0 (expected 1) for toast value 76753264 in pg_toast_10920100

ADSJ (Adam Sjøgren) wrote: > Our database has started reporting errors like this: > > 2017-05-31 13:48:10 CEST ERROR: unexpected chunk number 0 (expected 1) for > toast value 14242189 in pg_toast_10919630 Does the problem still reproduce if you revert commit

Re: [GENERAL] ERROR: unexpected chunk number 0 (expected 1) for toast value 76753264 in pg_toast_10920100

Hi, Please find the jar attached (renamed with a .txt extension as I know some email services deem jars a security issue). The jar accepts the following arguments: $1 = host $2 = database $3 = username $4 = password $5 = port It returns its logging to STDOUT. Please let me know if you require

[GENERAL] Is there a way to verify a signed digest within Postgres?

The following command was run and the content of content_file, signature_file and id_rsa.pub (or pem) are inserted into a Postgres database. openssl dgst -sign id_rsa content_file > signature_file Is there any way to verify that the signature corresponds with the content/public key within

Re: [GENERAL] ERROR: unexpected chunk number 0 (expected 1) for toast value 76753264 in pg_toast_10920100

Hi, Please find the jar attached (renamed with a .txt extension as I know some email services deem jars a security issue). The jar accepts the following arguments: $1 = host $2 = database $3 = username $4 = password $5 = port It returns its logging to STDOUT. Please let me know if you require

Re: [GENERAL] Deadlock with single update statement?

Justin Pryzby wrote: > detail|Process 26871 waits for ShareLock on transaction 13693505; blocked by > process 26646. > Process 26646 waits for ShareLock on transaction 13693504; blocked by process > 26871. > Process 26871: SELECT db_column_name,table_name FROM > huawei_m2000_counter_details

Re: [GENERAL] Inconsistent performance with LIKE and bind variable on long-lived connection

Hi On Sat, 2017-06-10 at 09:17 -0700, Steven Grimm wrote: > On Sat, Jun 10, 2017 at 1:46 AM, Alban Hertroys > wrote: > > I notice that you're declaring your ResultSet variable inside the > loop, which means that you create and destroy it frequently. I've > been told that this

Re: [GENERAL] Deadlock with single update statement?

On Sat, Jun 10, 2017 at 03:16:26PM -0400, Tom Lane wrote: > Rob Nikander writes: > >> On Jun 10, 2017, at 10:34 AM, Tom Lane wrote: > >> […] but it'd be better to adjust the query to ensure a deterministic > >> update order. > > > Thank you for the

Re: [GENERAL] Deadlock with single update statement?

Rob Nikander writes: >> On Jun 10, 2017, at 10:34 AM, Tom Lane wrote: >> […] but it'd be better to adjust the query to ensure a deterministic >> update order. > Thank you for the answer. Since `update` has no `order by` clause, I’m > guessing there’s

Re: [GENERAL] Deadlock with single update statement?

> On Jun 10, 2017, at 10:34 AM, Tom Lane wrote: > […] but it'd be better to adjust the query to ensure a deterministic > update order. Thank you for the answer. Since `update` has no `order by` clause, I’m guessing there’s no way to do this with just the `update` statement,

Re: [GENERAL] Inconsistent performance with LIKE and bind variable on long-lived connection

On Sat, Jun 10, 2017 at 1:46 AM, Alban Hertroys wrote: > I notice that you're declaring your ResultSet variable inside the loop, which means that you create and destroy it frequently. I've been told that this is a pattern that the GC has trouble keeping up with (although that

Re: [GENERAL] Deadlock with single update statement?

Rob Nikander writes: > I’m trying to track down a deadlock happening in a live app. I’m wondering > about statements like this, which select more than one row to update: > update t set num = 1 where name = ‘foo’; > It appears to be causing a deadlock, but I can’t

[GENERAL] Deadlock with single update statement?

Hi, I’m trying to track down a deadlock happening in a live app. I’m wondering about statements like this, which select more than one row to update: update t set num = 1 where name = ‘foo’; It appears to be causing a deadlock, but I can’t reproduce it on my test database. Could two

Re: [GENERAL] Inconsistent performance with LIKE and bind variable on long-lived connection

> On 10 Jun 2017, at 5:37, Steven Grimm wrote: […] I notice that you're declaring your ResultSet variable inside the loop, which means that you create and destroy it frequently. I've been told that this is a pattern that the GC has trouble keeping up with (although