Ahoi
I'm developing an auditing mechanism where table contents are logged as JSON (github.com/fxku/audit).
At first I just logged the whole row everytime my triggers were fired.
Now I'm trying to log only the old state of values that have changed.
Therefore I compare the OLD and NEW entry
Hi,
we have a problem since we migrate from 8.4 to 9.1
when we play : ANALYSE VERBOSE; ( stat on all databases, with 500 tables
and 1to DATA in all tables)
we now have this message :
org.postgresql.util.PSQLException: ERROR: out of shared memory Indice
: You might need to increase max_lock
On Mon, May 12, 2014 at 7:57 AM, Souquieres Adam
wrote:
> Hi,
>
> we have a problem since we migrate from 8.4 to 9.1
>
> when we play : ANALYSE VERBOSE; ( stat on all databases, with 500 tables and
> 1to DATA in all tables)
>
> we now have this message :
>
> org.postgresql.util.PSQLException: ERR
Merlin Moncure writes:
> On Mon, May 12, 2014 at 7:57 AM, Souquieres Adam
> wrote:
>> when we play : ANALYSE VERBOSE; ( stat on all databases, with 500 tables and
>> 1to DATA in all tables)
>> we now have this message :
>> org.postgresql.util.PSQLException: ERROR: out of shared memory Indice : Yo
Hi,
thanks you both for your quick answers,
Le 12/05/2014 15:29, Tom Lane a écrit :
Merlin Moncure writes:
On Mon, May 12, 2014 at 7:57 AM, Souquieres Adam
wrote:
when we play : ANALYSE VERBOSE; ( stat on all databases, with 500 tables and
1to DATA in all tables)
we now have this message
Souquieres Adam writes:
> ANALYSE VERBOSE; should use only one transaction or one transaction per
> table it analyse ?
ANALYZE is just a simple statement: it doesn't start or stop any
transactions. So all the locks will be acquired in the calling
transaction.
You might be better off using VACU
When i relaunch my ANALYSE VERBOSE, pg_locks table grows quickly from 20
lines to more than 1000 lines and still growing, all the lines are owned
by the same "virtual transaction" and the same "pid".
max locks is 128, so i don't understand what happening,
When i finish to write this email, i j
Hi
Related to this post: http://dba.stackexchange.com/q/50693/1396
Would it be a major change to allow the `returning` clause of `insert` to
return values that are *not* inserted? It seems you can already do so for
literals (and perhaps that should be made explicit in the docs here:
http://
I just hit the 20k locks in pg_locks, on 18k differents relations owned
by the same virtual transaction and PID.
I only have like 500 tables and like 2k indexes, i must miss something.
Le 12/05/2014 15:42, Tom Lane a écrit :
Souquieres Adam writes:
ANALYSE VERBOSE; should use only one trans
Souquieres Adam writes:
> When i relaunch my ANALYSE VERBOSE, pg_locks table grows quickly from 20
> lines to more than 1000 lines and still growing, all the lines are owned
> by the same "virtual transaction" and the same "pid".
Hm. I experimented a bit and looked at the code, and I find I wa
Le 12/05/2014 16:24, Tom Lane a écrit :
Souquieres Adam writes:
When i relaunch my ANALYSE VERBOSE, pg_locks table grows quickly from 20
lines to more than 1000 lines and still growing, all the lines are owned
by the same "virtual transaction" and the same "pid".
Hm. I experimented a bit and
Souquieres Adam wrote:
> The solution must be to define a *better strategy for tables
> statistics*... we dont really need stats on all the tables because
> the most part of them is static...
Tune autovacuum so that it does the analyses for you?
--
Álvaro Herrerahttp://www.2ndQu
Alvaro Herrera-9 wrote
> Souquieres Adam wrote:
>
>> The solution must be to define a *better strategy for tables
>> statistics*... we dont really need stats on all the tables because
>> the most part of them is static...
>
> Tune autovacuum so that it does the analyses for you?
And for those fe
Hi all.
Right now synchronous replication in postgresql chooses one replica as
synchronous and waits for replies from it (with synchronous_commit = on |
remote_write) until this replica host does not disconnect from master.
Are there any plans to implement something like semi synchronous replic
On Friday 09 May 2014 16:53:49 Adrian Klaver wrote:
> On 05/09/2014 08:04 AM, Vincent de Phily wrote:
> > Thanks to all for taking an interest so far, this bug is... weird.
>
> Yes weird. I tried to replicate your query to see if I could see
> anything similar. Tried it on 9.0.17 and 9.3.4 and cou
Did you try rewriting the query to avoid using an IN expression?
UPDATE foo SET processing = 't'
FROM (
SELECT id FROM foo WHERE processing = 'f' ORDER BY id ASC LIMIT 5000 FOR
UPDATE
) src
WHERE foo.id = src.id;
The workaround I mentioned above said that a CTE was needed but I'm thinking
that a
On 05/12/2014 09:42 AM, Borodin Vladimir wrote:
Hi all.
Right now synchronous replication in postgresql chooses one replica as
synchronous and waits for replies from it (with synchronous_commit = on
| remote_write) until this replica host does not disconnect from master.
Are there any plans to
Hi,
I have log data of the following format:
SessionTimestampEventParameters1 1
Started Session 1 2Logged In
Username:"user1"2 3Started Session1 3
Started Challengetitle:"Challenge 1
18 matches
Mail list logo
