From: "Andres Freund"
On 2014-07-18 23:38:09 +0900, MauMau wrote:
LOG: autovacuum: found orphan temp table "pg_temp_838"."some_table" in
database "some_db"
LOG: autovacuum: found orphan temp table "pg_temp_902"."some_table" in
database "some_db"
So they had server crashes of some form befor
> I think the basic problem would be what the check constraint subquery
> meant to the user, and how useful that is expected to be in general. A
> subquery in a check constraint would presumably involve checking the
> subquery using an existing snapshot of the command that required the
> constraint
Peter Geoghegan writes:
> On Fri, Jul 18, 2014 at 7:31 PM, Tatsuo Ishii wrote:
>> Has anybody tried to implement subquery in CHECK constaint? If so,
>> what are issues to implement it? Or the feature is not worth the
>> effort? Comments and/or opinions are welcome.
> I think the basic problem wo
Hi,
On Fri, Jul 18, 2014 at 7:31 PM, Tatsuo Ishii wrote:
> Has anybody tried to implement subquery in CHECK constaint? If so,
> what are issues to implement it? Or the feature is not worth the
> effort? Comments and/or opinions are welcome.
I think the basic problem would be what the check const
Hi,
Has anybody tried to implement subquery in CHECK constaint? If so,
what are issues to implement it? Or the feature is not worth the
effort? Comments and/or opinions are welcome.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www
On Wed, Jul 2, 2014 at 4:23 PM, Michael Paquier
wrote:
>
>
>
> On Wed, Jul 2, 2014 at 4:09 PM, Michael Paquier
> wrote:
>>
>> 3) I noticed a bug in gin redo code path when trying to use the WAL replay
>> facility.
This patch has been on status "Waiting on author" for a little bit of
time, marking
I looked into the problem described here:
http://www.postgresql.org/message-id/53c93986.80...@clickware.de
The core issue is that the ruleutils.c code isn't thinking about dropped
columns in the output of a function-in-FROM that returns a composite type.
Pre-9.3, there had been some code there to
>
> I think we do want a way to modify policies. However, we tend to
> avoid syntax that involves unnatural word order, as this certainly
> does. Maybe it's better to follow the example of CREATE RULE and
> CREATE TRIGGER and do something this instead:
>
> CREATE POLICY policy_name ON table_name
2014-07-19 6:26 GMT+08:00 Tom Lane :
> =?UTF-8?B?5Zyf5Y2c55q/?= writes:
> > for studying polyphase merge algorithm of tuplesort.c, I use ddd and
> > apend a table, which has a schema as follows:
> > ...
> > and has 36684 records, and every record is like:
> > id code article name
=?UTF-8?B?5Zyf5Y2c55q/?= writes:
> for studying polyphase merge algorithm of tuplesort.c, I use ddd and
> apend a table, which has a schema as follows:
> ...
> and has 36684 records, and every record is like:
> id code article name department
> 31800266\NMachault7
hi, all
for studying polyphase merge algorithm of tuplesort.c, I use ddd and
apend a table, which has a schema as follows:
CREATE TABLE Towns (
id SERIAL UNIQUE NOT NULL,
code VARCHAR(10) NOT NULL, -- Only unique inside a department
article TEXT,
name TEXT NOT NULL, -- Names are not
Jeff Janes wrote:
> Should we push the refactoring through anyway? I have a hard time
> believing that pg_dump is going to be the only client program we ever have
> that will need process-level parallelism, even if this feature itself does
> not need it. Why make the next person who comes along
John Cochran writes:
> Did a diff between the 2010c version of localtime.c and the postgres
> version and saw a lot more differences than what could have been expected
> from simple reformatting and adaptation. So I installed gitk and took a
> look at the change history of localtime.c
> Well,
On Wed, Jul 16, 2014 at 5:30 AM, Dilip kumar wrote:
> On 16 July 2014 12:13 Magnus Hagander Wrote,
>
> >>Yeah, those are exactly my points. I think it would be significantly
> simpler to do it that way, rather than forking and threading. And also
> easier to make portable...
>
> >>(and as a opt
On Fri, Jul 18, 2014 at 1:21 PM, Tom Lane wrote:
> John Cochran writes:
> > My proposal is the have the following directory structure
>
> ...
> > 1. I would have liked to recommend 2 sub-directories underneath
>
...
>
>
I have exactly zero expectation of using their Makefile, so this is not a
On Fri, Jul 18, 2014 at 11:32 AM, Peter Geoghegan wrote:
> Well, maybe. If the genericity of this syntax isn't what people want,
> I may go with something else.
By the way, I didn't mention that there is now also the optional
ability to specify a "merge on" unique index directly in DML. It would
On Wed, Jul 16, 2014 at 10:04 PM, Brightwell, Adam
wrote:
> Yes, I just tested it and the following would work from a grammar
> perspective:
>
> ALTER TABLE POLICY ADD (policy_quals)
> ALTER TABLE POLICY DROP
>
> Though, it would obviously require the addition of POLICY to the list of
> unres
On Fri, Jul 18, 2014 at 11:23 AM, Andres Freund wrote:
> Meh. A understandable syntax wouldn't require the pullups with a special
> scan node and such. I think you're attempting a sort of genericity
> that's making your (important!) goal much harder to reach.
Well, maybe. If the genericity of thi
On 2014-07-18 11:14:34 -0700, Peter Geoghegan wrote:
> On Fri, Jul 18, 2014 at 11:06 AM, Andres Freund
> wrote:
> > I don't see why you'd need such a node at all if we had a fully builtin
> > UPSERT. The whole stuff with ON CONFLICT SELECT FOR UPDATE and then
> > UPDATE ... FROM c CONFLICTS is to
On 08/07/14 02:14, Tom Lane wrote:
Also, the set of functions provided still needs more thought, because the
resolution of overloaded functions doesn't really work as nicely as all
that.
I am honestly considering just removing special case for int8 for now,
the sql standard width_bucket has on
On Fri, Jul 18, 2014 at 11:06 AM, Andres Freund wrote:
> I don't see why you'd need such a node at all if we had a fully builtin
> UPSERT. The whole stuff with ON CONFLICT SELECT FOR UPDATE and then
> UPDATE ... FROM c CONFLICTS is too complicated and exposes stuff that
> barely anybody will under
On 2014-07-18 10:53:36 -0700, Peter Geoghegan wrote:
> On Fri, Jul 18, 2014 at 10:46 AM, Andres Freund
> wrote:
> > I think the things that use "wierd" visibility semantics are pretty much
> > all doing that internally (things being EvalPlanQual stuff for
> > INSERT/UPDATE/DELETE and the referent
On Fri, Jul 18, 2014 at 10:46 AM, Andres Freund wrote:
> I think the things that use "wierd" visibility semantics are pretty much
> all doing that internally (things being EvalPlanQual stuff for
> INSERT/UPDATE/DELETE and the referential integrity triggers). I don't
> see sufficient reason why we
Hi,
On 2014-07-17 18:18:41 -0700, Peter Geoghegan wrote:
> I'm working on UPSERT again. I think that in order to make useful
> progress, I'll have to find a better way of overcoming the visibility
> issues (i.e. the problem of what to do about a
> still-in-progress-to-our-snapshot row being locked
John Cochran writes:
> My proposal is the have the following directory structure
> .../src/timezone - Would have only PostgreSQL specific code
> .../src/timezone/tznames - would be unaltered from current (optionally this
> could be removed)
> .../src/timezone/iana - would contain unaltered code a
Hi,
On 2014-07-18 23:38:09 +0900, MauMau wrote:
> My customer reported a problem that the following message is output too
> often.
>
> LOG: autovacuum: found orphan temp table "pg_temp_838"."some_table" in
> database "some_db"
> LOG: autovacuum: found orphan temp table "pg_temp_902"."some_table
Given my recent examination of the src/timezone subtree and the current
code at IANA for timezone information and tools, I proposing the following
changes and would like to first get group consensus on the change prior to
investing any major effort.
My proposal is the have the following directory
Please find attached 2 patches, which are a split of the patch discussed
in this thread.
(A) add gaussian & exponential options to pgbench \setrandom
the patch includes sql test files.
There is no change in the *code* from previous already reviewed
submissions, so I do not think that it
From: "Magnus Hagander"
On Fri, Jul 18, 2014 at 5:33 AM, Amit Kapila
wrote:
On Thu, Jul 17, 2014 at 4:51 PM, Magnus Hagander
wrote:
Did anyone actually test this patch? :)
I admit I did not build it on Windows specifically because I assumed
that was done as part of the development and revi
On 16/07/14 21:35, Pavel Stehule wrote:
The performance difference is about 20% (+/- few depending on the
array size), I don't know if that's bad enough to warrant
type-specific implementation. I personally don't know how to make
the generic implementation much faster than it is n
For example, when we set the number of transaction 10,000 (-t 1),
range of aid is 100,000,
and --exponential is 10, decile percents is under following as you know.
decile percents: 63.2% 23.3% 8.6% 3.1% 1.2% 0.4% 0.2% 0.1% 0.0% 0.0%
highest/lowest percent of the range: 9.5% 0.0%
They mean
On 18/07/14 13:18, Andres Freund wrote:
On 2014-07-18 13:08:24 +0200, Petr Jelinek wrote:
On 18/07/14 00:41, Andres Freund wrote:
Wouldn't it be better to use sscanf()? That should work with large
inputs across platforms.
Well, sscanf does not do much validation and silently truncates too bi
On Fri, Jul 18, 2014 at 3:12 PM, Воронин Дмитрий
wrote:
> I make a new version of patch. I corrected your notes for my previous
> version of patch. Could you test it? Thank you.
I just had a look at the new version of this patch, and this is
lacking a couple of things.
First, this patch has been
On 2014-07-18 13:08:24 +0200, Petr Jelinek wrote:
> On 18/07/14 00:41, Andres Freund wrote:
> >On 2014-06-27 00:51:02 +0200, Petr Jelinek wrote:
> >>{
> >>switch (c)
> >>{
> >>@@ -227,6 +229,33 @@ main(int argc, char *argv[])
> >>XLogFromFileN
On 18/07/14 00:41, Andres Freund wrote:
On 2014-06-27 00:51:02 +0200, Petr Jelinek wrote:
{
switch (c)
{
@@ -227,6 +229,33 @@ main(int argc, char *argv[])
XLogFromFileName(optarg, &minXlogTli,
&minXlogSegNo);
On Fri, Jul 18, 2014 at 5:33 AM, Amit Kapila wrote:
> On Thu, Jul 17, 2014 at 4:51 PM, Magnus Hagander
> wrote:
>>
>> Did anyone actually test this patch? :)
>>
>> I admit I did not build it on Windows specifically because I assumed
>> that was done as part of the development and review. And the
2014-07-18 5:13 GMT+09:00 Fabien COELHO :
>
> However, ISTM that it is not the purpose of pgbench documentation to be a
>>> primer about what is an exponential or gaussian distribution, so the idea
>>> would yet be to have a relatively compact explanation, and that the
>>> interested but clueless
37 matches
Mail list logo
