"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Well the problem is, it isn't the guy that sent the patch that is the
> idiot. That guys has zero control over the matter, the signature is
> going to be tacked on at the MTA level.
Sure, I know that and you know that. The problem we have to worry a
Darcy Buskermolen wrote:
> I'm observing high CPU usage (95%) of a 2.6GHz opteron by the stats collector
> on an 8.2.3 box investigation has lead me to belive that the stats file is
> written a lot more often that once every 500ms the following shows this
> behavior.
Any thoughts on the below
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> ... In regards to your idea of a filter, there is no reason why
>> we couldn't install a filter that checks for signatures with specific
>> legal words and strips said signature automatically, responding to the
>> sender that we did
"Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> At some point it might make sense to convert the FSM into a bitmap; that
> way everything just scales with database size.
> In the meantime, I'm not sure if it makes sense to tie the FSM size to
> the DSM size, since each FSM page requires 48x the stora
> Not that I think that anyone owning both a law degree and a computer
> in 2007 should legitimately be able to plead innocence here. FAST
> Australia's lawyers are making themselves look like idiots, and the
> same for every other company tacking on such notices. I think the
> real bottom line
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> ... In regards to your idea of a filter, there is no reason why
> we couldn't install a filter that checks for signatures with specific
> legal words and strips said signature automatically, responding to the
> sender that we did so.
The problem is t
> "Warren" == Warren Turkal <[EMAIL PROTECTED]> writes:
Warren> Is it possible to obtain a mirror of the CVS repository?
I use CVSup to locally mirror the repo. They've had the repo
available via CVSup for some years now.
I use this .cvsup file:
,(/mirror/CvsUp/Postgresql/pgsql.cvsup)
>> Yes, I do. If there is an explicit claim, like an email footer or a
>> copyright in the code, we do try to nail that down.
>
> AFAICT, the footer in question tries to make it illegal for us even to
> have the message in our mail archives. If I were running the PG lists,
> I would install fil
"Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> > I'd like to add some kind of logical flavors to max_fsm_pages
> > and max_dsm_pages.
>
> In the meantime, I'm not sure if it makes sense to tie the FSM size to
> the DSM size, since each FSM page requires 48x the storage of a DSM
> page. I think there
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Neil Conway wrote:
>> For the case in question, sure, requiring some clarification from FJ
>> would be reasonable. But more broadly, my point is that I think you're
>> fooling yourself if you think that requiring a disclaimer or explicit
>> transfer of co
On Wed, February 28, 2007 06:59, Jim C. Nasby wrote:
> On Tue, Feb 27, 2007 at 05:18:28PM -0500, Bruce Momjian wrote:
>> I think we will remove fsync in favor of the new delay, and allow -1 to
>> be the same behavior as fsync off.
>
> Well, presumably we'd still allow fsync for some number of vers
I wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I'm really curious to know how people feel about the varlena patch.
> One thing I think we could do immediately is apply the change to replace
> "VARATT_SIZEP(x) = len" with "SET_VARSIZE(x, len)" --- that would
> considerably reduce the size
On Tue, 27 Feb 2007, Henry B. Hotz wrote:
Question: are there any corresponding deadlines for the Java client code
that I need to worry about?
The JDBC driver will release a new version at the same time as the server,
but we don't have nearly as strict rules about feature freeze/beta. We
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'd be happier if the DSM content could be
>> treated as just a hint.
> If we don't have a frozen state, we can't use the DSM to implement
> index-only scans.
To implement index-only scans, the DSM would have to be expected to
p
Henry B. Hotz wrote:
>
> On Feb 23, 2007, at 1:24 PM, Joshua D. Drake wrote:
>
>> Henry Hotz: GSSAPI (with Magnus)
>
> Progressing. Had hoped to have alpha patches by March 1, but I just got
> handed a proposal that I have to do by then. I trust it's OK to send
> the first version in next week
Would you like a krb5.h file for Solaris 9-10 that will allow you to
"break into" the "hidden" library?
Also S10u4 won't be out until this summer. I'd say the answer is
currently "no". It's known by Sun that Postgres will compile against
their Kerberos libraries though.
On Feb 23, 2007,
On Feb 23, 2007, at 1:24 PM, Joshua D. Drake wrote:
Henry Hotz: GSSAPI (with Magnus)
Progressing. Had hoped to have alpha patches by March 1, but I just
got handed a proposal that I have to do by then. I trust it's OK to
send the first version in next week?
No real issues, except I ha
Galy Lee <[EMAIL PROTECTED]> writes:
> If we can stop at any point, we can make maintenance memory large
> sufficient to contain all of the dead tuples, then we only need to
> clean index for once. No matter how many times vacuum stops,
> indexes are cleaned for once.
I beg your pardon? You're th
Paul Silveira wrote:
> Hello,
>
> I just wanted to voice my opinion for this feature... I've implemented a
> few Production applicaitons with PostgreSQL now and would die for that
> feature. Right now, I am constantly trying to find way's to make my data
> more available.
Paul unfortunately yo
Tom Lane wrote:
> Huh? There is no extra cost in what I suggested; it'll perform
> exactly the same number of index scans that it would do anyway.
The things I wanted to say is that:
If we can stop at any point, we can make maintenance memory large
sufficient to contain all of the dead tuples,
On Wed, 28 Feb 2007, John Bartlett wrote:
> Hi,
>
> A list of ctids is stored in the file.
I would have thought these would be stored in memory. If the set got
large, you'd use a temporary file the way other systems which overflow to
disk do?
>
> The file is used to store the ctids during an upd
On Wed, 28 Feb 2007 09:48, Bruce Momjian wrote:
[Added a subejct line]
> FYI, I am not going to be comfortable accepting a final patch that
> contains this email signature:
>
> This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN
> 27 003 693 481. It is confidentia
Hello,
I just wanted to voice my opinion for this feature... I've implemented a
few Production applicaitons with PostgreSQL now and would die for that
feature. Right now, I am constantly trying to find way's to make my data
more available. I've even resulted to using pg_dump to create read onl
Hi,
A list of ctids is stored in the file.
The file is used to store the ctids during an updatable cursor transaction.
It is set up as a permanent file as it has a potential lifetime of
preserving data between crashes of the backend. Temporary files tend to be
used for data that is defined wit
Galy Lee <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ... or set a flag to stop at the next cycle-completion point.
> The extra cost to clean indexes may prevent this approach to work in
> practices.
Huh? There is no extra cost in what I suggested; it'll perform
exactly the same number of in
On 2/27/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
I suggested a while back implementing torn page detection by writing a
sequential number ever 512 bytes in the blocks. (I was talking about WAL at
the time but the same principle applies.) Do it at the smgr layer using
readv/writev and the uppe
Neil Conway wrote:
> On Tue, 2007-02-27 at 16:20 -0800, Joshua D. Drake wrote:
> > Thus we may literally not have rights to the code. Do you really want to
> > go down the path of in 2 years, Fujitsu (No offense Fujitsu), but you
> > are the topic) decides that the code they provided is owned by th
"Josh Berkus" writes:
> It's a question of whether your HW+OS can guarentee no torn page writes for
> the xlog.
no, the data files.
torn pages in the xlog is also a problem but we protect ourselves with a CRC
and stop replay if it the CRC doesn't match. So the cost there is a bit of
cpu, not
Bruce Momjian wrote:
> Joshua D. Drake wrote:
>> Gregory Stark wrote:
>>> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>>>
>> On 2/27/07, Josh Berkus wrote:
>>> I see no reason to implement it if there is no performance gain.
However, I strongly concur that we need at least some evid
Tom Lane wrote:
> Saving the array is
> expensive both in runtime and code complexity, and I don't believe we
> can trust it later --- at least not without even more expensive-and-
> complex measures, such as WAL-logging every such save :-(
I don’t understand well the things you are worrying about
On Tue, 2007-02-27 at 16:20 -0800, Joshua D. Drake wrote:
> Thus we may literally not have rights to the code. Do you really want to
> go down the path of in 2 years, Fujitsu (No offense Fujitsu), but you
> are the topic) decides that the code they provided is owned by them and
> they didn't give u
"Josh Berkus" writes:
> OK. I've seen no performance numbers yet though. It just seems to me that
> any performance patch proposal should start a discussion of what amount of
> performance we expect to gain.
There exist proposals that can be prototyped and measured to see what
potential they
Jeff,
> Is that an OS-dependent parameter? I always assumed it depended entirely
> on hardware. I have no way to test it for myself though, so I just leave
> full_page_writes=on to be safe.
It's a question of whether your HW+OS can guarentee no torn page writes for
the xlog. Running on Sun hard
On Tue, 2007-02-27 at 17:40 -0800, Josh Berkus wrote:
> All,
>
> > > But we do don't we? fsync = off, full_page_writes = off?
>
> BTW, our testing seems to indicate that full_page_writes = off is safe on
> Solaris 10 on good hardware. At least, we haven't been able to break it yet.
>
Is that
All,
> > But we do don't we? fsync = off, full_page_writes = off?
BTW, our testing seems to indicate that full_page_writes = off is safe on
Solaris 10 on good hardware. At least, we haven't been able to break it yet.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(
Joshua D. Drake wrote:
> Gregory Stark wrote:
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> >
> On 2/27/07, Josh Berkus wrote:
> > I see no reason to implement it if there is no performance gain.
> >
> >> However, I strongly concur that we need at least some evidence. It could
> >
Tom Lane wrote:
>One problem with it is that a too-small target would result in vacuum
>proceeding to scan indexes after having accumulated only a few dead
>tuples, resulting in increases (potentially enormous ones) in the total
>work needed to vacuum the table completely.
Yeah. This is also my bi
Gregory Stark wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>
On 2/27/07, Josh Berkus wrote:
> I see no reason to implement it if there is no performance gain.
>
>> However, I strongly concur that we need at least some evidence. It could
>> easily be that a misstep in the code,
Tom,
> One of the things that's really attractive about the proposed mode is
> that it does *not* create a risk of data corruption
Oh, ok. That wasn't how I understood Simon's case.
> I agree that we ought to look at some performance numbers before
> accepting the patch, but I think Josh's a
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>>> On 2/27/07, Josh Berkus wrote:
I see no reason to implement it if there is no performance gain.
> However, I strongly concur that we need at least some evidence. It could
> easily be that a misstep in the code, causes a loop over the w
Warren Turkal wrote:
On Tuesday 27 February 2007 13:50, Andrew Dunstan wrote:
You know, you can prune what is rsynced.
I am not sure why you brought this up, but yes I did know this.
Well I thought it might be useful to prune that directory you were
having trouble with. But we h
Warren Turkal wrote:
> On Tuesday 27 February 2007 12:26, Bruce Momjian wrote:
>> OK, I definately had added the semicolons, so I am confused why you
>> don't see them. Anyway, I have remove the duplicate 'creation:' lines,
>> so now there is only one line in each file. Let me know how that works
On Tue, Feb 27, 2007 at 07:17:37PM -0500, Bruce Momjian wrote:
> > Actually, I don't know that combining both settings is a wise move. The
> > delay should still provide crash protection, whereas with fsync=off
> > you've got absolutely no protection from anything. That's a huge
> > difference, and
Neil Conway wrote:
> On Tue, 2007-02-27 at 14:52 -0800, Joshua D. Drake wrote:
>> Gonna have to concur with that. Not that the sig is legally binding
>> anyway, we do need to have a disclaimer in the email stating that you
>> are assigning to PGDG
>
> I think it's pretty silly to start caring abou
Jim C. Nasby wrote:
> On Tue, Feb 27, 2007 at 05:18:28PM -0500, Bruce Momjian wrote:
> > Jim C. Nasby wrote:
> > > On Mon, Feb 26, 2007 at 10:56:58PM +, Simon Riggs wrote:
> > > > 2. remove fsync parameter
> > >
> > > Why? Wouldn't fsync=off still speed up checkpoints? ISTM you'd still
> > > w
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Is there any reason not to make these casts implicit?
To the extent that you're trying to provide operators that should be
indexable, that won't solve the problem.
I'm unconvinced that these casts should be implicit anyway, as the types
are really cons
On Tue, Feb 27, 2007 at 05:18:28PM -0500, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > On Mon, Feb 26, 2007 at 10:56:58PM +, Simon Riggs wrote:
> > > 2. remove fsync parameter
> >
> > Why? Wouldn't fsync=off still speed up checkpoints? ISTM you'd still
> > want this for things like database
On Tue, Feb 20, 2007 at 04:22:27PM -0500, Bruce Momjian wrote:
> Added to TODO:
>
> * Add missing operators for geometric data types
>
> Some geometric types do not have the full suite of geometric
> operators,
> e.g. box @> point
>
I've started looking at this, and
Neil Conway wrote:
> On Tue, 2007-02-27 at 14:52 -0800, Joshua D. Drake wrote:
> > Gonna have to concur with that. Not that the sig is legally binding
> > anyway, we do need to have a disclaimer in the email stating that you
> > are assigning to PGDG
>
> I think it's pretty silly to start caring a
On Tue, 2007-02-27 at 14:52 -0800, Joshua D. Drake wrote:
> Gonna have to concur with that. Not that the sig is legally binding
> anyway, we do need to have a disclaimer in the email stating that you
> are assigning to PGDG
I think it's pretty silly to start caring about this now. Do you think
tha
I have found some interesting results from my tests with the
Synchronized Scan patch I'm working on.
The two benefits that I hope to achieve with the patch are:
(1) Better caching behavior with multiple sequential scans running in
parallel
(2) Faster sequential reads from disk and less seeking
I
Bruce Momjian wrote:
> FYI, I am not going to be comfortable accepting a final patch that
> contains this email signature:
>
> This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN
> 27 003 693 481. It is confidential to the ordinary user of the email
> address
FYI, I am not going to be comfortable accepting a final patch that
contains this email signature:
This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN
27 003 693 481. It is confidential to the ordinary user of the email
address to which it was addressed
Warren Turkal wrote:
> On Tuesday 27 February 2007 12:26, Bruce Momjian wrote:
>> OK, I definately had added the semicolons, so I am confused why you
>> don't see them. Anyway, I have remove the duplicate 'creation:' lines,
>> so now there is only one line in each file. Let me know how that works
On Tuesday 27 February 2007 13:50, Andrew Dunstan wrote:
> You know, you can prune what is rsynced.
I am not sure why you brought this up, but yes I did know this.
> my rsync line looks like this:
>
> rsync -avzCH --delete --exclude-from=/home/cvsmirror/pg-exclude
> anoncvs.postgresql.org::pgsq
Bruce Momjian wrote:
> Jonah H. Harris wrote:
>> On 2/27/07, Josh Berkus wrote:
>>> You're missing my point, which is that nobody has demonstrated that there
>>> is any real performance gain from this. I see no reason to implement it
>>> if there is no performance gain.
>> While I'll back your re
Jim C. Nasby wrote:
> On Mon, Feb 26, 2007 at 10:56:58PM +, Simon Riggs wrote:
> > 2. remove fsync parameter
>
> Why? Wouldn't fsync=off still speed up checkpoints? ISTM you'd still
> want this for things like database restores.
I think we will remove fsync in favor of the new delay, and allo
Jonah H. Harris wrote:
> On 2/27/07, Josh Berkus wrote:
> > You're missing my point, which is that nobody has demonstrated that there
> > is any real performance gain from this. I see no reason to implement it
> > if there is no performance gain.
>
> While I'll back your request for results, it
Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > COMMIT NOWAIT can co-exist with the normal form of COMMIT and does not
> > threaten the consistency or robustness of other COMMIT modes. Read that
> > again and think about it, before we go further, please.
>
> I read that, and though
I'm observing high CPU usage (95%) of a 2.6GHz opteron by the stats collector
on an 8.2.3 box investigation has lead me to belive that the stats file is
written a lot more often that once every 500ms the following shows this
behavior.
PostgreSQL 8.2.3 on x86_64-redhat-linux-gnu, compiled by G
On 2/27/07, Josh Berkus wrote:
You're missing my point, which is that nobody has demonstrated that there
is any real performance gain from this. I see no reason to implement it
if there is no performance gain.
While I'll back your request for results, it seems nearly impossible
to expect no p
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Josh Berkus wrote:
>> It seriously narrows down the problem space to know that PostgreSQL does
>> *not*
>> allow data loss if it's physically possible to prevent it.
> But we do don't we? fsync = off, full_page_writes = off?
One of the things that
Warren Turkal wrote:
On Tuesday 27 February 2007 12:26, Bruce Momjian wrote:
OK, I definately had added the semicolons, so I am confused why you
don't see them. Anyway, I have remove the duplicate 'creation:' lines,
so now there is only one line in each file. Let me know how that works.
I am not sure about some of this. The Oracle option does not change the
engine fsync behavior I believe. All that is changed is whether the client
side waits for the complete of the fsync or not. If this is true, the data
store, logs, etc, are all protected. The user may still experience a d
Joshua D. Drake wrote:
> 2. We have to accept that not everyone wants IRON clad data integrity.
> We have many, many options for dealing with that now, including PITR and
> REPLICATION.
100% agreed - our own stats collector is extremely similar (in that it
may drop data under high load) to a syst
On Tuesday 27 February 2007 12:26, Bruce Momjian wrote:
> OK, I definately had added the semicolons, so I am confused why you
> don't see them. Anyway, I have remove the duplicate 'creation:' lines,
> so now there is only one line in each file. Let me know how that works.
Everything looks good n
Josh Berkus wrote:
> Simon,
>
> One of the things I love about doing informal online user support in the
> PostgreSQL community, and formal user support for Sun's customers, is the
> almost-ironclad guarentee that if a user has a corrupt database or data loss,
> one of three things is true:
> a
Jonah,
> Under Oracle, NOWAIT is an asynchronous commit... anyone that uses it
> should understand that it's still not on-disk and that they can lose
> it in the event of a failure. That's what Oracle's docs even say.
> It's just a risk vs. reward trade off.
You're missing my point, which is tha
On 2/27/07, Josh Berkus wrote:
It seriously narrows down the problem space to know that PostgreSQL does *not*
allow data loss if it's physically possible to prevent it.
Seems like we're trying to protect users from themselves again. This
is not a PostgreSQL database issue; it's a feature desi
Warren Turkal wrote:
> On Monday 26 February 2007 10:13, Bruce Momjian wrote:
> > Warren Turkal wrote:
> > > On Saturday 24 February 2007 16:47, Chad Wagner wrote:
> > > > head pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v
> > > > head ? ?1.3;
> > > > access;
> > > > symbols
> > > > ? ? ? ? R
> There are 2 GUCs that would control the behaviour here:
>
> transaction_guarantee = on | off
> has been enabled. Use this parameter with care; if you find
> yourself wanting to use this parameter all of the time you
> should consult a psychiatrist or change open source databas
On Feb 26, 2007, at 12:49 PM, Alvaro Herrera wrote:
Jim C. Nasby wrote:
That's why I'm thinking it would be best to keep the maximum size of
stuff for the second worker small. It probably also makes sense to
tie
it to time and not size, since the key factor is that you want it
to hit
the
On Tue, 27 Feb 2007, Tom Lane wrote:
No, because for the "standard" regression behavior we have variant
result files both with and without the DST law change: see horology and
horology_1. The issue only comes up for machines that were matching to
horology-no-DST-before-1970.out (which may be
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I've looked into cutting back on the implicit casts to text, which
> exposed the following little gem.
> The expressions
> 'abc' || 34
> 34 || 'abc'
> would no longer work, with the following error message:
> ERROR: 22P02: array value must start wit
On Tue, 2007-02-27 at 11:32 -0600, Jim C. Nasby wrote:
> On Tue, Feb 27, 2007 at 10:49:32AM +, Simon Riggs wrote:
> > > I dislike introducing new nonstandard syntax ("Oracle compatible" is not
> > > standard). If we did this I'd vote for control via a GUC setting only;
> > > I think that is mo
Martijn van Oosterhout wrote:
> I think it might be useful to at least encourage people wanting to an
> SoC project to create page on the developer wiki selling their idea.
> You know, questions like: why do we want it? Where do you expect it
> to be included? etc.
They are expected to do as much
On 2/27/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Pavan Deolasee wrote:
> - What do we do with the LP_DELETEd tuples at the VACUUM time ?
> In this patch, we are collecting them and vacuuming like
> any other dead tuples. But is that the best thing to do ?
Since they don't need index cl
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> In the following code from hstore_io.c, is HStore a varlena?
Sorry, thinko, it is a varlena but "size" isn't the first struct field,
there's a "len" field first.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
-
On Tue, 2007-02-27 at 12:23 -0500, Tom Lane wrote:
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> It occurs to me that we may be thinking about this the wrong way
> >> entirely. Perhaps a more useful answer to the problem of using a
> >> defined maintenance window is
Gregory Stark <[EMAIL PROTECTED]> writes:
> I'm really curious to know how people feel about the varlena patch.
One thing I think we could do immediately is apply the change to replace
"VARATT_SIZEP(x) = len" with "SET_VARSIZE(x, len)" --- that would
considerably reduce the size of the patch and a
On Tue, Feb 27, 2007 at 10:49:18AM -0600, Jim C. Nasby wrote:
> I agree we certainly don't want to go designing these projects in
> advance, but I think we could at least ensure that the community buys
> into the concept of each project. ISTM one of the big issues with FD is
> that most people didn
I've looked into cutting back on the implicit casts to text, which
exposed the following little gem.
The expressions
'abc' || 34
34 || 'abc'
would no longer work, with the following error message:
ERROR: 22P02: array value must start with "{" or dimension information
That's because the best
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> So would you set commit_fsync_delay on a per-transaction basis? That
> doesn't make much sense to me... I guess I'm not seeing how you would
> explicitly mark transactions that you didn't want to fsync immediately.
My assumption was that most of the tim
Greg,
> I'm really curious to know how people feel about the varlena patch. In
> particular I know these issues may elicit comment:
Haven't tested yet. Will let you know when I do.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)-
Simon,
One of the things I love about doing informal online user support in the
PostgreSQL community, and formal user support for Sun's customers, is the
almost-ironclad guarentee that if a user has a corrupt database or data loss,
one of three things is true:
a) they didn't apply some recommen
On Tue, Feb 27, 2007 at 10:49:32AM +, Simon Riggs wrote:
> > I dislike introducing new nonstandard syntax ("Oracle compatible" is not
> > standard). If we did this I'd vote for control via a GUC setting only;
> > I think that is more useful anyway, as an application can be made to run
> > with
On Tue, Feb 27, 2007 at 12:12:22PM -0500, Matthew T. O'Connor wrote:
> Jim C. Nasby wrote:
> >On Tue, Feb 27, 2007 at 12:00:41AM -0300, Alvaro Herrera wrote:
> >>Jim C. Nasby wrote:
> >>
> >>>The advantage to keying this to autovac_naptime is that it means we
> >>>don't need another GUC, but after
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It occurs to me that we may be thinking about this the wrong way
>> entirely. Perhaps a more useful answer to the problem of using a
>> defined maintenance window is to allow VACUUM to respond to changes in
>> the vacuum cost d
Jim C. Nasby wrote:
I agree we certainly don't want to go designing these projects in
advance, but I think we could at least ensure that the community buys
into the concept of each project.
Yes, at least for those that go on a suggestion list. And that was my
worry about Warren's suggestion
On Monday 26 February 2007 18:46, Josh Berkus wrote:
> Demian,
>
> > Could you also please share your thoughts on what would be a good
> > student profile- for instance, how much theoretical background and
> > practical experience, for working on a SoC project?
>
> Well, it shouldn't be the student
In the following code from hstore_io.c, is HStore a varlena? In which case is
the following code buggy because it omits to subtract VARHDRSZ from in->size
and therefore is not handling the empty hstore and also starting the loop from
the varlena header instead of the first data byte?
Or if HStore
> Well, the HOT discussion hasn't yet led to an accepted patch ... and I'd
> say its authors still did way too much work before getting the community
> involved. But certainly it's a better model to look at than what the
> FD author did.
That's pretty much the mentor's job. I don't remember who
Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
On Tue, 2007-02-27 at 10:37 -0600, Jim C. Nasby wrote:
... The idea would be to give vacuum a target run time, and it
would monitor how much time it had remaining, taking into account how
long it should take to scan the indexes based on
Kris Jurka <[EMAIL PROTECTED]> writes:
> Shouldn't all of the buildfarm members be failing either before or after
> the patch? That doesn't seem to be the case for any of them.
No, because for the "standard" regression behavior we have variant
result files both with and without the DST law chang
On Tue, 27 Feb 2007, Kris Jurka wrote:
I'll look at an upgrade. Eel is failing as well, but surprisingly canary is
not. Canary hasn't had any updates applied, so why isn't it failing as well:
Shouldn't all of the buildfarm members be failing either before or after
the patch? That doesn
Jim C. Nasby wrote:
On Tue, Feb 27, 2007 at 12:00:41AM -0300, Alvaro Herrera wrote:
Jim C. Nasby wrote:
The advantage to keying this to autovac_naptime is that it means we
don't need another GUC, but after I suggested that before I realized
that's probably not the best idea. For example, I've
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Tue, 2007-02-27 at 10:37 -0600, Jim C. Nasby wrote:
>> ... The idea would be to give vacuum a target run time, and it
>> would monitor how much time it had remaining, taking into account how
>> long it should take to scan the indexes based on how long
On Tue, Feb 27, 2007 at 05:38:39PM +0900, ITAGAKI Takahiro wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
>
> > > If we do UPDATE a tuple, the original page containing the tuple is marked
> > > as HIGH and the new page where the updated tuple is placed is marked as
> > > LOW.
> >
> > Don't y
On Tue, 27 Feb 2007, Tom Lane wrote:
I see that kudu and dragonfly are now failing regression in the 7.3 and
7.4 branches, as a consequence of this patch:
http://archives.postgresql.org/pgsql-committers/2007-02/msg00491.php
Is it reasonable to assume that that machine will soon be patched to
On Tue, Feb 27, 2007 at 12:55:21AM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Yes, DSM would make FSM recovery more important, but I thought it was
> > recoverable now? Or is that only on a clean shutdown?
>
> Currently we throw away FSM during any non-clean restart.
1 - 100 of 139 matches
Mail list logo
