Tom Lane schrieb:
Josh Berkus writes:
I've just been tweaking some autovac settings for a large database, and
came to wonder: why does vacuum_max_freeze_age default to such a high
number? What's the logic behind that?
(1) not destroying potentially useful forensic evidence too soon;
(2) ther
On Wed, Aug 12, 2009 at 5:57 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Yeah, I know, but feel like I'm being a bit naughty in using VACUUM
>> FREEZE -- the documentation says:
>
>> | Selects aggressive "freezing" of tuples. Specifying FREEZE is
>> | equivalent to performing VACUUM with the
"Kevin Grittner" writes:
> Yeah, I know, but feel like I'm being a bit naughty in using VACUUM
> FREEZE -- the documentation says:
> | Selects aggressive "freezing" of tuples. Specifying FREEZE is
> | equivalent to performing VACUUM with the vacuum_freeze_min_age
> | parameter set to zero. The F
Nickolay writes:
> BUT it seems that rarely this transaction is being delayed to apply and
> log entry is being inserted in wrong order:
> ID timestamp
> 1 2009-08-08 00:00:00.111
> 2 2009-08-08 00:00:30.311
> 3 2009-08-08 00:00:00.211
> Yep, that's right - sometimes for 30 seconds
Tom Lane wrote:
> Hmmm ... if you're using VACUUM FREEZE, its behavior is unaffected
> by this GUC anyway --- that option makes it use a freeze age of
> zero.
Yeah, I know, but feel like I'm being a bit naughty in using VACUUM
FREEZE -- the documentation says:
| Selects aggressive "freezing
Does anybody know any way to solve this? I did monitor the system
running at full load (~20 messages per second) - postmaster's processes
didn't eat more than 10-20% of CPU and memory. Neither did any of my
application's processes.
now() like current_timestamp is the time of transaction s
"Kevin Grittner" writes:
> Tom Lane wrote:
>> (2) there's not really much to be gained by reducing it.
> That depends. The backup techniques I recently posted, using hard
> links and rsync, saved us the expense of another ten or twenty TB of
> mirrored SAN archival storage space, and expensiv
Tom Lane wrote:
> (2) there's not really much to be gained by reducing it.
That depends. The backup techniques I recently posted, using hard
links and rsync, saved us the expense of another ten or twenty TB of
mirrored SAN archival storage space, and expensive WAN bandwidth
upgrades. In pil
Hello All,
I'm developing specialized message switching system and I've chosen to
use PostgreSQL as general tool to handle transactions, store and manage
all the data.
This system has pretty strong timing requirements. For example, it must
process not less than 10 messages per second. FYI: mes
