On Thu, 2010-05-27 at 11:28 +0900, Fujii Masao wrote:
On Wed, May 26, 2010 at 10:20 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-05-26 at 18:52 +0900, Fujii Masao wrote:
I guess that dropping the support of #3 doesn't reduce complexity
since the code of #3 is almost the same
On 27/05/10 03:25, Florian Pflug wrote:
On May 27, 2010, at 0:58 , Heikki Linnakangas wrote:
On 26/05/10 02:00, Sam Vilain wrote:
Florian Pflug wrote:
On May 25, 2010, at 12:18 , Heikki Linnakangas wrote:
Releasing the newer savepoint will cause the older one to again become
accessible, as
I think we should fix it now. Quick thought: maybe we could use FOR instead
of AS: select myfunc(7 for a, 6 for b); IIRC the standard's mechanism for
this is 'paramname = value', but I think that has problems because of our
possibly use of = as an operator - otherwise that would be by far
2010/5/27 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
On 27/05/10 02:09, alvherre wrote:
Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010:
I think we should fix it now. Quick thought: maybe we could use FOR
instead of AS: select myfunc(7 for a, 6 for b);
On Thu, 2010-05-27 at 02:18 +0300, Heikki Linnakangas wrote:
On 27/05/10 01:23, Simon Riggs wrote:
On Thu, 2010-05-27 at 00:21 +0300, Heikki Linnakangas wrote:
On 26/05/10 23:31, Dimitri Fontaine wrote:
d. choice of commit or rollback at timeout
Rollback is not an option. There is no
2010/5/27 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we go with the spec's syntax I think we'd have no realistic choice
except to forbid = altogether as an operator name. (And no, I'm not
for
2010/5/27 Robert Haas robertmh...@gmail.com:
On Wed, May 26, 2010 at 9:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we go with the spec's syntax I think we'd have no realistic choice
As we talked at the developer meeting on Ottawa, it needs to provide
a capability to assign a short text identifier on database objects
to support label based ESP (such as SELinux).
So, I'd like to propose a few approaches to support security label
as a draft of discussion.
An example of label:
On 27/05/10 09:51, Simon Riggs wrote:
On Thu, 2010-05-27 at 02:18 +0300, Heikki Linnakangas wrote:
In practice, hard synchronous don't return ever until the commit hits
the standby behavior is rarely what admins actually want, because it's
disastrous from an availability point of view. More
On 27/05/10 09:50, Pavel Stehule wrote:
2010/5/27 Heikki Linnakangasheikki.linnakan...@enterprisedb.com:
AFAIU, the standard doesn't say anything about named parameters. Oracle uses
=, but as you said, that's ambiguous with the = operator.
+1 for FOR.
I don't see any advantage of FOR.
Any
On Wed, May 26, 2010 at 10:37 PM, Simon Riggs si...@2ndquadrant.com wrote:
If the remote server responded first, then that proves it is a better
candidate for failover than the one you think of as near. If the two
standbys vary over time then you have network problems that will
directly affect
At 2010-05-27 08:50:18 +0200, pavel.steh...@gmail.com wrote:
I don't see any advantage of FOR. We can change ir to support new
standard or don't change it.
Adopting FOR would mean we don't use AS in a way that conflicts with the
standard. That's its only advantage. But I agree with you, I
2010/5/27 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
On 27/05/10 09:50, Pavel Stehule wrote:
2010/5/27 Heikki Linnakangasheikki.linnakan...@enterprisedb.com:
AFAIU, the standard doesn't say anything about named parameters. Oracle
uses
=, but as you said, that's ambiguous with
2010/5/27 Abhijit Menon-Sen a...@toroid.org:
At 2010-05-27 08:50:18 +0200, pavel.steh...@gmail.com wrote:
I don't see any advantage of FOR. We can change ir to support new
standard or don't change it.
Adopting FOR would mean we don't use AS in a way that conflicts with the
standard. That's
On 27/05/10 08:56, Jesper Krogh wrote:
Just a thought. Wouldn't a All-visible bit also enable index only scans
to some degree?
Yes. In fact, that's one reason I implemented the visibility map in the
first place. I started working on index-only scans based on that last
year, if you search the
On Thu, May 27, 2010 at 3:21 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-05-27 at 11:28 +0900, Fujii Masao wrote:
On Wed, May 26, 2010 at 10:20 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-05-26 at 18:52 +0900, Fujii Masao wrote:
I guess that dropping the support
On 27/05/10 10:16, Pavel Stehule wrote:
2010/5/27 Heikki Linnakangasheikki.linnakan...@enterprisedb.com:
On 27/05/10 09:50, Pavel Stehule wrote:
2010/5/27 Heikki Linnakangasheikki.linnakan...@enterprisedb.com:
AFAIU, the standard doesn't say anything about named parameters. Oracle
uses
=,
On tor, 2010-05-27 at 04:06 +0300, Heikki Linnakangas wrote:
On 27/05/10 03:57, Robert Haas wrote:
Being compatible with the SQL
standard and with Oracle is not to be taken lightly.
I seem to be alone believing that the SQL standard doesn't say anything
about named function parameters.
On 27/05/10 10:49, Peter Eisentraut wrote:
On tor, 2010-05-27 at 04:06 +0300, Heikki Linnakangas wrote:
On 27/05/10 03:57, Robert Haas wrote:
Being compatible with the SQL
standard and with Oracle is not to be taken lightly.
I seem to be alone believing that the SQL standard doesn't say
On tor, 2010-05-27 at 10:51 +0300, Heikki Linnakangas wrote:
On 27/05/10 10:49, Peter Eisentraut wrote:
On tor, 2010-05-27 at 04:06 +0300, Heikki Linnakangas wrote:
On 27/05/10 03:57, Robert Haas wrote:
Being compatible with the SQL
standard and with Oracle is not to be taken lightly.
2010/5/26 Peter Eisentraut pete...@gmx.net:
It turns out that the SQL standard uses the function call notation
foo(this AS that)
for something else:
routine invocation ::= routine name SQL argument list
routine name ::= [ schema name period ] qualified identifier
SQL argument list ::=
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 26/05/10 23:31, Dimitri Fontaine wrote:
So if you want simplicity to admin, effective data availability and
precise control over the global setup, I say go for:
a. transaction level control of the replication level
b.
On Thu, 2010-05-27 at 10:09 +0300, Heikki Linnakangas wrote:
No, not necessarily. As I said above, you might just want a guarantee
that *if* you query the standby, you get up-to-date results.
Of course. COMMIT was already one of the options, so this comment was
already understood.
What we are
On Thu, 2010-05-27 at 16:35 +0900, Fujii Masao wrote:
On Thu, May 27, 2010 at 3:21 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-05-27 at 11:28 +0900, Fujii Masao wrote:
On Wed, May 26, 2010 at 10:20 PM, Simon Riggs si...@2ndquadrant.com
wrote:
On Wed, 2010-05-26 at 18:52
Greg Stark gsst...@mit.edu writes:
Fwiw I like the word replica but I don't see an obvious choice of
word to pair it with
I guess it's replica / origin, per choice of Jan Wieck to be found in
our catalogs:
http://www.postgresql.org/docs/current/static/catalog-pg-trigger.html
tgenabled
On Thu, 2010-05-27 at 16:13 +0900, Fujii Masao wrote:
On Wed, May 26, 2010 at 10:37 PM, Simon Riggs si...@2ndquadrant.com wrote:
Please explain what will happen when the near server is unavailable,
with per-standby settings. Please also explain what will happen if we
choose to have 4 or 5
On Thu, 2010-05-27 at 16:13 +0900, Fujii Masao wrote:
On Wed, May 26, 2010 at 10:37 PM, Simon Riggs si...@2ndquadrant.com wrote:
If the remote server responded first, then that proves it is a better
candidate for failover than the one you think of as near. If the two
standbys vary over time
On Thu, May 27, 2010 at 6:30 PM, Simon Riggs si...@2ndquadrant.com wrote:
Who sends the ack message?
walreceiver
Who receives it?
walsender
Would it be easier to have
this happen in a second pair of processes WALSynchroniser (on primary)
and WAL Acknowledger (on standby). WALAcknowledger
Peter Eisentraut wrote:
On ons, 2010-05-26 at 11:47 +0100, Mike Fowler wrote:
The XMLEXISTS function works with XQuery expressions and doesn't have
the call signature that your patch implements
Looking at the manuals of Oracle, Derby and DB2 I see how the call
signature differs. I
On Thu, 2010-05-27 at 19:21 +0900, Fujii Masao wrote:
On Thu, May 27, 2010 at 6:30 PM, Simon Riggs si...@2ndquadrant.com wrote:
Would it be easier to have
this happen in a second pair of processes WALSynchroniser (on primary)
and WAL Acknowledger (on standby). WALAcknowledger would send
On Thu, May 27, 2010 at 7:21 PM, Simon Riggs si...@2ndquadrant.com wrote:
Seems strange. If you have 2 standbys and you say you would like node1
to be the preferred candidate, then you load it so heavily that a remote
server with by-definition much larger network delay responds first, then
I
Anyone working on make contrib/pg_trgm mutibyte encoding aware? If
not, I'm interested in the work.
It's already multibyte safe since 8.4
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
On Thu, May 27, 2010 at 7:33 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-05-27 at 19:21 +0900, Fujii Masao wrote:
On Thu, May 27, 2010 at 6:30 PM, Simon Riggs si...@2ndquadrant.com wrote:
Would it be easier to have
this happen in a second pair of processes WALSynchroniser (on
Simon Riggs si...@2ndquadrant.com writes:
Seems strange. If you have 2 standbys and you say you would like node1
to be the preferred candidate, then you load it so heavily that a remote
server with by-definition much larger network delay responds first, then
I say your preference was wrong.
On Thu, May 27, 2010 at 3:13 AM, Fujii Masao masao.fu...@gmail.com wrote:
(1) most standard case: 1 master + 1 sync standby (near)
When the master goes down, something like a clusterware detects that
failure, and brings the standby online. Since we can ensure that the
standby has all
On Thu, 2010-05-27 at 20:13 +0900, Fujii Masao wrote:
On Thu, May 27, 2010 at 7:33 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-05-27 at 19:21 +0900, Fujii Masao wrote:
On Thu, May 27, 2010 at 6:30 PM, Simon Riggs si...@2ndquadrant.com wrote:
Would it be easier to have
On Thu, 2010-05-27 at 19:50 +0900, Fujii Masao wrote:
For now, I agree that we support a quorum commit feature for 9.1 or later.
But I don't think that it's simpler, more intuitive and easier-to-understand
than per-standby setting. So I think that we should include the per-standby
setting in
It's already multibyte safe since 8.4
No, it doesn't.
$ psql test
Pager usage is off.
psql (8.4.4)
Type help for help.
test=# select similarity('abc', 'abd'); -- OK
similarity
0.33
(1 row)
test=# select similarity('日本語', '日本後'); -- NG
similarity
On Thu, May 27, 2010 at 8:28 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, May 27, 2010 at 3:13 AM, Fujii Masao masao.fu...@gmail.com wrote:
(1) most standard case: 1 master + 1 sync standby (near)
When the master goes down, something like a clusterware detects that
failure, and
On Thu, May 27, 2010 at 8:30 PM, Simon Riggs si...@2ndquadrant.com wrote:
Why does it? I just explained a design where that wasn't required.
Hmm.. my expression might have been ambiguous. Walreceiver still needs
to wait for WAL flush by walwriter *before* sending the ACK to the master,
in #3
On Thu, May 27, 2010 at 8:30 PM, Simon Riggs si...@2ndquadrant.com wrote:
There already is a first patch to the community that implements quorum
commit, just not by you.
Yeah, AFAIK, that patch includes also per-standby setting.
If you have a better way, describe it in detail and in full now,
Hi,
On Thursday 27 May 2010 13:53:37 Tatsuo Ishii wrote:
It's already multibyte safe since 8.4
No, it doesn't.
Encoding is EUC_JP, locale is C. Included is the script to reproduce
the problem.
test=# select show_trgm('日本語');
show_trgm
No, it doesn't.
Encoding is EUC_JP, locale is C. Included is the script to reproduce
the problem.
test=# select show_trgm('日本語');
show_trgm
---
{0x8194c0,0x836e53,0x1dc363,0x1e22e9}
(1 row)
Time: 0.443 ms
test=#
On Thu, May 27, 2010 at 8:02 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, May 27, 2010 at 8:28 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, May 27, 2010 at 3:13 AM, Fujii Masao masao.fu...@gmail.com wrote:
(1) most standard case: 1 master + 1 sync standby (near)
When the
On Thursday 27 May 2010 14:40:41 Tatsuo Ishii wrote:
No, it doesn't.
Encoding is EUC_JP, locale is C. Included is the script to reproduce
the problem.
test=# select show_trgm('日本語');
show_trgm
---
On Thu, May 27, 2010 at 9:48 PM, Robert Haas robertmh...@gmail.com wrote:
There could still be additional transactions that the original master
has committed locally but were not acked to the client. I guess you'd
just work around that by taking a new base backup from the new master.
Right.
On 27/05/10 12:39, Dimitri Fontaine wrote:
Greg Starkgsst...@mit.edu writes:
Fwiw I like the word replica but I don't see an obvious choice of
word to pair it with
I guess it's replica / origin, per choice of Jan Wieck to be found in
our catalogs:
On 27/05/10 12:39, Dimitri Fontaine wrote:
Greg Starkgsst...@mit.edu writes:
Fwiw I like the word replica but I don't see an obvious choice of
word to pair it with
I guess it's replica / origin, per choice of Jan Wieck to be found in
our catalogs:
What is your locale?
It was en_EN.UTF-8. Interesting. With C it fails...
Yes, pg_trgm seems to have problems with multibyte + C locale.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list
Following design offers simplicity of design, performance and user
control over sync rep waits, including wait-for-apply for HS.
This implements Oracle's Maximum Availability option AND Maximum
Performance options both together, rather than just one or the other:
async and sync replication
With the parameter checkpoint_segment and wal_keep_segments the max. number of
wal segments are set. If now the max number is reached,
(1) the segments are deleted/recycled
or (2) if the time set by the checkpoint_timeout is over, a checkpoint is set
and if possible a deletion/recycling is
On Thu, May 27, 2010 at 9:09 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, May 27, 2010 at 9:48 PM, Robert Haas robertmh...@gmail.com wrote:
There could still be additional transactions that the original master
has committed locally but were not acked to the client. I guess you'd
just
Jan Wieck janwi...@yahoo.com wrote:
On 5/26/2010 4:34 PM, Kevin Grittner wrote:
My latest idea for handling this in WAL-based replication
involves WAL-logging information about the transaction through
which a the committing transaction makes it safe to view. There
are a few options here at
Tatsuo Ishii is...@postgresql.org writes:
What is your locale?
It was en_EN.UTF-8. Interesting. With C it fails...
Yes, pg_trgm seems to have problems with multibyte + C locale.
It's not a problem, it's just pilot error, or possibly inadequate
documentation. pg_trgm uses the locale's
On Wed, May 26, 2010 at 5:38 PM, Greg Stark gsst...@mit.edu wrote:
How about just API generalities? Like, where do you need this data, on
the master or on the slave? Would PGXC like it on the transaction
coordinator?
What question do you need to answer, do you need to pull out sets of
Yes, pg_trgm seems to have problems with multibyte + C locale.
It's not a problem, it's just pilot error, or possibly inadequate
documentation. pg_trgm uses the locale's definition of alpha,
digit, etc. In C locale only basic ASCII letters and digits will be
recognized as word
On Thu, May 27, 2010 at 10:13 PM, Sander, Ingo (NSN - DE/Munich)
ingo.san...@nsn.com wrote:
With the parameter checkpoint_segment and wal_keep_segments the max. number
of wal segments are set. If now the max number is reached,
(1) the segments are deleted/recycled
or (2) if the time set by
On Thu, May 27, 2010 at 9:08 AM, Simon Riggs si...@2ndquadrant.com wrote:
* New process: WALAck (on standby)
Reads shared memory to get last received and last applied xlog location
and sends message to WALSync on primary. Loop/Sleep forever.
So would WALAck be polling shared memory? That
On Thu, May 27, 2010 at 10:09 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, May 27, 2010 at 10:13 PM, Sander, Ingo (NSN - DE/Munich)
ingo.san...@nsn.com wrote:
With the parameter checkpoint_segment and wal_keep_segments the max. number
of wal segments are set. If now the max number is
Tatsuo Ishii is...@postgresql.org writes:
It's not a problem, it's just pilot error, or possibly inadequate
documentation. pg_trgm uses the locale's definition of alpha,
digit, etc. In C locale only basic ASCII letters and digits will be
recognized as word constituents.
That means there is
Exactly what do you consider to be the missing functionality?
You need a notion of word vs non-word character from somewhere,
and the locale setting is the standard place to get that. The
core text search functionality behaves the same way.
No. Text search works fine with multibyte + C
Tatsuo Ishii is...@sraoss.co.jp writes:
Anyway locale is completely usesless for finding word vs non-character
an agglutinative language such as Japanese.
Well, that doesn't mean that the answer is to use C locale ;-)
However, you could possibly think about making this bit of code
more
Well, that doesn't mean that the answer is to use C locale ;-)
Of course it's up to user whether to use C locale or not. I just want
pg_trgm work with C locale as well.
However, you could possibly think about making this bit of code
more flexible:
#ifdef KEEPONLYALNUM
#define iswordchr(c)
Tatsuo Ishii is...@postgresql.org writes:
! #define iswordchr(c)(t_isalpha(c) || t_isdigit(c) ||
(lc_ctype_is_c() !t_isspace(c)))
This seems entirely arbitrary. It might fix things in your view
but it will break the longstanding behavior for other people.
I think a more appropriate
On Thu, May 27, 2010 at 3:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think a more appropriate type of fix would be to expose the
KEEPONLYALNUM option as a GUC, or some other way of letting the
user decide what he wants.
So I think a GUC is broken because pg_tgrm has a index opclasses and
any
Current thought among core is to wrap beta2 Thursday June 3 (a week
from today) for public release on Monday the 7th. Get those fixes in.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Tom Lane wrote:
Joshua Tolley eggyk...@gmail.com writes:
Agreed. As long as a trusted language can do things outside the
database only by going through a database and calling some function to
which the user has rights, in an untrusted language, that seems decent
to me. A user with
On tor, 2010-05-27 at 23:20 +0900, Tatsuo Ishii wrote:
Anyway locale is completely usesless for finding word vs non-character
an agglutinative language such as Japanese.
I don't know about Japanese, but the locale approach works just fine for
other agglutinative languages. I would rather
On Fri, May 14, 2010 at 6:41 AM, Simon Riggs si...@2ndquadrant.com wrote:
The main reason for having a separate recovery.conf file is that its
existence is what drives the setting of InArchiveRecovery. If we were
to devise some other trigger for that condition, it'd be possible to
fold all
On Wed, May 26, 2010 at 9:00 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 26, 2010 at 8:20 PM, Andrew Dunstan and...@dunslane.net
wrote:
Gurjeet Singh wrote:
I did a `git clean -f -d` and even that did not remove gram.c,
apparently
because this file _was_ alive at some
On Sat, May 15, 2010 at 7:38 AM, Marc G. Fournier scra...@hub.org wrote:
most people are not prepared to understand the concept of more than
one list for project...
Apparently you don't use very many large projects ... FreeBSD has 20+ lists,
dedicated to various aspects of both end user and
On Thu, 2010-05-27 at 16:20 +0100, Greg Stark wrote:
My suggestion is we should fold all the parameters into
postgresql.conf and treat recovery.conf as an additional
postgresql.conf to read. It would allow any GUC. The only difference
is that it would be moved out of the way automatically
I don't know about Japanese, but the locale approach works just fine for
other agglutinative languages. I would rather suspect that it is the
trigram approach that might be rather useless for such languages,
because you are going to get a lot of similarity hits for the affixes.
I'm not sure
On Thu, 2010-05-27 at 10:11 -0400, Robert Haas wrote:
On Thu, May 27, 2010 at 9:08 AM, Simon Riggs si...@2ndquadrant.com wrote:
* New process: WALAck (on standby)
Reads shared memory to get last received and last applied xlog location
and sends message to WALSync on primary. Loop/Sleep
So I think a GUC is broken because pg_tgrm has a index opclasses and
any indexes built using one setting will be broken if the GUC is
changed.
Perhaps we need two sets of functions (which presumably call the same
implementation with a flag to indicate which definition to use). Then
you can
On Thu, 27 May 2010, Greg Stark wrote:
Sure, if we have distinctions which make sense then having separate
lists makes sense. Linux has separate lists for different drivers,
different parts of the kernel, projects to improve the kernel in
various specific ways (latency, etc). I'm all for having
On Thu, May 27, 2010 at 11:50 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-05-27 at 10:11 -0400, Robert Haas wrote:
On Thu, May 27, 2010 at 9:08 AM, Simon Riggs si...@2ndquadrant.com wrote:
* New process: WALAck (on standby)
Reads shared memory to get last received and last
alvherre alvhe...@commandprompt.com writes:
Excerpts from Ray Stell's message of mié may 26 17:08:33 -0400 2010:
I just installed a compiled from src 8.3.11. I usually include %i, command
tag,
in the log_line_prefix setting. This causes some spewage I'd not seen before
on connection
Excerpts from Tom Lane's message of jue may 27 12:49:49 -0400 2010:
alvherre alvhe...@commandprompt.com writes:
Excerpts from Ray Stell's message of mié may 26 17:08:33 -0400 2010:
I just installed a compiled from src 8.3.11. I usually include %i,
command tag,
in the log_line_prefix
On 5/27/2010 9:59 AM, Greg Stark wrote:
On Wed, May 26, 2010 at 5:38 PM, Greg Stark gsst...@mit.edu wrote:
How about just API generalities? Like, where do you need this data, on
the master or on the slave? Would PGXC like it on the transaction
coordinator?
What question do you need to answer,
Andrew Dunstan and...@dunslane.net writes:
Peter Eisentraut wrote:
In systems that have inheritance of composite types, this is used to
specify which type the value is supposed to be interpreted as (for
example, to treat the value as a supertype).
Why don't they just use CAST() syntax for
alvherre alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of jue may 27 12:49:49 -0400 2010:
That is in the right place, isn't it. That would suggest that
get_ps_display() is returning a wrong length on Ray's machine.
It works okay here, but since that's platform-specific
On Thu, May 27, 2010 at 12:49:49PM -0400, Tom Lane wrote:
alvherre alvhe...@commandprompt.com writes:
Excerpts from Ray Stell's message of mi?? may 26 17:08:33 -0400 2010:
I just installed a compiled from src 8.3.11. I usually include %i,
command tag,
in the log_line_prefix setting.
On Wed, 2010-05-26 at 16:22 -0700, Josh Berkus wrote:
Just this second posted about that, as it turns out.
I have a v3 *almost* ready of the keepalive patch. It still makes sense
to me after a few days reflection, so is worth discussion and review. In
or out, I want this settled within
On May 27, 2010, at 9:59 AM, Tom Lane wrote:
I think we should fix it now. Quick thought: maybe we could use FOR
instead of AS: select myfunc(7 for a, 6 for b);
I'm afraid FOR doesn't work either; it'll create a conflict with the
spec-defined SUBSTRING(x FOR y) syntax.
How about
Hi all,
I have try to understand how parser work. So far the raw parser in
PostgreSQL will produce that called raw parser tree and the raw
parser tree will be passed to analyzer, right?
I have modified PostgreSQL, so the program wont call function
raw_parser -a function container that make by
Well, maybe I'm confused here, but arranging things so that we NEVER
have to visit the page after initially writing it seems like it's
setting the bar almost impossibly high.
That is the use case, though. What I've encountered so far at 3 client
sites is tables which are largely
On fre, 2010-05-28 at 00:46 +0900, Tatsuo Ishii wrote:
I don't know about Japanese, but the locale approach works just fine for
other agglutinative languages. I would rather suspect that it is the
trigram approach that might be rather useless for such languages,
because you are going to
On 5/27/10 8:38 AM, Greg Stark wrote:
Lists like -ecpg or -odbc
would work fine if the traffic warranted them.
A low-traffic list is a feature, not a bug. Most people don't *like*
subscribing to lists which have 80posts/day.
But some of the lists we have now are 99% overlap with each other
On Thu, 2010-05-27 at 11:24 -0400, Tom Lane wrote:
Current thought among core is to wrap beta2 Thursday June 3 (a week
from today) for public release on Monday the 7th. Get those fixes in.
I believe my issues are all sorted, apart from one outstanding patch to
attempt to address the
On 5/26/10 6:32 PM, Robert Haas wrote:
Hmm, yeah. Maybe we should freeze when we set PD_ALL_VISIBLE; that
might be just as good, and simpler. Assuming the visibility map is
sufficiently crash-safe/non-buggy, we could then teach VACUUM that
it's OK to advance relfrozenxid even when doing just
Ray Stell ste...@cns.vt.edu writes:
On Thu, May 27, 2010 at 12:49:49PM -0400, Tom Lane wrote:
That is in the right place, isn't it. That would suggest that
get_ps_display() is returning a wrong length on Ray's machine.
It works okay here, but since that's platform-specific code that
hardly
I've started implementing the JSON datatype; the repo is at
http://git.postgresql.org/gitweb?p=json-datatype.git .
On Fri, May 14, 2010 at 1:15 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, May 13, 2010 at 9:47 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
Would it be a bad idea to
On Thu, May 27, 2010 at 2:39 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
I've started implementing the JSON datatype; the repo is at
http://git.postgresql.org/gitweb?p=json-datatype.git .
On Fri, May 14, 2010 at 1:15 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, May 13, 2010 at
On Thu, May 27, 2010 at 2:17 PM, Josh Berkus j...@agliodbs.com wrote:
On 5/26/10 6:32 PM, Robert Haas wrote:
Hmm, yeah. Maybe we should freeze when we set PD_ALL_VISIBLE; that
might be just as good, and simpler. Assuming the visibility map is
sufficiently crash-safe/non-buggy, we could then
On Thu, May 27, 2010 at 2:00 PM, Josh Berkus j...@agliodbs.com wrote:
Well, maybe I'm confused here, but arranging things so that we NEVER
have to visit the page after initially writing it seems like it's
setting the bar almost impossibly high.
That is the use case, though. What I've
On Thu, May 27, 2010 at 1:27 PM, David E. Wheeler da...@kineticode.com wrote:
On May 27, 2010, at 9:59 AM, Tom Lane wrote:
I think we should fix it now. Quick thought: maybe we could use FOR
instead of AS: select myfunc(7 for a, 6 for b);
I'm afraid FOR doesn't work either; it'll create a
On May 27, 2010, at 11:55 AM, Robert Haas wrote:
Or we could use the Finnish word
epäjärjestelmällistyttämättömyydellänsäkäänköhän, which I'm pretty
sure is not currently used in our grammar.
I thought that was an Icelandic volcano.
Best,
David
--
Sent via pgsql-hackers mailing list
On Thu, May 27, 2010 at 2:01 PM, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2010-05-28 at 00:46 +0900, Tatsuo Ishii wrote:
I don't know about Japanese, but the locale approach works just fine for
other agglutinative languages. I would rather suspect that it is the
trigram approach
On Thu, May 27, 2010 at 2:59 PM, David E. Wheeler da...@kineticode.com wrote:
On May 27, 2010, at 11:55 AM, Robert Haas wrote:
Or we could use the Finnish word
epäjärjestelmällistyttämättömyydellänsäkäänköhän, which I'm pretty
sure is not currently used in our grammar.
I thought that was an
1 - 100 of 167 matches
Mail list logo
