For anyone that's still following - we tried upgrading to postgres 9.3.3 -
that hasn't helped.
Running an strace on the pid that was consuming the highest CPU at the
time of the outage shows:
semop(91521110, {{12, -1, 0}}, 1) = 0
semop(91521110, {{12, -1, 0}}, 1) = 0
semop(91521110, {
Hi all,
I'm running PostgreSQL 9.1 on a fairly beefy server with a lot of RAM,
so I generally want work_mem set pretty high. One of my tables has a
GIN index, and, as a consequence of the high work_mem setting, its
fastupdate pending list can grow very large. This leads to the
occasional IN
On 3/14/2014 6:08 AM, Antman, Jason (CMG-Atlanta) wrote:
I'm not a "high level committer", nor am I even a regular poster to this
list.
not saying this post is true, but... If I'm reading between the lines
correctly, this could make for quite a striking headline in the tech
news - "NSA dumps Ora
Thanks Tom.
The database had been up for 6 months now with no problems at all so,
according to your comment, it was a change that became current when the
server was rebooted. I need someone to help me out with the server rules
to find out what's wrong (or different) with that.
Regarding the ser
Ignacio Colmenero writes:
> Yesterday, the database server was rebooted and database wasn't shut
> down properly.
> When it went back online, the following messages showed up:
> 2014-03-13 08:46:08 UTC LOG: 08006: test message did not get through
> on socket for statistics collector
The only
Hi Guys.
Yesterday, the database server was rebooted and database wasn't shut
down properly.
When it went back online, the following messages showed up:
2014-03-13 08:46:08 UTC LOG: 08006: test message did not get through
on socket for statistics collector
2014-03-13 08:46:08 UTC LOCATION
Turns out that it was a JBoss problem. I had to remove the driver jar from
the deployed EAR file and set a dependency to the module in the JBoss
server.
This link has the details: https://community.jboss.org/message/862434
Thanks for pointing me in the right direction.
On Wed, Mar 12, 2014 at 1
I am terribly sorry. I was sinked in this for about 2 days and just a
few minutes after i posted this a was told by a 3rd person that I am
using datbase postgres instead of eb3_nz to searched for pending OID in
pg_rewrite. So the common delete from pg_rewrite where oid = 1001837 worked.
Thanks a lo
HI all,
I’ve had an interesting problem trying to perform an UPDATE based on the
results of processing an xpath against a field of type xml.
Specifically, my query would fail with:
> ERROR: could not parse XML document
> DETAIL: line 1: Start tag expected, '<' not found
I thought this strange
David Welton writes:
> We tracked down the commit that introduced the automatically generated
> prepared statement names:
> https://github.com/epgsql/epgsql/commit/dabf972f74735d2
> The author wrote "Usage of unnamed prepared statement and portals
> leads to unpredictable results in case of conc
On 03/14/2014 06:56 AM, Jakub Can wrote:
Hello, our database suddenly went broken somehow. We still dont know if
it is becouse of hw failure etc., anyway, when I try to make dump using
pg_dump or pg_dumpall I have got error message like this:
pg_dump: failed sanity check, parent table OID 100183
Hello, our database suddenly went broken somehow. We still dont know if
it is becouse of hw failure etc., anyway, when I try to make dump using
pg_dump or pg_dumpall I have got error message like this:
pg_dump: failed sanity check, parent table OID 1001834 of pg_rewrite
entry OID 1001837 not found
De: pgsql-general-ow...@postgresql.org [pgsql-general-ow...@postgresql.org] en
nombre de Susan Cassidy [susan.cass...@decisionsciencescorp.com]
Enviado: jueves, 13 de marzo de 2014 02:48 p.m.
Para: Rodrigo Gonzalez
CC: Steve Atkins; pgsql-general@postgresql.org
Asunto: Re: [GENERAL] puzzling perl
Markus,
thanks for your reply.
> The pipelined top-n query has two very important properties:
> (1) it utilizes the index order to avoid the sort operation required to
> satisfy ORDER BY clause
> (2) it realizes that it can stop processing as soon as it has delivered
> enough rows.
>
> The e
2014-03-14 13:02 GMT+01:00 Markus Winand :
> Hi!
>
> I'd like to clarify this as the original author of the page in question.
>
> Fist of all, I also recommend the row-value syntax as you can see on the
> "previous" page:
> http://use-the-index-luke.com/sql/partial-results/fetch-next-page
>
> I've
Hi!
I'd like to clarify this as the original author of the page in question.
Fist of all, I also recommend the row-value syntax as you can see on the
"previous" page:
http://use-the-index-luke.com/sql/partial-results/fetch-next-page
I've also explained this procedure at conferences. Here are th
I'm not a "high level committer", nor am I even a regular poster to this
list.
not saying this post is true, but... If I'm reading between the lines
correctly, this could make for quite a striking headline in the tech
news - "NSA dumps Oracle proprietary database in favor of PostgreSQL."
I'd v
Hi,
On Thu, Mar 13, 2014 at 1:51 AM, Tom Lane wrote:
> David Welton writes:
>>> send(State, ?BIND, ["", 0, StatementName, 0, Bin1, Bin2]),
>>> send(State, ?EXECUTE, ["", 0, <<0:?int32>>]),
>>> send(State, ?CLOSE, [?PREPARED_STATEMENT, StatementName, 0]),
>>> send(State, ?SYNC, []),
>
>> And then
18 matches
Mail list logo
