(2014/04/02 21:25), Etsuro Fujita wrote:
> Attached is v11.
>
> Changes:
>
> * Rebased to head
> * Improve an error message added to tablecmd.c to match it to existing
> ones there
> * Improve the documentaion a bit
I moved this to 2014-06.
Since I've merged with the initial patch by Hanada-san
Hi Hadi,
Sorry for the delay.
(2014/04/25 22:39), Hadi Moshayedi wrote:
On second thought I noticed that that makes CREATE FOREIGN TABLE include
an OID column in newly-created foreign tables wrongly, when the
default_with_oids parameter is set to on. Please find attached a patch.
On Sat, May 10, 2014 at 6:22 AM, Tom Lane wrote:
> Robert Haas writes:
>> The test_shm_mq regression tests hung on this machine this morning.
>
> It looks like hamster may have a repeatable issue there as well,
> since the last set of DSM code changes.
Yeah, this node has a limited amount of spac
On Mon, May 12, 2014 at 12:50 AM, Tom Lane wrote:
> Since this bug would block testing of ALTER SYSTEM by a nontrivial
> population of users, I felt it was important to get it fixed before beta,
> so I went to try and fix it as above. It turns out that reading the two
> config files separately do
> On 8 May 2014 22:55, Tom Lane wrote:
>
> >> We're past the prototyping stage and into productionising what we
> >> know works, AFAIK. If that point is not clear, then we need to
> >> discuss that first.
> >
> > OK, I'll bite: what here do we know works? Not a damn thing AFAICS;
> > it's all sp
On Sun, May 4, 2014 at 11:12:57AM -0400, Tom Lane wrote:
> Stephen Frost writes:
> > * Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
> >> 1. I wish it were possible to prevent even the superuser from disabling
> >> audit logging once it's enabled, so that if someone gained superuser
> >> access
While looking into this report
http://www.postgresql.org/message-id/cf48ccfb.65a9d%tim.k...@gmail.com I
noticed that we don't accept empty values as xml "content" values, even
though this should apparently be allowed by the spec. Attached is a
patch to fix it (which needs updates to xml_1.out, whi
On Sun, May 11, 2014 at 3:20 PM, Tom Lane wrote:
> I wrote:
>> I think what probably has to happen is that ProcessConfigFile shouldn't
>> be internally responsible for reading the auto file at all, but that we
>> do that via two separate calls to ProcessConfigFile, one for the main
>> file and the
On 2014-05-11 12:47:21 -0400, Tom Lane wrote:
> Another idea is that the main reason we do things like this is the
> assumption that for UPDATE, ModifyTable receives complete new rows
> that only need to be pushed back into the table (and hence have
> to already match the rowtype of the specific ch
On 2014-05-11 12:24:30 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-05-10 23:21:34 -0700, Peter Geoghegan wrote:
> >> On Fri, May 9, 2014 at 1:50 PM, Andres Freund
> >> wrote:
> >>> And adding a proper unsigned type doesn't sound like a small amount of
> >>> work.
>
> >> Perhaps
On Sat, May 10, 2014 at 3:33 AM, Peter Eisentraut wrote:
> The pg_basebackup documentation says that only regular files and
> directories are "allowed" in the data directory. But it is more correct
> that any other files are skipped. Attached is a patch to correct that.
> I also added a link t
I wrote:
> I think what probably has to happen is that ProcessConfigFile shouldn't
> be internally responsible for reading the auto file at all, but that we
> do that via two separate calls to ProcessConfigFile, one for the main
> file and then one for the auto file; and during initial startup,
> S
Amit Kapila writes:
> This problem occurs because we don't have the value of data_directory
> set in postgresql.conf by the time we want to parse .auto.conf file
> during server start. The value of data_directory is only available after
> processing of config files. To fix it, we need to store t
Amit Kapila writes:
> In above scenario, I think you are expecting it should use
> /data2/postgresql.auto.conf and that is what you have mentioned
> up-thread. The way to handle it by server is just to forbid setting
> this parameter
> by Alter System or the user himself should not perform such a
Simon Riggs writes:
> On 11 May 2014 11:18, Andres Freund wrote:
>> I don't know. I'd find UPDATE/DELETE ORDER BY something rather
>> useful.
> Perhaps if an index exists to provide an ordering that makes it clear
> what this means, then yes.
The $64 question is whether we'd accept an implement
Andres Freund writes:
> On 2014-05-10 23:21:34 -0700, Peter Geoghegan wrote:
>> On Fri, May 9, 2014 at 1:50 PM, Andres Freund wrote:
>>> And adding a proper unsigned type doesn't sound like a small amount of work.
>> Perhaps not, but it's overdue. We ought to have one.
> Maybe. But there's so m
On 30 August 2013 04:55, Fujii Masao wrote:
> My idea is very simple, just compress FPW because FPW is
> a big part of WAL. I used pglz_compress() as a compression method,
> but you might think that other method is better. We can add
> something like FPW-compression-hook for that later. The patch
On 11 May 2014 11:18, Andres Freund wrote:
> On 2014-05-11 10:33:10 +0200, Simon Riggs wrote:
>> On 11 May 2014 07:37, Amit Kapila wrote:
>>
>> > Tom Lane has explained these problems in a very clear manner
>> > in his below mail and shared his opinion about this feature as
>> > well.
>> > http:/
On Sun, May 11, 2014 at 10:33 AM, Simon Riggs wrote:
> On 11 May 2014 07:37, Amit Kapila wrote:
>
>> Tom Lane has explained these problems in a very clear manner
>> in his below mail and shared his opinion about this feature as
>> well.
>> http://www.postgresql.org/message-id/26819.1291133...@sss
On 2014-05-11 10:33:10 +0200, Simon Riggs wrote:
> On 11 May 2014 07:37, Amit Kapila wrote:
>
> > Tom Lane has explained these problems in a very clear manner
> > in his below mail and shared his opinion about this feature as
> > well.
> > http://www.postgresql.org/message-id/26819.1291133...@sss
On 2014-05-10 23:21:34 -0700, Peter Geoghegan wrote:
> On Fri, May 9, 2014 at 1:50 PM, Andres Freund wrote:
> > And adding a proper unsigned type doesn't sound like a small amount of work.
>
> Perhaps not, but it's overdue. We ought to have one.
Maybe. But there's so many things to decide around
On 11 May 2014 07:37, Amit Kapila wrote:
> Tom Lane has explained these problems in a very clear manner
> in his below mail and shared his opinion about this feature as
> well.
> http://www.postgresql.org/message-id/26819.1291133...@sss.pgh.pa.us
I don't have Tom's wonderfully articulate way of
On 8 May 2014 22:55, Tom Lane wrote:
>> We're past the prototyping stage and into productionising what we know
>> works, AFAIK. If that point is not clear, then we need to discuss that
>> first.
>
> OK, I'll bite: what here do we know works? Not a damn thing AFAICS;
> it's all speculation that c
Hello,
> What kind of error did you get at the server crash? Assertion error? If yes,
> it might be because of the conflict with
> 4a170ee9e0ebd7021cb1190fabd5b0cbe2effb8e.
> This commit forbids palloc from being called within a critical section, but
> the patch does that and then the assertion er
24 matches
Mail list logo
