Hi Thomas,
I like the whole idea.
In fact, i understood this in your very first response itself.
Only thing is every time i have to check for dsa_attached or not. I mean
get_my_shared_state() is NULL or not.
To avoid that check, i tried creating it in _PG_Init(postmaster process itself)
Hi,
On 21 June 2017 at 13:11, Heikki Linnakangas wrote:
> On 06/16/2017 01:24 PM, Shubham Barai wrote:
>
>> @@ -497,6 +499,13 @@ gistplacetopage(Relation rel, Size freespace,
>> GISTSTATE *giststate,
>> for (ptr = dist->next; ptr; ptr = ptr->next)
>>
On Mon, Jun 19, 2017 at 11:57 PM, Konstantin Knizhnik
wrote:
> I attached simple patch adding ASOF join to Postgres. Right now it support
> only outer join and requires USING clause (consequently it is not possible
> to join two tables which joi keys has different
On Wed, Jun 21, 2017 at 5:27 PM, Mahendranath Gurram
wrote:
> Initially i tried to design the same way.
> I mean, i have created a background worker and created dsa in it.
> I tried to attach/detach to the same dsa/dsm by all the backends(postgres
> clients/connections)
On 06/21/2017 10:41 AM, Heikki Linnakangas wrote:
On 06/16/2017 01:24 PM, Shubham Barai wrote:
@@ -497,6 +499,13 @@ gistplacetopage(Relation rel, Size freespace, GISTSTATE
*giststate,
for (ptr = dist->next; ptr; ptr = ptr->next)
> From: "Heikki Linnakangas"
>
> Hmm. The hash table ought to speed up the RWConflictExists() function
> right? Where in the flame graph is RWConflictExists()? If it only
> accounts for a small amount of the overall runtime, even drastic speedup
> there won't make much
Here is a patch to fix a typo in a comment in ExecWithCheckOptions():
s/as as/as/.
Best regards,
Etsuro Fujita
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 7f460bd..9dbe175 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
Commit d3cc37f1d801a6b5cad9bf179274a8d767f1ee50 added this to
ExecInitModifyTable:
+ /* The root table RT index is at the head of the partitioned_rels
list */
+ if (node->partitioned_rels)
+ {
+ Index root_rti;
+ Oid root_oid;
+
+ root_rti =
On 06/16/2017 01:24 PM, Shubham Barai wrote:
@@ -497,6 +499,13 @@ gistplacetopage(Relation rel, Size freespace, GISTSTATE
*giststate,
for (ptr = dist->next; ptr; ptr = ptr->next)
UnlockReleaseBuffer(ptr->buffer);
}
+
+
(I'm cleaning up my inbox, hence the delayed reply)
On 08/02/2016 10:51 PM, Robert Haas wrote:
On Tue, Aug 2, 2016 at 2:33 PM, Bruce Momjian wrote:
On Tue, Jul 26, 2016 at 05:42:43PM -0400, Chapman Flack wrote:
Even so, I'd be curious whether it would break anything to have
On 2017/06/21 3:53, Robert Haas wrote:
> On Tue, Jun 20, 2017 at 2:54 AM, Amit Khandekar
> wrote:
>>> I guess I don't see why it should work like this. In the INSERT case,
>>> we must build withCheckOption objects for each partition because those
>>> partitions don't
On 06/21/2017 11:35 AM, Etsuro Fujita wrote:
Here is a patch to fix a typo in a comment in ExecWithCheckOptions():
s/as as/as/.
Fixed, thanks!
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 21.06.2017 04:48, Michael Paquier wrote:
There has not been much activity on this thread for some time, and I
mentioned my intentions to some developers at the last PGCon. But I am
planning to study more the work that has been done here, with as
envisaged goal to present a patch for the first
Hi,
After changing
sendTimeLineIsHistoric = state->currTLI == ThisTimeLineID;
to
sendTimeLineIsHistoric = state->currTLI != ThisTimeLineID;
I was facing another issue.
On promotion of a cascaded server ThisTimeLineID in the standby server having
logical slot becomes 0.
Then i added a function
On 20 June 2017 at 03:01, Amit Langote wrote:
> Hmm, yes. The following exercise convinced me.
>
> create table r (a int) partition by range (a);
> create table r1 partition of r for values from (1) to (10);
> create rule "_RETURN" as on select to r1 do instead
Fujita-san,
On 2017/06/21 16:59, Etsuro Fujita wrote:
> Commit d3cc37f1d801a6b5cad9bf179274a8d767f1ee50 added this to
> ExecInitModifyTable:
>
> + /* The root table RT index is at the head of the partitioned_rels list */
> + if (node->partitioned_rels)
> + {
> + Index root_rti;
> +
On 21.06.2017 11:00, Thomas Munro wrote:
Hmm. Yeah, I see the notational problem. It's hard to come up with a
new syntax that has SQL nature. What if... we didn't use a new syntax
at all, but recognised existing queries that are executable with this
strategy? Queries like this:
WITH
Hi,
I have found that we can cancel/terminate autovacuum launchers and
background worker processes by pg_cancel/terminate_backend function.
I'm wondering this behavior is not expected and if not I want to fix it.
The current pg_stat_activity shows background workers and autovacuum
lancher as
Hi,
As I report in another thread[1], I found the autovacuum launcher occurs
the following error in PG 10 when this received SIGINT. I can repuroduce
this by pg_cancel_backend or `kill -2 `.
2017-06-21 13:56:07.010 JST [32483] ERROR: canceling statement due to user
request
2017-06-21
Hi,
In the documentation[1], there is the following description:
"pg_stat_activity does not show an entry for the Startup process"
However, the current pg_stat_activity show startup process's entry.
postgres=# select pid, backend_type from pg_stat_activity ;
pid | backend_type
We are also seeing contention on the walwritelock and repeated writes to the
same offset if we move the flush outside the lock in the Azure environment.
pgbench doesn't scale beyond ~8 cores without saturating the IOPs or
bandwidth. Is there more work being done in this area?
--
View this
On Wed, Jun 21, 2017 at 5:45 PM, Yugo Nagata wrote:
> Hi,
>
> As I report in another thread[1], I found the autovacuum launcher occurs
> the following error in PG 10 when this received SIGINT. I can repuroduce
> this by pg_cancel_backend or `kill -2 `.
>
> 2017-06-21
On 06/20/2017 08:30 PM, Tom Lane wrote:
> Michael Paquier writes:
>> On Wed, Jun 21, 2017 at 8:43 AM, Tom Lane wrote:
>>> Yeah, I thought it would work fine with Makefile-using Windows toolchains.
>>> But people who use MSVC need something else,
Hi,
Sorry for being away from here.
I had some issues with my laptop, and I have resumed working on this.
On Thu, Jun 15, 2017 at 1:21 AM, Robert Haas wrote:
> On Wed, Jun 14, 2017 at 8:02 AM, Jeevan Ladhe
> wrote:
> > Here are the details
Thanks Ashutosh and Kyotaro for reviewing further.
I shall address your comments in next version of my patch.
Regards,
Jeevan Ladhe
On Fri, Jun 16, 2017 at 1:46 PM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> Hello, I'd like to review this but it doesn't fit the master, as
>
While playing with HEAD as of d14c85ed,
I ran into the following:
CREATE DATABASE source;
CREATE DATABASE recipient;
\c source
CREATE TABLE repli(id integer PRIMARY KEY, val text NOT NULL);
INSERT INTO repli VALUES (1, 'one');
CREATE PUBLICATION repsend FOR TABLE repli;
SELECT
Hi Amit,
On Thu, Jun 15, 2017 at 12:31 PM, Amit Langote <
langote_amit...@lab.ntt.co.jp> wrote:
> Oops, I meant to send one more comment.
>
> On 2017/06/15 15:48, Amit Langote wrote:
> > BTW, I noticed the following in 0002
> +errmsg("there exists a
On Tue, Jun 20, 2017 at 6:57 PM, Dilip Kumar wrote:
> This is basically crashing in RelationBuildPartitionDesc, so I think
> we don't have any test case for testing DEFAULT range partition where
> partition key has more than one attribute. So I suggest we can add
> such
On Wed, Jun 21, 2017 at 6:50 PM, Kuntal Ghosh
wrote:
> I think we can just check dsm_find_mapping() to check whether the dsm
> handle is already attached. Something like,
>
> }
> - else
> + else if(!dsm_find_mapping(AutoVacuumShmem->av_dsa_handle))
On Wed, Jun 21, 2017 at 6:05 PM, Yugo Nagata wrote:
>
> Attached is a patch for the documentation fix.
>
Please attach the patch as well. :-)
--
Thanks & Regards,
Kuntal Ghosh
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list
On 21 June 2017 at 20:14, Robert Haas wrote:
> On Wed, Jun 21, 2017 at 5:28 AM, Amit Langote
> wrote:>> The comment "UPDATE/DELETE
> cases are handled above" is referring to
>>> the code that initializes the WCOs generated by the planner.
On 06/21/2017 02:25 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 06/21/2017 11:30 AM, Tom Lane wrote:
>>> Andrew Dunstan writes:
Unfortunately this seems precluded by the use of the non-standard
"err.h". It looks
On 6/21/17 09:02, Albe Laurenz wrote:
> 2017-06-21 14:55:12.033 CEST [23124] LOG: could not send data to client:
> Broken pipe
> 2017-06-21 14:55:12.033 CEST [23124] FATAL: connection to client lost
> 2017-06-21 14:55:17.032 CEST [23133] LOG: logical replication apply worker
> for
On Thu, Jun 15, 2017 at 3:11 AM, Satyanarayana Narlapuram
wrote:
> The proposal is to tweak the connectivity wire protocol, and add a
> connection id (GUID) filed in the startup message. We can trace the
> connection using this GUID and investigate further
On Wed, Jun 21, 2017 at 12:15 PM, Robert Haas wrote:
> I think the problem is real,
> but I'm not sure that this is the best solution. On the other hand,
> I'm also not entirely sure I understand the proposal yet.
Given the problems with changing the protocol it does seem
On Wed, Jun 21, 2017 at 04:07:30PM -0400, Tom Lane wrote:
> I wrote:
> > Barring objections, I'd like to reindent HEAD with the new version
> > of pg_bsd_indent (and correspondingly updated pgindent script)
> > tomorrow, say around 1800 UTC.
>
> ... and it's done.
You are eventually doing all
Hi,
Author: Heikki Linnakangas
Branch: master Release: REL9_5_BR [b2a5545bd] 2015-04-13 16:53:49 +0300
Branch: REL9_4_STABLE Release: REL9_4_2 [d72792d02] 2015-04-13 17:22:21 +0300
Branch: REL9_3_STABLE Release: REL9_3_7 [a800267e4] 2015-04-13 17:22:35 +0300
Branch:
In the attached script, the second insert into t2 (as part of the CTE)
should succeed. My actual use case isn't much more complex; the function is
used primarily to allow peaking at columns that the function definer has
access to but a typical user does not. Function also makes it easy to copy
On 2017/06/21 18:49, Dean Rasheed wrote:
> On 20 June 2017 at 03:01, Amit Langote wrote:
>> Hmm, yes. The following exercise convinced me.
>>
>> create table r (a int) partition by range (a);
>> create table r1 partition of r for values from (1) to (10);
>> create
On 2017-06-21 17:28:32 -0400, Tom Lane wrote:
> Right now we're really just speculating about how much pain there will
> be, on either end of this. So it'd be interesting for somebody who's
> carrying large out-of-tree patches (EDB? Citus?) to try the new
> pgindent version on a back branch and
On 2017-06-22 08:46:35 +0900, Michael Paquier wrote:
> On Thu, Jun 22, 2017 at 4:16 AM, Peter Eisentraut wrote:
> > Restart logical replication launcher when killed
>
> - /* The logical replication launcher can be stopped at any time. */
> - proc_exit(0);
> +
Bruce Momjian writes:
> On Wed, Jun 21, 2017 at 04:07:30PM -0400, Tom Lane wrote:
>> ... and it's done.
> You are eventually doing all active branches, right?
I don't think we'd entirely decided that we should do that, or when
to do it. I'm not in a huge hurry; we might find
2017-06-21 15:14 GMT-03:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> > It doesn't appear to be contingent on anything other than the content of
> > the command you just gave it. I don't think we need a NOTICE saying
> > that it did that thing I just told it to do--that should be
On 22 Jun. 2017 07:40, "Andres Freund" wrote:
On 2017-06-20 17:51:23 +0200, Daniel Verite wrote:
> Andres Freund wrote:
>
> > FWIW, I still think this needs a pgbench or similar example integration,
> > so we can actually properly measure the benefits.
>
> Here's an
Rod Taylor writes:
> In the attached script, the second insert into t2 (as part of the CTE)
> should succeed.
No, I don't think so. You declared the check function as STABLE which
means it is confined to seeing the same snapshot as the surrounding query.
So it can't see
On Thu, Jun 22, 2017 at 4:16 AM, Peter Eisentraut wrote:
> Restart logical replication launcher when killed
- /* The logical replication launcher can be stopped at any time. */
- proc_exit(0);
+ /* The logical replication launcher can be stopped at
On Wed, Jun 21, 2017 at 7:46 PM, Tom Lane wrote:
> Rod Taylor writes:
> > In the attached script, the second insert into t2 (as part of the CTE)
> > should succeed.
>
> No, I don't think so. You declared the check function as STABLE which
> means it is
On Wed, Jun 21, 2017 at 11:42 PM, Daniel Gustafsson wrote:
> The message is truncated in SetBackendCancelMessage() for safety, but
> pg_{cancel|terminate}_backend() could throw an error on too long message, or
> warning truncation, to the caller as well. Personally I think a
Hi,
On 2017-06-20 16:11:32 +0300, Heikki Linnakangas wrote:
> On 06/19/2017 10:30 AM, Andres Freund wrote:
> > Greg Burek from Heroku (CCed) reported a weird issue on IM, that was
> > weird enough to be interesting. What he'd observed was that he promoted
> > some PITR standby, and early clones
Andres Freund writes:
> On 2017-06-21 17:28:32 -0400, Tom Lane wrote:
>> And I think it'd make sense to wait a few
>> months and garner some experience with back-patching from v10 into the
>> older branches, so we have more than guesses about how much pain not
>> reindenting
The release team has agreed that a good time to put out beta2 will
be the second week of July, ie wrap tarballs 10 July for announcement
13 July.
I imagine beta3 will appear along with the scheduled back-branch
releases in the second week of August, but that's not positively
decided yet.
On 2017-06-20 17:51:23 +0200, Daniel Verite wrote:
> Andres Freund wrote:
>
> > FWIW, I still think this needs a pgbench or similar example integration,
> > so we can actually properly measure the benefits.
>
> Here's an updated version of the patch I made during review,
> adding
Today, lorikeet failed with a new variant on the bgworker start crash:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet=2017-06-21%2020%3A29%3A10
This one is even more exciting than the last one, because it sure looks
like the crashing bgworker took the postmaster down with it.
On 2017-06-21 16:40:48 -0700, Andres Freund wrote:
> On 2017-06-20 17:51:23 +0200, Daniel Verite wrote:
> > Andres Freund wrote:
> >
> > > FWIW, I still think this needs a pgbench or similar example integration,
> > > so we can actually properly measure the benefits.
> >
> > Here's an
On Mon, Jun 19, 2017 at 11:57 PM, Konstantin Knizhnik
wrote:
> On 16.06.2017 19:07, David Fetter wrote:
>> If you turn your head sideways, it's very similar to the range merge
>> join Jeff Davis proposed. https://commitfest.postgresql.org/14/1106/
>
> May be, but I do
On 06/21/2017 11:30 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Unfortunately this seems precluded by the use of the non-standard
>> "err.h". It looks like that will trip us up on mingw also.
> Hm, why? Doesn't the -I search path get the right thing?
>
>
On 6/21/17 13:03, Yugo Nagata wrote:
> As I report in another thread[1], when the logical replication launcher
> is terminated by SIGTERM, it never been restarted and we need to restart
> the server to enable logical replication again.
>
> This is because the logical replication launcher exits
I wrote:
> Barring objections, I'd like to reindent HEAD with the new version
> of pg_bsd_indent (and correspondingly updated pgindent script)
> tomorrow, say around 1800 UTC.
... and it's done.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On 6/20/17 22:54, Jeff Janes wrote:
> I think this should go away:
>
> ereport(NOTICE,
> (errmsg("created replication slot \"%s\" on
> publisher",
> slotname)));
>
> It doesn't appear to be contingent on anything other than the
On 6/20/17 22:37, Etsuro Fujita wrote:
> On 2017/06/21 3:30, Peter Eisentraut wrote:
>> On 6/20/17 05:50, Etsuro Fujita wrote:
>>> Here is a small patch to add a comment on its new member PartitionRoot.
>>
>> The existing comment style is kind of unusual. How about the attached
>> to clean it up
On Tue, Jun 20, 2017 at 2:58 PM, Merlin Moncure wrote:
> On Tue, Jun 20, 2017 at 2:34 PM, David G. Johnston
> wrote:
>> On Tue, Jun 20, 2017 at 12:22 PM, Chapman Flack
>> wrote:
>>> I get the reported result (DELETE 0 and a
Hi,
When promoting a standby without using the "fast promotion" logic,
e.g. by using recovery targets (which doesn't use fast promotion for
unbeknownst to me reasons), checkpointer doesn't necessarily respect
archive timeout for the first cycle after promotion. The reason for
that is that it
On Mon, Jun 12, 2017 at 9:50 PM, Haribabu Kommi
wrote:
> Open Items:
>
> 1. The BitmapHeapScan and TableSampleScan are tightly coupled with
> HeapTuple and HeapScanDesc, So these scans are directly operating
> on those structures and providing the result.
>
> These scan
On Wed, Jun 21, 2017 at 1:37 PM, Amit Khandekar wrote:
>> e.g. the table is partitioned on order number, and you do UPDATE
>> lineitem SET product_code = 'K372B' WHERE product_code = 'K372'.
>
> This query does not update order number, so here there is no
>
On Wed, Jun 21, 2017 at 1:38 PM, Amit Khandekar wrote:
>>> Yep, it's more appropriate to use
>>> ModifyTableState->rootResultRelationInfo->ri_RelationDesc somehow. That
>>> is, if answer to the question I raised above is positive.
>
> From what I had checked earlier when
On 21 June 2017 at 00:23, Robert Haas wrote:
> On Tue, Jun 20, 2017 at 2:54 AM, Amit Khandekar
> wrote:
>>> I guess I don't see why it should work like this. In the INSERT case,
>>> we must build withCheckOption objects for each partition because
Hi,
Now that hash index support write-ahead logging, it will be great if we add
support for predicate locking to it.
Implementation of predicate locking in hash index seems very simple.
I have already made changes in the code. I am currently working on testing.
Here is my approach
1)
Satyanarayana Narlapuram writes:
>> Why do we need to incur a protocol break to add another one?
> This is optional and is not a protocol break.
Yes, it is. We've been around on this sort of thing before and we
understand the consequences. If the option
Hi,
When doing a PITR style recovery, with recovery target set, we're
currently not doing a fast promotion, in contrast to the handling when
doing a pg_ctl or trigger file based promotion. That can prolong making
the server available for writes.
I can't really see a reason for this?
Greetings,
Andrew Dunstan writes:
> On 06/21/2017 11:30 AM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> Unfortunately this seems precluded by the use of the non-standard
>>> "err.h". It looks like that will trip us up on mingw also.
>> Hm,
On Thu, Jun 15, 2017 at 9:50 AM, Tom Lane wrote:
> Can you give a concrete example where this would have
> helped above and beyond knowing, eg, the source and time of the connection
> attempt?
I can imagine that in really high-volume use cases (such as the OP
apparently has)
> I should think that in such cases, the end client is exactly not what you
> want to be choosing which server it gets redirected to. You'd be wanting to
> base that on >policies defined at the pooler. There are already plenty of
> client-supplied attributes you could use as inputs for such
PgBouncer for example assumes that the database names are unique across the
database clusters it is serving. Our front-end Gateways can serve tens of
thousands of Postgres servers spanning multiple customers, and organizations,
and enforcing the database names being unique is not possible for
On Thu, Jun 15, 2017 at 09:04:44AM +0100, Simon Riggs wrote:
> On 15 June 2017 at 02:59, Noah Misch wrote:
>
> > Formally, the causative commit is the one that removed the superuser() test,
> > namely 25fff40.
> >
> > [Action required within three days. This is a generic
On Thu, Jun 22, 2017 at 2:58 AM, Andres Freund wrote:
> One easy way to fix that would be to just wakeup the checkpointer from
> the startup process once at the end of recovery, but it'd not be
> pretty. I think it'd be better to change the
>
On 2017-06-22 09:03:05 +0800, Craig Ringer wrote:
> On 22 June 2017 at 08:29, Andres Freund wrote:
>
> > I.e. we're doing tiny write send() syscalls (they should be coalesced)
>
> That's likely worth doing, but can probably wait for a separate patch.
I don't think so, we
On 2017-06-21 00:57:32 -0700, jasrajd wrote:
> We are also seeing contention on the walwritelock and repeated writes to the
> same offset if we move the flush outside the lock in the Azure environment.
> pgbench doesn't scale beyond ~8 cores without saturating the IOPs or
> bandwidth. Is there
On Wed, Jun 21, 2017 at 9:15 PM, Yugo Nagata wrote:
> This errors continue until this process is terminated or the server is
> restarted.
>
> When SIGINT is issued, the process exits from the main loop and returns
> to sigsetjmp, and calls dsa_attach() before entering into
On Wed, Jun 21, 2017 at 4:57 PM, jasrajd wrote:
> We are also seeing contention on the walwritelock and repeated writes to the
> same offset if we move the flush outside the lock in the Azure environment.
> pgbench doesn't scale beyond ~8 cores without saturating the IOPs
On Wed, Jun 21, 2017 at 3:32 AM, Peter Eisentraut
wrote:
> On 6/19/17 23:02, Masahiko Sawada wrote:
>> Hi,
>>
>> Attached patch for $subject.
>>
>> s/opreator/operator/
>
> fixed
>
Thank you!
I found another one.
s/retrived/retrieved/
Regards,
--
Masahiko
On 2017/06/21 23:52, Robert Haas wrote:
You're right that there is a comment missing from the function header,
but it's not too hard to figure out what it should be. Just consult
the definition of ModifyTable itself:
/* RT indexes of non-leaf tables in a partition tree */
On Mon, Jun 19, 2017 at 11:04 AM, Andrew Gierth
wrote:
>> "Thomas" == Thomas Munro writes:
>
> Thomas> That accidentally removed a comment that I wanted to keep.
> Thomas> Here is a better version.
>
> I plan to commit this soon;
On Thu, Jun 22, 2017 at 4:47 AM, Robert Haas wrote:
> I think that BitmapHeapScan, at least, is applicable to any table AM
> that has TIDs. It seems to me that in general we can imagine three
> kinds of table AMs:
>
> 1. Table AMs where a tuple can be efficiently located
On 6/19/17 22:41, Masahiko Sawada wrote:
> On Tue, Jun 20, 2017 at 10:47 AM, Peter Eisentraut
> wrote:
>> On 6/16/17 04:16, Masahiko Sawada wrote:
>>> A subscription relation state may have been removed already when we
>>> try to update it.
On 6/20/17 19:10, Peter Eisentraut wrote:
> On 6/19/17 22:54, Masahiko Sawada wrote:
>>> It seems to me we could just take a stronger lock around
>>> RemoveSubscriptionRel(), so that workers can't write in there concurrently.
>>
>> Since we reduced the lock level of updating pg_subscription_rel by
Peter Eisentraut writes:
> On 6/18/17 10:14, Tom Lane wrote:
>> Doesn't cope with backslash-quoted characters. If we're going to bother
>> to do anything here, I think we ought to make it reversible for all
>> possible characters.
> Makes sense. Updated patch
On Thu, 22 Jun 2017 13:12:48 +0900
Michael Paquier wrote:
> On Wed, Jun 21, 2017 at 9:15 PM, Yugo Nagata wrote:
> > This errors continue until this process is terminated or the server is
> > restarted.
> >
> > When SIGINT is issued, the process
On Wed, 21 Jun 2017 15:17:20 -0400
Peter Eisentraut wrote:
> On 6/21/17 13:03, Yugo Nagata wrote:
> > As I report in another thread[1], when the logical replication launcher
> > is terminated by SIGTERM, it never been restarted and we need to restart
> > the
On 6/20/17 22:44, Noah Misch wrote:
>> A patch has been posted, and it's being reviewed. Next update Monday.
>
> This PostgreSQL 10 open item is past due for your status update. Kindly send
> a status update within 24 hours, and include a date for your subsequent status
> update. Refer to the
On Thu, Jun 22, 2017 at 11:52 AM, Andres Freund wrote:
> On 2017-06-22 11:49:47 +0900, Yugo Nagata wrote:
>> I agree that we can kill theses processes by the OS command. However,
>> It seems to me that pg_{cancel,terminate}_backend don't need to be able to
>> kill processes
On 6/14/17 01:34, Amit Langote wrote:
> How about the attached patch that teaches pgrowlocks() to error out unless
> a meaningful result can be returned? With the patch, it will issue a "%s
> is not a table" message if it is not a RELKIND_RELATION, except a
> different message will be issued for
The patch got conflicted. This is a new version just rebased to
the current master. Furtuer amendment will be taken later.
> The attached patch is rebased on the current master, but no
> substantial changes other than disallowing partitioned tables on
> async by assertion.
regards,
--
Kyotaro
On 22 June 2017 at 08:29, Andres Freund wrote:
> I.e. we're doing tiny write send() syscalls (they should be coalesced)
That's likely worth doing, but can probably wait for a separate patch.
The kernel will usually do some packet aggregation unless we use
TCP_NODELAY (which
On 22 June 2017 at 09:07, Andres Freund wrote:
> On 2017-06-22 09:03:05 +0800, Craig Ringer wrote:
>> On 22 June 2017 at 08:29, Andres Freund wrote:
>>
>> > I.e. we're doing tiny write send() syscalls (they should be coalesced)
>>
>> That's likely worth
On Thu, Jun 22, 2017 at 6:46 AM, Michael Paquier
wrote:
> On Wed, Jun 21, 2017 at 4:57 PM, jasrajd wrote:
>> We are also seeing contention on the walwritelock and repeated writes to the
>> same offset if we move the flush outside the lock in the
On 6/18/17 10:14, Tom Lane wrote:
> pg_strtok recognizes "<>" and returns length = 0, so debackslash()
> would produce the right answer AFAICS (admittedly, I haven't tested).
> But I don't really want to do it like that because of the wasted
> palloc space and cycles.
>
>> Maybe
>>
On 2017/06/22 12:26, Peter Eisentraut wrote:
> On 6/14/17 01:34, Amit Langote wrote:
>> How about the attached patch that teaches pgrowlocks() to error out unless
>> a meaningful result can be returned? With the patch, it will issue a "%s
>> is not a table" message if it is not a
On Thu, Jun 22, 2017 at 9:48 AM, Michael Paquier
wrote:
> On Thu, Jun 22, 2017 at 1:29 AM, Kuntal Ghosh
> wrote:
>> On Wed, Jun 21, 2017 at 7:52 PM, Dilip Kumar wrote:
>>> On Wed, Jun 21, 2017 at 7:47 PM, Kuntal Ghosh
On 2017/06/21 21:37, Jeevan Ladhe wrote:
> Hi Amit,
>
> On Thu, Jun 15, 2017 at 12:31 PM, Amit Langote <
> langote_amit...@lab.ntt.co.jp> wrote:
>
>> Oops, I meant to send one more comment.
>>
>> On 2017/06/15 15:48, Amit Langote wrote:
>>> BTW, I noticed the following in 0002
>> +
On 2017/06/22 10:01, Michael Paquier wrote:
> #3 implies that the index AM logic is implemented in the table
> AM. Not saying that it is not useful, but it does not feel natural to
> have the planner request for a sequential scan, just to have the table
> AM secretly do some kind of index/skipping
1 - 100 of 142 matches
Mail list logo