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

Alvaro Herrera wrote: > 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

On 09/06/2017 19:02, Harry Ambrose wrote: Hi, No error messages found. - is your RAM ECC? Did you run any memtest? Yes, memory is ECC. No error messages found. So I guess you run memtest86+ and it reported that your memory is indeed ECC and also that it is working properly? Best wishes,

Re: [GENERAL] pg_catalog tables don't have constraints?

> > Of course. My plan is to copy the catalogs into a new schema so I can add fk > constraints and then get something like navicat or datagrip to draw it. > Hi. I made some progress on this and I've added all the diagrams and documentation I've been able to produce so far for v10beta as well as th

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

On Sun, Jun 11, 2017 at 1:10 AM, Steven Grimm wrote: > (first five iterations) > > Index Only Scan using test_pkey on test (cost=0.29..476.29 rows= > width=4) (actual time=0.058..2.439 rows=1 loops=1) > Index Cond: (col1 = 'xyz'::text) > Filter: (col2 ~~ '%'::text) > Heap Fetches:

Re: [GENERAL] JSON to INT[] or other custom type

On Sun, Jun 11, 2017 at 2:35 PM, Rory Campbell-Lange < r...@campbell-lange.net> wrote: > I'm hoping, in the plpgsql function, to unfurl the supplied json into a > custom type or at least an array of ints, and I can't work out how to do > that. ​You will be unable to cast the array itself. You m

Re: [GENERAL] Unsubscription

chuma.of...@ww-cs.de wrote: > Dear Sir/Madam > > > > How would i unsubscribe the general post? I have removed you from pgsql-general. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-gener

Re: [GENERAL] JSON to INT[] or other custom type

On Sun, Jun 11, 2017 at 22:35:14 +0100, Rory Campbell-Lange wrote: I'm hoping, in the plpgsql function, to unfurl the supplied json into a custom type or at least an array of ints, and I can't work out how to do that. select * from json_array_elements_text('[[0, 1], [1, 2]]'); value

Re: [GENERAL] Huge Pages - setting the right value

Yes, those should always be disabled using tuned or other methods. Using tuned is described here (second method). I think the grub.conf method described is unique to RHEL/OEL/CENTOS. http://houseofbrick.com/disabling-transparent-hugepages-using-tuned/ On Sun, Jun 11, 2017 at 5:00 PM, Lucas Poss

Re: [GENERAL] Huge Pages - setting the right value

2017-06-12 9:52 GMT+12:00 Andrew Kerber : > Was that transparent hugepages or standard hugepages? databases commonly > have problems dealing with transparent hugepages. > > IN my case, it was the Transparent Hugepages Lucas

Re: [GENERAL] Huge Pages - setting the right value

Was that transparent hugepages or standard hugepages? databases commonly have problems dealing with transparent hugepages. On Sun, Jun 11, 2017 at 4:39 PM, Lucas Possamai wrote: > 2017-06-12 7:52 GMT+12:00 Andrew Kerber : > >> I am sure it does not. >> >> Sent from my iPhone >> >> > On Jun 11,

Re: [GENERAL] Huge Pages - setting the right value

2017-06-12 7:52 GMT+12:00 Andrew Kerber : > I am sure it does not. > > Sent from my iPhone > > > On Jun 11, 2017, at 10:50 AM, pinker wrote: > > > > Andrew Kerber wrote > >> I can't give you an absolutely authoritative answer, but because of the > >> way hugepages are implemented and allocated, I

[GENERAL] JSON to INT[] or other custom type

I'm playing with plpgsql function parameters to try and come up with a neat way of sending an array of arrays or array of custom types to postgres from python and PHP. Psycopg works fine with an array of custom types: In [108]: query = 'select * from fn_test03(%s, %s::dow_session[])' In

Re: [GENERAL] trying to program in PostgreSQL C a statistics function

Hi Andre, I've written some C statistics functions for Postgres before, here: https://github.com/pjungwir/aggs_for_arrays https://github.com/pjungwir/aggs_for_vecs They are all really simple, although they operate on arrays, so yours should be even simpler. The second link has aggregate functi

Re: [GENERAL] Limiting DB access by role after initial connection?

