do about stale files and missing files
References:
0 -
http://www.postgresql.org/message-id/200606081508.k58f85m29...@candle.pha.pa.us
1 - http://www.postgresql.org/message-id/8291.1115340...@sss.pgh.pa.us
Ron
--
Command Prompt, Inc. http://www.commandprompt.com/ +1-800-492-2240
PostgreSQL
Tom Lane wrote:
> Simon Riggs writes:
>> It's a major undertaking trying to write software that runs against
>> PostgreSQL for more than one release. We should be making that easier,
>> not harder.
>
> None of the proposals would make it impossible to write a LOCK statement
> that works on all av
Josh Berkus wrote:
>> Mainly, that it's not clear we need it. Nobody's pointed to a concrete
>> failure mechanism that makes it necessary for an existing app to run
>> under fake-SERIALIZABLE mode.
>
> I think it's quite possible that you're right, and nobody depends on
> current SERIALIZABLE beh
Tom Lane wrote:
> argue that there was a regression. It's certainly a performance bug
> though: nobody would expect that giving a query *more* work_mem would
> cause it to run many times slower.
I wouldn't be that surprised - otherwise it'd just be hard-coded to
something large.
Especially since
Josh Berkus wrote:
> On 11/20/10 6:11 PM, Jeff Janes wrote:
>> True, but I think that changing these from their defaults is not
>> considered to be a dark art reserved for kernel hackers, i.e they are
>> something that sysadmins are expected to tweak to suite their work
>> load, just like the shmma
Tom Lane wrote:
> It's possible that the multiply-by-31 method is as good as the
> rotate-and-xor method by that measure, or even better; but it's far from
> obvious that it's better. And I'm not convinced that the multiply
> method has a pedigree that should encourage me to take it on faith.
Sho
Markus Wanner wrote:
> On 09/07/2010 02:16 PM, Robert Haas wrote:
>> practice, this means that the master and standby need to compare notes
>> on the ending WAL location and whichever one is further advanced needs
>> to stream the intervening records to the other.
>
> Not necessarily, no. Remember
Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Sep 3, 2010 at 10:07 AM, Tom Lane wrote:
>>> [ shrug... ] I stated before that the Hot Standby patch is doing
>>> utterly unsafe things in signal handlers. Simon rejected that.
>>> I am waiting for irrefutable evidence to emerge from the field
>>
Robert Haas wrote:
>
> If git had a place to store all the information we care about, that
> would be fine...
>
> There's no "reviewer" header, and there's no concept that a patch
> might have come from the author (or perhaps multiple authors), but
> then have been adjusted by one or more reviewe
Robert Haas wrote:
> On Wed, Jun 16, 2010 at 9:56 PM, Tom Lane wrote:
>> Sorry, I've been a bit distracted by other responsibilities (libtiff
>> security issues for Red Hat, if you must know). I'll get on it shortly.
>
> What? You have other things to do besides hack on PostgreSQL? Shocking!
Tom Lane wrote:
> Robert Haas writes:
>> So... can we get back to coming up with a reasonable
>> definition,
>
> (1) no access to system calls (including file and network I/O)
If a PL has file access to it's own sandbox (similar to what
flash seems to do in web browsers), could that be considere
Jaime Casanova wrote:
> At Saturday, 02/27/2010 on 4:21 pm "Marc G. Fournier" wrote:
>> On Sat, Feb 27, 2010 at 10:45 PM, Alvaro Herrera
>> wrote:
>>> Is there a higher then normal amount of earthquakes happening recently?
>>>
>> Re: the more frequent earthquakes, yeah I was thinking the same t
Lucas wrote:
> I believe that "in core" may be "installed by default" in case of
Those seem like totally orthogonal concepts to me.
A feature may be "in core" but not "installed by default" (like many PLs).
A feature might not be "in core" but "installed" by many installers (say
postgis).
I
Magnus Hagander wrote:
> On Fri, Jan 8, 2010 at 05:22, Ron Mayer wrote:
>> David E. Wheeler wrote:
>>> On Jan 7, 2010, at 1:31 PM, Dave Page wrote:
>>>> No, I'm suggesting the mechanism needs to support source and binary
>>>> distribution. For mo
David E. Wheeler wrote:
> On Jan 7, 2010, at 1:31 PM, Dave Page wrote:
>> No, I'm suggesting the mechanism needs to support source and binary
>> distribution. For most *nix users, source will be fine. For Windows
>> binaries are required.
>
> I would love to follow what Strawberry Perl has done to
Tom Lane wrote:
> Magnus Hagander writes:
>> ...oom_adj...
>
> One interesting thing I read there is:
> Swapped out tasks are killed first. Half of each child's memory size is
> added to the parent's score if they do not share the same memory.
> ^^^
Peter Eisentraut wrote:
> Could we create an option to create index names automatically, so you'd
> only have to write
>
> CREATE INDEX ON foo (a);
>
> which would pick a name like foo_a_idx.
Why wouldn't it default to a name more like:
CREATE INDEX "foo(a)" on foo(a);
which would extend p
+1 for such a feature, simply to avoid the need of
writing a hstore-parser (which wasn't too bad
to write, but it felt unnecessary). Doesn't
matter to me if it's hstore-to-json or hstore-to-xml
or hstore-to-yaml. Just something that parsers are
readily available for.
Heck, I wouldn't mind if hs
Bruce Momjian wrote:
> Well, the bottom line is that this effort should grow the development
> and user community of Postgres --- it if doesn't, it is a failure.
Really? Even if it only allows existing Postgres users and companies to
expand their use into higher security applications IMHO it's a
Tom Lane wrote:
> Why don't you
> just do "\pset format unaligned" (or "\a" if you're lazy)?
That's fair. Now that I see it, I guess I should have been
doing that for copy&paste work anyway.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
Alvaro Herrera wrote:
> Robert Haas escribió:
>> On first blush, I'm inclined to suggest that the addition of + signs
>> to mark continuation lines is a misfeature.
>
> EXPLAIN is a special case. IMHO it should be dealt with accordingly.
>
Is it?
Wouldn't it affect anyone who stuck XML in a tx
Greg Smith wrote:
> That's a step backwards. By providing JSON format, we've also satisfied
> people who want YAML. Ripping out JSON would mean we *only* support
> YAML. There are far many more JSON parsers than YAML parsers, which is
> why I thought the current code committed was good enough.
Josh Berkus wrote:
>> ... YAML for easier readability ...
>
> "almost as good" ... I agree with Kevin that it's more readable.
>
> Again, if there were a sensible way to do YAML as a contrib module, I'd
> go for that, but there isn't.
Perhaps that's be a direction this could take? What would
i
Robert Haas wrote:
> On Thu, Dec 3, 2009 at 5:23 PM, Josh Berkus wrote:
>> Kaigai, you've said that you could get SELinux folks involved in the
>> patch review. I think it's past time that they were; please solicit them.
>
> Actually, we tried that already, in a previous iteration of this
> disc
Joshua D. Drake wrote:
> On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote:
>> "Joshua D. Drake" writes:
>>> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
This is totally separate from the really important question of whether
SE-Linux has a future, and another about whether, if
KaiGai Kohei wrote:
> Needless to say, NEC is also a supporter to develop and maintain
> SE-PgSQL feature. We believe it is a necessity feature to construct
> secure platform for SaaS/Cloud computing, so my corporation has funded
> to develop SE-PgSQL for more than two years.
Rather than "needless
Dave Page wrote:
> On Tue, Dec 1, 2009 at 4:41 PM, Tom Lane wrote:
>>
>> ... 8.1 in RHEL5 ...
+1 for letting 7.* and 8.0 die whenever no-one's
motivated to bother supporting it anymore.
> Presumably you'll be on the hook until 2014 for 8.1 security patches
> I can't see the community wanting to
Tom Lane wrote:
> Andrew Dunstan writes:
>> YAML...
>
> Hmm. So the argument for it is "let's make a machine-readable format
> more human-readable"? I'm not getting the point. People should look
> at the regular text output.
IMHO YAML beats the regular text format for human-readability -
at l
Brendan Jurd wrote:
> 2009/11/29 Bruce Momjian :
>> Wow, we mention 28k modems --- we are legacy software: ;-)
>>
>> This initial checkout is a little slower than simply downloading
>> a tar.gz file; expect it to take 40 minutes
>> or so if you have a 28.8K modem.
>
> Yes, and what ab
Andrew Gierth wrote:
> This query:
>
> select random() from generate_series(1,10) order by random();
> produces sorted output. Should it?
I recall a workaround from a different thread[1] if specifically
were looking for random ordering of random numbers is:
select random() from foo order
Robert Haas wrote:
>
> That wasn't my intention. I really was assuming that we would just
> let those patches drop on the floor, and that they would not be picked
> up either by reviewers or committers.
Surely it should depend on the nature of the patch.
For an extreme strawman, segfault fixes
Is a somewhat related question "how long are the various commercial
support organizations committed to supporting 7.4"?
I guess support companies might support their client's systems
for longer or shorter times than the community patches the old
versions. No doubt it's easier for them if the com
Tom Lane wrote:
> What are the probabilities that the OpenACSes of the world will just
> set the value to "backward compatible" instead of touching their code?
Would postgres get considerably cleaner if a hypothetical 9.0 release
skipped backward compatibility and removed anything that's only
main
lication suites. Seems it'd be good for the postgres
project to similarly communicate that the database kernel
is the core of a platform that's broader than just a
database kernel.
Ron
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Dave Page wrote:
> I never said it wasn't - in fact I said from the outset it was about
> box-checking, and that anyone doing things properly will use
> LDAP/SSPI/Kerberos etc.
I don't understand why the box-checkers can't already check that
box; with the explanation stating "Yes - by using LDAP o
Mark Mielke wrote:
> On 10/15/2009 10:08 AM, Dave Page wrote:
>> ...other
>> DBMSs (and all major operating systems I can think of) offer password
>> policy features as non-client checks...we are compared ...
>
> Not so clear to me. If they're doing strong checks, this means they're
> sending pass
Andrew Gierth wrote:
> I'd appreciate public feedback on:
> - whether conversions to/from a {key,val,key,val,...} array are needed
>(and if there's strong opinions in favour of making them casts; in the
>absence of strong support for that, I'll stick to functions)
Strikes me as an indepen
Robert Haas wrote:
> Heikki Linnakangas wrote:
>> Hannu Krosing wrote:
>>> On Wed, 2009-09-16 at 21:23 +0300, Heikki Linnakangas wrote:
2) Another utility that does something like UPDATE ... WHERE ctid > ? to
> I also wonder whether we should consider teaching regular VACUUM to do
> a little
Josh Berkus wrote:
> I can't find information about HTTPD release planning so I'll take your
> word for it. On the other hand, I have to point out that Apache is
> releasing HTTPD major versions an average of once every 3 years. I
> don't think we want to go to 3 years, do we?
I'd say it depends
Andrew Dunstan wrote:
> In any case, I don't accept this analogy. The mechanics of a Linux
> distribution are very different from the mechanics of a project like
> PostgreSQL. The prominent OSS project that seems to me most like ours is
> the Apache HTTP project.
I'd think that File Systems might
Robert Haas wrote:
> On Tue, Sep 1, 2009 at 9:29 PM, Alvaro
> Herrera wrote:
>> Ron Mayer wrote:
>>> Greg Stark wrote:
>>>> That's what I want to believe. But picture if you have, say a
>>>> 1-terabyte table which is 50% dead tuples and you don&#x
Greg Stark wrote:
>
> That's what I want to believe. But picture if you have, say a
> 1-terabyte table which is 50% dead tuples and you don't have a spare
> 1-terabytes to rewrite the whole table.
Could one hypothetically do
update bigtable set pk = pk where ctid in (select ctid from bigtable
Peter Eisentraut wrote:
> On fre, 2009-08-28 at 20:13 +, Greg Sabino Mullane wrote:
>> Readability and easy editing. All the power of JSON without the
>> annoying quotes, braces, and brackets.
>
> But these are supposed to be machine-readable formats. So readability
> and editability are not
Josh Berkus wrote:
> There's some very good reasons for the health of the project to have
> specific release dates and stick to them.
Help me understand why?
The Linux kernel seems to do fine with a "when it is ready" cycle,
where some releases(2.6.24) take twice the time of others(2.6.28)[1,2]
Andrew Dunstan wrote:
> I don't know of anyone who is likely to want to try out alphas in their
> normal development environments. The client I approached was
> specifically prepared to test beta releases that way.
Perhaps end-users won't, but I think companies who develop software that
works on t
Tom Lane wrote:
> Josh Berkus writes:
>>> That is a slightly alarmist. Who are we going to lose these users to?
>
>> Drizzle. MySQL forks. CouchDB. Any database which has replication
>> which you don't need a professional DBA to understand. Whether or not
>> it works.
>
> You haven't explai
Robert Haas wrote:
> On Wed, Jul 22, 2009 at 2:17 PM, Andrew
> Gierth wrote:
>> Unless I hear any objections I will proceed accordingly...
>
> At this point it's been 12 days since this was written and no updated
> patch has been posted, so I think it's well past time to move this to
> "Returned w
David Fetter wrote:
> On Tue, Aug 11, 2009 at 08:56:38AM -0500, Kevin Grittner wrote:
>> Bruce Momjian wrote:
>>
>>> OK, so it is "warm slave".
Why isn't it just a "read only slave". Do some systems
have read-only slave databases that can't serve as a warm
standby system as well as this one c
I'm curious what advantages there are in building compression into
the database itself, rather than using filesystem-based compression.
I see ZFS articles[1] discuss how enabling compression
improves performance with ZFS; for Linux, Btrfs has compression
features as well[2]; and on Windows NTFS se
Robert Haas wrote:
> If you want to store intelligence data about the war in Iraq and
> intelligence data about the war in Afghanistan, it might not be too
> bad to store them in separate databases, though storing them in the
> same database might also make things simpler for users who have access
Paul Sheer wrote:
> Hadoop backend for PostGreSQL
Resurrecting an old thread, it seems some guys at Yale implemented
something very similar to what this thread was discussing.
http://dbmsmusings.blogspot.com/2009/07/announcing-release-of-hadoopdb-longer.html
> >
> >It's an open source stack t
David Fetter wrote:
>
> 2. Apart from Kohei-san and Stephen Frost, is anybody actually
> interested in having this feature at all?
The features (both MAC, and row-level security), are interesting.
* I've worked with organizations where MAC was a big deal.
* I've had use cases where row-level s
Joshua Brindle wrote:
> How many people are you looking for? Is there a number or are you
> waiting for a good feeling?
Is it individuals or organizations people are looking for?
I see KaiGai wrote "In addition, I (and NEC) can provide our
capability to the PostgreSQL community to keep these secu
Heikki Linnakangas wrote:
> ...
> CREATE TABLE manytomany (aid integer, bid integer);
> CREATE INDEX a_b ON manytomany (aid, bid);
> CREATE INDEX b_a ON manytomany (bid, aid);
> ...
>> new and interesting indexing strategies. Covered indexes are also one
>> kind of materialized view. It may be bett
Josh Berkus wrote:
> I'd suggest that we publish an official policy, with the following dates
> for "EOL":
> 7.4 2009-08-01 ...
> 8.4 2014-08-01
What would such forward-looking statements even mean for a
community-driven project?
I assume for a commercial product, such a statement would mean
Tom Lane wrote:
> "Kevin Grittner" writes:
>> You do, but it's been pretty rare in my experience, and we're
>> considering alternatives which give a lot less flexibility that this.
>
> I dunno about "considering". We've already wasted vastly more time on
> this than it's worth. AFAIR there has
Josh Berkus wrote:
Folks,...the first CF on July 15th.
Would it make the CommitFest easier if there were an additional
column which indicates what CVS-version of Postgres the patch
cleanly applies to?
Perhaps a patch submitter could indicate the CVS date/time
with which he developed the patch.
Bruce Momjian wrote:
Where did you see 8.4 was scheduled to be released around the start of
the year? I never never seen that and would have disputed anyone saying
it publicly.
I think people carefully avoided the word "scheduled", but the
press FAQ on www.postgresql.org did say to expect it i
Tom Lane wrote:
"Joshua D. Drake" writes:
We already push and pull our release dates based are what in the queue,
we just do so informally. Why not just make it part of the process?
I think we used to do it more or less like that, but people didn't like
it because they couldn't do any long-ra
Greg Stark wrote:
Right, that was why my proposed interface was to dump out the explain
plan with the number of loops, row counts seen so far, and approximate
percentage progress.
My thinking was that a human could interpret that to understand where
the bottleneck is if, say you're still on the
Robert Haas wrote:
> On Fri, Jun 5, 2009 at 12:15 PM, Tom Lane wrote:
>> ... but I'm not at all excited about cluttering the
>> long-term project history with a zillion micro-commits. One of the
>> things I find most annoying about reviewing the current commit history
>> is that Bruce has taken a
Markus Wanner wrote:
> The "new branches getting merged up" could work. That is, applying the
> fix to the oldest back-branch which requires the fix first and then
> merge it to all newer ones, including HEAD. However, that would require
> some rethinking: instead of creating bugfix-patches for HEA
Robert Haas wrote:
> But I
> wonder if it would make more sense to include some kind of metadata in
> the commit message (or some other property of the commit? does git
> support that?) to make it not depend on that.
>From elsewhere in this thread[1], 'The "git cherry-pick" ... "-x" flag adds
a n
Robert Haas wrote:
> The problem with making each release a separate directory is that,
> just like using separate repositories, it will defeat one of the main
> strengths of git, which is the ability to move around commits easily.
> git-new-workdir is the only solution to the problem of having mul
Robert Haas wrote:
> And, unfortunately, I'm not sure there's a good solution. Tom could
> create 1 local repository cloned from the origin and then N-1 copies
> cloned with --local from that one, but this sort of defeats the
> purpose of using git, because now if he commits a change to one of
> t
Tom Lane wrote:
> Marko Kreen writes:
>> They cannot be same commits in GIT as the resulting tree is different.
> The way I prepare a patch that has to be back-patched is first to make
> and test the fix in HEAD. Then apply it (using diff/patch and perhaps
> manual adjustments) to the first back
Aidan Van Dyk wrote:
> * Markus Wanner [090602 10:23]:
>> As mentioned before, I'd personally favor *all* of the back-ports to
>> actually be merges of some sort, because that's what they effectively
>> are. However, that also bring up the question of how we are going to do
>> back-patches in
Euler Taveira de Oliveira wrote:
> Robert Haas escreveu:
>> ...EXPLAIN ANALYZE reports the number of rows as an integer... Any
>> chance we could reconsider this decision? I often find myself wanting
>> to know the value that is here called ntuples, but rounding
>> ntuples/nloops off to the neare
Andrew Gierth wrote:
> I have a patch almost done that adds some obvious but currently
> missing functionality to hstore...
> If there's any other features that people find notably missing from
> hstore, I could stick them in too; any requests?
Currently hstore gives me an indexed operator to que
Alvaro Herrera wrote:
> Gregory Stark escribió:
>> Heikki Linnakangas writes:
>>
>>> KaiGai Kohei wrote:
* [..feature description..]
>>> This again falls into the category of trying to have more fine-grained
>>> permissions than vanilla PostgreSQL has
>> Would it make sense to instead of
Tom Lane wrote:
> "Joshua D. Drake" writes:
>> I know we are a little uncomfortable here but KaiGai-San (forgive me if
>> I type that wrong) has proven to be a contributor in his own right,
>
> Not to put too fine a point on it, but: no, he hasn't. Show me one
> significant patch he's contribute
Selena Deckelmann wrote:
> Tom Lane wrote:
>> Greg Sabino Mullane writes:
>>> ...
>>> deprecate -d by having it throw an exception when used.
>>
>> "Deprecate" does not mean "break".
> ...
> While this change may break existing scripts...less painful
Why do people want a failure rather than warni
Robert Haas wrote:
> experience, most bad plans are caused by bad selectivity estimates,
> and the #1 source of bad selectivity estimates is selectivity
> estimates for unknown expressions.
ISTM unknown expressions should be modeled as a range of
values rather than one single arbitrary value.
For
Joshua D. Drake wrote:
> On Thu, 2009-02-05 at 17:08 -0500, Tom Lane wrote:
>> My feeling is that we should be trying to eliminate use-cases for
>> cron-driven vacuuming, not trying to make sure that cron-driven
>> scripts can do anything autovacuum can.
> Agreed. IMO, the user should only have to
Bruce Momjian wrote:
> Josh Berkus wrote:
>> Bruce Momjian wrote:
>>> Josh Berkus wrote:
> Yea, it would take some work but it is an idea.
It's *an* idea,yes. But it introduces as many (or more) problems than
it solves.
>>> Ah, but my problems might be easier solved than the row-lev
Joshua Brindle wrote:
> Nonetheless, this conversation seems moot now that Tom has walled off
> and won't even discuss row-level access controls.
I think that's a bit of an overstatement.
He says he's against them[1] and he says that they are the sticking
point on this patch[2], and that they bre
Stephen Frost wrote:
> And, just to go full circle, row-level access controls are exactly what
> the other enterprise RDBMSs have and is what is used in these security
> circles today. One of the major issues, as I understand it, is to be
> able to use stock applications with multiple security lev
Joshua Brindle wrote:
> Tom Lane wrote:
>> Joshua Brindle writes:
>>> I'm not sure how much it would cut to remove row level access
>>> controls, but I do have some points here. To me, row level access
>>> controls are the most important part, this is the feature that lets us
>>> put secret and to
Tom Lane wrote:
> Heh. The reason we wanted a short 8.3 cycle was so we could push out
> patches that had been held over from 8.2. We are going to have exactly
> no credibility if we tell Simon et al "we're pushing these patches to
> 8.5, but don't worry, it'll be a short release cycle".
>
> I t
Joshua Brindle wrote:
>> FWIW, as you know, sepostgresql is already included in Fedora. You can
>> continue shipping it as a seperate RPM set.
>
> That is non-ideal. Getting the capability in to the standard database
> shipped with RHEL is very important to me and my customers.
Could you speak -
Tom Lane wrote:
>> We do not consider that a short coming, anyone who needs to hide
>> existence of files needs to set up their directory structure to
>> disallow read/search/create on the directories they aren't allowed to
>> discover filenames in.
>
> This seems to me to be exactly parallel to d
Stephen Frost wrote:
> * Gregory Stark (st...@enterprisedb.com) wrote:
>> It does seem weird to simply omit records rather than throw an error and
>> require the user to use a where clause, even if it's something like WHERE
>> pg_accessible(tab).
>
> It is weird from an SQL perspective, I agree wi
Dave Page wrote:
> On Tue, Jan 27, 2009 at 2:01 PM, Peter Eisentraut wrote:
>
>> Updatable views is reverted. I agree that we should reject the rest and
>> prepare a release.
>
> That will send a fine message to those companies that have sponsored
> development work - that we will arbitrarily r
Peter Eisentraut wrote:
> On Tuesday 27 January 2009 00:42:32 Ron Mayer wrote:
>> If it were just as easy for us to pull from a
>> "all 'pending-patches' for-commit-fest-nov that pass regression tests"
>> branch, I'd happily pull from that instead.
Simon Riggs wrote:
> The process works like this: software gets developed, then it gets
> certified. If its not certified, then Undercover Elephant will not be
> used by the secret people. We can't answer the "will it be certified?"
> question objectively yet. If we have someone willing to write th
Tom Lane wrote:
> Hmm, you think selinux people read pgsql-announce? But seriously,
> we *have* been trying to get people's attention for this patch, both
> inside and outside the postgres community, for well over a year now.
> The lack of response has been depressing and (IMHO) telling. Nowhere
Tom Lane wrote:
> Ron Mayer writes:
>> Are we underestimating Kaigai Kohei?
> Perhaps he walks on water, but still I'd like to have more than one
> person who has confidence that this design and implementation are correct.
Totally fair. I know I'm totally unqualified
Tom Lane wrote:
> The problem, in words of one syllable, is that we are not sure we want
> it. Do you see a user community clamoring for SEPostgres, or a hacker
This is a chicken-and-egg type of problem.
Security-conscious users, applications, hackers, and customers will
flock towards whichever
Christopher Browne wrote:
> On Mon, Jan 26, 2009 at 5:42 PM, Ron Mayer
> wrote:
> There has been enough experimentation with git usage during the 8.4 ...
I certainly didn't mean for the idea to be advocating git nor any
changes in 8.4.
I was hoping the main idea was that the p
Gregory Stark wrote:
> I think a lot of people weren't aware there was anybody testing this patch
> ...I wonder how many more people are trying it out?
I think I have an idea to improve this aspect for future commit fests.
For a long time at each of my workplaces I've been running a development
i
Gregory Stark wrote:
>
> I think a lot of people weren't aware there was anybody testing this patch
> other than Simon and Heikki -- I wasn't until just today. I wonder how many
> more people are trying it out?
I've been running the patch (I think since Jan 5) on a couple dev instances
that were
Gregory Stark wrote:
> Simon Riggs writes:
>
>> The original design of Postgres allowed pluggable index access methods,
>> but that capability has not been brought forward to allow for WAL. This
>> patch would bridge that gap.
>
> Well I think what people do is what GIST did early on -- they jus
Robert Haas wrote:
>>> 2. Start using more git...
>> This is a red herring, unless your proposal also includes making the
>> master CVS^H^H^Hgit repository world-writable. The complaint I have
>> about people posting URLs is that there's no stable archive of what the
>> patches really were, and j
Hitoshi Harada wrote:
> 2008/12/28 Tom Lane :
>> "Hitoshi Harada" writes:
>>> 2008/12/27 Tom Lane :
which doesn't conform to spec AFAICS ...
>>> 4.15...says:
>> interesting...6.10 general rule 1b, which very clearly states ...
>> ... 4.15 does seem like evidence that the spec authors may
Robert Haas wrote:
... serializable transaction ...
If we were to construct a database that had one giant lock for the
entire database so that only a single query could execute at one time,
transactions would be serializable (because they'd in fact be
serialized). However, performance would suc
Tom Lane wrote:
I am, btw, still waiting for an actually plausible use-case for this.
AFAICS the setjmp-vs-exceptions thing puts a very serious crimp in
what you could hope to accomplish by importing a pile of C++ code.
The one use-case I can think of that imports a pile of C++ code
is the GEOS
Josh Berkus wrote:
Hmmm. I thought this was pretty clear. There's three levels of synch
which are useful features:
1) "synchronus" standby which is really asynchronous, but only has a gap
of < 100ms.
2) Synchronous standby which guarentees that all committed transactions
are on the fail
Robert Haas wrote:
We can make the reply to a commit message when any of the following
events have occurred
1. We sent the message to standby
2. We received the message on standby
3. We wrote the WAL to the WAL file
4. We fsync'd the WAL file
5. We CRC checked the WAL commit record
6. We applied
Gregory Stark wrote:
Simon Riggs writes:
The amount of I/O could stay the same, just sample all rows on block. []
It will also introduce strange biases. For instance in a clustered table it'll
think there are a lot more duplicates than there really are because it'll see
lots of similar va
Tom Lane wrote:
Given the above constraints, I think the only real role for C++ here
would be to allow access to third-party C++ libraries as Postgres
extensions --- for instance something like an XML or numerical analysis
I seem to recall that we're already able to do this.
IIRC, some older
1 - 100 of 382 matches
Mail list logo
