Attached a patch for $SUBJECT.
- * If RecPtr is not NULL, try to read a record at that position. Otherwise
+ * If RecPtr is valid, try to read a record at that position. Otherwise
Commit 4d6d425ab8d addressed the comment above XLogReadRecord() in
xlogreader.c, but missed the same above ReadReco
On Thu, Jun 22, 2017 at 2:44 PM, Kuntal Ghosh
wrote:
> On Thu, Jun 22, 2017 at 9:48 AM, Michael Paquier
> wrote:
>> On Thu, Jun 22, 2017 at 1:29 AM, Kuntal Ghosh
>> wrote:
>>> But, I've some more doubts.
>>> 1. When should we use dsm_find_mapping()? (The first few lines of
>>> dsm_attach is same
Hello,
At Wed, 21 Jun 2017 22:43:32 -0400, Peter Eisentraut
wrote in
<501f75c9-c5d6-d023-add0-3b670ac86...@2ndquadrant.com>
> 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
> >>> RemoveSubscri
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
> do_restartpoint = RecoveryInP
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 notification.]
> >
> > T
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
>>> wrote:
> IMHO, It's not a good idea to use DSM call to verify the DSA
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; if anyone has any comment to make, now would
> be a good time
On Mon, Jun 19, 2017 at 11:06 AM, Andrew Gierth
wrote:
>> "Thomas" == Thomas Munro writes:
>
> Thomas> Thanks both for the review. New version of patch #2 attached.
>
> I'm looking to commit this soon; if anyone has any further comment now
> would be a good time to speak up.
Here's patch #
On Mon, Jun 12, 2017 at 2:03 PM, Thomas Munro
wrote:
> Thanks for the review. New version of patch #1 attached.
Here's a version rebased on top of the recently reindented master branch.
--
Thomas Munro
http://www.enterprisedb.com
transition-tuples-from-child-tables-v12.patch
Description: Bin
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 H
On Thu, Jun 22, 2017 at 1:52 PM, Yugo Nagata wrote:
> On Thu, 22 Jun 2017 12:05:19 +0900
> Michael Paquier wrote:
>> signal-able). Different thought, but I'd love to see a SQL function
>> that allows triggering SIGHUP on a specific process, like an
>> autovacuum worker to change its cost paramete
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 server to enable logical replication
On Thu, Jun 22, 2017 at 3:04 AM, Andres Freund wrote:
> 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 wr
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 exits from the main loop and returns
> > to sigset
On Thu, 22 Jun 2017 12:05:19 +0900
Michael Paquier wrote:
> 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}_backen
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
>> wrote:
IMHO, It's not a good idea to use DSM call to verify the DSA handle.
>>> Okay. Is there any particular scenario you've i
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 the loop again,
> this
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 RELKIND_RELATION,
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 attached.
That looks sane to me, t
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 p
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 except for client backe
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
>> local_node->fld
On Thu, Jun 22, 2017 at 11:12 AM, Amit Langote
wrote:
> 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
On 2017/06/22 11:25, Etsuro Fujita wrote:
> 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 inde
On 2017-06-22 11:49:47 +0900, Yugo Nagata wrote:
> On Wed, 21 Jun 2017 11:04:34 -0400
> Robert Haas wrote:
>
> > On Wed, Jun 21, 2017 at 7:56 AM, Yugo Nagata wrote:
> > > I have found that we can cancel/terminate autovacuum launchers and
> > > background worker processes by pg_cancel/terminate_b
On Wed, 21 Jun 2017 11:04:34 -0400
Robert Haas wrote:
> On Wed, Jun 21, 2017 at 7:56 AM, Yugo Nagata wrote:
> > 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 expec
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 p
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. SetSubscriptionRelState didn't emit an error in such
>>>
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
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 */
Lis
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 Sawada
NIPPON TELEGRAPH AND TELEPHONE
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
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 Azure environment.
>> pgbench doesn't scale beyond
On Thu, Dec 22, 2016 at 11:29 PM, Tomas Vondra
wrote:
>
> How do these counts compare to the other wait events? For example
> CLogControlLock, which is what Amit's patch [1] is about?
>
> [1]
> https://www.postgresql.org/message-id/flat/84c22fbb-b9c4-a02f-384b-b4feb2c67193%402ndquadrant.com
>
Hell
On Wed, Jun 21, 2017 at 9:46 PM, Konstantin Knizhnik
wrote:
> Thank you for this idea. I agree that it is the best way of implementing
> ASOF join - just as optimization of standard SQL query.
Great. I think this part definitely has potential.
> But do you think that still it will be good idea
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 more
On 2017-06-21 18:07:21 -0700, 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 doing, but can probably wait for
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 doing, but can probably wait for a separate
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 or
> bandwidth. Is there
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 should get this right,
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 we don't and shouldn'
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 by a real TID.
> By a re
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 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 not understand how to limit
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 rule "_RETURN" as on select to r
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 updated
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 warning is
> the
> a
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 confined to seeing the same snapshot as th
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);
> + /* The
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 anything inserted by that
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 any time.
+
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 updated version of the p
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 \beginbatc
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
this
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.
Today, lorikeet failed with a new variant on the bgworker start crash:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet&dt=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.
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 will be for us.
> Hm.
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 se
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 imp
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 o
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 some more tweaks
we
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: REL9_2_STABLE Release: REL9_2_
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 act
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 coding that part,
> rootR
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 is carried in the startup
message, the c
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
> partition-key-update. Are you thinking t
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 table containing 2 and 3)
>>> in both 'read committed' and 'read uncomm
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 (pgsql-hackers@pos
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 types may not be applicable
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 like
generalizing away
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 a
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 th
> 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 po
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 wi
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) the number of client
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 where the connection
> failed.
Wire p
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) PredicateLo
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 subscription
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 like that will trip us up on mingw also.
>>> Hm, why? Doesn't the
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, why? Doesn't the -I search path get the right thing?
> The file
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?
>
>
The file is
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 c
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,
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 dete
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. You've
>>> modified the comment in your patch, but the as
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 those
>>> partitions don't appear in the plan ot
Hi,
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 with exitstatus 0,
so if it exits with statu
On 20/06/2017 17:37, Tom Lane wrote:
I wrote:
Marco Atzeri writes:
Building on Cygwin latest 10 beta1 or head sourece,
make check fails as:
...
performing post-bootstrap initialization ... 2017-05-31 23:23:22.214
CEST [16860] FATAL: collation "ja_JP" for encoding "EUC_JP" already exists
H
On Wed, 21 Jun 2017 16:18:50 +0200
Simon Riggs wrote:
> On 21 June 2017 at 16:15, Yugo Nagata wrote:
> > On Wed, 21 Jun 2017 19:08:35 +0530
> > Kuntal Ghosh wrote:
> >
> >> On Wed, Jun 21, 2017 at 6:05 PM, Yugo Nagata wrote:
> >> >
> >> > Attached is a patch for the documentation fix.
> >> >
>
On Wed, Jun 21, 2017 at 07:49:21PM +0530, Amit Kapila wrote:
> On Tue, Jun 20, 2017 at 7:24 PM, Amit Kapila wrote:
> > Hmm. I think we need something that works with lesser effort because
> > not all users will be as knowledgeable as you are, so if they make any
> > mistakes in copying the file m
On Wed, Jun 21, 2017 at 7:52 PM, Dilip Kumar wrote:
> On Wed, Jun 21, 2017 at 7:47 PM, Kuntal Ghosh
> wrote:
>>> IMHO, It's not a good idea to use DSM call to verify the DSA handle.
>>>
>> Okay. Is there any particular scenario you've in mind where this may fail?
>
> It's not about failure, but a
On Wed, Jun 21, 2017 at 11:11:57AM -0400, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Oh, here is a fixed version that requires an @ sign, which all message
> > id's have:
> >
> > sed '/http/!s;^\(Discussion: *\)\(.*@.*\)$;\1https://postgr.es/m/\2;'
>
> So how do you actually use this
Andres Freund writes:
> On 2017-06-20 20:30:34 -0400, Tom Lane wrote:
>> Well, *I* don't care, but I thought we wanted to support Windows-using
>> developers as reasonably first-class citizens.
> The old one didn't have windows support either, right?
Not that I was aware of, but a large part of
On 2017-06-20 20:30:34 -0400, 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, no?
>
> > Are there that many anyway who
Robert Haas writes:
> It appears to me that create_modifytable_path() has a partitioned_rels
> argument and it looks like inheritance_planner not only passes it but
> guarantees that it's non-empty when the target is a partitioned table.
Oh, somehow I missed the call in inheritance_planner. Righ
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?
regards, tom lane
--
Sent via pgsql-hackers mailing list (p
On Wed, Jun 21, 2017 at 8:08 PM, Robert Haas wrote:
> I think somebody should do some testing of the existing code with
> valgrind. And then apply the list-partitioning patch and this patch,
> and do some more testing with valgrind. It seems to be really easy to
> miss these uninitialized access
Bruce Momjian wrote:
> Oh, here is a fixed version that requires an @ sign, which all message
> id's have:
>
> sed '/http/!s;^\(Discussion: *\)\(.*@.*\)$;\1https://postgr.es/m/\2;'
So how do you actually use this?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL D
Yugo Nagata wrote:
> However, we can terminate background workers by pg_terminate_backend.
> In the following example, I terminated the logical replication launcher,
> and this process did not appear again[1].
>
> postgres=# select pg_terminate_backend(30902);
> pg_terminate_backend
>
On Wed, Jun 21, 2017 at 7:56 AM, Yugo Nagata wrote:
> 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.
I think it is expected. Even
1 - 100 of 144 matches
Mail list logo
