Gregory Stark wrote:
Hiroki Kataoka [EMAIL PROTECTED] writes:
I think there is no problem. Bloating will make pages including the
unnecessary area which will not be accessed. Soon, those pages will be
registered into DSM.
Except the whole point of the DSM is to let us vacuum those pages
3) To maintain crash recovery chance and reduce the amount of
archive log, removal of unnecessary full page writes from
archive logs is a good choice.
Definitely, yes. pg_compresslog could even move the full pages written
during backup out of WAL and put them in a different file that needs
Koichi, Andreas,
1) To deal with partial/inconsisitent write to the data file at crash
recovery, we need full page writes at the first modification to pages
after each checkpoint. It consumes much of WAL space.
We need to find a way around this someday. Other DBs don't do this; it may be
Josh Berkus [EMAIL PROTECTED] writes:
Well, as a PG hacker I find the name wal_fullpage_optimization quite
baffling and I think our general user base will find it even more so.
Now that I have Koichi's explanation of the problem, I vote for simply
slaving this to the PITR settings and not
The Apache runtime library, which is using a similar concept for
allocating heap-based memory out of a pool, has some since utility
functions, named apr_psprintf and apr_pstrdup.
These functions allocate a memory-block out of a pool and print a
formatted string into that block, or duplicate a
Jacob Rief wrote:
char *SPI_psprintf(const char *fmt, ...);
allocates a block of memory out of the memory pool and prints a
formatted string into it
Such matters are best solved using the StringInfo API.
SPI_pstrdup(const char *src);
allocates a block of memory out of the memory pool and
Jacob Rief [EMAIL PROTECTED] writes:
The Apache runtime library, which is using a similar concept for
allocating heap-based memory out of a pool, has some since utility
functions, named apr_psprintf and apr_pstrdup.
SPI_palloc might possibly be worth the trouble, but the other thing
is
