Hi Kevin,
When I check Idle session running question, shows the many queries running
but end of the query it shows Rollback and commit which take lot of time. I
am little scared bcoz I made changes in memory parameter first time in
postgres and getting this result, earlier I have not seen this. Is
I have set up a PG9.2 database slightly over 110 GB in size. In addition to
the master server, I have 2 servers running as active standby nodes.
When I run pg_basebackup to set up the standby servers, it completes in
about 60 minutes - which is okay for my needs. However, I also need to set
up anot
> Does "select * from pg_prepared_xacts" find anything?
Yes indeed, so I rollback our old prepared transactions.
I will check tomorrow, and I will let you know.
Best regards,
Baptiste.
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP S.A.S. - Technopole Izarbel - 64210 Bidart
Téléphone :
Baptiste LHOSTE writes:
>> As I said, because they are still visible to other transactions. Try to
>> see if you have long-lasting transactions.
> How can I do that ? I check running query in pg_stat_activity, but there is
> no query on that table.
Does "select * from pg_prepared_xacts" find an
I run a select on the pg_stat_all_tables and it returns that there is 0
n_dead_tup.
I am really confused.
Best regards,
Baptiste.
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP S.A.S. - Technopole Izarbel - 64210 Bidart
Téléphone : +33 (0) 5 59 41 51 10
www.alaloop.com
--
Sent via
>As I said, because they are still visible to other transactions. Try to
>see if you have long-lasting transactions.
How can I do that ? I check running query in pg_stat_activity, but there is no
query on that table.
Best regards,
Baptiste.
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP
On Mon, 2012-12-17 at 17:10 +0100, Baptiste LHOSTE wrote:
> > It could be dead rows, still visible for other transactions.
>
> Ok but in this case, why the automatic vacuum task of the autovacuum process
> does not delete theses dead rows ?
>
As I said, because they are still visible to other
> It could be dead rows, still visible for other transactions.
Ok but in this case, why the automatic vacuum task of the autovacuum process
does not delete theses dead rows ?
Best regards,
Baptiste
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP S.A.S. - Technopole Izarbel - 64210 Bidart
On Mon, 2012-12-17 at 16:57 +0100, Baptiste LHOSTE wrote:
> Hi everybody,
>
> I have trouble understanding some logs of postgreSQL.
>
> Here you can find a log from the auto-vacuum process :
>
> 2012-12-17 16:38:58 CET LOG: automatic vacuum of table
> "flows.public.agg_t344_outgoing_a41_src_ne
Hi everybody,
I have trouble understanding some logs of postgreSQL.
Here you can find a log from the auto-vacuum process :
2012-12-17 16:38:58 CET LOG: automatic vacuum of table
"flows.public.agg_t344_outgoing_a41_src_net_and_dst_net_f5": index scans: 0
pages: 0 removed, 59820 remain
Shams Khan wrote:
> Question 1. How do we correlate our memory with kernel parameters, I mean
> to say is there any connection between shared_buffer and kernel SHMMAX. For
> example if I define my shared buffer more than my current SHMMAX value, it
> would not allow me to use that ??or vice versa.
Can somebody help me this???
On Sat, Dec 15, 2012 at 12:53 AM, Shams Khan wrote:
> Hey Kevin,
>
> Thanks for such great help :
> I analyzed on query before changing parameters;
>
> explain select count(distinct a.subsno ) from subsexpired a where
> a.subsno not in (select b.subsno from subs b
Hello together,
last thursday I upgraded one of our 9.0.6 postgresql servers to 9.2.2
with pg_upgrade. So far everything seemed to work but we now discover
problems with the enum types. If we run one specific query it breaks all
time with such an error message:
ERROR: invalid internal value
13 matches
Mail list logo
