On Mon, Aug 16, 2010 at 2:47 PM, Peter Koczan wrote:
> On Mon, Aug 16, 2010 at 1:34 PM, Scott Marlowe
> wrote:
>> If autovac is properly configured, very few, if any, PostgreSQL
>> databases need routine vacuuming jobs. However, other than sleep
>> states making it run slower, autovacuum is no
On Mon, Aug 16, 2010 at 3:01 PM, Tom Lane wrote:
> Greg Smith writes:
>> Tom Lane wrote:
>>> On versions where autovacuum is on by default, I would certainly
>>> recommend trying to use only autovacuum. cron-driven vacuum still
>>> has some uses but they are corner cases.
>
>> Corner cases impli
On Mon, Aug 16, 2010 at 1:34 PM, Scott Marlowe wrote:
> If autovac is properly configured, very few, if any, PostgreSQL
> databases need routine vacuuming jobs. However, other than sleep
> states making it run slower, autovacuum is no different than a regular
> old vacuum. Are you sure this wasn
On Mon, Aug 16, 2010 at 4:01 PM, Tom Lane wrote:
> Greg Smith writes:
>> The other alternative here is to just tune autovacuum so it runs really
>> slowly, so it won't kill responsiveness during any peak period. While
>> in theory that's the right thing to do, this is much harder to get
>> worki
Greg Smith writes:
> Tom Lane wrote:
>> On versions where autovacuum is on by default, I would certainly
>> recommend trying to use only autovacuum. cron-driven vacuum still
>> has some uses but they are corner cases.
> Corner cases implies something a bit more rare than I'd consider the
> case
Tom Lane wrote:
On versions where autovacuum is on by default, I would certainly
recommend trying to use only autovacuum. cron-driven vacuum still
has some uses but they are corner cases.
Corner cases implies something a bit more rare than I'd consider the
case here. Consider a server whe
Peter Koczan writes:
> The issue was that a routine VACUUM process (vacuumdb -az, called
> nightly via cron) was locking a table and wasn't completing. This
> server is also running autovacuum. This wasn't the source of the
> deadlock, but I'm wondering if regular vacuuming is necessary or even
>
On Mon, Aug 16, 2010 at 12:08 PM, Peter Koczan wrote:
> Hi all,
>
> I have an database server that is experiencing some lock contention
> and deadlock. It's infrequent, maybe once every two months, but
> time-consuming to deal with.
>
> The issue was that a routine VACUUM process (vacuumdb -az, ca
Hi all,
I have an database server that is experiencing some lock contention
and deadlock. It's infrequent, maybe once every two months, but
time-consuming to deal with.
The issue was that a routine VACUUM process (vacuumdb -az, called
nightly via cron) was locking a table and wasn't completing. T
"Josi Perez (3T Systems)" wrote:
> Without considering the errors, the transaction should not start
> after the AFTER INSERT?
Anything happening in a trigger is always part of the same database
transaction as the database action which fired the trigger.
-Kevin
--
Sent via pgsql-admin maili
Thank you for your answer.
Without considering the errors, the transaction should not start after the
AFTER INSERT?
Josi Perez
2010/8/12 Tom Lane
> "Josi Perez (3T Systems)" writes:
> > If I write a trigger AFTER INSERT and I have one error in this trigger,
> the
> > record (that I think was a
Edoardo Innocenti writes:
> I got the following error during a select query.
What was the query, what does EXPLAIN show as the plan for it,
and which PG version is your server exactly?
> MessageContext: 2042626048 total in 256 blocks; 16072 free (7
> chunks); 2042609976 used
This looks like i
Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelben
13 matches
Mail list logo