On Sun, Jun 11, 2017 at 12:15 PM, Bruno Wolff III wrote: > On Fri, Jun 09, 2017 at 21:14:15 -0700, > Ken Tanzer wrote: > >> On Fri, Jun 9, 2017 at 5:38 PM, Bruno Wolff III wrote: >> >> Seems to me they are separate issues. App currently has access to the >> password for accessing the DB. (T

[GENERAL] Unsubscription

Dear Sir/Madam How would i unsubscribe the general post? Chuma David Ofole W+W Consulting GmbH mob.: +49-152-1477 6857 mail.: chuma.of...@ww-cs.de

Re: [GENERAL] Huge Pages - setting the right value

I am sure it does not. Sent from my iPhone > On Jun 11, 2017, at 10:50 AM, pinker wrote: > > Andrew Kerber wrote >> I can't give you an absolutely authoritative answer, but because of the >> way hugepages are implemented and allocated, I can't think how they could >> be used for other processe

Re: [GENERAL] Limiting DB access by role after initial connection?

On Fri, Jun 09, 2017 at 21:14:15 -0700, Ken Tanzer wrote: On Fri, Jun 9, 2017 at 5:38 PM, Bruno Wolff III wrote: Seems to me they are separate issues. App currently has access to the password for accessing the DB. (Though I could change that to ident access and skip the password.) App 1)

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

2017-06-11 18:34 GMT+02:00 Steven Grimm : > On Sun, Jun 11, 2017 at 8:21 AM, Tom Lane wrote: > >> Yeah, I've been watching this thread and trying to figure out how to >> explain that part; I suspected a cause of this form but couldn't >> make that theory match the 9-iterations observation. (I st

[GENERAL] trying to program in PostgreSQL C a statistics function

SUMMARY -- I am trying to program in PostgreSQL a statistics function. My old method in SQL is here. select ( avg(measure) - 0.0 ) / nullif(stddev_pop(case when measure > 0.00 then 0.00 else measure end ),0) sortino_true from TABLE/VIEW; The logic is based on SORTINO RATIO: ARE YOU CALCULA

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

On Sun, Jun 11, 2017 at 8:21 AM, Tom Lane wrote: > Yeah, I've been watching this thread and trying to figure out how to > explain that part; I suspected a cause of this form but couldn't > make that theory match the 9-iterations observation. (I still can't.) > I walked through the Java code in

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

On 06/11/2017 08:34 AM, Tom Lane wrote: Alvaro Herrera writes: I'm unable to run this file. Maybe it was corrupted in transit, given that it was considered to be text. My copy came through fine, so I tried to forward it to you off-list, but gmail rejected it as a possible security hazard. D

Re: [GENERAL] Huge Pages - setting the right value

Andrew Kerber wrote > I can't give you an absolutely authoritative answer, but because of the > way hugepages are implemented and allocated, I can't think how they could > be used for other processes. Linux hugepages are either 2m or 1g, far too > large for any likely processes to require. They ca

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

I wrote: > Right. The plancache code is designed to switch to a generic plan if > that doesn't seem to save anything compared to a custom plan that's > built for the specific parameter value(s). Er, -ENOCAFFEINE. That's backwards of course. I think the rest of what I wrote is okay.

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

Alvaro Herrera writes: > I'm unable to run this file. Maybe it was corrupted in transit, given > that it was considered to be text. My copy came through fine, so I tried to forward it to you off-list, but gmail rejected it as a possible security hazard. Do you know which binary mime types they

Re: [GENERAL] Huge Pages - setting the right value

I can't give you an absolutely authoritative answer, but because of the way hugepages are implemented and allocated, I can't think how they could be used for other processes. Linux hugepages are either 2m or 1g, far too large for any likely processes to require. They cannot be allocated in part

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

Steven Grimm writes: > That seems to fit the behavior. Thanks; I wasn't aware of that feature of > prepared statements. I changed the Python code to do EXPLAIN ANALYZE > EXECUTE rather than EXECUTE, and I do indeed see a change in plan after the > fifth iteration: > (first five iterations) > Ind

Re: [GENERAL] Huge Pages - setting the right value

We are experiencing some performance issues because of high CPU load. So I would like to ask one more time. The exact question is: Does PostgreSQL can use huge pages for processes or only for shared buffers? (Does it make any sense to set the number of huge pages above the shared_buffers?) Any help

Re: [GENERAL] Removing null bytes from a json column

Timothy Garnett writes: > 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,

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

Harry Ambrose wrote: > 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 loggi

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

On Sat, Jun 10, 2017 at 11:10 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > https://www.postgresql.org/docs/current/static/sql-prepare.html > > Specifically, the notes section. That seems to fit the behavior. Thanks; I wasn't aware of that feature of prepared statements. I change