On Thu, Sep 18, 2008 at 05:41:16PM +0300, Heikki Linnakangas wrote:
> Attached is an updated version of the stripped-down patch. I've cleaned
> it up a bit, and added more sanity checks. Documentation is still
> missing and I haven't test it much.
FWIW, I disagree with the stripping down and thi
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 Co
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
au
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 secu
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
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)
> * Ab
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, th
> 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 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 Post
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
ei
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
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 k
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
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 off
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 tosse
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:
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 tr
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 FreeSpaceM
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 i
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:
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 t
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 an
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.
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 proje
"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 t
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
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
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, th
"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 peo
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 updat
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 th
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
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 d
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.
-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
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 smgrimmedsyn
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]
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 includin
-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
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 o
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:
> "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
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
c
"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
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 deb
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 ...
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 w
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
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 y
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 t
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, ye
-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.
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 up
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 relea
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 cons
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
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
Prague
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
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 conv
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
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 a
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 i
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 http://www.enterpr
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 t
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 ha
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 t
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 run/snap-sh
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 Ri
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
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 th
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
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
compariso
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 xl_p
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 clas
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 problem
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 eli
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
www.enterprise
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 g
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 th
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 h
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
81 matches
Mail list logo
