On Jul 15, 2010, at 11:18 PM, Josh Berkus wrote:
> I think it's very important, as Haas says, to consider that whatever we
> do in this arena, we'll be living with it forever, so let's not make the
> \dv vs. \df mistake again, ok?
Refresh my memory?
...Robert
--
Sent via pgsql-hackers mailing
On Jul 16, 2010, at 2:27 AM, Heikki Linnakangas
wrote:
> If we continue with the approach I took, we should implement the suggestion
> to create a new data type for this in 9.1. That would be more waterproof than
> the changes I made, if we introduce new ways to call functions in the future.
T
On fre, 2010-07-16 at 14:13 +0300, Hannu Krosing wrote:
> Should we put some externally managed languages , like pl/proxy also in
> pgtemplate, so that CREATE LANGUAGE would work on them ?
This has been rejected several times before. See:
http://archives.postgresql.org/pgsql-hackers/2009-01/msg00
Hi
Should we put some externally managed languages , like pl/proxy also in
pgtemplate, so that CREATE LANGUAGE would work on them ?
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
--
Sent via pgsql-hackers mailing l
Hi all,
I was reading a post from Sushant Sinha about english parser wich do not
consider dot as a word delimiter. In a following mail it has been proposed
to add a patch.
Is there any news about that ?
I would enjoy this patch, too ;)
Thank's
--
Paul Fariello
Étudiant ingénieur à l'Universit
On 16/07/10 10:40, Fujii Masao wrote:
So we should always prevent the standby from applying any WAL in pg_xlog
unless walreceiver is in progress. That is, if there is no WAL available
in the archive, the standby ignores pg_xlog and starts walreceiver
process to request for WAL streaming.
That c
Tom Lane wrote:
> Itagaki Takahiro writes:
>> ...
>> We should also check the value not to be something like 0699.
>> How about checking it with (file_mode & ~0666) != 0 ?
>> ...
>> I want show_log_file_mode to print the setting value in octal format.
>
> It seems like a whole lot of lily-gilding
On 16/07/10 12:26, Boxuan Zhai wrote:
For the EXPLAIN MERGE command, I expect it to return a result similar to
that of a SELECT command.
I think the EXPLAIN command is to show how the tables in a query is scaned
and joined. In my design, the merge command will generate a top-level query
(and pla
Hi,
For the EXPLAIN MERGE command, I expect it to return a result similar to
that of a SELECT command.
I think the EXPLAIN command is to show how the tables in a query is scaned
and joined. In my design, the merge command will generate a top-level query
(and plan) as the main query. It is in fact
On Tue, Jul 6, 2010 at 9:59 AM, Takahiro Itagaki
wrote:
>
> Tom Lane wrote:
>> Truncating seems like an ugly kluge that's not fixing the real problem.
>> Why are there open descriptors for a dropped relation? They should all
>> get closed as a consequence of relcache flush.
>
> Relcache will be
On Thu, Jul 1, 2010 at 1:09 PM, Fujii Masao wrote:
> Thanks for reminding me. I attached the updated patch.
This patch left uncommitted for half a month. No one is interested in
the patch?
The patch adds the document about the relationship between a restartpoint
and checkpoint_segments parameter
On Mon, May 31, 2010 at 8:48 PM, Simon Riggs wrote:
> On Mon, 2010-05-31 at 20:11 +0900, Fujii Masao wrote:
>> On Thu, May 13, 2010 at 8:39 PM, Simon Riggs wrote:
>> > Log Message:
>> > ---
>> > Ensure that top level aborts call XLogSetAsyncCommit(). Not doing
>> > so simply leads to data
On Jul 15, 2010, at 6:43 PM, Magnus Hagander wrote:
> On Thu, Jul 15, 2010 at 18:35, Simon Riggs wrote:
>> On Thu, 2010-07-15 at 17:38 +0200, Magnus Hagander wrote:
>>
>>> Is there an actual common use-case for having these commands available
>>> for *non-psql* interfaces?
>>
>> There are many
On Thu, Jul 15, 2010 at 12:16 AM, Robert Haas wrote:
> On Wed, Jul 14, 2010 at 2:50 AM, Fujii Masao wrote:
>> The patch have no features for performance improvement of synchronous
>> replication. I admit that currently the performance overhead in the
>> master is terrible. We need to address the
On 13/07/10 21:36, Tom Lane wrote:
Dave Page writes:
We had a report of the above error from a pgAdmin user testing
1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
as a superuser:
SELECT pg_get_expr(proargdefaults, 'pg_catalog.pg_class'::regclass)
FROM pg_proc pr
On Thu, 2010-07-15 at 21:57 -0400, Robert Haas wrote:
> Exactly which commands are we going to support? With exactly what
> syntax? What information will be returned by each command? In what
> format? We have no agreement on any of these points.
The normal process is that we discuss the requi
101 - 116 of 116 matches
Mail list logo
