Hi,
while TFM says that we can use EXECUTE 'select ' INTO instead of the
non implemented EXECUTE 'select ... into ', the message in plpgsql
fails to say the same thing... seems like a HINT to me
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de
On Wed, Apr 14, 2010 at 9:16 AM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Sat, Apr 10, 2010 at 12:23 AM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Fri, Apr 9, 2010 at 3:39 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
i think make standbycheck needs a
On Mon, Apr 26, 2010 at 3:25 AM, Erik Rijkers e...@xs4all.nl 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?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND
On Sun, 2010-04-25 at 19:18 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
Jaime Casanova wrote:
On Wed, Apr 14, 2010 at 9:16 AM, Jaime Casanova
jcasa...@systemguards.com.ec 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
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
heikki.linnakan...@enterprisedb.com 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
Tom Lane t...@sss.pgh.pa.us 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
Rod Taylor p...@rbt.ca 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
On Mon, 2010-04-26 at 10:41 +0200, Dimitri Fontaine wrote:
Tom Lane t...@sss.pgh.pa.us 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.
On Sun, Apr 25, 2010 at 10:19 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Sun, Apr 25, 2010 at 8:07 PM, Robert Haas robertmh...@gmail.com wrote:
1. We could move the responsibility for removing the files associated
with temp rels from the background writer to the owning backend.
On Fri, Apr 23, 2010 at 11:27 PM, Rod Taylor p...@rbt.ca 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
On Fri, Apr 23, 2010 at 4:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Mon, Apr 26, 2010 at 6:08 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-04-26 at 10:41 +0200, Dimitri Fontaine wrote:
Tom Lane t...@sss.pgh.pa.us writes:
The only workable
alternative I can see to keeping archive_mode is to tell people to
set archive_command to something
On Wed, Apr 21, 2010 at 9:11 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Apr 21, 2010 at 1:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
...shouldn't we move the tests, plural, rather than just the one?
It seems right to reject new SR connections
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 as it
Robert Haas wrote:
On Fri, Apr 23, 2010 at 4:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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)
On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Mon, Apr 26, 2010 at 8:57 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi 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
* 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.
Thoughts?
On Fri, Apr 23, 2010 at 4:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Takahiro Itagaki wrote:
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp 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
On 26 April 2010 11:19, Robert Haas robertmh...@gmail.com wrote:
On Fri, Apr 23, 2010 at 11:27 PM, Rod Taylor p...@rbt.ca 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,
Stephen Frost sfr...@snowman.net 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
Applied; catalog version bumped.
---
Bruce Momjian wrote:
Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
The current column ordering can be rationalized to
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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,
On Mon, Apr 26, 2010 at 10:23 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
* How about naming the parameter wal_level instead of wal_mode? That
would better
Robert Haas wrote:
On Fri, Apr 23, 2010 at 4:44 PM, Tom Lane t...@sss.pgh.pa.us 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,
On Mon, April 26, 2010 08:52, Fujii Masao wrote:
On Mon, Apr 26, 2010 at 3:25 AM, Erik Rijkers e...@xs4all.nl 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
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 aberration').
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
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
On Mon, Apr 26, 2010 at 2:15 PM, Josh Berkus j...@agliodbs.com 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
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 time
Murali M. Krishna murali1...@yahoo.com 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
Simon Riggs si...@2ndquadrant.com 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
On Mon, Apr 26, 2010 at 2:36 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Murali M. Krishna murali1...@yahoo.com 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
On Mon, 2010-04-26 at 15:40 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
On Mon, Apr 26, 2010 at 3:30 PM, Simon Riggs si...@2ndquadrant.com 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
On Mon, Apr 26, 2010 at 3:36 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Murali M. Krishna murali1...@yahoo.com 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
Simon Riggs si...@2ndquadrant.com 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
On Mon, Apr 26, 2010 at 3:03 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Apr 26, 2010 at 3:36 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Murali M. Krishna murali1...@yahoo.com wrote:
Basically, I would like to discard the result rows after doing all
the work required to
Tom Lane escribió:
[ forgot to respond to this part ]
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com wrote:
On Mon, Apr 26, 2010 at 3:36 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Murali M. Krishna murali1...@yahoo.com wrote:
Basically, I would like to discard the result rows after doing
all the work required to execute the query.
I would use
Jaime Casanova jcasa...@systemguards.com.ec writes:
On Mon, Apr 26, 2010 at 3:03 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Apr 26, 2010 at 3:36 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
I would use EXPLAIN ANALYZE SELECT ...
There's some overhead to that, of course.
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
There was talk of including pg_migrator in Postgres 9.0 in /contrib. Do
we still want to do that?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
--
Sent via pgsql-hackers mailing list
On Mon, Apr 26, 2010 at 9:26 PM, Bruce Momjian br...@momjian.us 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
Robert Haas wrote:
On Mon, Apr 26, 2010 at 9:26 PM, Bruce Momjian br...@momjian.us 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
On Mon, Apr 26, 2010 at 9:46 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Apr 26, 2010 at 9:26 PM, Bruce Momjian br...@momjian.us 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 26, 2010 at 9:26 PM, Bruce Momjian br...@momjian.us 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
On Sun, 2010-04-25 at 13:51 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
Simon Riggs si...@2ndquadrant.com 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
54 matches
Mail list logo
