Josh Berkus wrote:
Yea, this is just pushing off work until later, which I don't support.
There is no easy out here and I am afraid we will just have to accept a
3-month feature freeze.
I think that may be where we're heading. In that case, we may need to talk
about branching earlier s
> Tatsuo Ishii wrote:
> > > Stefan Kaltenbrunner wrote:
> > > >> They are not stable. The items should point to the archives, which are
> > > >> supposedly more stable. (I had already fixed one item in PatchStatus
> > > >> this morning). Really it would be much nicer to have links using the
> >
Bruce,
> It seems unfair to disinguish between early/last in cycle postings.
I think it's fair. A patch which was submitted for 8.2 and didn't get in
should get consideration over a patch which was still in prototype form a
week before feature freeze. Also, I really don't think it's a crime t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, May 15, 2007 16:33:32 -0700 "Joshua D. Drake"
<[EMAIL PROTECTED]> wrote:
> If the developers were to actually take a step back and say, "Hey... instead
> of working on these dozen different features, I should work on three and help
Tom Lane <[EMAIL PROTECTED]> wrote:
> I'm concerned that this one creates
> an open-loop behavior in which the n_dead_tuples estimate will diverge
> arbitrarily far from reality over time. I criticized the original
> proposal on that basis, and I'm not convinced this version fixes it,
> because o
On Tuesday 15 May 2007 16:48, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > > That is not fair to patch submitters, and pushes the problem to 8.4,
> > > where it will be no better.
> >
> > If it isn't done, it isn't done. We aren't dropping the patch. The patch
> > has been accepted, just not r
Tatsuo Ishii wrote:
> > Stefan Kaltenbrunner wrote:
> > >> They are not stable. The items should point to the archives, which are
> > >> supposedly more stable. (I had already fixed one item in PatchStatus
> > >> this morning). Really it would be much nicer to have links using the
> > >> Message
Jeff Davis wrote:
On Tue, 2007-05-15 at 10:42 +0100, Heikki Linnakangas wrote:
Luke Lonergan wrote:
32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2 cache
effect.
How about using 256/blocksize?
Sounds reasonable. We need to check the effect on the synchronized
scans, though.
Simon Riggs wrote:
> > > 3. Should the WALWriter also do the wal_buffers half-full write at the
> > > start of XLogInsert() ?
> >
> > That should go away entirely; to me the main point of the separate
> > wal-writer process is to take over responsibility for not letting too
> > many dirty wal buff
On 5/15/07, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> Stefan Kaltenbrunner wrote:
> >> They are not stable. The items should point to the archives, which
are
> >> supposedly more stable. (I had already fixed one item in PatchStatus
> >> this morning). Really it would be much nicer to have lin
Simon Riggs wrote:
> On Thu, 2007-04-26 at 21:14 -0400, Bruce Momjian wrote:
> > Simon Riggs wrote:
> > > > That should go away entirely; to me the main point of the separate
> > > > wal-writer process is to take over responsibility for not letting too
> > > > many dirty wal buffers accumulate.
> >
> Stefan Kaltenbrunner wrote:
> >> They are not stable. The items should point to the archives, which are
> >> supposedly more stable. (I had already fixed one item in PatchStatus
> >> this morning). Really it would be much nicer to have links using the
> >> Message-Id but I doubt that's at all
OK, removed.
---
Jim C. Nasby wrote:
> Simon intended to commit this per
> http://archives.postgresql.org/pgsql-hackers/2007-03/msg01761.php
> (actually, there was a change in what was being done). I suspect this
> item isn'
Simon intended to commit this per
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01761.php
(actually, there was a change in what was being done). I suspect this
item isn't valid any longer.
On Tue, May 15, 2007 at 07:30:58PM -0400, Bruce Momjian wrote:
>
> This has been saved for the 8.4
Bruce Momjian wrote:
Joshua D. Drake wrote:
Bruce Momjian wrote:
If people want proof that we have had some patches for months, this
email is from Simon from January, 2007.
I don't think anyone (at least sanely) questions that there are patches
hanging out there.
My point is that pushing th
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Simon Riggs wrote:
> On Fri, 2007-03-09 at 11:47 -0500, Tom Lane wrote:
> > "Simon Riggs" <[EMAIL PROTECTED]> writes:
Jim C. Nasby wrote:
> On Tue, May 15, 2007 at 07:01:39PM -0400, Bruce Momjian wrote:
> > > Unless you're really in love with doing that sort of thing it's really
> > > good that someone else did it. You're one of a handful of folks that can
> > > actually review patches, while there's any number of
On Tue, May 15, 2007 at 07:01:39PM -0400, Bruce Momjian wrote:
> > Unless you're really in love with doing that sort of thing it's really
> > good that someone else did it. You're one of a handful of folks that can
> > actually review patches, while there's any number of us that can update
> > a wi
On Tue, May 15, 2007 at 04:37:28PM +0100, Heikki Linnakangas wrote:
> While testing the buffer ring patch, I noticed that bulk inserts with
> both INSERT and COPY pin and unpin the buffer they insert to for every
> tuple. That means that the usage_count of all those buffers are bumped
> A fix
Jim C. Nasby wrote:
> On Tue, May 15, 2007 at 10:32:14PM +0200, Magnus Hagander wrote:
> > Stefan Kaltenbrunner wrote:
> > >> They are not stable. The items should point to the archives, which are
> > >> supposedly more stable. (I had already fixed one item in PatchStatus
> > >> this morning). R
Jim C. Nasby wrote:
> On Tue, May 15, 2007 at 12:42:28PM -0400, Bruce Momjian wrote:
> > Joshua D. Drake wrote:
> > > > Patch status:
> > > >
> > > > http://developer.postgresql.org/index.php/Todo:PatchStatus
> > >
> > > If... this is actually a problem (I leave to other committers and
>
On Tue, May 15, 2007 at 10:32:14PM +0200, Magnus Hagander wrote:
> Stefan Kaltenbrunner wrote:
> >> They are not stable. The items should point to the archives, which are
> >> supposedly more stable. (I had already fixed one item in PatchStatus
> >> this morning). Really it would be much nicer t
On Tue, May 15, 2007 at 12:42:28PM -0400, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > > Patch status:
> > >
> > > http://developer.postgresql.org/index.php/Todo:PatchStatus
> >
> > If... this is actually a problem (I leave to other committers and
> > reviewers to comment) then I suggest
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > If people want proof that we have had some patches for months, this
> > email is from Simon from January, 2007.
> >
>
> I don't think anyone (at least sanely) questions that there are patches
> hanging out there.
My point is that pushing them fo
Alvaro Herrera wrote:
Russell Smith wrote:
Alvaro Herrera wrote:
Alvaro Herrera wrote:
2. decide that the standard is braindead and just omit dumping the
grantor when it's no longer available, but don't remove
pg_auth_members.grantor
Which do people feel should be implem
Bruce Momjian wrote:
If people want proof that we have had some patches for months, this
email is from Simon from January, 2007.
I don't think anyone (at least sanely) questions that there are patches
hanging out there.
Joshua D. Drake
---
On Tue, May 15, 2007 at 10:25:35AM -0700, Jeff Davis wrote:
> On Tue, 2007-05-15 at 10:42 +0100, Heikki Linnakangas wrote:
> > Luke Lonergan wrote:
> > > 32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2 cache
> > > effect.
> > >
> > > How about using 256/blocksize?
> >
> > Sounds rea
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Alvaro Herrera wrote:
2. decide that the standard is braindead and just omit dumping the
grantor when it's no longer available, but don't remove
pg_auth_members.grantor
Which do people feel should be implemented? I can do whatever we
On Tue, May 15, 2007 at 01:18:42PM -0400, Bruce Momjian wrote:
> > In Debian's bug tracking system, when the bug is created (which is done
> > by sending an email to a certain address) it gets a number, and the
> > email is distributed to certain lists. People can then reply to that
> > mail, and
If people want proof that we have had some patches for months, this
email is from Simon from January, 2007.
---
Simon Riggs wrote:
> On Mon, 2007-01-01 at 19:04 -0500, Bruce Momjian wrote:
>
> > I will start processing the
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > Joshua D. Drake wrote:
>
> >>> One good thing is that we have community discussion this now, so at
> >>> least we are focusing on it.
> >>>
> >> Agreed, but it certainly is not a critical mass problem either. We are
> >> starting to bounce off the
Bruce Momjian wrote:
Joshua D. Drake wrote:
One good thing is that we have community discussion this now, so at
least we are focusing on it.
Agreed, but it certainly is not a critical mass problem either. We are
starting to bounce off the wall, and are starting to take a step back to
reflec
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > Oleg Bartunov wrote:
> > This is a good example of how developers can get frustrated. Pushing a
> > patch to 8.4 that was completed before 8.3 feature freeze is guaranteed
> > to add to that --- and if we lose our developers, we might as well shut
Alvaro Herrera wrote:
Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
developed outside of core. Don't get me wrong I like the feature but it
can take advantage of facilities outside of core.
url fixed - I wonder why we
Bruce Momjian wrote:
Oleg Bartunov wrote:
This is a good example of how developers can get frustrated. Pushing a
patch to 8.4 that was completed before 8.3 feature freeze is guaranteed
to add to that --- and if we lose our developers, we might as well shut
down the PostgreSQL project.
Let's no
Bruce Momjian wrote:
> Stefan Kaltenbrunner wrote:
> > > PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
> > > developed outside of core. Don't get me wrong I like the feature but it
> > > can take advantage of facilities outside of core.
> >
> > url fixed - I wonder why w
Alvaro Herrera wrote:
> Stefan Kaltenbrunner wrote:
> > Alvaro Herrera wrote:
> > > Stefan Kaltenbrunner wrote:
> > >> Joshua D. Drake wrote:
> > >
> > >>> PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
> > >>> developed outside of core. Don't get me wrong I like the feat
Stefan Kaltenbrunner wrote:
> > PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
> > developed outside of core. Don't get me wrong I like the feature but it
> > can take advantage of facilities outside of core.
>
> url fixed - I wonder why we had so much of them and all tho
Oleg Bartunov wrote:
> On Tue, 15 May 2007, Joshua D. Drake wrote:
>
> > Tsearch2 in core. I know that Tom has some reservations, he I and Treat all
> > commented on how it was done and to my knowledge those reservations have
> > not
> > been resolved.
>
> We'd like to know about these reserva
On Tue, 15 May 2007, Joshua D. Drake wrote:
Oleg Bartunov wrote:
On Tue, 15 May 2007, Joshua D. Drake wrote:
Oleg Bartunov wrote:
On Tue, 15 May 2007, Joshua D. Drake wrote:
Tsearch2 in core. I know that Tom has some reservations, he I and Treat
all commented on how it was done and to my k
Joshua D. Drake wrote:
> Oleg Bartunov wrote:
> > On Tue, 15 May 2007, Joshua D. Drake wrote:
> >
> >> Tsearch2 in core. I know that Tom has some reservations, he I and
> >> Treat all commented on how it was done and to my knowledge those
> >> reservations have not been resolved.
> >
> > We'd l
Oleg Bartunov wrote:
On Tue, 15 May 2007, Joshua D. Drake wrote:
Oleg Bartunov wrote:
On Tue, 15 May 2007, Joshua D. Drake wrote:
Tsearch2 in core. I know that Tom has some reservations, he I and
Treat all commented on how it was done and to my knowledge those
reservations have not been res
Chris Browne wrote:
> [EMAIL PROTECTED] (Josh Berkus) writes:
> > Bruce,
> >
> > Realistically I just don't see getting everything in the ToDo patch
> > list in; my vote is that we start deferring stuff for 8.4 if it
> > doesn't have a reviewer, except for items which were submitted early
> > in th
Bruce Momjian wrote:
> Gregory Stark wrote:
> > "Bruce Momjian" <[EMAIL PROTECTED]> writes:
> >
> > > I think the only other thing we _could_ do is to re-open normal 8.3
> > > development, so we aren't hampering updates to trivial parts of the
> > > code. Many of the patches now in the queue had b
Andrew Dunstan wrote:
> >> I think the only other thing we _could_ do is to re-open normal 8.3
> >> development, so we aren't hampering updates to trivial parts of the
> >> code. Many of the patches now in the queue had been developed for months
> >> before 8.3 started, so the hope is that we would
Joshua D. Drake wrote:
> > That is not fair to patch submitters, and pushes the problem to 8.4,
> > where it will be no better.
>
> If it isn't done, it isn't done. We aren't dropping the patch. The patch
> has been accepted, just not reviewed. It is just delayed.
Delayed isn't rejected, but it
Josh Berkus wrote:
> Bruce,
>
> Realistically I just don't see getting everything in the ToDo patch list in;
> my vote is that we start deferring stuff for 8.4 if it doesn't have a
> reviewer, except for items which were submitted early in the cycle (and to
> whom it would be unfair).
It seem
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > I think the only other thing we _could_ do is to re-open normal 8.3
> > development, so we aren't hampering updates to trivial parts of the
> > code. Many of the patches now in the queue had been developed for months
> > befo
On Tue, 15 May 2007, Joshua D. Drake wrote:
Oleg Bartunov wrote:
On Tue, 15 May 2007, Joshua D. Drake wrote:
Tsearch2 in core. I know that Tom has some reservations, he I and Treat
all commented on how it was done and to my knowledge those reservations
have not been resolved.
We'd like to
Aidan Van Dyk wrote:
>
> > They are not stable. The items should point to the archives, which are
> > supposedly more stable. (I had already fixed one item in PatchStatus
> > this morning). Really it would be much nicer to have links using the
> > Message-Id but I doubt that's at all doable.
>
Joshua D. Drake wrote:
> Bruce Momjian wrote:
>
> >> In Debian's bug tracking system, when the bug is created (which is done
> >> by sending an email to a certain address) it gets a number, and the
> >> email is distributed to certain lists. People can then reply to that
> >> mail, and send messa
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
>
> > > In Debian's bug tracking system, when the bug is created (which is done
> > > by sending an email to a certain address) it gets a number, and the
> > > email is distributed to certain lists. People can then reply to th
Stefan Kaltenbrunner wrote:
>> They are not stable. The items should point to the archives, which are
>> supposedly more stable. (I had already fixed one item in PatchStatus
>> this morning). Really it would be much nicer to have links using the
>> Message-Id but I doubt that's at all doable.
>
Stefan Kaltenbrunner wrote:
> Alvaro Herrera wrote:
> > Stefan Kaltenbrunner wrote:
> >> Joshua D. Drake wrote:
> >
> >>> PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
> >>> developed outside of core. Don't get me wrong I like the feature but it
> >>> can take advantage
> They are not stable. The items should point to the archives, which are
> supposedly more stable. (I had already fixed one item in PatchStatus
> this morning). Really it would be much nicer to have links using the
> Message-Id but I doubt that's at all doable.
I use this all the time:
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
> > 2. decide that the standard is braindead and just omit dumping the
> >grantor when it's no longer available, but don't remove
> >pg_auth_members.grantor
> >
> > Which do people feel should be implemented? I can do whatever we
> > decide
Alvaro Herrera wrote:
> Stefan Kaltenbrunner wrote:
>> Joshua D. Drake wrote:
>
>>> PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
>>> developed outside of core. Don't get me wrong I like the feature but it
>>> can take advantage of facilities outside of core.
>> url fixe
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
Joshua D. Drake wrote:
PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
developed outside of core. Don't get me wrong I like the feature but it
can take advantage of facilities outside of core.
url fixed - I wonder why
Stefan Kaltenbrunner wrote:
> Joshua D. Drake wrote:
> > PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
> > developed outside of core. Don't get me wrong I like the feature but it
> > can take advantage of facilities outside of core.
>
> url fixed - I wonder why we had s
Oleg Bartunov wrote:
On Tue, 15 May 2007, Joshua D. Drake wrote:
Tsearch2 in core. I know that Tom has some reservations, he I and
Treat all commented on how it was done and to my knowledge those
reservations have not been resolved.
We'd like to know about these reservations. If I understand
Joshua D. Drake wrote:
[...]
> Concurrent psql, nifty but still trying to decide on actual interface.
>
> Full Page Writes Improvement, doesn't actually do anything *yet* (as far
> as I can tell) it just makes it so something can be done in the future.
> It is also apparently a small patch.
>
>
On Tue, 15 May 2007, Joshua D. Drake wrote:
Tsearch2 in core. I know that Tom has some reservations, he I and Treat all
commented on how it was done and to my knowledge those reservations have not
been resolved.
We'd like to know about these reservations. If I understand you mean there
are i
I wrote:
I propose to unbreak this contrib module for machines that don't have
uuid.h installed in a directory called ossp (e.g. fc6), by changing
#include
to
#include
People who *do* have it installed in such a directory can add to the
build with a --with-includes configure directive.
[EMAIL PROTECTED] (Josh Berkus) writes:
> Bruce,
>
> Realistically I just don't see getting everything in the ToDo patch
> list in; my vote is that we start deferring stuff for 8.4 if it
> doesn't have a reviewer, except for items which were submitted early
> in the cycle (and to whom it would be u
We have new patch available
http://www.sigaev.ru/misc/tsearch_core-0.47.gz
to sync with CVS HEAD.
Oleg
On Tue, 15 May 2007, Joshua D. Drake wrote:
Bruce Momjian wrote:
Based on our progress during this feature freeze, we will not complete
the feature freeze until August/September. I think we
Bruce Momjian wrote:
In Debian's bug tracking system, when the bug is created (which is done
by sending an email to a certain address) it gets a number, and the
email is distributed to certain lists. People can then reply to that
mail, and send messages to [EMAIL PROTECTED] and it gets tracked
Gregory Stark wrote:
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
I think the only other thing we _could_ do is to re-open normal 8.3
development, so we aren't hampering updates to trivial parts of the
code. Many of the patches now in the queue had been developed for months
before 8.3 start
That is not fair to patch submitters, and pushes the problem to 8.4,
where it will be no better.
If it isn't done, it isn't done. We aren't dropping the patch. The patch
has been accepted, just not reviewed. It is just delayed.
Sure it is, if we have a short release cycle. There are plenty of
On May 11, 1:16 pm, "Erik 2.0" <[EMAIL PROTECTED]> wrote:
Is pg_comparator the only project out there that does what it does? I
tried patching it, and it seems OK, but I'm not terribly confident in
my patch. I'm hoping someone will tell me there's a great table-
driven rsync out there that ev
Bruce,
Realistically I just don't see getting everything in the ToDo patch list in;
my vote is that we start deferring stuff for 8.4 if it doesn't have a
reviewer, except for items which were submitted early in the cycle (and to
whom it would be unfair).
If that means shortening the 8.4 cycle
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > In Debian's bug tracking system, when the bug is created (which is done
> > by sending an email to a certain address) it gets a number, and the
> > email is distributed to certain lists. People can then reply to that
> > mail, and send messages to
Gregory Stark wrote:
>
> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark wrote:
> >>
> >> When starting up a postmaster from an older build on a database initialized
> >> with a newer build I'm getting the following errors. I think I saw the same
> >> thing earlier going in the
On Tue, 2007-05-15 at 10:42 +0100, Heikki Linnakangas wrote:
> Luke Lonergan wrote:
> > 32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2 cache
> > effect.
> >
> > How about using 256/blocksize?
>
> Sounds reasonable. We need to check the effect on the synchronized
> scans, though.
>
Alvaro Herrera wrote:
> Joshua D. Drake wrote:
>
> > >Also, if I want to discuss renaming something or cleaning up some code,
> > >do we create a tracker item for that or do we have a developer email
> > >list to discuss such issues?
> >
> > In the most conformist sense yes, but I can tell you t
Joshua D. Drake wrote:
> FYI, whoever did that Todo:Patch status, Bravo! That is easily one of
> the smallest but best improvements to the process I have seen in recent
> memory.
well bruce asked for something like that:
http://archives.postgresql.org/pgsql-hackers/2007-05/msg00249.php
and I sim
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Joshua D. Drake wrote:
>> Bruce Momjian wrote:
>> > Based on our progress during this feature freeze, we will not complete
>> > the feature freeze until August/September. I think we need adjust
>> > expectations about an 8.3 release date, and decide
Joshua D. Drake wrote:
> >Also, if I want to discuss renaming something or cleaning up some code,
> >do we create a tracker item for that or do we have a developer email
> >list to discuss such issues?
>
> In the most conformist sense yes, but I can tell you that generally
> isn't how CMD does
Joshua D. Drake wrote:
> > Patch status:
> >
> > http://developer.postgresql.org/index.php/Todo:PatchStatus
>
> If... this is actually a problem (I leave to other committers and
> reviewers to comment) then I suggest we push all patches without a
> reviewer as of now to 8.4.
>
> Leaving on
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > Based on our progress during this feature freeze, we will not complete
> > the feature freeze until August/September. I think we need adjust
> > expectations about an 8.3 release date, and decide if we want to
> > radically change our work process.
Richard Huxton wrote:
Hiroshi Inoue wrote:
Florian G. Pflug wrote:
I think there should be a big, fat warning that self-referential
updates have highly non-obvious behaviour in read-committed mode,
and should be avoided.
It seems pretty difficult for PostgreSQL rule system to avoid such
kin
Bruce Momjian wrote:
To follow up on this, if you look at how TODO items are created, they
often come out of discussion threads, and sometimes more than one idea
comes from a discussion thread. If we moved to a trackers system, how
would we handle that?
We have the discussion on list, if it w
Hiroshi Inoue wrote:
Florian G. Pflug wrote:
I think there should be a big, fat warning that self-referential
updates have highly non-obvious behaviour in read-committed mode,
and should be avoided.
It seems pretty difficult for PostgreSQL rule system to avoid such
kind of updates. I'm suspi
Bruce Momjian wrote:
Based on our progress during this feature freeze, we will not complete
the feature freeze until August/September. I think we need adjust
expectations about an 8.3 release date, and decide if we want to
radically change our work process.
Basically, to make a release anywhere
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> I think the only other thing we _could_ do is to re-open normal 8.3
> development, so we aren't hampering updates to trivial parts of the
> code. Many of the patches now in the queue had been developed for months
> before 8.3 started, so the hope is th
While testing the buffer ring patch, I noticed that bulk inserts with
both INSERT and COPY pin and unpin the buffer they insert to for every
tuple. That means that the usage_count of all those buffers are bumped
up to 5. That's gotta be bad if you try to run a COPY concurrently with
other activ
Based on our progress during this feature freeze, we will not complete
the feature freeze until August/September. I think we need adjust
expectations about an 8.3 release date, and decide if we want to
radically change our work process.
Basically, to make a release anywhere near July, we need 10x
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>>
>> When starting up a postmaster from an older build on a database initialized
>> with a newer build I'm getting the following errors. I think I saw the same
>> thing earlier going in the opposite direction too. Shouldn't the
To follow up on this, if you look at how TODO items are created, they
often come out of discussion threads, and sometimes more than one idea
comes from a discussion thread. If we moved to a trackers system, how
would we handle that?
Also, if I want to discuss renaming something or cleaning up so
Russell Smith wrote:
> Alvaro Herrera wrote:
> >Alvaro Herrera wrote:
> >
> >
> >>2. decide that the standard is braindead and just omit dumping the
> >> grantor when it's no longer available, but don't remove
> >> pg_auth_members.grantor
> >>
> >>Which do people feel should be implemented?
Gregory Stark wrote:
>
> When starting up a postmaster from an older build on a database initialized
> with a newer build I'm getting the following errors. I think I saw the same
> thing earlier going in the opposite direction too. Shouldn't there be some
> earlier errors firing from the control f
I propose to unbreak this contrib module for machines that don't have
uuid.h installed in a directory called ossp (e.g. fc6), by changing
#include
to
#include
People who *do* have it installed in such a directory can add to the
build with a --with-includes configure directive.
If someon
When starting up a postmaster from an older build on a database initialized
with a newer build I'm getting the following errors. I think I saw the same
thing earlier going in the opposite direction too. Shouldn't there be some
earlier errors firing from the control file version number?
[EMAIL PRO
On Wed, May 09, 2007 at 12:46:52PM +0100, Dave Page wrote:
> >Unfortunately I do not have access to a Vista system I could use to test
> >and track this one down.
>
> I'm happy to run any tests you like.
Dave, could you please apply this small patch to pgtypeslib/datetime.c.
I still have no clue
Luke Lonergan wrote:
32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2 cache
effect.
How about using 256/blocksize?
Sounds reasonable. We need to check the effect on the synchronized
scans, though.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---
Heikki,
32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2 cache
effect.
How about using 256/blocksize?
- Luke
> -Original Message-
> From: Heikki Linnakangas [mailto:[EMAIL PROTECTED] On
> Behalf Of Heikki Linnakangas
> Sent: Tuesday, May 15, 2007 2:32 AM
> To: PostgreSQL-d
Just to keep you guys informed, I've been busy testing and pondering
over different buffer ring strategies for vacuum, seqscans and copy.
Here's what I'm going to do:
Use a fixed size ring. Fixed as in doesn't change after the ring is
initialized, however different kinds of scans use different
Alvaro Herrera wrote:
Alvaro Herrera wrote:
2. decide that the standard is braindead and just omit dumping the
grantor when it's no longer available, but don't remove
pg_auth_members.grantor
Which do people feel should be implemented? I can do whatever we
decide; if no one has a stro
Andrew Dunstan wrote:
>
>
> Dave Page wrote:
>>
>> 1) There appears to be no way to specify the default port number in the
>> MSVC build. The buildfarm passes it to configure for regular builds,
>> which obviously isn't run in VC++ mode, thus leaving the build on 5432.
>>
>>
>>
>
> I have com
98 matches
Mail list logo
