Hi Bruce,
Uh, do we still need this patch?
I'd say yes for 8.3.x (my guess is that I see this because I have
additional libraries installed on my mingw version versus what other
developers have - perhaps openssl-0.9.8i).
Not sure on 8.4, but can test if you'd like.
Charlie
smime.p7s
This test case:
CREATE TABLE atable(n int);
CREATE TABLE btable(n int);
CREATE RULE insteadrule AS ON INSERT TO atable DO INSTEAD delete from
btable;
CREATE FUNCTION rulecrash() RETURNS void AS $$
begin
insert into atable values(1);
end;
$$ LANGUAGE plpgsql;
SELECT rulecrash();
Fails an
Tom Lane wrote:
I never understood why autovacuum should need a particularly short fuse
on the stats file age to start with. If the launcher is launching
multiple workers into the same database with only a few milliseconds
between them, isn't the launcher pretty broken anyhow? ISTM that
Peter Eisentraut wrote:
Tom Lane wrote:
+1 for making TRUNCATE and LOCK support ONLY.
Patch attached.
This was committed.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I wrote:
Here is the current line-up:
command supports ONLY
ALTER TABLE all other actions yes
ALTER TABLE RENAME COLUMN yes
ALTER TABLE RENAME no
ALTER TABLE SET SCHEMA documented no, but accepted and ignored
This is actually a bit worse:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
This area is under SQL standard control, so we can't really invent our
own behavior.
What *would* do the right thing here, or would anything?
I think we don't need GRANT to be recursive, but instead the permission
checks at runtime
Devrim GÜNDÜZ wrote:
On Sun, 2009-01-11 at 11:46 -0500, Tom Lane wrote:
If we try to fix those cases I think we should try to fix Turkish i
as well ... but I concur that first requires determining if it's
behaving wrong or not. Devrim, or someone?
What exactly do you want to see?
Using a
Robert Haas escribió:
On Sun, Jan 11, 2009 at 6:47 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Robert Haas escreveu:
Several things related to this patch have been committed:
http://archives.postgresql.org/message-id/20081219143958.6f2dd756...@cvs.postgresql.org
Hi,
On Mon, 2009-01-12 at 12:06 +0200, Peter Eisentraut wrote:
Using a glibc system, initdb with --locale=tr_TR (or tr_TR.utf8 or
whatever) and run make installcheck. You should see test failures in
the tsearch and tsdicts tests that appear to relate to issues with
lowercasing the I
Heikki, can I get your feedback on this urgently please? I want to
respond positively to your review comments and complete something you
will find acceptable. But I need to know what that is, please.
On Sun, 2009-01-11 at 11:55 +, Simon Riggs wrote:
On Sun, 2009-01-11 at 10:41 +0200, Heikki
On Mon, 2009-01-12 at 11:43 +0200, Peter Eisentraut wrote:
Peter Eisentraut wrote:
Tom Lane wrote:
+1 for making TRUNCATE and LOCK support ONLY.
Patch attached.
This was committed.
Please could we put in a GUC to allow that to be toggled in this release
and warning issued for
So, what's happening. Is this discussion going into Limbo again for
six months. It feels like the latest round of messages just went
around the same circles as before. Let me summarize the different
possibilities as I see them.
0. Drop this patch
1. Call it Rest and make it 100% compliant
2.
D'Arcy J.M. Cain wrote:
So, what's happening. Is this discussion going into Limbo again for
six months. It feels like the latest round of messages just went
around the same circles as before. Let me summarize the different
possibilities as I see them.
0. Drop this patch
1. Call it Rest
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2009-01-12 at 11:43 +0200, Peter Eisentraut wrote:
Peter Eisentraut wrote:
Tom Lane wrote:
+1 for making TRUNCATE and LOCK support ONLY.
Patch attached.
This was committed.
Please could we put in a GUC to allow that to be toggled
Bernd Helmle wrote:
--On Freitag, Januar 09, 2009 17:53:31 +0100 Bernd Helmle
maili...@oopsware.de wrote:
I've decided to check updatability of all involved views during view
creation. Please find attached a new version with all other open issues
adressed.
Oops, forgot to track some files
Alvaro Herrera escribió:
I have a separate branch on which I keep the old patch from Euler
updated to the current reloptions code; so it is probably very similar
to what Euler just sent. (I'll have a look at that soon anyway.)
Huh, nevermind -- I thought that Euler had just sent an updated
Gregory Stark st...@enterprisedb.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
2. I fixed it so that setting effective_io_concurrency to zero disables
prefetching altogether; there was no way to do that in the patch as
submitted.
Hm. the original intent was that effective_io_concurrency 1
On Mon, 2009-01-12 at 14:10 +0200, Heikki Linnakangas wrote:
However, I think XactLockTableWait() doesn't need to know the parent
either. (This feels more like wishful thinking, but here goes anyway).
We release locks *after* TransactionIdAbortTree() has fully executed, so
the test for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
D'Arcy J.M. Cain a écrit :
So, what's happening. Is this discussion going into Limbo again for
six months. It feels like the latest round of messages just went
around the same circles as before. Let me summarize the different
possibilities as I
Simon Riggs wrote:
Rather than store the
parent xid itself we store the difference between the current xid and
the parent xid. Typically this will be less than 65535; when it is not
we set it to zero but issue an xid assignment xlog record.
That sounds pretty hacky.
However, I think
This is V4 patch to improve file read during startup for review.
Basic algorithm is same as V3 but works with Gregory's fadvise patch.
http://archives.postgresql.org/pgsql-hackers/2009-01/msg00026.php
This patc also include additional patch for posix_fadvise to skip
prefetch of pages which does
On Sun, 2009-01-11 at 12:07 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
Recovery doesn't have a test framework as yet. I would like to add one
for this release, especially since we have so much recovery-related code
being added to the release (and manual testing is so
Gregory Stark st...@enterprisedb.com writes:
Simon Riggs si...@2ndquadrant.com writes:
Please could we put in a GUC to allow that to be toggled in this release
That seems like it would just be putting off the pain.
Yes, we already had exactly this discussion and concluded that a GUC
wasn't
Peter Eisentraut wrote:
On Tuesday 06 January 2009 02:03:14 Tom Lane wrote:
I don't think there's a bug here, at least not in the sense that it
isn't Operating As Designed. But it does seem like we could do with
some more/better documentation about exactly how FOR UPDATE works.
The sequence of
Alvaro Herrera alvhe...@commandprompt.com writes:
My vote goes for 1.
I wonder why you think it's impossible. Is it because you must scan
the whole table before being able to print any of it? (For example to
add extra alignment for the escaping backslashes in a way that doesn't
render it
Peter Eisentraut pete...@gmx.net writes:
I can see two ways forward:
1) We document bluntly that ORDER BY + FOR UPDATE can return unordered
results, or
2) We prohibit ORDER BY + FOR UPDATE, like we do with a number of other
clauses. (There would be no loss of functionality, because you
Hitoshi Harada wrote:
- CREATE FUNCTION command accepts WINDOW keyword for non-c language
like plpgsql. Don't we need to throw error?
The validator procedures of those languages should be made to reject
that case if they can't support it.
--
Sent via pgsql-hackers mailing list
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
The problem is that mod_stmt is determined for the query that has
canSetTag set, but in case of an INSTEAD OF rule that rewrites the
statement into a different command, an INSERT into a DELETE in this
case, canSetTag is not set.
Simon Riggs si...@2ndquadrant.com writes:
Is it flaky? Not fundamentally; code wise I see it more as a
question of time.
a question of time indeed.
If we insist upon cuts, ...
Even if we reject replication entirely ...
There's a clear difference between how you're thinking about this and
Tom Lane t...@sss.pgh.pa.us writes:
Peter Eisentraut pete...@gmx.net writes:
I can see two ways forward:
1) We document bluntly that ORDER BY + FOR UPDATE can return unordered
results, or
2) We prohibit ORDER BY + FOR UPDATE, like we do with a number of other
clauses. (There would be
Gregory Stark st...@enterprisedb.com writes:
... But from my point of view it would
just always be better to commit large patches immediately after forking a
release instead of just before the beta to give them a whole release cycle of
exposure to developers before beta testers.
I'm in favor
On Mon, 12 Jan 2009, C?dric Villemain wrote:
we, at dalibo, used to write our docs with ReST and most of the time we
don't need to escape special char
I'm interested in this patch for a similar reason, ReST has been working
well for internal documentation at my office. I know I'll run into
Peter Eisentraut pete...@gmx.net writes:
Hitoshi Harada wrote:
- CREATE FUNCTION command accepts WINDOW keyword for non-c language
like plpgsql. Don't we need to throw error?
The validator procedures of those languages should be made to reject that case
if they can't support it.
Even if
Charlie Savage wrote:
Hi Bruce,
Uh, do we still need this patch?
I'd say yes for 8.3.x (my guess is that I see this because I have
additional libraries installed on my mingw version versus what other
developers have - perhaps openssl-0.9.8i).
Not sure on 8.4, but can test if you'd
On Mon, 12 Jan 2009, D'Arcy J.M. Cain wrote:
0. Drop this patch
1. Call it Rest and make it 100% compliant
2. Call it Rest-like
3. Call it simply border level 3
Every time I play with this for a minute or two, I'm able to find some
real-world data that completely breaks the ReST
On Mon, 2009-01-12 at 09:04 -0500, Tom Lane wrote:
I wasn't trying to start
a discussion about general project policies, but about the specific
status of this particular group of patches.
Which ones exactly?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and
Gregory Stark st...@enterprisedb.com writes:
Even if they can support it shouldn't they reject functions that aren't
actually window functions? What happens if you mark a perfectly normal
function as a window function, does it behave sanely?
Yes, for small values of sane. It will see all its
--On Montag, Januar 12, 2009 14:48:46 +0200 Peter Eisentraut
pete...@gmx.net wrote:
gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv
-g -I../../../src/include -I/sw/include/libxml2 -I/sw/include -c -o
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2009-01-12 at 09:04 -0500, Tom Lane wrote:
I wasn't trying to start
a discussion about general project policies, but about the specific
status of this particular group of patches.
Which ones exactly?
Well, one of the things that makes me
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Simon Riggs wrote:
I notice that we allow commands such as
SET TRANSACTION read only read write read only;
BEGIN TRANSACTION read only read only read only;
My own feeling is that the second example is okay but the first should
be
Peter Eisentraut pete...@gmx.net writes:
I think this might be best solved by providing a common function that
checks a DefElem list for duplicates. This could be used in a number of
other places as well (grep for conflicting or redundant options).
It's not clear what that would save
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Alvaro Herrera wrote:
I like Teodor's proposal; I'll see about implementing that.
Attached.
You missed updating the sgml docs, and personally I'd be
On Mon, 2009-01-12 at 09:55 -0500, Tom Lane wrote:
(And for the record,
there is nothing I like even a little bit about the practice of posting
a URL instead of an actual patch.)
I don't like it either.
The patchsets are too big to post to the list directly, at least that is
the reason in my
Simon Riggs wrote:
On Mon, 2009-01-12 at 09:55 -0500, Tom Lane wrote:
(And for the record,
there is nothing I like even a little bit about the practice of posting
a URL instead of an actual patch.)
I don't like it either.
The patchsets are too big to post to the list directly, at least that
On Mon, Jan 12, 2009 at 3:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, we are getting off onto a tangent. I wasn't trying to start
a discussion about general project policies, but about the specific
status of this particular group of patches.
I concur with Gregory on this one.
Simon Riggs wrote:
Recovery doesn't have a test framework as yet.
I have been having these concerns as well. In fact, I recall
discussions at least 8 years back about how pg_dump doesn't really have
any organized testing, and we also have little regular testing of PITR
aside from specific
While this behavior may be very old, I would still contend that it is
incorrect (or at least inconsistent with one's expectations). If it will
not be changed, some additional documentation might be helpful. Perhaps
a WARNING could be raised (unconditionally, as it might be a bit
intensive to
On 1/12/09, Guillaume Smet guillaume.s...@gmail.com wrote:
On Mon, Jan 12, 2009 at 3:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, we are getting off onto a tangent. I wasn't trying to start
a discussion about general project policies, but about the specific
status of this
On Mon, Jan 12, 2009 at 4:56 PM, Merlin Moncure mmonc...@gmail.com wrote:
I disagree at least with hot standby. I've been using/testing (as
have others) it under a variety of workloads for several months now
with no issues outside of corrected issues in the very early patches.
Also, a
Hi!
As I think has been previously noted, using pg_restore with -1 (single
transaction) is fundamentally incompatible with -C (we can't CREATE
DATABASE inside a transaction) and often incompatible with -c (we don't
do DROP IF EXISTS, so if the objects don't exist the entire restore will
fail). It
On Mon, Jan 12, 2009 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2009-01-12 at 09:04 -0500, Tom Lane wrote:
Well, one of the things that makes me uncomfortable is that it's not
even clear exactly which set of patches is currently proposed
Guillaume Smet guillaume.s...@gmail.com writes:
On Mon, Jan 12, 2009 at 4:56 PM, Merlin Moncure mmonc...@gmail.com wrote:
I disagree at least with hot standby. I've been using/testing (as
have others) it under a variety of workloads for several months now
with no issues outside of corrected
On Mon, Jan 12, 2009 at 11:07 AM, Guillaume Smet
guillaume.s...@gmail.com wrote:
On Mon, Jan 12, 2009 at 4:56 PM, Merlin Moncure mmonc...@gmail.com wrote:
I disagree at least with hot standby. I've been using/testing (as
have others) it under a variety of workloads for several months now
with
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
The problem is that mod_stmt is determined for the query that has
canSetTag set, but in case of an INSTEAD OF rule that rewrites the
statement into a different command, an INSERT into a DELETE in this
case,
On Mon, Jan 12, 2009 at 11:11:20AM -0500, Greg Stark wrote:
On Mon, Jan 12, 2009 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2009-01-12 at 09:04 -0500, Tom Lane wrote:
Well, one of the things that makes me uncomfortable is that it's
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
If _SPI_execute_plan reaches the above if and sets my_res = res,
SPI_processed is left at 0. So FOUND is always set to false if the
rewritten command type doesn't match the original.
Right, and I think that's probably sane
David Fetter da...@fetter.org writes:
Two things to fix this, and several other problems:
1. Remove the messages size limits on -hackers. They serve no useful
purpose, and they interfere with our development process.
Agreed, or at least boost it up a good bit more.
If -hackers
isn't
On Mon, 2009-01-12 at 11:18 -0500, Tom Lane wrote:
My point is that what Simon currently has (and so what you tested) is
different from what is going to be commited (note the final in what
I wrote) and I suspect there will be a certain number of non
negligible adjustments (see the last
On Mon, 2009-01-12 at 11:33 -0500, Tom Lane wrote:
If -hackers
isn't already subscriber-only, now would be the time to make it so.
Not sure how that's relevant?
So we don't get spam patches.
Joshua D. Drake
regards, tom lane
--
PostgreSQL
Consulting,
On Mon, Jan 12, 2009 at 11:33:43AM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
Two things to fix this, and several other problems:
1. Remove the messages size limits on -hackers. They serve no
useful purpose, and they interfere with our development process.
Agreed,
On Mon, Jan 12, 2009 at 5:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Basically I think we are up against the same type of project management
decision we've had several times before: are we willing to slip the
8.4 release schedule for however long it will take for hot standby
and the other
Magnus Hagander mag...@hagander.net writes:
It should be possible to make it compatible with -C by moving the CREATE
DATABASE command to outside of the transaction. I have only had a quick
look at the code wrt how much work this would be. One thing that hit me
quickly: do we support multiple
On 1/12/09, Joshua D. Drake j...@commandprompt.com wrote:
Basically I think we are up against the same type of project management
decision we've had several times before: are we willing to slip the
8.4 release schedule for however long it will take for hot standby
and the other
On Mon, Jan 12, 2009 at 4:37 PM, Joshua D. Drake j...@commandprompt.com wrote:
On Mon, 2009-01-12 at 11:18 -0500, Tom Lane wrote:
Basically I think we are up against the same type of project management
decision we've had several times before: are we willing to slip the
8.4 release schedule
On 12 jan 2009, at 17.42, David Fetter da...@fetter.org wrote:
On Mon, Jan 12, 2009 at 11:33:43AM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
Two things to fix this, and several other problems:
1. Remove the messages size limits on -hackers. They serve no
useful
On Mon, Jan 12, 2009 at 05:50:19PM +0100, Magnus Hagander wrote:
2. Start using more git, as many hackers and committers have
already started to do. This is the kind of situation where CVS
just plain falls down because branching and merging are
unmanageably difficult in it, where in git,
On 12 jan 2009, at 17.46, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
It should be possible to make it compatible with -C by moving the
CREATE
DATABASE command to outside of the transaction. I have only had a
quick
look at the code wrt how much work this
On 2009-01-12, at 16:48, Dave Page wrote:
On Mon, Jan 12, 2009 at 4:37 PM, Joshua D. Drake
j...@commandprompt.com wrote:
On Mon, 2009-01-12 at 11:18 -0500, Tom Lane wrote:
Basically I think we are up against the same type of project
management
decision we've had several times before: are
Magnus Hagander mag...@hagander.net writes:
On 12 jan 2009, at 17.46, Tom Lane t...@sss.pgh.pa.us wrote:
However, one of the properties -1 is supposed to have is that any
failure aborts the whole restore; it's not immediately clear how to
preserve that with CREATE DATABASE issued separately.
On Mon, Jan 12, 2009 at 5:48 PM, Dave Page dp...@pgadmin.org wrote:
I would. PostgreSQL is not a commercial application which has to be
released on schedule to satisfy shareholders - it's an Open Source
project that aims to provide it's users with useful features.
It has nothing to do with
t...@postgresql.org (Tom Lane) writes:
Log Message:
---
Tweak order of operations in BitmapHeapNext() to avoid the case of prefetching
the same page we are nanoseconds away from reading for real. There should be
something left to do on the current page before we consider issuing a
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
My vote goes for 1.
I wonder why you think it's impossible. Is it because you must scan
the whole table before being able to print any of it? (For example to
add extra alignment for the escaping backslashes in a way
Dave Page dp...@pgadmin.org writes:
On Mon, Jan 12, 2009 at 4:37 PM, Joshua D. Drake j...@commandprompt.com
wrote:
I would certainly not like to see 8.4 slip.
I would. PostgreSQL is not a commercial application which has to be
released on schedule to satisfy shareholders - it's an Open
Peter Eisentraut wrote:
Simon Riggs wrote:
Recovery doesn't have a test framework as yet.
I have been having these concerns as well. In fact, I recall
discussions at least 8 years back about how pg_dump doesn't really have
any organized testing, and we also have little regular testing
On Mon, 2009-01-12 at 16:48 +, Dave Page wrote:
On Mon, Jan 12, 2009 at 4:37 PM, Joshua D. Drake j...@commandprompt.com
wrote:
On Mon, 2009-01-12 at 11:18 -0500, Tom Lane wrote:
Basically I think we are up against the same type of project management
decision we've had several times
Peter Eisentraut wrote:
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Alvaro Herrera wrote:
I like Teodor's proposal; I'll see about implementing that.
Attached.
You missed updating the sgml
On Mon, Jan 12, 2009 at 5:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
Yeah, but there are already a number of things in 8.4 that are killer
features for various applications --- window functions and WITH to take
two recently-committed examples. Should we sit
On Mon, 2009-01-12 at 17:27 +, Dave Page wrote:
In general, we have always regretted it in the past when we chose to
slip a release waiting for a specific feature...
I don't recall such a time - though perhaps the last time it happened
was before I was so heavily involved in the
Gregory Stark st...@enterprisedb.com writes:
t...@postgresql.org (Tom Lane) writes:
Tweak order of operations in BitmapHeapNext() to avoid the case of
prefetching
the same page we are nanoseconds away from reading for real. There should be
something left to do on the current page before we
On Mon, Jan 12, 2009 at 5:20 PM, Joshua D. Drake j...@commandprompt.com wrote:
The community are our shareholders.
Exactly - and their dividends are the features we release, not a share
of profits we make from pushing out something a few weeks earlier.
Right. Except that isn't really the
2. Start using more git, as many hackers and committers have already
started to do. This is the kind of situation where CVS just plain
falls down because branching and merging are unmanageably difficult in
it, where in git, they're many-times-a-day operations.
This is a red herring, unless
Tom Lane t...@sss.pgh.pa.us writes:
Yeah, but there are already a number of things in 8.4 that are killer
features for various applications --- window functions and WITH to take
two recently-committed examples. Should we sit on those for however
long it will take to make replication
On Mon, 2009-01-12 at 15:26 +0200, Peter Eisentraut wrote:
1) We document bluntly that ORDER BY + FOR UPDATE can return unordered
results, or
2) We prohibit ORDER BY + FOR UPDATE, like we do with a number of other
clauses. (There would be no loss of functionality, because you can run
On Mon, Jan 12, 2009 at 12:27 PM, Dave Page dp...@pgadmin.org wrote:
On Mon, Jan 12, 2009 at 5:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In general, we have always regretted it in the past when we chose to
slip a release waiting for a specific feature...
I don't recall such a time - though
On Mon, 2009-01-12 at 08:37 -0800, Joshua D. Drake wrote:
On Mon, 2009-01-12 at 11:18 -0500, Tom Lane wrote:
My point is that what Simon currently has (and so what you tested) is
different from what is going to be commited (note the final in what
I wrote) and I suspect there will be a
On Mon, Jan 12, 2009 at 8:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
I can see two ways forward:
1) We document bluntly that ORDER BY + FOR UPDATE can return unordered
results, or
2) We prohibit ORDER BY + FOR UPDATE, like we do with a number of other
On Mon, 2009-01-12 at 08:32 -0500, Tom Lane wrote:
That code has been working like this for eight or ten years now and this
is the first complaint, so taking away functionality on the grounds that
someone might happen to update the ordering column doesn't seem like the
answer to me.
If they
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
On Mon, 2009-01-12 at 12:47 -0500, Robert Haas wrote:
If the only case where ORDER BY + FOR UPDATE are not strictly
compatible is when the columns being updated are the same as the
columns of the sort, a blanket prohibition against using the two
together seems like it prohibits an awful lot of
Dave Page dp...@pgadmin.org writes:
On Mon, Jan 12, 2009 at 5:20 PM, Joshua D. Drake j...@commandprompt.com
wrote:
Well its really nobody's fault except the hacker that didn't step up to
do the work. I believe all hackers have already been working diligently.
They have - but I see no reason
On Mon, Jan 12, 2009 at 5:30 PM, Joshua D. Drake j...@commandprompt.com wrote:
On Mon, 2009-01-12 at 17:27 +, Dave Page wrote:
In general, we have always regretted it in the past when we chose to
slip a release waiting for a specific feature...
I don't recall such a time - though
Robert Haas robertmh...@gmail.com writes:
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 because it
Alvaro Herrera escreveu:
Alvaro Herrera escribió:
I have a separate branch on which I keep the old patch from Euler
updated to the current reloptions code; so it is probably very similar
to what Euler just sent. (I'll have a look at that soon anyway.)
Huh, nevermind -- I thought that
Christopher Browne cbbro...@gmail.com writes:
On Mon, Jan 12, 2009 at 12:27 PM, Dave Page dp...@pgadmin.org wrote:
On Mon, Jan 12, 2009 at 5:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In general, we have always regretted it in the past when we chose to
slip a release waiting for a specific
No, git really does help with this. If Simon were making his changes
in git and pushing them to a git branch on git.postgresql.org, you
would be able to see exactly what he changed and when he changed it.
Well, if that's actually an archival repository then it would work.
But wasn't I just
Please commit soon
On Fri, 2009-01-09 at 18:30 +0200, Heikki Linnakangas wrote:
The hot standby patch has some hacks to decide which full-page-images
can be restored holding an exclusive lock and which ones need a
vacuum-strength lock. It's not very pretty as is, as mentioned in
That's happened more than once, though my memory of details is fuzzy
and I don't have time to troll the archives for them right now.
Maybe Bruce can remember without a lot of searching. But our current
policy of time-based releases (ie deadlines) is born of hard experience
with the negative
On Mon, 2009-01-12 at 13:23 -0500, Robert Haas wrote:
No, git really does help with this. If Simon were making his changes
in git and pushing them to a git branch on git.postgresql.org, you
would be able to see exactly what he changed and when he changed it.
Well, if that's actually an
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 12, 2009 at 8:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
That code has been working like this for eight or ten years now and this
is the first complaint, so taking away functionality on the grounds that
someone might happen to update the
On Mon, 2009-01-12 at 13:04 -0500, Tom Lane wrote:
Simon didn't ramp up
his effort until around September IIRC.
The main topic of snapshot creation was being discussed at PGcon in May
and another sponsors got serious then. I started working on a coherent
detailed design in July, but didn't
1 - 100 of 152 matches
Mail list logo
