Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Sun, Jan 07, 2007 at 12:42:06AM -0500, Bruce Momjian wrote:
Joshua D. Drake wrote:
On Sat, 2007-01-06 at 23:38 -0500, Tom Lane wrote:
Everyone using these tools knows about the two-pass behavior.
No, not everyone
Simon Riggs [EMAIL PROTECTED] writes:
On Sun, 2007-01-07 at 03:53 -0500, Tom Lane wrote:
I think you just talked yourself out of getting this patch applied.
Maybe; what would be your explanation?
The main reason is that you were guilty of false advertising. This
patch was described as being
I wrote:
... The active-portal kluge that you've just
mentioned is nothing but a kluge, proving that you thought of some cases
where it would fail. But I doubt you thought of everything.
BTW, a sufficient counterexample for that kluge is that neither SPI or
SQL-function execution use a
Bruce Momjian [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
I don't know enough about the relevent tool to know if they actually
generate a warning about whether they need to be rerun. In any case it
seems a much better approach to simply run it again when needed rather
than
Simon Riggs [EMAIL PROTECTED] writes:
There is no failure condition where the rows continue to exist
on disk the table relfilenode shows a committed transaction pointing
to the file containing the marked-valid-but-actually-not rows.
What of
BEGIN;
CREATE TABLE foo ...;
On Sun, 2007-01-07 at 11:14 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Sun, 2007-01-07 at 03:53 -0500, Tom Lane wrote:
I think you just talked yourself out of getting this patch applied.
Maybe; what would be your explanation?
The main reason is that you were guilty
On Sun, 2007-01-07 at 11:29 -0500, Tom Lane wrote:
I wrote:
... The active-portal kluge that you've just
mentioned is nothing but a kluge, proving that you thought of some cases
where it would fail. But I doubt you thought of everything.
BTW, a sufficient counterexample for that kluge
Tom Lane wrote:
Perhaps even more to the point, what makes you think that someone
will notice the warning? If the docs build is one step in an
automated build process, this seems unlikely.
Taking a closer look, it's pretty much guaranteed that no one will see
them, because the targets they
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Perhaps even more to the point, what makes you think that someone
will notice the warning? If the docs build is one step in an
automated build process, this seems unlikely.
Taking a closer look, it's pretty much guaranteed that no
On Sun, 7 Jan 2007, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Perhaps even more to the point, what makes you think that someone
will notice the warning? If the docs build is one step in an
automated build process, this seems unlikely.
Taking a closer
Peter Eisentraut wrote:
Tom Lane wrote:
Perhaps even more to the point, what makes you think that someone
will notice the warning? If the docs build is one step in an
automated build process, this seems unlikely.
Taking a closer look, it's pretty much guaranteed that no one will see
On Fri, 2007-01-05 at 22:57 -0500, Tom Lane wrote:
Jim Nasby [EMAIL PROTECTED] writes:
On Jan 5, 2007, at 6:30 AM, Zeugswetter Andreas ADI SD wrote:
Ok, so when you need CRC's on a replicate (but not on the master) you
Which sounds to me like a good reason to allow the option in
Simon Riggs wrote:
Somehow, neither of these statements seem likely to be uttered by
a sane DBA ...
If I take a backup of a server and bring it up on a new system, the
blocks in the backup will not have been CRC checked before they go to
disk.
If I take the same server and now stream
Tom Lane wrote:
I'm wondering how this got into the TODO list. It seems rather
pointless, and likely to create client compatibility problems (if
not, why is NAMEDATALEN exported at all?)
I think because it used to be used in libpq's notification structure.
--
Peter Eisentraut
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
... why is NAMEDATALEN exported at all?)
I think because it used to be used in libpq's notification structure.
Yeah, you're probably right. Maybe we should take it out of
postgres_ext.h and move it to pg_config_manual.h. If no one
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The attached patch warns users when they create documentation output
that has no index, and suggests re-running 'gmake'.
This is just useless noise. If it could tell the difference between an
up-to-date
On Sat, 2007-01-06 at 23:38 -0500, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The attached patch warns users when they create documentation output
that has no index, and suggests re-running 'gmake'.
This is just useless noise. If it could tell the difference between an
Joshua D. Drake wrote:
On Sat, 2007-01-06 at 23:38 -0500, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The attached patch warns users when they create documentation output
that has no index, and suggests re-running 'gmake'.
This is just useless noise. If it could tell the
Recovery can occur with/without same setting of wal_checksum, to
avoid
complications from crashes immediately after turning GUC on.
Surely not. Otherwise even the on setting is not really a
defense.
Only when the CRC is exactly zero, which happens very very rarely.
It
On Fri, 2007-01-05 at 11:01 +0100, Zeugswetter Andreas ADI SD wrote:
What's the use-case for changing the variable on the fly anyway? Seems a
better
solution is just to lock down the setting at postmaster start.
I guess that the use case is more for a WAL based replicate, that
What's the use-case for changing the variable on the fly anyway?
Seems a
better
solution is just to lock down the setting at postmaster start.
I guess that the use case is more for a WAL based replicate, that
has/wants a different setting. Maybe we want a WAL entry for the
Ok, so when you need CRC's on a replicate (but not on the master)
you
turn it
off during standby replay, but turn it on when you start the
replicate
for normal operation.
Thought: even when it's off, the CRC had better be computed for
shutdown-checkpoint records. Else there's no way
On Jan 5, 2007, at 6:30 AM, Zeugswetter Andreas ADI SD wrote:
Ok, so when you need CRC's on a replicate (but not on the master) you
turn it
off during standby replay, but turn it on when you start the replicate
for normal operation.
Which sounds to me like a good reason to allow the option in
On Jan 3, 2007, at 4:20 PM, Bill Moran wrote:
* trace_temp_files is now an int: -1 disables, 0 and up equate to
log if
the file is this size or larger
Another thought is to allow ignoring files over a certain size. The
reason is that if you end up creating 10MB of temp files, you can
Jim Nasby [EMAIL PROTECTED] writes:
On Jan 5, 2007, at 6:30 AM, Zeugswetter Andreas ADI SD wrote:
Ok, so when you need CRC's on a replicate (but not on the master) you
Which sounds to me like a good reason to allow the option in
recovery.conf as well...
Actually, I'm not seeing the
Actually, I'm not seeing the use-case for a slave having a different
setting from the master at all?
My backup server is less reliable than the primary.
My backup server is more reliable than the primary.
Somehow, neither of these statements seem likely to be uttered by
a
In response to Andrew Dunstan [EMAIL PROTECTED]:
Bill Moran wrote:
Andrew Dunstan [EMAIL PROTECTED] wrote:
Bill Moran wrote:
+if (trace_temp_files != -1)
Might be more robust to say
if (trace_temp_files = 0)
Because it would allow for the easy addition
Bill Moran wrote:
In response to Andrew Dunstan [EMAIL PROTECTED]:
Bill Moran wrote:
Andrew Dunstan [EMAIL PROTECTED] wrote:
Bill Moran wrote:
+ if (trace_temp_files != -1)
Might be more robust to say
if (trace_temp_files = 0)
Bill Moran [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] wrote:
Might be more robust to say
if (trace_temp_files = 0)
I specified in the GUC config that minimum allowable value is -1.
I'd still tend to go with Andrew's suggestion because it makes this
particular bit of code
In response to Tom Lane [EMAIL PROTECTED]:
Bill Moran [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] wrote:
Might be more robust to say
if (trace_temp_files = 0)
I specified in the GUC config that minimum allowable value is -1.
I'd still tend to go with Andrew's
On Thu, 2007-01-04 at 11:09 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2007-01-04 at 10:00 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Recovery can occur with/without same setting of wal_checksum, to avoid
complications from crashes immediately
On Thu, 2007-01-04 at 17:58 +0100, Florian Weimer wrote:
* Simon Riggs:
Surely not. Otherwise even the on setting is not really a defense.
Only when the CRC is exactly zero, which happens very very rarely.
Have you tried switching to Adler32 instead of CRC32?
No. Please explain
Florian Weimer [EMAIL PROTECTED] writes:
Have you tried switching to Adler32 instead of CRC32?
Is anything known about the error detection capabilities of Adler32?
There's a lot of math behind CRCs but AFAIR Adler's method is pretty
much ad-hoc.
regards, tom lane
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2007-01-04 at 11:09 -0500, Tom Lane wrote:
It works most of the time doesn't exactly satisfy me.
It seemed safer to allow a very rare error through to the next level of
error checking rather than to close the door so tight that recovery
would not
* Tom Lane:
Florian Weimer [EMAIL PROTECTED] writes:
Have you tried switching to Adler32 instead of CRC32?
Is anything known about the error detection capabilities of Adler32?
There's a lot of math behind CRCs but AFAIR Adler's method is pretty
much ad-hoc.
Correct me if I'm wrong, but the
Florian Weimer [EMAIL PROTECTED] writes:
* Tom Lane:
There's a lot of math behind CRCs but AFAIR Adler's method is pretty
much ad-hoc.
Correct me if I'm wrong, but the main reason for the WAL CRC is to
detect partial WAL writes (due to improper caching, for instance).
Well, that's *a*
Florian Weimer [EMAIL PROTECTED] writes:
Ah, does this mean that each WAL entry gets its own checksum?
Right.
(I had assumed that PostgreSQLs WAL checksumming was justified by the
partial write issue. The wild store could easily occur with a heap
page, too, and AFAIK, tuples, aren't
On Tue, 2007-01-02 at 18:20 -0500, Tom Lane wrote:
Bill Moran [EMAIL PROTECTED] writes:
In response to Alvaro Herrera [EMAIL PROTECTED]:
Please change things to save the stat() syscall when the feature is not
in use.
Do you have a suggestion on how to do that and still have the
Bill Moran wrote:
+ if (trace_temp_files != -1)
Might be more robust to say
if (trace_temp_files = 0)
cheers
andrew
---(end of broadcast)---
TIP 6: explain analyze is your friend
In response to Simon Riggs [EMAIL PROTECTED]:
On Tue, 2007-01-02 at 18:20 -0500, Tom Lane wrote:
Bill Moran [EMAIL PROTECTED] writes:
In response to Alvaro Herrera [EMAIL PROTECTED]:
Please change things to save the stat() syscall when the feature is not
in use.
Do you have a
Andrew Dunstan [EMAIL PROTECTED] wrote:
Bill Moran wrote:
+ if (trace_temp_files != -1)
Might be more robust to say
if (trace_temp_files = 0)
Because it would allow for the easy addition of more negative numbers
with magic value?
---(end of
Applied.
---
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, are you saying that there is a signal we are ignoring for
overflow/underflow, or that we should just silently
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, are you saying that there is a signal we are ignoring for
overflow/underflow, or that we should just silently overflow/underflow
and not throw an error?
Silent underflow is fine with me; it's the norm in most all float
Teodor Sigaev [EMAIL PROTECTED] writes:
Just a freshing for clean applying..
http://www.sigaev.ru/misc/user_defined_typmod-0.11.gz
Applied with some revisions, and pg_dump support and regression tests
added.
regards, tom lane
---(end of
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
This is *not* going in the right direction :-(
Well, then show me what direction you think is better.
Fewer restrictions, not more. The thrust of what I've been saying
(and I think Roman too) is to trust in the hardware float-arithmetic
Just a freshing for clean applying..
http://www.sigaev.ru/misc/user_defined_typmod-0.11.gz
Is any objections to commit?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
This is *not* going in the right direction :-(
Well, then show me what direction you think is better.
Fewer restrictions, not more. The thrust of what I've been saying
(and I think Roman too) is to trust in the
Bruce Momjian [EMAIL PROTECTED] writes:
OK, are you saying that there is a signal we are ignoring for
overflow/underflow, or that we should just silently overflow/underflow
and not throw an error?
Silent underflow is fine with me; it's the norm in most all float
implementations and won't
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, are you saying that there is a signal we are ignoring for
overflow/underflow, or that we should just silently overflow/underflow
and not throw an error?
Silent underflow is fine with me; it's the norm in most all float
On 12/29/2006 12:23 AM, Bruce Momjian wrote:
Well, then show me what direction you think is better.
Think about this idea please. This has no INF, NaN or range
checks and detects all bad cases with any floating point
math.
The only issue is that a bad case is detected only once.
You need to
Teodor Sigaev [EMAIL PROTECTED] writes:
Just a freshing for clean applying..
http://www.sigaev.ru/misc/user_defined_typmod-0.11.gz
Is any objections to commit?
There's still a lot I don't particularly care for here (lack of
documentation being the biggest), but I'll make a pass at cleaning it
Roman Kononov [EMAIL PROTECTED] writes:
Think about this idea please. This has no INF, NaN or range
checks and detects all bad cases with any floating point
math.
Doesn't even compile here (no fenv.h).
regards, tom lane
---(end of
On 12/29/2006 11:27 AM, Tom Lane wrote:
Doesn't even compile here (no fenv.h).
Where do you compile?
Roman
---(end of broadcast)---
TIP 6: explain analyze is your friend
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I wasn't excited about doing one isinf() call to avoid three, so I just
made a fast isinf() macro:
/*We call isinf() a lot, so we use a fast version in this file */
#define fast_isinf(val) (((val) DBL_MIN || (val)
Joshua D. Drake wrote:
The current terminology of live and dead is already used in many places in
the
documentation and in userspace; mostly around the need for maintainance of
dead tuples within tables, reindex cleaning up dead pages, and even in the
vacuum commands output (n dead
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
I'm not really convinced that Bruce's proposed names seem any better to
me. What's wrong with dead and live?
In my mind, visible really means visible to anyone, and expired means
visible to no one.
Um
On Tuesday 26 December 2006 23:12, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
I'm not really convinced that Bruce's proposed names seem any better
to me. What's wrong with dead and live?
In my mind, visible really means
The current terminology of live and dead is already used in many places in
the
documentation and in userspace; mostly around the need for maintainance of
dead tuples within tables, reindex cleaning up dead pages, and even in the
vacuum commands output (n dead tuples cannot be removed
0.9 doesn't apply cleanly after Peter's changes, so, new version
http://www.sigaev.ru/misc/user_defined_typmod-0.10.gz
Teodor Sigaev wrote:
Perhaps an array of int4 would be better? How much
Done
http://www.sigaev.ru/misc/user_defined_typmod-0.9.gz
The patch needs more cleanup before
On Wed, Dec 20, 2006 at 01:39:58AM +, Tom Dunstan wrote:
Not with this patch, and AFAIK not possible generally, without writing
separate I/O functions for each type. I'd love to be able to do that,
but I don't think it's possible currently. The main stumbling block is
the output
Teodor Sigaev [EMAIL PROTECTED] writes:
Perhaps an array of int4 would be better? How much
Done
http://www.sigaev.ru/misc/user_defined_typmod-0.9.gz
The patch needs more cleanup before applying, too, eg make comments
match code, get rid of unused keywords added to gram.y.
Cleaned.
OK.
Martijn van Oosterhout wrote:
Also, it's not just I/O functions that are the issue, consider the
enum-to-integer cast.
er, what cast? :-)
IIRC Tom hasn't provided one. If you don't break the enum abstraction
there should be no need for one, and given the implementation it's not
quite
Andrew Dunstan wrote:
As for efficiency, I agree with what Tom says about alignment and
padding dissolving away any perceived advantage in most cases. If we
ever get around to optimising record layout we could revisit it.
I don't, because there are always those that are knowledgeable enough
Alvaro Herrera wrote:
Andrew Dunstan wrote:
As for efficiency, I agree with what Tom says about alignment and
padding dissolving away any perceived advantage in most cases. If we
ever get around to optimising record layout we could revisit it.
I don't, because there are always those
Alvaro Herrera [EMAIL PROTECTED] writes:
I don't, because there are always those that are knowledgeable enough to
know how to reduce space lost to padding. So it would be nice to have
2-byte enums on-disk, and resolve them based on the column's typid. But
then, I'm not familiar with the
Andrew Dunstan [EMAIL PROTECTED] writes:
I'm not a big fan of ordering columns to optimise record layout, except in the
most extreme cases (massive DW type apps). I think visible column order should
be logical, not governed by physical considerations.
Well as long as we're talking shoulds the
Alvaro Herrera wrote:
I don't, because there are always those that are knowledgeable enough to
know how to reduce space lost to padding. So it would be nice to have
2-byte enums on-disk, and resolve them based on the column's typid. But
then, I'm not familiar with the patch at all so I'm not
Simon Riggs napsal(a):
On Sat, 2006-12-02 at 09:43 +0100, Peter Eisentraut wrote:
Simon Riggs wrote:
Enclose new trace.sgml file as discussed on -docs.
I have a question here, regarding this:
To include DTrace support in a 64-bit binary, specify --enable-dtrace
and DTRACEFLAGS=-64 to
Teodor Sigaev [EMAIL PROTECTED] writes:
but the real problem is that there's no way for the planner
to reason about ordering in this representation. This patch would
guarantee that an ORDER BY with the NULLS option couldn't use an
indexscan, even if the index sorts nulls at the correct end.
On Mon, Dec 04, 2006 at 01:35:21PM -0500, Tom Lane wrote:
3) Allow to use index for IS [NOT] NULL
http://www.sigaev.ru/misc/indexnulls_82-0.6.gz
Initially patch was developed by Martijn van Oosterhout
kleptog@svana.org.
But it's reworked and support of searching NULLS to GiST
On Mon, Dec 04, 2006 at 02:04:26PM -0500, Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] writes:
1) Typmod for user-defined types
http://www.sigaev.ru/misc/user_defined_typmod-0.7.gz
Patch is based on ideas from
http://archives.postgresql.org/pgsql-hackers/2004-06/msg00932.php
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Not sure if people want this for 8.2. I think we can modify
test_fsync.c anytime but the movement of the defines into an include
file is a backend code change.
I think fooling with this on the day before RC1 is an unreasonable risk
Tom Lane wrote:
While there's not anything wrong with this proposed patch in itself,
I have to admit that I don't see the point.
The points are:
1. It is just unpleasant to leave the overflow.
2. It is not easy for users to understand what they should do when they
encounter the error
On Sun, 2006-11-05 at 15:02 +, Simon Riggs wrote:
Code comments now discuss relative paths also.
Patch containing just the minor cleanup of docs and code comments.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Index: doc/src/sgml/backup.sgml
On Sat, 2006-11-04 at 13:29 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, Nov 03, 2006 at 11:25:09AM -0500, Tom Lane wrote:
Since 8.1 has done this all along and no one's actually complained about
it, I guess no one is using scripts that do cd. I'm inclined to go
Simon Riggs [EMAIL PROTECTED] writes:
On Sat, 2006-11-04 at 13:29 -0500, Tom Lane wrote:
Looking back in the archives, I note that one of the arguments for
making the server use relative paths everywhere was so that it'd be
robust against things like DBAs moving directories that contain live
On Sun, 2006-11-05 at 11:10 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Sat, 2006-11-04 at 13:29 -0500, Tom Lane wrote:
Looking back in the archives, I note that one of the arguments for
making the server use relative paths everywhere was so that it'd be
robust against
Simon Riggs [EMAIL PROTECTED] writes:
I'm pretty sure most people don't move live postmasters very frequently,
plus it isn't clear to me why we should support the people that want
that to do that, yet not the people who want the absolute-path option.
As already discussed upthread, anyone who
On Sun, 2006-11-05 at 11:49 -0500, Tom Lane wrote:
I don't see why we should go out of our way to
provide a bad substitute for pwd.
That argument is conclusive. Agreed.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, Nov 03, 2006 at 11:25:09AM -0500, Tom Lane wrote:
Since 8.1 has done this all along and no one's actually complained about
it, I guess no one is using scripts that do cd. I'm inclined to go
with Bernd's suggestion to change the docs to match the
On Fri, Nov 03, 2006 at 11:25:09AM -0500, Tom Lane wrote:
Since 8.1 has done this all along and no one's actually complained about
it, I guess no one is using scripts that do cd. I'm inclined to go
with Bernd's suggestion to change the docs to match the code, but does
anyone have a contrary
Tom Lane wrote:
Bernd Helmle [EMAIL PROTECTED] writes:
Since 8.1 has done this all along and no one's actually complained about
it, I guess no one is using scripts that do cd. I'm inclined to go
with Bernd's suggestion to change the docs to match the code, but does
anyone have a contrary
On Fri, 2006-11-03 at 17:34 +0100, Martijn van Oosterhout wrote:
On Fri, Nov 03, 2006 at 11:25:09AM -0500, Tom Lane wrote:
Since 8.1 has done this all along and no one's actually complained about
it, I guess no one is using scripts that do cd. I'm inclined to go
with Bernd's suggestion to
Simon Riggs wrote:
On Fri, 2006-11-03 at 17:34 +0100, Martijn van Oosterhout wrote:
On Fri, Nov 03, 2006 at 11:25:09AM -0500, Tom Lane wrote:
Since 8.1 has done this all along and no one's actually complained
about
it, I guess no one is using scripts that do cd. I'm inclined to go
with
Since 8.1 has done this all along and no one's actually
complained
about it, I guess no one is using scripts that do cd. I'm
inclined to go with Bernd's suggestion to change the docs
to match
the code, but does anyone have a contrary opinion?
In Unix you can easily prepend
On Tue, 2006-10-31 at 11:04 -0500, Tom Lane wrote:
It seems that we're converging on the conclusion that not truncating
clog early is the least bad alternative. This has the advantage of
making things a lot simpler --- we won't need to track minxid at all.
Allow me to summarize what I think
Simon Riggs [EMAIL PROTECTED] writes:
Do we need another GUC? I thought your observation about a PITR slave
having that set lower than its master still remains unresolved.
No, AFAICS that's not an issue in this design. The facts-on-the-ground
are whatever is recorded in pg_class.relvacuumxid,
Tom Lane wrote:
The only alternative I can see is the one Heikki suggested: don't
truncate clog until the freeze horizon. That's safe (given the planned
change to WAL-log tuple freezing) and clean and simple, but a permanent
requirement of 250MB+ for pg_clog would put the final nail in the
Heikki Linnakangas [EMAIL PROTECTED] writes:
I got another idea. If we make sure that vacuum removes any aborted xid
older than OldestXmin from the table, we can safely assume that any xid
the current clog truncation point we are going to be interested in is
committed. Vacuum already
Alvaro Herrera [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Ouch! We did discuss that also. Flushing the buffercache is nasty with
very large caches, so this makes autovacuum much less friendly - and
could take a seriously long time if you enforce the vacuum delay
costings.
Hmm, isn't the
It seems that we're converging on the conclusion that not truncating
clog early is the least bad alternative. This has the advantage of
making things a lot simpler --- we won't need to track minxid at all.
Allow me to summarize what I think has to happen:
* VACUUM will determine a freeze cutoff
On Mon, 2006-10-30 at 20:40 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
That was understood; in the above example I agree you need to flush. If
you don't pass a truncation point, you don't need to flush whether or
not you actually truncate. So we don't need to flush *every*
Tom Lane [EMAIL PROTECTED] writes:
The added WAL volume should be pretty minimal, because only tuples that have
gone untouched for a long time incur extra work.
That seems like a weak point in the logic. It seems like it would make VACUUM
which is already an i/o hog even more so. Perhaps
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
The added WAL volume should be pretty minimal, because only tuples that have
gone untouched for a long time incur extra work.
That seems like a weak point in the logic. It seems like it would make VACUUM
which is already an i/o
Alvaro Herrera [EMAIL PROTECTED] writes:
Huh, but the log would not be flushed for each operation that the vacuum
logs. Only when it's going to commit.
It strikes me that the vacuum cost delay feature omits to consider
generation of WAL records as a cost factor. It may not be a big problem
On Mon, 2006-10-30 at 12:05 -0500, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Ugh. Is there another solution to this? Say, sync the buffer so that
the hint bits are written to disk?
Yeah. The original design for all this is explained by the notes for
TruncateCLOG:
*
Simon Riggs wrote:
On Mon, 2006-10-30 at 12:05 -0500, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Ugh. Is there another solution to this? Say, sync the buffer so that
the hint bits are written to disk?
Yeah. The original design for all this is explained by the notes
Simon Riggs [EMAIL PROTECTED] writes:
ISTM we only need to flush iff the clog would be truncated when we
update relminxid.
Wrong :-( If the relvacuumxid change (not relminxid ... as I said, these
names aren't very transparent) makes it to disk but not all the hint
bits do, you're at risk.
Alvaro Herrera [EMAIL PROTECTED] writes:
In fact I don't understand what's the point about multiple databases vs.
a single database. Surely a checkpoint would flush all buffers in all
databases, no?
Yeah --- all the ones that are dirty *now*. Consider the case where you
vacuum DB X, update
On Mon, 2006-10-30 at 16:58 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
ISTM we only need to flush iff the clog would be truncated when we
update relminxid.
Wrong :-( If the relvacuumxid change (not relminxid ... as I said, these
names aren't very transparent) makes it
201 - 300 of 660 matches
Mail list logo
