On Saturday, June 10, 2017, Steven Grimm wrote:
> 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 statem
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 = psycopg2.conn
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 figur
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
6c243f90ab6904f27fa990f1f3261e1d09
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 f
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 Pos
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 f
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 ORD
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 is a pattern that th
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 answer. Since `update` has no `order by` clause
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 no way to do this with just the `update` sta
> 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, and that I should
u
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
was around the Java 5
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 reproduce it on my test
> d
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 thread
> 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 that was around the
Java 5
16 matches
Mail list logo