Hello!
I'm sorry that I could not answer at once.
Meanwhile I investigated the matter of my problem, learned about SSI
(mostly at http://wiki.postgresql.org/wiki/Serializable) and
realized that we wouldn't need "serializable" transaction isolation
level anymore (thanks to SSI). So I just turned i
"Kevin Grittner" wrote:
> Andrew Alcheyev wrote:
>
>> Well, it does good and the backend hasn't crashed yet, but the
>> client is still experiencing query problems at some point (not
>> far, I guess, from where its backend would segfault without the
>> patch). This time it encounters the follow
Andrew Alcheyev wrote:
> Well, it does good and the backend hasn't crashed yet, but the
> client is still experiencing query problems at some point (not
> far, I guess, from where its backend would segfault without the
> patch). This time it encounters the following error from the
> backend:
>
Hello!
On Tuesday, January 10, 2012, 10:11:04 PM you wrote:
HL> That clearly looks like a bug in the SSI feature, introduced in
HL> PostgreSQL 9.1.
HL> This looks superficically similar to the bug that Dan Ports spotted on
HL> Friday:
HL> http://www.mail-archive.com/pgsql-hackers@postgresql.org
On 10.01.2012 17:22, Andrew Alcheyev wrote:
At some point the backend with this client crashes due to segmentation
fault with signal 11.
GDB shows the following:
#0 0x006b3a5b in SHMQueueDelete (queue=0x845b4c498) at shmqueue.c:77
77 prevElem->next = queue->next;
[New Threa
Hello everybody.
Today I have run into some strange situation, maybe a bug.
There is a client with variable
"default_transaction_isolation='serializable'" set in role properties
and it connects to Postgres via pgbouncer.
The problem appears after it executes several ten thousand queries, the
mos
