On Thu, Apr 9, 2009 at 5:00 AM, Fujii Masao masao.fu...@gmail.com wrote:
RequestXLogSwitch() doesn't wait until the switched WAL file has
actually been archived. So, some WAL files still may not exist in
the standby server also after clean shutdown of the primary.
Thanks for your comment.
Hi,
On Thu, Apr 9, 2009 at 6:36 PM, Guillaume Smet guillaume.s...@gmail.com wrote:
On Thu, Apr 9, 2009 at 5:00 AM, Fujii Masao masao.fu...@gmail.com wrote:
RequestXLogSwitch() doesn't wait until the switched WAL file has
actually been archived. So, some WAL files still may not exist in
the
and dtrace probes, but I'll submit it to the next commit-fest
for the record.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
profiler-20090409.tar.gz
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
Peter Eisentraut wrote:
On Thursday 02 April 2009 21:38:06 Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Now, what about the idea of providing a shorthand LOCALE='foo',
mirroring --locale=foo initdb option? It seems like a good idea, because
you almost never
I happen to be doing this grep (the error message could perhaps use a HINT as
I couldn't figure out how to satisfy it...)
I noticed that the Croatian msgid string seems not to match the other
languages. Did this message change recently? Does this get updated only when
we reach beta and declare a
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Here is my thinking, and considering that that would basically involve a
forward-looking design decision right now, I would support dropping the
cardinality() function from 8.4 (if people agree that this is in fact the
design
On Thursday 09 April 2009 12:55:40 Gregory Stark wrote:
I noticed that the Croatian msgid string seems not to match the other
languages. Did this message change recently? Does this get updated only
when we reach beta and declare a string freeze?
It gets updated when someone with the language
Fujii Masao wrote:
Hi,
On Wed, Apr 8, 2009 at 6:56 AM, Guillaume Smet guillaume.s...@gmail.com wrote:
On Fri, Apr 3, 2009 at 5:42 AM, Fujii Masao masao.fu...@gmail.com wrote:
Here is the patch;
- Smart failover is chosen if the trigger file labeled smart or
an empty one exists.
- Fast
This query surprised me. I expected us to do the Aggregate once for all the
aggregate functions in the select target which is what normally happens. If I
simplify the query further it actually does so.
I don't really understand what's going on here. It can't be the volatile
random() because in
On Wed, Apr 08, 2009 at 08:16:52PM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
On Wed, Apr 08, 2009 at 06:11:59PM -0400, Tom Lane wrote:
Anyway, I revised this a bit and applied to HEAD.
I've not tested; but your changes look as though they will break:
SELECT
On Thu, Apr 9, 2009 at 1:29 PM, Peter Eisentraut pete...@gmx.net wrote:
It gets updated when someone with the language skills and interest updates it.
:-/ As the header tells you, this wasn't recently:
POT-Creation-Date: 2003-09-22 23:33+0200\n
PO-Revision-Date: 2003-09-22 23:05+0100\n
I
While I was testing this I realized that I wasn't getting quite the same
answers :-(. In particular, it seems that the core operators consider
an empty array to be contained in anything else, while intarray will
only return true for two nonempty arrays.
Urgh. We (with Oleg) digged a bit around
2009/4/9 Teodor Sigaev teo...@sigaev.ru:
contains - all elements of second array are contained in the first one.
Empty array has no element, so it can't be contained.
That sounds wrong. A contains B should surely always be true if B is
empty. ie for all x, x in B implies x in A. Or put another
On Thursday 09 April 2009 16:04:32 Greg Stark wrote:
Hm, I may have made an assumption here which might be wrong. I assumed
the original English strings were updated regularly whenever we made a
release or even more often. Even if no translator was available to add
translations for them. Or do
We have an API definition by which extractQuery can distinguish all
match from no match. If we just legislate that some match isn't
a valid behavior for zero-key queries, then the code is correct and the
Right now I don't see an example with zero keys and some match, consistent
method will
Peter Eisentraut wrote:
Tom Lane wrote:
plpgsql does not consider standard_conforming_strings --- it still uses
backslash escaping in its function bodies regardless. Since the
language itself is not standardized, I see no particular reason that
standard_conforming_strings should govern
On Thu, Apr 9, 2009 at 11:16 AM, Bruce Momjian br...@momjian.us wrote:
Peter Eisentraut wrote:
Tom Lane wrote:
plpgsql does not consider standard_conforming_strings --- it still uses
backslash escaping in its function bodies regardless. Since the
language itself is not standardized, I see
Bruce Momjian br...@momjian.us wrote:
standard_conforming_strings was added in Postgres 8.1, and
escape_string_warning was enabled in 8.2.
Other way around -- the warning was available in 8.1; the standard
character string literals were available in 8.2.
I think the big issue is that having
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Bruce Momjian br...@momjian.us wrote:
I think the big issue is that having standard_conforming_strings
affect function behavior introduces the same problems we have had in
the past of having a GUC affect function behavior.
Can't that be
Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Bruce Momjian br...@momjian.us wrote:
I think the big issue is that having standard_conforming_strings
affect function behavior introduces the same problems we have had in
the past of having a GUC affect function behavior.
Michael Renner wrote:
Hi,
this is a small update to the first paragraph of the WAL configuration
chapter, going into more detail WRT redo vs. checkpoint records, since
the underlying behavior is currently only deducible from the source. I'm
not perfectly sure if I got everything right,
Gregory Stark st...@enterprisedb.com writes:
I don't really understand what's going on here.
It's flattening the sub-select, converting
select sum(n),sum(n)
from (select (select count(*) as n from a ) as n
from (select random() as s) as xyzzy) as xyzzy ;
to
select sum((select
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Can't that be managed with this CREATE FUNCTION option?:
SET configuration_parameter { TO value | = value | FROM CURRENT }
It can be, the question is whether we're prepared to break
everything
under the
Greg Smith wrote:
On Mon, 23 Mar 2009, Tom Lane wrote:
We used to have the stats_reset_on_server_start thingy, which covered
that case. When we removed it on the grounds that you could do the
same less klugily with pg_stat_reset(), nobody complained about
cluster-wide stats...
Not
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Here is my thinking, and considering that that would basically involve a
forward-looking design decision right now, I would support dropping the
cardinality() function from 8.4 (if people
Andrew Gierth wrote:
David == David E Wheeler da...@kineticode.com writes:
On Mar 24, 2009, at 2:51 PM, Andrew Gierth wrote:
By popular demand, a version of this will go up on pgfoundry for
use with 8.3 etc.
David Wow. Nice stuff! I hope it's not too late for 8.4?
I personally
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
It can be, the question is whether we're prepared to break everything
under the sun until people add that.
I think we would first have to agree to issue escape_string_warning
warnings for code in PL/pgSQL functions, then think about
Bruce == Bruce Momjian br...@momjian.us writes:
In the absence of feedback to the contrary, I will submit it for
the first commitfest of 8.5, and maintain the pgfoundry version
for 8.3 and 8.4.
Bruce Andrew, do you want to add it to the 8.5 commitfest:
I will do so soon but I need to
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Here is my thinking, and considering that that would basically involve a
forward-looking design decision right now, I would support dropping the
cardinality() function
Andrew Gierth wrote:
Bruce == Bruce Momjian br...@momjian.us writes:
1) select ... from foo, unnest(foo.bar); -- UNNEST is implicitly LATERAL
[...]
It's point (1) that's the killer - without it, unnest() is just a
trivial shorthand for stuff that can be done anyway; it doesn't
On 4/9/09 10:42 AM, Bruce Momjian wrote:
Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
Here is my thinking, and considering that that would basically involve a
forward-looking design decision right now, I would support
On 04/08/09 13:10, Josh Berkus wrote:
On 4/8/09 9:44 AM, Tom Lane wrote:
Josh Berkusj...@agliodbs.com writes:
What about seq scans?
If the kernel can't read-ahead a seqscan by itself, it's unlikely to
be smart enough to be helped by posix_fadvise ... or at least so I
would think. Do you
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Well, surely the 8.3 behavior is not what we want.
Unless I'm missing something, plpgsql *already* effectively recognizes
and respects the standard_conforming_strings GUC *except* as the last
character of a conforming string literal within the
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Unless I'm missing something, plpgsql *already* effectively recognizes
and respects the standard_conforming_strings GUC *except* as the last
character of a conforming string literal within the procedure body,
and then not always. Am I missing
Tom Lane t...@sss.pgh.pa.us wrote:
I think you are confusing parsing of the string literal that
is the argument of CREATE FUNCTION with the parsing that the plpgsql
interpreter does on the function body once it gets it. In
particular, this example:
create or replace function kjgtest()
Teodor Sigaev teo...@sigaev.ru writes:
We have an API definition by which extractQuery can distinguish all
match from no match. If we just legislate that some match isn't
a valid behavior for zero-key queries, then the code is correct and the
Right now I don't see an example with zero keys
I wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
I think you are confusing parsing of the string literal that
is the argument of CREATE FUNCTION with the parsing that the
plpgsql
interpreter does on the function body once it gets it.
Oh, I'm not confused about that at all. I'm arguing that
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
http://developer.postgresql.org/pgdocs/postgres/monitoring-stats.html
says: Note: blocks_fetched minus blocks_hit gives the number of
kernel read() calls issued for the table, index, or database; but the
actual number of physical
All,
The Tsearch2.sql compatibility fuctions in
/contrib/tsearch2/tsearch2.sql don't include an important compatibility
object. For 8.2 Tsearch2 usage, a lot of queries were written calling
the default config, like:
to_tsvector('default',somedata)
In 8.3 this fails with a No such config
Robert Haas wrote:
On Sat, Apr 4, 2009 at 6:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
http://developer.postgresql.org/pgdocs/postgres/monitoring-stats.html
says: Note: blocks_fetched minus blocks_hit gives the number of
kernel read() calls issued
On Thu, Apr 9, 2009 at 11:14 PM, Bruce Momjian br...@momjian.us wrote:
Done with attached patch; good idea.
Bruce,
You are a documentation-tuning machine... thanks.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Hi,
On Thu, Apr 9, 2009 at 9:47 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
+ if (strspn(buf, smart) == 5 strncmp(buf, smart, 5) == 0)
+ {
The strspn() call seems pointless here.
OK, I'll get rid of it.
One problem with this patch is that in smart mode,
We still have a little work to do on dependencies in parallel
pg_restore. The current test compares the candidate's locking
dependencies with those of the running jobs, and allows the candidate is
there isn't a match. That's not a broad enough test. The candidate will
block if there's a
Josh Berkus j...@agliodbs.com writes:
The Tsearch2.sql compatibility fuctions in
/contrib/tsearch2/tsearch2.sql don't include an important compatibility
object. For 8.2 Tsearch2 usage, a lot of queries were written calling
the default config, like:
to_tsvector('default',somedata)
In
No, we should not. It's up to the user to create a default config
that matches whatever they were using before.
Oh, good point. I was assuming that Default would match the user's
default, but of course it might not.
Hmmm, this is a common enough case that it ought to be documented
Josh Berkus j...@agliodbs.com writes:
Hmmm, this is a common enough case that it ought to be documented
somewhere though.How about if I add an example to F.31.2. Converting
a pre-8.3 Installation ?
I think it already points out the need to manually convert your
configuration, but feel
46 matches
Mail list logo
