On Wed, Dec 14, 2016 at 4:34 PM, Ashutosh Sharma wrote:
> Attached is the patch based on Amit's explanation above. Please have a
> look and let me know for any concerns. Thank you Micheal and Andres
> for sharing your thoughts and Amit for your valuable inputs.
}
+event = &set->events[0]
Hi,
> Okay, but I think we need to re-enable the existing event handle for
> required event (FD_READ) by using WSAEventSelect() to make it work
> sanely. We have tried something on those lines and it resolved the
> problem. Ashutosh will post a patch on those lines later today. Let
> us know if
On 2016/12/09 19:46, Maksim Milyutin wrote:
I would like to work on two tasks:
- insert (and eventually update) tuple routing for foreign partition.
- the ability to create an index on the parent and have all of the
children inherit it;
The first one has been implemented in pg_pathman somehow,
On Tue, Dec 13, 2016 at 11:11 PM, Pavan Deolasee
wrote:
> To be fair to myself, I did try to find patches with equal or more
> complexity. But most of them had (multiple) reviewers assigned and were
> being discussed for weeks and months. I did not think I could contribute
> positively to those di
On Tue, Dec 13, 2016 at 1:00 PM, Ian Jackson wrote:
> The conversion is as follows: if a scenario is affected by the caveat,
> in there must be at least one transaction T which firstly produces
> "impossible" results I, and in which some later statement S produces a
> serialisation failure.
>
> To
On Tue, Dec 13, 2016 at 9:49 PM, Andres Freund wrote:
> On 2016-12-12 16:46:38 +0900, Michael Paquier wrote:
>> OK, I think that I have spotted an issue after additional read of the
>> code. When a WSA event is used for read/write activity on a socket,
>> the same WSA event gets reused again and a
On Thu, Dec 8, 2016 at 3:11 AM, Robert Haas wrote:
> On Thu, Oct 20, 2016 at 11:30 AM, Pavan Deolasee
> wrote:
> > We have a design to convert WARM chains back to HOT and that will
> increase
> > the percentage of WARM updates much beyond 50%. I was waiting for
> feedback
> > on the basic patch
On Mon, Dec 12, 2016 at 3:06 PM, Amit Langote wrote:
>
> Hi,
>
> On 2016/12/11 10:02, Venkata B Nagothi wrote:
> > On Fri, Dec 9, 2016 at 11:11 PM, Amit Langote
> > wrote:
> >> On Fri, Dec 9, 2016 at 3:16 PM, Venkata B Nagothi
> >> wrote:
> >>> I am testing the partitioning feature from the lat
On 13 Dec. 2016 20:54, "amul sul" wrote:
postgres=> select * from pg_background_result(67069) as (x text);
ERROR: terminating connection due to administrator command
CONTEXT: background worker, pid 67069
postgres=>
It'll also want to handle cancellation due to conflict with recovery if you
i
On Mon, Dec 12, 2016 at 4:46 PM, Thomas Munro
wrote:
> On Tue, Dec 13, 2016 at 10:47 AM, Kevin Grittner wrote:
>> Barring objections I will back-patch to 9.2 through 9.5 tomorrow.
>> (9.1 is out of support and the fix is already in 9.6 and forward.)
>
> +1
Done.
I will add a test case based on
On Wed, Dec 14, 2016 at 1:14 AM, Ashutosh Sharma wrote:
> I have been working on this issue for last few days and it seems like
> i have almost found the reason for this failure. My findings till date
> are as follows.
>
> Just to confirm if the problem is happening due to reusability of
> WaitEve
On 13/12/16 21:42, Peter Eisentraut wrote:
> On 12/10/16 2:48 AM, Petr Jelinek wrote:
>> Attached new version with your updates and rebased on top of the current
>> HEAD (the partitioning patch produced quite a few conflicts).
>
> I have attached a few more "fixup" patches, mostly with some editin
On 13/12/16 22:05, Andres Freund wrote:
> Hi,
>
> On 2016-12-13 15:42:17 -0500, Peter Eisentraut wrote:
>> I think this is getting very close to the point where it's committable.
>> So if anyone else has major concerns about the whole approach and
>> perhaps the way the new code in 0005 is organiz
On Wed, Dec 14, 2016 at 9:25 AM, Kyotaro HORIGUCHI
wrote:
> Ah, sorry for the confusion.
>
> At Tue, 13 Dec 2016 22:43:22 +0900, Michael Paquier
> wrote in
>
>> On Tue, Dec 13, 2016 at 7:15 PM, Kyotaro HORIGUCHI
>> wrote:
>> > Thank you for the comment.
>>
>> Er, it is good to see more people
On 14/12/16 01:26, Peter Eisentraut wrote:
> On 12/12/16 7:33 PM, Andres Freund wrote:
>> +-- test switching between slots in a session
>> +SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot1',
>> 'test_decoding', true);
>> +SELECT 'init' FROM pg_create_logical_replication_slot
Ah, sorry for the confusion.
At Tue, 13 Dec 2016 22:43:22 +0900, Michael Paquier
wrote in
> On Tue, Dec 13, 2016 at 7:15 PM, Kyotaro HORIGUCHI
> wrote:
> > Thank you for the comment.
>
> Er, it is good to see more people interested in this problem... As the
> former author, still working acti
On 12/12/16 7:33 PM, Andres Freund wrote:
> +-- test switching between slots in a session
> +SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot1',
> 'test_decoding', true);
> +SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot2',
> 'test_decoding', true);
>
On Tue, Dec 13, 2016 at 11:40:54AM -0500, Robert Haas wrote:
> Let's confine ourselves to fixing one problem at a time. I think we
> can get where we want to be in this case by adding one new column and
> some new rows to pg_stat_activity.
Agreed. Let's also remove the abuse of WAL senders with t
On Thu, Dec 1, 2016 at 3:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Dec 1, 2016 at 2:32 PM, Tom Lane wrote:
>>> ... well, they would be if we passed down xactStartTimestamp to parallel
>>> workers, but I can't find any code that does that. In view of the fact that
>>> transaction_t
On 2016-12-13 06:55:31 +0100, Petr Jelinek wrote:
> >> This is a quadratic algorithm - that could bite us... Not sure if we
> >> need to care. If we want to fix it, one approach owuld be to use
> >> RangeVarGetRelid() instead, and then do a qsort/deduplicate before
> >> actually opening the relati
Hi,
On 2016-12-13 15:42:17 -0500, Peter Eisentraut wrote:
> I think this is getting very close to the point where it's committable.
> So if anyone else has major concerns about the whole approach and
> perhaps the way the new code in 0005 is organized, now would be the time ...
Uh. The whole cach
On 12/10/16 2:48 AM, Petr Jelinek wrote:
> Attached new version with your updates and rebased on top of the current
> HEAD (the partitioning patch produced quite a few conflicts).
I have attached a few more "fixup" patches, mostly with some editing of
documentation and comments and some compiler w
ronan.dunk...@dalibo.com writes:
> On mardi 13 décembre 2016 09:10:47 CET Adrien Nayrat wrote:
>> The commit 100340e2dcd05d6505082a8fe343fb2ef2fa5b2a introduce an
>> estimation error :
> The problem is, for semi and anti joins, we assume that we have nohing to do
> (costsize.c:4253):
>
On Tue, Dec 13, 2016 at 12:00 PM, Ian Jackson wrote:
> Kevin Grittner writes:
> I still hope to be able to convince you that the definition of
> SERIALIZABLE (in the pgsql docs) ought to be a stronger version, which
> covers even non-committed transactions.
That doesn't seem likely. The stronge
On mardi 13 décembre 2016 09:10:47 CET Adrien Nayrat wrote:
> Hi hackers,
>
> The commit 100340e2dcd05d6505082a8fe343fb2ef2fa5b2a introduce an
> estimation error :
[]
>
> Estimated row is 10x larger since 100340e2d
>
> Regards,
Hello,
I think I understand what the problem is. In get_foreig
Nico Williams writes:
> On Tue, Dec 13, 2016 at 10:26:24AM +0900, Michael Paquier wrote:
>> On Mon, Dec 12, 2016 at 10:22 PM, Greg Stark wrote:
>>> One option might be for Postgres to define duplicate operator names
>>> using ¿ or something else.
>> Are you sure that using a non-ASCII character
On Tue, Dec 13, 2016 at 12:22 PM, Ildar Musin wrote:
> We've noticed that PartitionDispatch object is built on every INSERT query
> and that it could create unnecessary overhead. Wouldn't it be better to keep
> it in relcache?
You might be able to cache some of that data in the relcache, but List
On Mon, Dec 12, 2016 at 9:21 PM, Amit Kapila wrote:
> The reason is to make the operations consistent in master and standby.
> In WAL patch, for clearing the SPLIT_CLEANUP flag, we write a WAL and
> if we don't release the lock after writing a WAL, the operation can
> appear on standby even before
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation [and 2 more messages]"):
> [various things]
I get the feeling from your message that I have irritated you. I'm
sorry if I have. In particular, I wanted to say that I certainly
don't expect bug
Based on discussion in
https://www.postgresql.org/message-id/CAE1wr-w%3DLE1cK5uG_rmAh-VBxc4_Bnw-gAE3qSqL-%3DtWwvLvjQ%40mail.gmail.com
.
Tested via regression tests.
To be applied in master only and to be included in 10.0.
--
Vladimir Rusinov
Storage SRE, Google Ireland
Google Ireland Ltd.,Gor
Hi hackers,
On 08.12.2016 19:44, Dmitry Ivanov wrote:
That would be fantastic. I and my colleagues at EnterpriseDB can
surely help review; of course, maybe you and some of your colleagues
would like to help review our patches, too.
Certainly, I'll start reviewing as soon as I get familiar wit
On Mon, Dec 12, 2016 at 6:45 PM, Kevin Grittner wrote:
> On Mon, Dec 12, 2016 at 10:33 AM, Andres Freund
> wrote:
> > On 2016-12-12 13:26:32 -0300, Alvaro Herrera wrote:
> >> Robert Haas wrote:
>
> >>> 1. Show all processes that have a PGPROC in pg_stat_activity,
>
> >>> 2. Add a second view, sa
On Tue, Dec 13, 2016 at 10:26:24AM +0900, Michael Paquier wrote:
> On Mon, Dec 12, 2016 at 10:22 PM, Greg Stark wrote:
> > One option might be for Postgres to define duplicate operator names
> > using ¿ or something else. I think ¿ is a good choice because it's a
> > common punctuation mark in spa
On Mon, Dec 12, 2016 at 8:26 PM, Michael Paquier
wrote:
> On Mon, Dec 12, 2016 at 10:22 PM, Greg Stark wrote:
>> On 12 December 2016 at 04:59, Craig Ringer wrote:
>>> I didn't realise Pg's use of ? was that old, so thanks. That makes
>>> offering alternatives much less appealing.
>>
>> One optio
On Tue, Dec 13, 2016 at 9:50 AM, Ian Jackson wrote:
> Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db:
> Retry on constraint violation [and 2 more messages]"):
>> On Tue, Dec 13, 2016 at 5:30 AM, Ian Jackson
>> wrote:
>>> Are all of these cases fixed by fcff8a57519847 "D
On Mon, Dec 12, 2016 at 8:13 PM, Michael Paquier
wrote:
> On Tue, Dec 13, 2016 at 10:05 AM, Craig Ringer wrote:
>> We should probably expose a proc_type or something, with types:
>>
>> * client_backend
>> * bgworker
>> * walsender
>> * autovacuum
>> * checkpointer
>> * bgwriter
>
> A text field i
On Tue, Dec 13, 2016 at 1:58 AM, Amit Langote
wrote:
> Attaching the above patch, along with some other patches posted earlier,
> and one more patch fixing another bug I found. Patch descriptions follow:
>
> 0001-Miscallaneous-code-and-comment-improvements.patch
>
> Fixes some obsolete comments w
On 2016-12-12 16:46:38 +0900, Michael Paquier wrote:
> OK, I think that I have spotted an issue after additional read of the
> code. When a WSA event is used for read/write activity on a socket,
> the same WSA event gets reused again and again. That's fine for
> performance reasons
It's actually a
Hi All,
I have been working on this issue for last few days and it seems like
i have almost found the reason for this failure. My findings till date
are as follows.
Just to confirm if the problem is happening due to reusability of
WaitEventSet structure, I had replaced a function call
ModifyWait
Hi Micheal,
> Ashutosh, could you try it and see if it improves things?
> -
>
Thanks for your patch. I would like to inform you that I didn't find any
improvement with your patch.
With Regards,
Ashutosh Sharma
EnterpriseDB: http://www.enterprisedb.com
Hi Gilles,
I don't plan to be able to get back to this patch until late
this week or early next week. My plan is to then go though
the whole thing and fix everything I can find. If we're both
working at the same time this could lead to wasted effort
so I will write as soon as I start work and if
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation [and 2 more messages]"):
> On Tue, Dec 13, 2016 at 5:30 AM, Ian Jackson
> wrote:
> > Are all of these cases fixed by fcff8a57519847 "Detect SSI conflicts
> > before reporting constraint violati
On Tue, Dec 13, 2016 at 10:41 AM, Tom Lane wrote:
> Robert Haas writes:
>> I find this a bit unclear, because the revised text kind of jumps back
>> and forth between the floating-point and integer formats. Perhaps
>> something like this:
>
> Your wording seems OK to me, although I'd drop the "i
On Fri, Dec 9, 2016 at 5:46 AM, Maksim Milyutin
wrote:
> I would like to work on two tasks:
> - insert (and eventually update) tuple routing for foreign partition.
> - the ability to create an index on the parent and have all of the children
> inherit it;
>
> The first one has been implemented i
Robert Haas writes:
> I find this a bit unclear, because the revised text kind of jumps back
> and forth between the floating-point and integer formats. Perhaps
> something like this:
Your wording seems OK to me, although I'd drop the "instead".
regards, tom lane
--
S
On Thu, Dec 8, 2016 at 11:58 PM, Amit Langote
wrote:
> Hierarchical lock manager stuff is interesting. Are you perhaps alluding
> to a new *intention* lock mode as described in the literature on multiple
> granularity locking [1]?
Yes.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
T
On Mon, Dec 12, 2016 at 8:50 AM, Aleksander Alekseev
wrote:
> I suggest to rewrite the documentation a bit to make it more clear that
> by default timestamp is stored in microseconds. Corresponding patch is
> attached.
I find this a bit unclear, because the revised text kind of jumps back
and for
Jesper Pedersen writes:
> Attached is a new builtin function that exposes the CATALOG_VERSION_NO
> constant under the pg_catversion() function, e.g.
I'm pretty sure that we intentionally didn't expose that, reasoning that
users should only care about the user-visible version number. What
exactl
On Thu, Dec 8, 2016 at 4:34 PM, Karl O. Pinc wrote:
>> I do think that the blizzard of small patches that you've
>> submitted in some of your emails may possibly be a bit overwhelming.
>> We shouldn't really need a stack of a dozen or more patches to
>> implement one small feature. Declarative p
On Mon, Dec 12, 2016 at 4:31 AM, Gilles Darold wrote:
> Applied in last version of the patch v18 as well as removing of an
> unused variable.
OK, this looks a lot closer to being committable. But:
@@ -570,11 +583,13 @@ SysLogger_Start(void)
* a time-based rotation.
*/
first_sys
On Mon, Dec 12, 2016 at 10:08 PM, Tom Lane wrote:
> Every WHERE clause is a
>
boolean expression, so there's no principled reason why such a rule
> wouldn't result in canonicalizing e.g. "i = 42" into "(i = 42) = true",
> wreaking havoc on every other optimization we have. Restricting it
> to on
On Tue, Dec 13, 2016 at 6:42 AM, Dilip Kumar wrote:
>> This patch is hard to read because it is reorganizing a bunch of code
>> as well as adding new functionality. Perhaps you could separate it
>> into two patches, one with the refactoring and then the other with the
>> new functionality.
>
> Ok
On Mon, Dec 12, 2016 at 5:45 PM, Tom Lane wrote:
> One way that we could make things better is to rely on the knowledge
> that EPQ isn't asked to evaluate joins for more than one row per input
> relation, and therefore using merge or hash join technology is really
> overkill. We could make a tree
On Tue, Dec 13, 2016 at 5:30 AM, Ian Jackson wrote:
> I am concerned that there are other possible bugs of this form.
> In earlier messages on this topic, it has been suggested that the
> "impossible" unique constraint violation is only one example of a
> possible "leakage".
As I see it, the mai
On Tue, Dec 13, 2016 at 4:15 AM, Tom Lane wrote:
> Jeff Janes writes:
>> I have a test case where I made the fdw connect back to itself, and
>> stripped out all the objects that I could and still reproduce the case. It
>> is large, 21MB compressed, 163MB uncompressed, so I am linking it here:
>>
On 12/11/2016 11:37 PM, Amit Kapila wrote:
On Sun, Dec 11, 2016 at 11:54 AM, Amit Kapila wrote:
On Wed, Dec 7, 2016 at 2:02 AM, Jeff Janes wrote:
With above fixes, the test ran successfully for more than a day.
There was a small typo in the previous patch which is fixed in
attached. I don'
On Tue, Dec 13, 2016 at 7:15 PM, Kyotaro HORIGUCHI
wrote:
> Thank you for the comment.
Er, it is good to see more people interested in this problem... As the
former author, still working actively on this patch, perhaps it would
be better if I continue to code this patch, no? It is a waste to step
Hi Hackers,
Attached is a new builtin function that exposes the CATALOG_VERSION_NO
constant under the pg_catversion() function, e.g.
test=# SELECT pg_catversion();
pg_catversion
---
201612121
(1 row)
Although it mostly useful during the development cycle to verify if
dump/r
On Tue, Dec 13, 2016 at 12:49 PM, Fujii Masao wrote:
Thanks for the review.
> Isn't it better to mention "an exclusive backup" here? What about
>
> EXCLUSIVE_BACKUP_STARTING means that pg_start_backup() is starting an
> exclusive
> backup.
> EXCLUSIVE_BACKUP_STOPPING means that pg_stop_backup()
On Mon, Dec 12, 2016 at 1:34 AM, Heikki Linnakangas wrote:
> On 12/01/2016 09:45 PM, Andres Freund wrote:
>>
>> And nobody has added a buildfarm module to run it manually on their
>> servers either :(
>
> I just added a module to run "make -C src/test/ssl check" in chipmunk. So at
> least that's c
On Tue, Dec 13, 2016 at 2:05 PM, Andrew Borodin wrote:
> 2016-12-13 12:55 GMT+05:00 amul sul :
>> I think background-session code is not that much deviated from
>> pg_background code,
> It is not derived, though it is not much deviated. background sessions
> code do not have detailed exceptions an
2016-12-13 13:03 GMT+01:00 Alvaro Herrera :
> Pavel Stehule wrote:
> > Hi
> >
> > I don't remember well, there was maybe similar ToDo.
> >
> > Yesterday I got a incident on high load system when I executed DROP INDEX
> > cmd.
> >
> > This statement waited on a finish of long transaction, but it st
Pavel Stehule wrote:
> Hi
>
> I don't remember well, there was maybe similar ToDo.
>
> Yesterday I got a incident on high load system when I executed DROP INDEX
> cmd.
>
> This statement waited on a finish of long transaction, but it stopped any
> other statements.
>
> Can be nice when waiting
Hi
I don't remember well, there was maybe similar ToDo.
Yesterday I got a incident on high load system when I executed DROP INDEX
cmd.
This statement waited on a finish of long transaction, but it stopped any
other statements.
Can be nice when waiting on lock statement doesn't block another
sta
Thanks to everyone for your attention.
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation"):
> On Mon, Dec 12, 2016 at 8:45 AM, Ian Jackson
> wrote:
> > AIUI the documented behavour is that "every set of successful
> > transactions is seriali
Thank you for the comment.
At Tue, 13 Dec 2016 12:49:12 +0900, Fujii Masao wrote
in
> On Tue, Nov 8, 2016 at 11:18 AM, Kyotaro HORIGUCHI
> wrote:
> >> By the way, as long as I look at that, the patch applies cleanly on
> >> master and 9.6 but not further down. If a committer shows up to push
>
Hello, it seems to me to work as expected.
At Thu, 08 Dec 2016 15:58:10 -0500, Tom Lane wrote in
<7083.1481230...@sss.pgh.pa.us>
> I've pushed the previous patch to HEAD. Attached is a proposed patch
> (against 9.6) that we could use for the back branches; it takes the
> brute force approach of
On 2016/12/13 0:17, Tomas Vondra wrote:
> On 12/12/2016 07:37 AM, Amit Langote wrote:
>>
>> Hi Tomas,
>>
>> On 2016/12/12 10:02, Tomas Vondra wrote:
>>>
>>> 2) I'm wondering whether having 'table' in the catalog name (and also in
>>> the new relkind) is too limiting. I assume we'll have partitioned
2016-12-13 12:55 GMT+05:00 amul sul :
> I think background-session code is not that much deviated from
> pg_background code,
It is not derived, though it is not much deviated. background sessions
code do not have detailed exceptions and code comments, but it is
doing somewhat similar things.
>IIUC
Hi hackers,
The commit 100340e2dcd05d6505082a8fe343fb2ef2fa5b2a introduce an
estimation error :
create table t3 as select j from generate_series(1,1)
i,generate_series(1,100) j ;
create table t4 as select j from generate_series(1,100) j ;
create unique index ON t4(j);
alter table t3 add const
At Tue, 13 Dec 2016 08:46:06 +0530, Amit Kapila wrote
in
> On Mon, Dec 12, 2016 at 9:54 PM, Masahiko Sawada
> wrote:
> > On Mon, Dec 12, 2016 at 9:52 PM, Fujii Masao wrote:
> >> On Mon, Dec 12, 2016 at 9:31 PM, Masahiko Sawada
> >> wrote:
> >>> On Sat, Dec 10, 2016 at 5:17 PM, Amit Kapila
71 matches
Mail list logo