From: | Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Vikaas BV <vikas(at)cellcloud(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Size of Postgres Transaction Logs |
Date: | 2001-05-19 03:27:58 |
Message-ID: | 3.0.5.32.20010519112758.00fcc290@192.228.128.13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
At 12:45 PM 5/18/01 -0400, Tom Lane wrote:
>
>The WAL log should be auto-truncated at checkpoints, assuming that the
>old entries are no longer needed. However, if you leave uncommitted
>transactions sitting around, their WAL entries can't be deleted until
>you commit or abort them. I'd only expect massive WAL growth if you
>have very long-running transactions ...
Uhoh.
Scenario 1:
Using FCGI, persistent DB connections and Perl DBI.
The problem I see is that the Perl DBI doesn't have a BEGIN transaction,
can only rollback or commit, which implicitly begins a new transaction.
So what happens typically is:
1) open DB connection.
2) wait for http request.
3) rollback (to implicitly begin a new transaction so that 'now' isn't
years ago :) ).
4) do DB stuff
5) rollback/commit.
Would we get massive WAL growth if the long running transactions are
inactive (stuck at step 2) - not doing anything, but other transactions are
active?
Scenario 2:
search/query engine - only selects are done, so db connection and
transaction held open for long periods. Lots of selects being done.
Any issues with this?
Cheerio,
Link.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-05-19 03:37:51 | Re: Size of Postgres Transaction Logs |
Previous Message | Andrew Snow | 2001-05-19 03:25:46 | RE: Inserts using plpgsql - Further |