"Guillaume Smet" writes:
> On Mon, Jan 12, 2009 at 4:56 PM, Merlin Moncure 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.
On Mon, Jan 12, 2009 at 9:55 AM, Tom Lane wrote:
> Simon Riggs 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 for
> inclusion. We've seen a whol
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 4:56 PM, Merlin Moncure 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 relatively few amount
On 1/12/09, Guillaume Smet wrote:
> On Mon, Jan 12, 2009 at 3:04 PM, Tom Lane 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 wi
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 detect
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 e
On Mon, Jan 12, 2009 at 3:04 PM, Tom Lane 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.
IM(Very)HO, it's really
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 i
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
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera 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 inclined to
list -l before the i
Peter Eisentraut 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 exactly. The com
Tom Lane wrote:
Peter Eisentraut 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 rejected, since (a)
Simon Riggs 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 uncomfortable is
--On Montag, Januar 12, 2009 14:48:46 +0200 Peter Eisentraut
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
viewUpdate.o view
Gregory Stark 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 arguments as NULL
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 an
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 compatibility
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 y
Peter Eisentraut 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 they can s
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 t
Gregory Stark 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 of such an approach
Tom Lane writes:
> Peter Eisentraut 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 functionali
Simon Riggs 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 I do.
The way I
Heikki Linnakangas 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. The return code of SPI_execute_
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 (pgsql-hackers
Peter Eisentraut 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 can run
> t
Alvaro Herrera 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 invalid.) Note that ps
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
Gregory Stark writes:
> Simon Riggs 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 going to improve matters.
On Sun, 2009-01-11 at 12:07 -0500, Tom Lane wrote:
> Simon Riggs 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 time consuming)
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
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 XactLockT
-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 a
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 tes
Gregory Stark writes:
> Tom Lane 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 meant no
> prefetching because th
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
Bernd Helmle wrote:
--On Freitag, Januar 09, 2009 17:53:31 +0100 Bernd Helmle
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 in my new git branch a
Simon Riggs 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 i
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
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. Ca
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
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
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"
Robert Haas escribió:
> On Sun, Jan 11, 2009 at 6:47 PM, Euler Taveira de Oliveira
> wrote:
> > Robert Haas escreveu:
> >> Several things related to this patch have been committed:
> >>
> >> http://archives.postgresql.org/message-id/20081219143958.6f2dd756...@cvs.postgresql.org
> >> http://archive
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 gl
Tom Lane wrote:
Peter Eisentraut 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 should allow
S
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:
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
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 s
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 a
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
Des
101 - 152 of 152 matches
Mail list logo
