Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
BTW in testing this patch I was surprised by the fact that temp tables
files are removed at checkpoint time,
[ blink... ] Doesn't look like that should happen. What is your
test case?
Hmph, must be because of the patch from last
Tom Lane [EMAIL PROTECTED] wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
We probably need to add PG_BINARY when we open control files
because 0x1A is an end-of-file marker on Windows.
Well, why is that a bug? If the platform is so silly as to define text
files that way, who are we
On Thu, 2008-09-18 at 09:23 +0300, Heikki Linnakangas wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
BTW in testing this patch I was surprised by the fact that temp tables
files are removed at checkpoint time,
[ blink... ] Doesn't look like that should happen. What
Simon Riggs wrote:
On Thu, 2008-09-18 at 09:23 +0300, Heikki Linnakangas wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
BTW in testing this patch I was surprised by the fact that temp tables
files are removed at checkpoint time,
[ blink... ] Doesn't look like that should
On Thu, 2008-09-18 at 10:19 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
An unfortunate choice of words! Harmless is not how your average DBA
would describe it when their disk fills and they are apparently unable
to reduce space consumption. So there is still a problem there even
On Tue, 2008-09-16 at 15:45 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] wrote:
Testing takes a while on this, I probably won't complete it until
Friday. So enclosed patch is for eyeballs only at this stage.
What's the status on that patch?
Having some trouble trying to get a
Hi,
I downloaded latest postgresql source code from
git clone git://git.postgresql.org/git/postgresql.git
and tried to apply the patch
http://archives.postgresql.org/pgsql-hackers/2008-09/gza1fGXLvf3L.gz
It does not apply cleanly, see the failures in attached file.
Regards
Abbas
George McCollister wrote:
oprofile is showing that memset (via dopr) is using about 60% of the CPU. I
traced back further and noticed most of the usage was coming from
EncodeDateTime.
I'm not quite sure why oprofile is showing that memset is hogging so much CPU.
Regardless, I found way to
Simon Riggs wrote:
On Thu, 2008-09-18 at 10:19 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
An unfortunate choice of words! Harmless is not how your average DBA
would describe it when their disk fills and they are apparently unable
to reduce space consumption. So there is still a
Abbas napsal(a):
Hi,
I downloaded latest postgresql source code from
git clone git://git.postgresql.org/git/postgresql.git
and tried to apply the patch
http://archives.postgresql.org/pgsql-hackers/2008-09/gza1fGXLvf3L.gz
It does not apply cleanly, see the failures in attached file.
It
I'd like to add some new flag bits to XLogRecord. (xlog.h)
Where? xl_prev.
xl_prev is an XLogRecPtr which points backwards to the immediately
preceeding WAL record. All of the bits are currently used, but I have
some observations and a proposal to change that.
We currently compare the whole
Simon Riggs wrote:
I'd like to add some new flag bits to XLogRecord. (xlog.h)
Where? xl_prev.
I'm more curious about What? and Why?, actually ;-),
So I would like to propose that we ignore the top 4 bits in
xl_prev.xlogid when comparing values, rather than using all 32 bits for
comparison.
ITAGAKI Takahiro wrote:
Tom Lane [EMAIL PROTECTED] wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
We probably need to add PG_BINARY when we open control files
because 0x1A is an end-of-file marker on Windows.
Well, why is that a bug? If the platform is so silly as to define text
files
Heikki Linnakangas wrote:
ITAGAKI Takahiro wrote:
Tom Lane [EMAIL PROTECTED] wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
We probably need to add PG_BINARY when we open control files
because 0x1A is an end-of-file marker on Windows.
Well, why is that a bug? If the platform is so silly
On Thu, 2008-09-18 at 13:56 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
I'd like to add some new flag bits to XLogRecord. (xlog.h)
Where? xl_prev.
I'm more curious about What? and Why?, actually ;-),
Just trying to solve the egg/chicken problem of I want to add a flag;
but
Why bit just add a new bitfield for flags if we need them? I'm usually
the one worried about data density so perhaps I should be on the other
side of the fence here but I'm not sure. The conventional wisdom is
that wal bandwidth is not a major issue.
greg
On 18 Sep 2008, at 12:15, Simon
Hi Heikki,
I finally performed iGen test. I used two v490 servers with 4 dual core SPARC
CPUs and 32GB RAM. I have only one disk and I did not performed any disk I/O
optimization. I tested 105 parallel connection and think time was 200ms.
See the result:
Original:
-
Actual
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Thanks. That's very disappointing :-(
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Suggestions:
1) remove WAL logging. I think that FSM record should be recovered
during processing of others WAL records (like insert, update).
Probably only we need full page write on first modification after
checkpoint.
Hmm, we don't
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
[ blink... ] Doesn't look like that should happen. What is your
test case?
Hmph, must be because of the patch from last winter to prevent
relfilenode reuse until next checkpoint.
Ah. I had misunderstood Alvaro to say that temp
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Can you do some analysis of why that is?
Looks like I need to blow the dust off my DBT-2 test rig and try to
reproduce that as well.
--
Heikki Linnakangas
EnterpriseDB
On Thu, 2008-09-18 at 12:40 +0100, Greg Stark wrote:
Why bit just add a new bitfield for flags if we need them? I'm usually
the one worried about data density so perhaps I should be on the other
side of the fence here but I'm not sure. The conventional wisdom is
that wal bandwidth is
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Looks like we didn't make an
exception for temporary tables. Although it's harmless, we could put an
isTempOrToastNamespace() test in there:
Bad, bad idea to have md.c doing any catalog access.
isTempOrToastNamespace() doesn't
On Thu, 2008-09-18 at 09:05 +0100, Simon Riggs wrote:
Feels like I should shutdown the bgwriter after recovery and then
allow it to be cranked up again after normal processing starts, and do
all of this through postmaster state changes. That way bgwriter
doesn't need to do a dynamic state
Heikki Linnakangas [EMAIL PROTECTED] writes:
Or, we could store only the delta between current record and the
previous one. Assuming we know what the current record is, that wouldn't
lose any precision. That way xl_prev only needs to be as big as the
biggest possible WAL record we can have.
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-09-18 at 12:40 +0100, Greg Stark wrote:
Why bit just add a new bitfield for flags if we need them? I'm usually
the one worried about data density so perhaps I should be on the other
side of the fence here but I'm not sure. The conventional
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Can you do some analysis of why that is?
I'll try something but I do not guarantee result.
Zdenek
--
Zdenek Kotala Sun Microsystems
Simon Riggs [EMAIL PROTECTED] writes:
Having some trouble trying to get a clean state change from recovery to
normal mode.
Startup needs to be able to write WAL at the end of recovery so it can
write a ShutdownCheckpoint, yet must not be allowed to write WAL before
that. Other services are
I went through the CVS logs to draft release notes, and found that the
list of patches applied to REL7_4_STABLE is a bit skimpy:
http://developer.postgresql.org/pgdocs/postgres/release-7-4-22.html
I'm wondering if we should leave 7.4 out of the current set of update
releases. If I were a DBA
Tom Lane wrote:
I went through the CVS logs to draft release notes, and found that the
list of patches applied to REL7_4_STABLE is a bit skimpy:
http://developer.postgresql.org/pgdocs/postgres/release-7-4-22.html
One thing that ties into this is whether there ever will *be* another
7.4.x
On Thu, Sep 18, 2008 at 2:20 PM, Tom Lane [EMAIL PROTECTED] wrote:
One thing that ties into this is whether there ever will *be* another
7.4.x release. We haven't formally discussed an EOL date for 7.4,
but its fifth birthday will be 2008-11-17. I imagine we'd want to make
its final update
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Comments?
IMO, we release 7.4.22 with the rest and it is also announced that as of
12-31-08 7.4.x is no more.
I'm all for killing 7.4, but that's a rather short time frame, especially as
this is a busy time of year for many businesses. How
On Thu, 2008-09-18 at 09:06 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Having some trouble trying to get a clean state change from recovery to
normal mode.
Startup needs to be able to write WAL at the end of recovery so it can
write a ShutdownCheckpoint, yet must not
I wrote:
Simon Riggs [EMAIL PROTECTED] writes:
In some cases, but my wish is also to minimise WAL volume as much as
possible.
I'm with Greg on this one: baroque bit-squeezing schemes are a bad idea.
Wait a minute ... why are we even having this conversation? XLogRecord
has at least two
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Comments?
IMO, we release 7.4.22 with the rest and it is also announced that as of
12-31-08 7.4.x is no more.
I'm all for killing 7.4, but that's a rather short time frame, especially as
this is a busy time of
On Thu, 2008-09-18 at 08:38 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-09-18 at 12:40 +0100, Greg Stark wrote:
Why bit just add a new bitfield for flags if we need them? I'm usually
the one worried about data density so perhaps I should be on the other
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-09-18 at 09:06 -0400, Tom Lane wrote:
Do we really need a checkpoint there at all?
Timelines only change at shutdown checkpoints.
Hmm. I *think* that that is just a debugging crosscheck rather than a
critical property. But yeah, it would
On Thu, 2008-09-18 at 09:57 -0400, Tom Lane wrote:
I wrote:
Simon Riggs [EMAIL PROTECTED] writes:
In some cases, but my wish is also to minimise WAL volume as much as
possible.
I'm with Greg on this one: baroque bit-squeezing schemes are a bad idea.
Wait a minute ... why are we even
On Thu, 2008-09-18 at 10:09 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-09-18 at 09:06 -0400, Tom Lane wrote:
Do we really need a checkpoint there at all?
Timelines only change at shutdown checkpoints.
Hmm. I *think* that that is just a debugging
Joshua D. Drake [EMAIL PROTECTED] writes:
Greg Sabino Mullane wrote:
I'm all for killing 7.4, but that's a rather short time frame, especially as
this is a busy time of year for many businesses. How about we make it further
in the future (perhaps 2009-07-01, six months into the next year), and
Gregory Stark wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Well, I proposed disallowing using a different collation than the source
database, except for using template0 as the source. That's pretty limited, but
is trivial to implement and still let's you have databases with different
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Greg Sabino Mullane wrote:
I'm all for killing 7.4, but that's a rather short time frame, especially as
this is a busy time of year for many businesses. How about we make it
further
in the future (perhaps 2009-07-01, six months into
On Tue, 2008-09-16 at 10:11 -0400, Alvaro Herrera wrote:
I wonder if the improved clog API required to mark multiple
transactions as committed at once would be also useful to
TransactionIdCommitTree which is used in regular transaction commit.
I've hacked together this concept patch (WIP).
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
[ blink... ] Doesn't look like that should happen. What is your
test case?
This was simply a CREATE TEMP TABLE ... ON COMMIT DROP. The file stays
in place until checkpoint (either a manually invoked one, or a
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
The handwriting has been on the wall for 7.4 ever since we agreed that
7.3 would be EOL'd at five years...
Handwriting on the wall is entirely unrelated to an offical,
published end of life date.
It's not like people have to stop using it
Greg Sabino Mullane wrote:
No, but if we are going to stop releasing revisions with critical bugfixes,
it is important that people know well in advance and can plan a migration
to a supported version.
Frankly, the whole pg_dump mess is what keeps many people on older versions,
somtimes
On Thu, Sep 18, 2008 at 03:25:10PM -, Greg Sabino Mullane wrote:
Frankly, the whole pg_dump mess is what keeps many people on older versions,
somtimes including 7.4.
This isn't my experience. The reasons people stay on older releases
are manifold.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
Heikki Linnakangas [EMAIL PROTECTED] writes:
Here's a new patch, updated per your comments.
I did a read-through of the portions of this patch that change the rest
of the system (ie, not the guts of the new FSM itself). Mostly it looks
pretty nice, but I have a few gripes:
Does smgrimmedsync
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Frankly, the whole pg_dump mess is what keeps many people on older versions,
somtimes including 7.4.
Sure but that was fixed, four years ago. At some point you recognize
laziness and ineptness over caution and responsibility.
I think you
Alvaro Herrera [EMAIL PROTECTED] writes:
Don't temp tables use this kind of temp file? I admit I didn't check; I
just assumed they did.
No, temp tables go through localbuf.c, which sits atop regular smgr.
I don't think fd.c knows any difference from regular tables.
Greg Sabino Mullane wrote:
- From a business perspective, there has been no reason to go through the
pain and downtime of an upgrade, as long as the PG project is releasing
point revisions to the 7.4 branch. As I said, I'm all for getting people
off 7.4, but it needs to be done with a definite
Heikki Linnakangas [EMAIL PROTECTED] writes:
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Thanks. That's very disappointing :-(
One thing that jumped out at me is that you call FreeSpaceMapExtendRel
every time a rel is extended by even
Hi,
On Thu, 2008-09-18 at 09:20 -0400, Tom Lane wrote:
So I'm thinking that generating a 7.4.x tarball now would be mostly a
waste of server space, and we should leave these changes for the next
update cycle.
How much server space or CPU cycles are we talking about? I bet it is
less than the
On Sep 18, 2008, at 07:38, Tom Lane wrote:
I wasn't intending to start a discussion about how/when to EOL 7.4,
but since the thread has gone in that direction: my vote would be to
announce now (say, with the announcement of this set of releases) that
7.4 will be EOL'd with our first set of
Joshua D. Drake [EMAIL PROTECTED] writes:
Greg Sabino Mullane wrote:
- From a business perspective, there has been no reason to go through the
pain and downtime of an upgrade, as long as the PG project is releasing
point revisions to the 7.4 branch. As I said, I'm all for getting people
off
Bernt Drange escribió:
After a lot of fiddling with being able to enter single user mode on a
windows machine (I had to figure out how to run the command line as
the correct user, then for some reason -D didn't work, but SET
PGDATA=xxx worked), I finally managed to fix my problem.
Hmm, the
Heikki Linnakangas [EMAIL PROTECTED] writes:
No, FANOUT^4 doesn't fit in int, good catch. Actually, FANOUTPOWERS
table doesn't need to go that far, so that's just a leftover. It only
needs to have DEPTH elements. However, we have the same problem if
DEPTH==3, FANOUT^4 will not fit into int.
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Thanks. That's very disappointing :-(
One thing that jumped out at me is that you call FreeSpaceMapExtendRel
every time a rel is
Greg Sabino Mullane [EMAIL PROTECTED] writes:
From a business perspective, there has been no reason to go through the
pain and downtime of an upgrade, as long as the PG project is releasing
point revisions to the 7.4 branch. As I said, I'm all for getting people
off 7.4, but it needs to be
Howdy,
Not *exactly* hackers-related, but I wanted to get a feel for this
from those who are likely to use project hosting, and to minimize the
chances of a flame war.
Right now I have pgTAP on pgFoundry, which is okay, though it appears
to be largely unmaintained. PostgreSQL module
On Thu, 18 Sep 2008 11:22:14 -0700
David E. Wheeler [EMAIL PROTECTED] wrote:
* LaunchPad
Is backed by PostgreSQL. It is the only logical choice :). Seriously
though it is a good service.
Joshua D. Drake
--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
One thing that jumped out at me is that you call FreeSpaceMapExtendRel
every time a rel is extended by even one block.
Yes, most of those calls end up being no-op. Which is exactly why I
would be surprised if those made any
Zdenek Kotala [EMAIL PROTECTED] writes:
1) remove WAL logging. I think that FSM record should be recovered
during processing of others WAL records (like insert, update).
Why are we WAL-logging FSM operations at all? It's only a hint.
I think we'd still need to WAL log operations that
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Here's a new patch, updated per your comments.
I did a read-through of the portions of this patch that change the rest
of the system (ie, not the guts of the new FSM itself). Mostly it looks
pretty nice, but I have a few gripes:
Tom Lane wrote:
I did a bit of testing and immediately got an Assert failure:
...
The scary part of that is that it gets through the regression tests ---
doesn't leave one with a warm feeling about how much of VACUUM gets
exercised by regression.
Ouch..
I take it the comment at the top of
Heikki Linnakangas napsal(a):
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Thanks. That's very disappointing :-(
One thing that jumped out at me is that you call
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
1) remove WAL logging. I think that FSM record should be recovered
during processing of others WAL records (like insert, update).
Why are we WAL-logging FSM operations at all? It's only a hint.
- to ensure self-consistency of the
Heikki Linnakangas [EMAIL PROTECTED] writes:
... but we still haven't actually
established that the WAL-logging is causing the performance degradation
Zdenek observed.
Yeah, that's a good point. I did some simple performance testing on
bulk inserts and updates, and found that while they
Tom Lane wrote:
Yeah. What this is about is how long the *community* supports 7.4...
Perhaps the discussion should be more global (and ultimately save time
on having this discussion again in the future). Decide on the policy,
make official and make it obvious. The time I usually hear
I did some editorializing on the FSM README file, in the line of
familiarizing myself with the contents. Attached is an updated version.
Here are a couple of other random comments I jotted in the process:
search_avail makes me nervous: in the presence of a corrupt tree
I think it could index
On Sep 18, 2008, at 11:27, Joshua Drake wrote:
* LaunchPad
Is backed by PostgreSQL. It is the only logical choice :). Seriously
though it is a good service.
Looks pretty nice, though it doesn't have project home pages. Having
just created one for pgTAP on pgFoundry, I'd
David,
Right now I have pgTAP on pgFoundry, which is okay, though it appears
to be largely unmaintained. PostgreSQL module projects seem to mainly
just flounder there.
Yeah. We had huge plans for pgFoundry, but got burned out by a combination
of GForge problems and Hub.org problems -- I
Simon Riggs wrote:
Why not:
1. Same procedure as Warm Standby now
a) WAL archiving to standby starts
b) base backup
2. Startup standby, with additional option to stream WAL. WALReceiver
starts, connects to Primary. Primary issues log switch. Archiver turns
itself off after sending that
Steve Crawford wrote:
Tom Lane wrote:
Yeah. What this is about is how long the *community* supports 7.4...
Is there any way to poll the community and see how much people
in the community care about 7.4 community support?
It seems possible that most people with large important 7.4 systems
On Thu, 18 Sep 2008 16:57:19 -0700
Ron Mayer [EMAIL PROTECTED] wrote:
(c) are secretly praying for an excuse
to upgrade anyway.
heh
--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States
Why does set_recursion_pathlist think that the subquery might have
useful pathkeys? We know it must always be a UNION ALL, no?
Right. But someday we might implement UNION (without ALL) then we
have useful pathkeys...
Or shall I completely remove the step to generate patheys and do not
pass
On Thursday 18 September 2008 14:22:14 David E. Wheeler wrote:
Howdy,
Not *exactly* hackers-related, but I wanted to get a feel for this
from those who are likely to use project hosting, and to minimize the
chances of a flame war.
Right now I have pgTAP on pgFoundry, which is okay, though
David E. Wheeler wrote:
So I'm wondering, given the various discussions of PostgreSQL module
hosting in the past, where would be a good place to put a PostgreSQL
module project? The things I would like to have are:
* SVN or git hosting (I've not used git, but would try it)
* Ability
Tatsuo Ishii [EMAIL PROTECTED] writes:
Why does set_recursion_pathlist think that the subquery might have
useful pathkeys? We know it must always be a UNION ALL, no?
Right. But someday we might implement UNION (without ALL) then we
have useful pathkeys...
Good point. Might as well leave it
At the CommitFest:Sep, I got several comments about SE-PostgreSQL from Peter.
(Thanks for your comments.)
He asked me several questions about its concept, then I replied for them.
However, it seems to me there is a difference in our opinions.
In my opinion, it is quite natural that different
I have an 8.3.1 instance on Linux and since June 29th the autovacuum process
has claimed to be working on the same three tables. That's OK, I am a very
patient man, and these are very large tables. Today I started to get
transaction wraparound warnings, so I go and check it out. Turns out the
I committed this to HEAD. If anything breaks, I request that someone
else does the cleanup, as it looks like we're headed for the hospital
first thing tomorrow morning to see what newborns look like.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL
82 matches
Mail list logo
