On Sun, 2010-04-25 at 19:18 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > [ v2 patch ]
>
> I've been studying this some more while making notes for improved
> comments, and I've about come to the conclusion that having readers
> move the tail pointer (at the end of KnownAssignedXidsGetAndSetXm
Jaime Casanova wrote:
> On Wed, Apr 14, 2010 at 9:16 AM, Jaime Casanova
> wrote:
>> 3) it should execute the existing set of tests (the ones installcheck
>> execute) but with a new set of expected results, that way we can be
>> sure that what should be disallowed is disallowed and that the
>> data
On Sun, 2010-04-25 at 23:52 +0200, Erik Rijkers wrote:
> I'll try to repeat this pattern on other hardware; although
> if my tests were run with faulty hardware I wouldn't know how/why
> that would give the above effect (such a 'regular aberration').
> testing is more difficult than I thought...
On Mon, Apr 26, 2010 at 2:32 AM, Heikki Linnakangas
wrote:
>
> How many of the tests in the regular regression suite do anything useful
> when run against a standby server? They all have to set up a bunch of
> objects before they run queries, so you just get a lot of errors
> complaining that you
Tom Lane writes:
> The only workable
> alternative I can see to keeping archive_mode is to tell people to
> set archive_command to something like /usr/bin/true ... which is not
> simpler, especially not on Windows.
Would it be possible to have "internal" commands there, as for example
cd is in
Rod Taylor wrote:
> Is there any particular reason why the citext module doesn't have
> citext_pattern_ops operator family?
>
> Specifically, I wish to index for this type of query:
>
> ... WHERE citext_column LIKE 'Foo%';
I think it is a reasonable suggestion.
=# \d tbl
Table "public.t
On Mon, 2010-04-26 at 10:41 +0200, Dimitri Fontaine wrote:
> Tom Lane writes:
> > The only workable
> > alternative I can see to keeping archive_mode is to tell people to
> > set archive_command to something like /usr/bin/true ... which is not
> > simpler, especially not on Windows.
>
> Would i
On Sun, Apr 25, 2010 at 10:19 PM, Jaime Casanova
wrote:
> On Sun, Apr 25, 2010 at 8:07 PM, Robert Haas wrote:
>>
>> 1. We could move the responsibility for removing the files associated
>> with temp rels from the background writer to the owning backend. I
>> think the reason why we initially tru
On Fri, Apr 23, 2010 at 11:27 PM, Rod Taylor wrote:
> Is there any particular reason why the citext module doesn't have
> citext_pattern_ops operator family?
You forgot to send in the patch. :-)
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Fri, Apr 23, 2010 at 4:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> Well, I think the real hole is that turning archive_mode=on results in
>> WAL never being deleted unless it's successfully archived.
>
> Hm, good point. And at least in principle you could have SR setups
> that don't care
On Mon, Apr 26, 2010 at 6:08 AM, Simon Riggs wrote:
> On Mon, 2010-04-26 at 10:41 +0200, Dimitri Fontaine wrote:
>> Tom Lane writes:
>> > The only workable
>> > alternative I can see to keeping archive_mode is to tell people to
>> > set archive_command to something like /usr/bin/true ... which
On Wed, Apr 21, 2010 at 9:11 PM, Robert Haas wrote:
> On Wed, Apr 21, 2010 at 1:56 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> ...shouldn't we move the "tests", plural, rather than just the one?
>>> It seems right to reject new SR connections during shutdown.
>>
>> Yeah; you'd also need to ad
Tom Lane wrote:
> Personally I agree with your objection to "crash" but not with the
> objection to "standby". Maybe this would be appropriate:
>
> wal_mode = minimal | archive | hot_standby
Ok, here's a patch implementing this proposal. It adds a new wal_mode
setting, leaving archive_mode
Robert Haas wrote:
On Fri, Apr 23, 2010 at 4:11 PM, Tom Lane wrote:
Robert Haas writes:
Well, I think the real hole is that turning archive_mode=on results in
WAL never being deleted unless it's successfully archived.
Hm, good point. And at least in principle you could have SR setups
that d
Hi,
This came up on IRC today and I recall several instances of this during
the last two months or so, so I decided to send a patch. The problem in
question occurs when you have extra parentheses in an INSERT list:
INSERT INTO foo(a,b,c) SELECT (a,b,c) FROM ..; or
INSERT INTO foo(a,b,c) VALUES((
On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
wrote:
> Tom Lane wrote:
>> Personally I agree with your objection to "crash" but not with the
>> objection to "standby". Maybe this would be appropriate:
>>
>> wal_mode = minimal | archive | hot_standby
>
> Ok, here's a patch implementing
On Mon, Apr 26, 2010 at 8:57 AM, Marko Tiikkaja
wrote:
> Hi,
>
> This came up on IRC today and I recall several instances of this during
> the last two months or so, so I decided to send a patch. The problem in
> question occurs when you have extra parentheses in an INSERT list:
>
> INSERT INTO f
* Robert Haas (robertmh...@gmail.com) wrote:
> > The first version is a lot more common and as it turns out, is sometimes
> > very hard to spot. This patch attaches a HINT message to these two
> > cases. The message itself could probably be a lot better, but I can't
> > think of anything.
> >
> >
On Fri, Apr 23, 2010 at 4:44 PM, Tom Lane wrote:
> Simon Riggs writes:
>> No intention of doing that. This change allows people to see what the
>> dependency actually is once the bug has been fixed. Change needs to
>> start from here, not from where we were before.
>
> Well, actually, now that I'
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> > Takahiro Itagaki wrote:
> >> Takahiro Itagaki wrote:
> >>
> >>> Revised patch attached. Please test it.
> >> I applied this version of the patch.
> >> Please check wheter the bug is fixed and any buildfarm failures.
> >
> > Great. I have merged in
On 26 April 2010 11:19, Robert Haas wrote:
> On Fri, Apr 23, 2010 at 11:27 PM, Rod Taylor wrote:
> > Is there any particular reason why the citext module doesn't have
> > citext_pattern_ops operator family?
>
> You forgot to send in the patch. :-)
>
> ...Robert
>
>
Yes, someone implementing thi
Stephen Frost writes:
> Not to be a pain, but the hint really is kind of terrible.. It'd
> probably be better if you included somewhere that the insert appears to
> be a single column with a record-type rather than multiple columns of
> non-composite type..
I don't much care for the test, either
Applied; catalog version bumped.
---
Bruce Momjian wrote:
> Tom Lane wrote:
> > "Kevin Grittner" writes:
> > > Tom Lane wrote:
> > >> The current column ordering can be rationalized to some extent as
> > >>
> > >> 1. ide
Robert Haas writes:
> On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
> wrote:
>> * How about naming the parameter wal_level instead of wal_mode? That
>> would better convey that the higher levels add stuff on top of the lower
>> levels, instead of having different modes that are somehow mutu
On Mon, Apr 26, 2010 at 10:23 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
>> wrote:
>>> * How about naming the parameter wal_level instead of wal_mode? That
>>> would better convey that the higher levels add stuff on top of the lower
>>> level
Robert Haas wrote:
> On Fri, Apr 23, 2010 at 4:44 PM, Tom Lane wrote:
>> Well, actually, now that I've looked at the patch I think it's starting
>> from a fundamentally wrong position anyway. Checkpoint records are a
>> completely wrong mechanism for transmitting this data to slaves, because
>> a
On Mon, April 26, 2010 08:52, Fujii Masao wrote:
> On Mon, Apr 26, 2010 at 3:25 AM, Erik Rijkers wrote:
>> FWIW, here are some more results from pgbench comparing
>> primary and standby (both with Simon's patch).
>
> Was there a difference in CPU utilization between the primary
> and standby?
>
On Mon, April 26, 2010 09:43, Simon Riggs wrote:
> On Sun, 2010-04-25 at 23:52 +0200, Erik Rijkers wrote:
>
>> I'll try to repeat this pattern on other hardware; although
>> if my tests were run with faulty hardware I wouldn't know how/why
>> that would give the above effect (such a 'regular aberra
Hello Hackers:
Two questions.
1.
I would like to execute queries such as
select * from part and time the query. But I want to ignore how much time is
taken for printing the result to a file or the screen.
Basically, I would like to discard the result rows after doing all the work
required t
Folks,
(a) is this checked in yet?
(b) should we delay Beta to test it?\
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-
On Mon, Apr 26, 2010 at 2:15 PM, Josh Berkus wrote:
> (a) is this checked in yet?
No.
> (b) should we delay Beta to test it?\
I suspect it's going to be checked in pretty soon, so that may not be
necessary. Not my call, though.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Sun, 2010-04-25 at 11:35 -0400, Robert Haas wrote:
> And I don't
> think you can even get that far, because I don't think too many people
> here are going to say that we shouldn't add global temporary tables
> unless we can also make them work with Hot Standby.
The policy round here for some t
"Murali M. Krishna" wrote:
> Basically, I would like to discard the result rows after doing all
> the work required to execute the query.
I would use EXPLAIN ANALYZE SELECT ...
> I looked at the documentation and I saw something about using the
> keyword PERFORM rather than SELECT.
I don't
Simon Riggs writes:
> On Sun, 2010-04-25 at 11:35 -0400, Robert Haas wrote:
>> And I don't
>> think you can even get that far, because I don't think too many people
>> here are going to say that we shouldn't add global temporary tables
>> unless we can also make them work with Hot Standby.
> The
On Mon, Apr 26, 2010 at 2:36 PM, Kevin Grittner
wrote:
> "Murali M. Krishna" wrote:
>
>> I looked at the documentation and I saw something about using the
>> keyword PERFORM rather than SELECT.
>
> I don't remember ever seeing anything like that. Do you have a URL?
>
i guess he is refering to t
On Mon, 2010-04-26 at 15:40 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Sun, 2010-04-25 at 11:35 -0400, Robert Haas wrote:
> >> And I don't
> >> think you can even get that far, because I don't think too many people
> >> here are going to say that we shouldn't add global temporary tables
>
On Mon, Apr 26, 2010 at 3:30 PM, Simon Riggs wrote:
> On Sun, 2010-04-25 at 11:35 -0400, Robert Haas wrote:
>
>> And I don't
>> think you can even get that far, because I don't think too many people
>> here are going to say that we shouldn't add global temporary tables
>> unless we can also make t
On Mon, Apr 26, 2010 at 3:36 PM, Kevin Grittner
wrote:
> "Murali M. Krishna" wrote:
>
>> Basically, I would like to discard the result rows after doing all
>> the work required to execute the query.
>
> I would use EXPLAIN ANALYZE SELECT ...
There's some overhead to that, of course.
Robert
Simon Riggs writes:
> On Mon, 2010-04-26 at 15:40 -0400, Tom Lane wrote:
>> The current definition of Hot Standby is that it's a *read only*
>> behavior. Not read mostly. What you are proposing is a rather
>> fundamental change in the behavior of HS, and it doesn't seem to me
>> that it should b
On Mon, Apr 26, 2010 at 3:03 PM, Robert Haas wrote:
> On Mon, Apr 26, 2010 at 3:36 PM, Kevin Grittner
> wrote:
>> "Murali M. Krishna" wrote:
>>
>>> Basically, I would like to discard the result rows after doing all
>>> the work required to execute the query.
>>
>> I would use EXPLAIN ANALYZE SEL
Tom Lane escribió:
> [ forgot to respond to this part ]
>
> Robert Haas writes:
> > ... I don't see the problem with DROP.
> > Under the proposed design, it's approximately equivalent to dropping a
> > table that someone else has truncated. You just wait for the
> > necessary lock and then do i
Robert Haas wrote:
> On Mon, Apr 26, 2010 at 3:36 PM, Kevin Grittner
> wrote:
>> "Murali M. Krishna" wrote:
>>
>>> Basically, I would like to discard the result rows after doing
>>> all the work required to execute the query.
>>
>> I would use EXPLAIN ANALYZE SELECT ...
>
> There's some overhea
Jaime Casanova writes:
> On Mon, Apr 26, 2010 at 3:03 PM, Robert Haas wrote:
>> On Mon, Apr 26, 2010 at 3:36 PM, Kevin Grittner
>> wrote:
>>> I would use EXPLAIN ANALYZE SELECT ...
>>
>> There's some overhead to that, of course.
> he could see the "actual time" in the very first row of the EXP
Hello All:
The optimizer assumes that data is disk resident when computing the cost of a
query plan.
I am trying to ascertain what the correlation is between times and costs of
some benchmark queries to see how good the cost model is.
Since I have more than 100 queries, it would be painful to
There was talk of including pg_migrator in Postgres 9.0 in /contrib. Do
we still want to do that?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
On Mon, Apr 26, 2010 at 9:26 PM, Bruce Momjian wrote:
> There was talk of including pg_migrator in Postgres 9.0 in /contrib. Do
> we still want to do that?
I think you articulated some pretty good reasons previously for
keeping it separate and, at any rate, I'm not eager to do it at the
11th hou
Robert Haas wrote:
> On Mon, Apr 26, 2010 at 9:26 PM, Bruce Momjian wrote:
> > There was talk of including pg_migrator in Postgres 9.0 in /contrib. ?Do
> > we still want to do that?
>
> I think you articulated some pretty good reasons previously for
> keeping it separate and, at any rate, I'm not
On Mon, Apr 26, 2010 at 9:46 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Apr 26, 2010 at 9:26 PM, Bruce Momjian wrote:
>> > There was talk of including pg_migrator in Postgres 9.0 in /contrib. ?Do
>> > we still want to do that?
>>
>> I think you articulated some pretty good reasons p
Robert Haas writes:
> On Mon, Apr 26, 2010 at 9:26 PM, Bruce Momjian wrote:
>> There was talk of including pg_migrator in Postgres 9.0 in /contrib. Do
>> we still want to do that?
> I think you articulated some pretty good reasons previously for
> keeping it separate and, at any rate, I'm not e
On Sun, 2010-04-25 at 13:51 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Sun, 2010-04-25 at 13:33 -0400, Tom Lane wrote:
> >> If you like I'll have a go at rewriting the comments for this patch,
> >> because I am currently thinking that the problem is not so much with
> >> the code as with
Simon Riggs writes:
> v3 attached
Thanks, will work on this tomorrow.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
51 matches
Mail list logo
