to 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 si...@2ndquadrant.com 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
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 behavior
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 shmmax and
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.
Short
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 that
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Sep 3, 2010 at 10:07 AM, Tom Lane t...@sss.pgh.pa.us 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
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 reviewers and
Robert Haas wrote:
On Wed, Jun 16, 2010 at 9:56 PM, Tom Lane t...@sss.pgh.pa.us 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?
Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
Jaime Casanova wrote:
At Saturday, 02/27/2010 on 4:21 pm Marc G. Fournier scra...@hub.org wrote:
On Sat, Feb 27, 2010 at 10:45 PM, Alvaro Herrera alvhe...@alvh.no-ip.org
wrote:
Is there a higher then normal amount of earthquakes happening recently?
Re: the more frequent earthquakes, yeah I
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).
It seems like
Magnus Hagander wrote:
On Fri, Jan 8, 2010 at 05:22, Ron Mayer rm...@cheapcomplexdevices.com 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 most *nix users, source will be fine
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 solve
Tom Lane wrote:
Magnus Hagander mag...@hagander.net 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 pretty
+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
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
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 txt
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 copypaste work anyway.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
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.
XML
Robert Haas wrote:
On Thu, Dec 3, 2009 at 5:23 PM, Josh Berkus j...@agliodbs.com 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
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
it take
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
Dave Page wrote:
On Tue, Dec 1, 2009 at 4:41 PM, Tom Lane t...@sss.pgh.pa.us 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
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 to
Joshua D. Drake wrote:
On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com 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
Brendan Jurd wrote:
2009/11/29 Bruce Momjian br...@momjian.us:
Wow, we mention 28k modems --- we are legacy software: ;-)
This initial checkout is a little slower than simply downloading
a filenametar.gz/filename file; expect it to take 40 minutes
or so if you have a 28.8K
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 by
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
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
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 subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 passwords in
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 or
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
Robert Haas wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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 be
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 on
Robert Haas wrote:
On Tue, Sep 1, 2009 at 9:29 PM, Alvaro
Herreraalvhe...@commandprompt.com 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't have a spare
1-terabytes to rewrite
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 high
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 top
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].
I
Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
Robert Haas wrote:
On Wed, Jul 22, 2009 at 2:17 PM, Andrew
Gierthand...@tao11.riddles.org.uk 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
David Fetter wrote:
On Tue, Aug 11, 2009 at 08:56:38AM -0500, Kevin Grittner wrote:
Bruce Momjian br...@momjian.us 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
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
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
to
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 that
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
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
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 better to
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 kevin.gritt...@wicourts.gov 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.
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
Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com 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
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 in
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 Lanet...@sss.pgh.pa.us 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
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 HEAD,
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
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 note to
Aidan Van Dyk wrote:
* Markus Wanner mar...@bluegap.ch [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
Tom Lane wrote:
Marko Kreen mark...@gmail.com 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
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
them
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 nearest
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 query
Alvaro Herrera wrote:
Gregory Stark escribió:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com 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
Selena Deckelmann wrote:
Tom Lane wrote:
Greg Sabino Mullaneg...@endpoint.com 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
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 think
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-level permission
Joshua Brindle wrote:
Tom Lane wrote:
Joshua Brindle met...@manicmethod.com 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
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 levels
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
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 the
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.
Considering that most patches don't come
Dave Page wrote:
On Tue, Jan 27, 2009 at 2:01 PM, Peter Eisentraut pete...@gmx.net 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
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 with you
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 deciding
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 - even
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 think
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:
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
Christopher Browne wrote:
On Mon, Jan 26, 2009 at 5:42 PM, Ron Mayer
rm...@cheapcomplexdevices.com 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
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
Tom Lane wrote:
Ron Mayer rm...@cheapcomplexdevices.com 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:
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
Gregory Stark wrote:
Simon Riggs si...@2ndquadrant.com 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
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 just
Hitoshi Harada wrote:
2008/12/28 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
2008/12/27 Tom Lane t...@sss.pgh.pa.us:
which doesn't conform to spec AFAICS ...
4.15...says:
interesting...6.10 general rule 1b, which very clearly states ...
... 4.15 does seem
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
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
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
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
Gregory Stark wrote:
Simon Riggs si...@2ndquadrant.com 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
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 368 matches
Mail list logo
