On Fri, Apr 05, 2019 at 07:34:48AM +, Tsunakawa, Takayuki wrote:
> From: Michael Paquier [mailto:mich...@paquier.xyz]
>> The first letter should be upper-case.
>
> Thank you for taking care of this patch, and sorry to cause you
> trouble to fix that...
I have just committed the GUC and libpq
Hi!
> 6 апр. 2019 г., в 6:38, GUO Rui написал(а):
>
> I added more details about GiST use cases (PostGIS and ScalaGiST) in my
> proposal and created one more entry for reviewing other patches in the time
> table.
ScalaGiST is quite distant project. It is not PostgreSQL part, it is MR
subsyst
Andres Freund writes:
> I wonder if one approach to solve this wouldn't be to just make the
> hashtable drastically smaller. Right now we'll often have have lots
> empty entries that are 72 bytes + dynahash overhead. That's plenty of
> memory that needs to be skipped over. I wonder if we instead
Hi,
On 2019-04-05 23:03:11 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > I can't detect any performance improvement with the patch applied to
> > current master, using the test case from Yoshikazu Imai (2019-03-19).
>
> FWIW, I tried this patch against current HEAD (959d00e9d).
> Using t
Hi,
On 2018-12-21 02:40:18 +0300, Alexander Korotkov wrote:
> On Thu, Dec 20, 2018 at 1:41 AM Alexander Korotkov
> wrote:
> > Please, find attached two patches I'm going to commit: for master and
> > for backpatching.
>
> So, pushed.
I noticed that I didn't adapt this in
commit 558a9165e081d19
On 2019-Apr-05, Peter Eisentraut wrote:
> I've reworded the phases a bit. There was a bit of a mixup of waiting
> for snapshots and waiting for lockers. Perhaps not so important from a
> user's perspective, but at least now it's more consistent with the
> source code comments.
No disagreement w
On 2019-Apr-05, Alvaro Herrera wrote:
> Looking at the current proposal, I think I like \dPn+ very much -- it
> shows the aggregated size of all partitioned tables. But I think \dP
> (without the +) is almost completely useless. I'm not really sure about
> having to add the "n" flag, but I suspe
Peter Eisentraut writes:
> I can't detect any performance improvement with the patch applied to
> current master, using the test case from Yoshikazu Imai (2019-03-19).
FWIW, I tried this patch against current HEAD (959d00e9d).
Using the test case described by Amit at
I do measure an undeniable s
On Sat, Apr 6, 2019 at 6:16 AM Alvaro Herrera wrote:
>
> Pushed this.
Thank you!
>
> The mechanism of creating a new slot from the source, then later
> advancing the LSN of the new slot using the updated values from the
> source slot, seems quite clever. I reworded the comment that explained
>
On Sat, Apr 6, 2019 at 10:23 AM Andres Freund wrote:
>
> Hi,
>
> On 2019-04-04 15:05:55 -0400, Robert Haas wrote:
> > On Wed, Apr 3, 2019 at 10:32 PM Masahiko Sawada
> > wrote:
> > > Attached the updated version patch.
> >
> > Committed with a little bit of documentation tweaking.
>
> I've close
Hi,
On 2019-03-21 22:06:36 +0400, David Steele wrote:
> On 2/15/19 11:59 AM, Peter Eisentraut wrote:
> > On 14/02/2019 20:13, Andres Freund wrote:
> > > On 2019-02-04 11:02:44 +0900, Michael Paquier wrote:
> > > > +1. I have just looked at the patch, and my take is that listing all
> > > > the wa
Hi,
On 2019-02-28 11:05:33 +0200, David Steele wrote:
> The 2019-03 CF is almost upon us. The CF will officially start at 00:00 AoE
> (12:00 UTC) on Friday, March 1st.
I'd like to move all the CF entries targeting v13 at this time. We might
get a patch or five more committed in the next two days
Hi,
On 2019-02-28 13:36:32 -0500, Mike Palmiotto wrote:
> On Wed, Feb 27, 2019 at 12:36 PM Peter Eisentraut
> wrote:
> >
> > To rephrase this: You have a partitioned table, and you have a RLS
> > policy that hides certain rows, and you know based on your business
> > logic that under certain cir
I added more details about GiST use cases (PostGIS and ScalaGiST) in my
proposal and created one more entry for reviewing other patches in the time
table.
I'll try to polish the proposal in the remaining three days to the GSoC
deadline. I don't think I have much time to modify PostgreSQL source co
Hi,
On 2019-04-04 15:05:55 -0400, Robert Haas wrote:
> On Wed, Apr 3, 2019 at 10:32 PM Masahiko Sawada wrote:
> > Attached the updated version patch.
>
> Committed with a little bit of documentation tweaking.
I've closed the commitfest entry. I hope that's accurate?
Greetings,
Andres Freund
Hi,
On 2019-04-04 16:01:26 -0300, Alvaro Herrera wrote:
> Also, if you parse once and bind/execute many times, IMO the statement
> should be logged exactly once. I think you could that with the flag I
> propose.
I'm not actually sure I buy this. Consider e.g. log analysis for
workloads with lon
On Sat, 6 Apr 2019 at 12:26, Tom Lane wrote:
> Pushed with some hacking, mostly trying to improve the comments.
Great! Many thanks for improving those and pushing it.
Many thanks to Julien, Antonin for their detailed reviews on this.
Thanks Amit for your input on this as well. Much appreciated.
Thomas Munro writes:
> On Sat, Apr 6, 2019 at 11:19 AM Tom Lane wrote:
>> This sort of thing has pretty much always happened. I believe it is
>> just down to the designed-in unreliability of the current stats collection
>> mechanism. We might be able to get rid of it if we go over to
>> shared-
On Sat, Apr 6, 2019 at 11:19 AM Tom Lane wrote:
> Thomas Munro writes:
> > Just now, and also once 5-and-a-bit days ago, flaviventris failed like
> > this, as did filefish 41 days ago[1] (there may be more, I just
> > checked a random sample of InstallCheck-C failures accessible via the
> > web i
On 2019-Apr-04, Amit Langote wrote:
> > When you
> > have many partitions (and we're now making the system scale into the
> > thousands for a single partitioned table), they clutter the output
> > making it unusable. So, rather than think as \dP as "the way to show
> > the aggregate size of a par
David Rowley writes:
> On Wed, 3 Apr 2019 at 14:01, Amit Langote
> wrote:
>> I don't have any more comments.
> Great. Many thanks for having a look at this. Going by [1], Julien
> also seems pretty happy, so I'm going to change this over to ready for
> committer.
Pushed with some hacking, mos
Hi,
Thanks for the new version of the patch. Btw, could you add Craig as a
co-author in the commit message of the next version of the patch? Don't
want to forget him.
On 2019-04-05 17:08:39 +0530, Amit Khandekar wrote:
> Regarding the test result failures, I could see that when we drop a
> logic
Hi,
On 2019-04-05 18:19:17 -0400, Tom Lane wrote:
> We might be able to get rid of it if we go over to shared-memory
> stats, but I've yet to look at that patch :-(.
I did a few review cycles on it, and while I believe the concept is
sound, I think it needs a good bit more time to mature. Not
rea
Thomas Munro writes:
> Just now, and also once 5-and-a-bit days ago, flaviventris failed like
> this, as did filefish 41 days ago[1] (there may be more, I just
> checked a random sample of InstallCheck-C failures accessible via the
> web interface):
This sort of thing has pretty much always happe
Hi,
Just now, and also once 5-and-a-bit days ago, flaviventris failed like
this, as did filefish 41 days ago[1] (there may be more, I just
checked a random sample of InstallCheck-C failures accessible via the
web interface):
WHERE relname like 'trunc_stats_test%' order by relname;
relnam
Hi,
On 2019-04-01 11:25:46 +0200, Peter Eisentraut wrote:
> On 2019-03-31 05:00, Andres Freund wrote:
> > Also, have you actually benchmarked this code? ISTM that adding a
> > stored generated column would cause quite noticable slowdowns in the
> > COPY path based on this code.
>
> Yes, it'll be
On Fri, Apr 5, 2019 at 10:17 AM Masahiko Sawada wrote:
>
> On Fri, Apr 5, 2019 at 4:06 AM Robert Haas wrote:
> >
> > On Wed, Apr 3, 2019 at 10:32 PM Masahiko Sawada
> > wrote:
> > > Attached the updated version patch.
> >
> > Committed with a little bit of documentation tweaking.
> >
>
> Thank
On 05/04/2019 23:16, Alvaro Herrera wrote:
> Pushed this.
>
Thanks!
> The mechanism of creating a new slot from the source, then later
> advancing the LSN of the new slot using the updated values from the
> source slot, seems quite clever. I reworded the comment that explained
> how it is suppos
On Fri, Apr 5, 2019 at 4:10 PM Masahiko Sawada wrote:
>
> On Fri, Apr 5, 2019 at 3:47 PM Kyotaro HORIGUCHI
> wrote:
> >
> > Thank you for the rebased version.
> >
> > At Fri, 5 Apr 2019 13:59:36 +0900, Masahiko Sawada
> > wrote in
> >
> > > Thank you for the notice. Rebased.
> >
> > +inte
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-04-05 14:48, Stephen Frost wrote:
> > On a failure to set up an encrypted connection, we'll actually fall back
> > to a non-encrypted one using GSSAPI *just* for authentication, which is>
> > why I was asking if thi
Pushed this.
The mechanism of creating a new slot from the source, then later
advancing the LSN of the new slot using the updated values from the
source slot, seems quite clever. I reworded the comment that explained
how it is supposed to work; please double-check to ensure I got it
right.
I ren
On 2019-04-05 17:01, Alvaro Herrera wrote:
> Users are going to wonder why the other phases don't appear to complete
> for a long time :-) Keep in mind that the "waiting" phases are very
> confusing to users. I suggest we just define additional phase numbers
> for those phases, then switch the "f
On 2019-04-05 14:48, Stephen Frost wrote:
> All of it was built against the OS-provided Kerberos install, and you
> got the failure..?
right
> On a failure to set up an encrypted connection, we'll actually fall back
> to a non-encrypted one using GSSAPI *just* for authentication, which is> why
>
Hi,
In this email I want to give a brief status update of the table access
method work - I assume that most of you sensibly haven't followed it
into all nooks and crannies.
I want to thank Haribabu, Alvaro, Alexander, David, Dmitry and all the
others that collaborated on making tableam happen. It
On Fri, Apr 5, 2019 at 11:22 AM Antonin Houska wrote:
> > Wouldn't Tom's proposal to use a stream cipher fix all this?
>
> Yes it would make the extra alignment unnecessary, but our solution tries to
> meet specific requirements of disk encryption. Stream cipher appears to be
> incompatible with t
On Thu, Apr 4, 2019 at 11:55 PM Tom Lane wrote:
> > Indeed.
>
> Well, the problem is the lack of grammatical agreement between "waiting"
> and "release". It's poor English at least.
It's not correct for formal writing, but I think a lot of people would
find it acceptable in casual speech. At an
On Fri, Apr 5, 2019 at 8:41 PM Alvaro Herrera wrote:
>
> Is 0001 a bugfix?
Yep, it is rather a bugfix and can be applied independently.
The fix allocates temporary strings using temporary context
Conf->buildCxt.
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgr
On Thu, Apr 4, 2019 at 5:37 PM Bossart, Nathan wrote:
> Thanks! I noticed a very small typo in the new documentation.
Committed, thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Fri, Apr 5, 2019 at 3:28 PM Adrien Mobile wrote:
> How about TRIM?
The problem, in my view, is not that there is anything ipso facto
wrong with SHRINK. The problem is that it's a turn term that has only
de minimis use up until now. Replacing it with some other term that
has never before been
Le 5 avril 2019 20:11:38 GMT+02:00, Julien Rouhaud a écrit
:
>On Fri, Apr 5, 2019 at 7:04 PM Robert Haas
>wrote:
>>
>
>> My preference is for "truncate" over "shrink".
>
>I don't really like "shrink" either, but users already have problems
>to get the difference between VACUUM and VACUUM FULL, I
On Fri, Apr 5, 2019 at 2:11 PM Julien Rouhaud wrote:
> > My preference is for "truncate" over "shrink".
>
> I don't really like "shrink" either, but users already have problems
> to get the difference between VACUUM and VACUUM FULL, I'm afraid that
> "VACUUM TRUNCATE_TABLE" will just make things w
On Fri, Apr 5, 2019 at 7:04 PM Robert Haas wrote:
>
> On Thu, Apr 4, 2019 at 9:19 PM Masahiko Sawada wrote:
> > As INDEX_CLEANUP option has been added by commit a96c41f, the new
> > option for this feature could also accept zero or one boolean
> > argument, that is SHRINK_TABLE [true|false] and t
Is 0001 a bugfix?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi,
On 2019-04-05 16:26:16 +, Alexis Andrieu wrote:
> I noticed a small typo (word 'the' is repeated twice) in the recent tableam
> doc.
>
> The patch remove the typo in the doc ('/doc/src/sgml/tableam.sgml').
Thanks for noticing and reporting! It was already reported by Justin
Pryzby. I'd
On Thu, Apr 4, 2019 at 9:19 PM Masahiko Sawada wrote:
> As INDEX_CLEANUP option has been added by commit a96c41f, the new
> option for this feature could also accept zero or one boolean
> argument, that is SHRINK_TABLE [true|false] and true by default.
> Explicit options on VACUUM command overwrit
"Daniel Verite" writes:
>> Hm, if that's as much as we have to touch, I think there's a good
>> argument for squeezing it into v12 rather than waiting. The point
>> here is mostly to avoid a behavior change from pre-v12
> Yes. I was mentioning the next CF because ISTM that nowadays
> non-committ
Hi,
On 2019-04-04 00:51:38 -0500, Justin Pryzby wrote:
> I reviewed new docs for $SUBJECT.
> Find attached proposed changes.
> There's one XXX item I'm unsure what it's intended to say.
Thanks! I applied most of these, and filled in the XXX. I didn't like
the s/allow to to specify properties/al
05.04.2019 18:01, Tom Lane writes:
Andrew Dunstan writes:
On Fri, Apr 5, 2019 at 2:02 AM Thomas Munro wrote:
This is a strange failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=loach&dt=2019-04-05%2005%3A15%3A00
[ wrong answers from queries using a GIST index ]
There are a co
Hello,
I noticed a small typo (word 'the' is repeated twice) in the recent tableam doc.
The patch remove the typo in the doc ('/doc/src/sgml/tableam.sgml').
Regard,
Alexis
tableam-fix-doc.patch
Description: tableam-fix-doc.patch
Le 25/03/2019 à 01:31, Amit Langote a écrit :
> On 2019/03/22 17:17, Amit Langote wrote:
>> I'll add this to July fest to avoid forgetting about this.
> I'd forgotten to do this, but done today. :)
>
> Thanks,
> Amit
Hello Amit,
Just a quick information that your last patch does not apply on he
Stephen Frost writes:
> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
>> On 2019-04-05 04:59, Stephen Frost wrote:
>>
>>> Alright, that over-size error was a bug in the error-handling code,
>>> which I've just pushed a fix for. That said...
>>
>> Yes, that looks better now.
>
> G
Tom Lane wrote:
> Antonin Houska writes:
> > Antonin Houska wrote:
> >> Since palloc() only ensures MAXIMUM_ALIGNOF, that wouldn't help here
> >> anyway.
>
> > After some more search I'm not sure about that. The following comment
> > indicates that MAXALIGN helps too:
>
> Well, there is more
Robert Haas wrote:
> On Thu, Mar 21, 2019 at 7:46 AM Antonin Houska wrote:
> > Nevertheless, with the current version of our patch, PG should be resistant
> > against such a partial write anyway because we chose to align XLOG records
> > to
> > 16 bytes (as long as the encryption is enabled) fo
On Fri, Apr 05, 2019 at 03:14:56PM +0300, Surafel Temesgen wrote:
On Tue, Mar 26, 2019 at 5:46 PM Tomas Vondra
wrote:
On Tue, Mar 26, 2019 at 03:06:52PM +0300, Surafel Temesgen wrote:
>On Thu, Feb 28, 2019 at 11:16 PM Tomas Vondra <
tomas.von...@2ndquadrant.com>
>wrote:
>
>>
>> To give you a (
Andrew Dunstan writes:
> On Fri, Apr 5, 2019 at 2:02 AM Thomas Munro wrote:
>> This is a strange failure:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=loach&dt=2019-04-05%2005%3A15%3A00
>> [ wrong answers from queries using a GIST index ]
> There are a couple of other recent instan
On 2019-Apr-05, Peter Eisentraut wrote:
> It seems we can easily extend this to also monitor REINDEX
> [CONCURRENTLY]. Attached is a quick patch.
That's much easier than I was expecting. I think we should endeavor to
get this done for pg12.
> For the concurrently part, we currently don't have
It seems we can easily extend this to also monitor REINDEX
[CONCURRENTLY]. Attached is a quick patch.
For the concurrently part, we currently don't have any phases defined
for the index swap and drop, but maybe we can just skip that initially.
What happens if we don't have those?
It might be nic
On Fri, Apr 5, 2019 at 2:02 AM Thomas Munro wrote:
>
> Hi,
>
> This is a strange failure:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=loach&dt=2019-04-05%2005%3A15%3A00
>
> test _int ... FAILED 649 ms
>
> = pgsql.build/contrib/intarray/r
On Fri, Apr 5, 2019 at 2:58 AM Michael Paquier wrote:
>
> On Wed, Apr 03, 2019 at 03:23:33PM +0900, Michael Paquier wrote:
> > It seems to me that c251336 should have done all those things from the
> > start... In other terms, isn't that a bug and something that we
> > should fix and back-patch?
Tom Lane wrote:
> Hm, if that's as much as we have to touch, I think there's a good
> argument for squeezing it into v12 rather than waiting. The point
> here is mostly to avoid a behavior change from pre-v12
Yes. I was mentioning the next CF because ISTM that nowadays
non-committers are
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-04-05 04:59, Stephen Frost wrote:
> > Alright, that over-size error was a bug in the error-handling code,
> > which I've just pushed a fix for. That said...
>
> Yes, that looks better now.
Great.
> > This looks l
Chapman Flack wrote:
> >> "Daniel Verite" writes:
> >>> One consequence of using the "C" collation in the catalog versus
> >>> the db collation
>
> As an intrigued Person Following At Home, I was happy when I found
> this little three-message thread had more context in [1] and [2]. :)
>
On Tue, Mar 26, 2019 at 5:46 PM Tomas Vondra
wrote:
> On Tue, Mar 26, 2019 at 03:06:52PM +0300, Surafel Temesgen wrote:
> >On Thu, Feb 28, 2019 at 11:16 PM Tomas Vondra <
> tomas.von...@2ndquadrant.com>
> >wrote:
> >
> >>
> >> To give you a (admittedly, somewhat contrived and artificial example):
Thank you for looking at it
On Mon, Apr 1, 2019 at 12:34 AM Andres Freund wrote:
> Hi,
>
> On 2019-03-29 12:04:50 +0300, Surafel Temesgen wrote:
>
> > + if (node->limitOption == PERCENTAGE)
> > + {
> > + w
On Wed, 3 Apr 2019 at 19:57, Amit Khandekar wrote:
> Oops, it was my own change that caused the hang. Sorry for the noise.
> After using wal_debug, found out that after replaying the LOCK records
> for the catalog pg_auth, it was not releasing it because it had
> actually got stuck in ReplicationS
On 2019-03-29 15:55, Alexey Bashtanov wrote:
>> ERROR: value "62812" is out of range for type smallint
>> STATEMENT: SELECT abalance FROM pgbench_accounts WHERE aid = $1;
>>
>> (In this case the error message contains the parameter value, so it's
>> not a very practical case, but it should work,
On Fri, Apr 05, 2019 at 10:39:26AM +0200, Michael Banck wrote:
> Ok, so the problem is that that checkpoint might be still ongoing when
> you quickly issue a pg_rewind from the other side?
The end-of-recovery checkpoint may not have even begun.
> I think it might be useful to specify more exactly
On Fri, Apr 05, 2019 at 10:11:22AM +0200, Magnus Hagander wrote:
> If that is the case, would running a CHECKPOINT actually cause a problem?
If you exclude the point that it may not be necessary and the
potential extra I/O, no. However we would come back to the point of
pg_rewind requiring a supe
On 2019-03-19 10:21, Tsunakawa, Takayuki wrote:
> From: Tsunakawa, Takayuki [mailto:tsunakawa.ta...@jp.fujitsu.com]
>> Fixed.
>
> Rebased on HEAD.
Do you need the dlist_foreach_modify() calls? You are not actually
modifying the list structure.
--
Peter Eisentraut http://www.2ndQua
On Tue, Mar 26, 2019 at 5:46 PM Tomas Vondra
wrote:
> On Tue, Mar 26, 2019 at 03:06:52PM +0300, Surafel Temesgen wrote:
>
> As for the OFFSET, I don't see why that would be incompatible with PERCENT
> clause. I'm not sure if it should compute the percentage from the total
> number of rows (includ
On Fri, 5 Apr 2019 at 23:07, Amit Langote wrote:
>
> Hi,
>
> On 2019/04/05 18:13, Floris Van Nee wrote:
> > One unrelated thing I noticed (but I'm not sure if it's worth a separate
> > email thread) is that the changed default of jit=on in v12 doesn't work
> > very well with a large number of pa
On Fri, 5 Apr 2019 at 17:31, Pavan Deolasee wrote:
> IMV it makes sense to simply cap the lower limit of toast_tuple_target to the
> compile time default and update docs to reflect that. Otherwise, we need to
> deal with the possibility of dynamically creating the toast table if the
> relation
Hi!
> 5 апр. 2019 г., в 14:07, GUO Rui написал(а):
>
> I drafted my proposal about the above topic at
> https://docs.google.com/document/d/1X7Lw-c0rLYuSjwLNfw6qXpN5Cf1_0u2gXtgEgLkNezA/edit?usp=sharing
> . Looking forward to your feedback.
I'd recommend planning some time to review other patch
Hi,
On 2019/04/05 18:13, Floris Van Nee wrote:
> One unrelated thing I noticed (but I'm not sure if it's worth a separate
> email thread) is that the changed default of jit=on in v12 doesn't work very
> well with a large number of partitions at run-time, for which a large number
> get excluded
Hosoya-san,
On 2019/04/04 13:00, Yuzuko Hosoya wrote:
> I added some test cases to each patch according to tests
> discussed in this thread.
Thanks a lot.
> However, I found another problem as follows. This query should
> output "One-Time Filter: false" because rlp3's constraints
> contradic
Thanks for the details! Indeed the versions with now()/current_date use the
runtime pruning rather than planning time. I wasn't aware of the use of 'today'
though - that could be useful in case we're sure statements won't be prepared.
Previously (v10/ partly v11) it was necessary to make sure th
I drafted my proposal about the above topic at
https://docs.google.com/document/d/1X7Lw-c0rLYuSjwLNfw6qXpN5Cf1_0u2gXtgEgLkNezA/edit?usp=sharing
. Looking forward to your feedback.
On Wed, Apr 3, 2019 at 10:55 PM GUO Rui wrote:
> Dear Andrey Borodin,
>
> I discussed the above topic with the profe
On Thu, Mar 14, 2019 at 11:05 AM Thomas Munro wrote:
> I renamed the CVs because the names I had used before broke the
> convention that variables named ckpt_* are protected by ckpt_lck, and
> pushed.
Erm... this made successful checkpoints slightly faster but failed
checkpoints infinitely slower
Hi,
On Fri, Apr 05, 2019 at 04:56:32PM +0900, Michael Paquier wrote:
> On Fri, Apr 05, 2019 at 09:41:58AM +0200, Michael Banck wrote:
> > Is there a good reason why Postgres doesn't just issue a CHECKPOINT
> > after promote itself? After all, this seems to be about making the
> > control file havi
At Fri, 05 Apr 2019 09:44:07 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190405.094407.151644324.horiguchi.kyot...@lab.ntt.co.jp>
> By the way, I found the reason of the wrong result of the
> previous benchmark. The test 3_0/1 needs to update catcacheclock
> midst of the loop. I'm
On Fri, Apr 5, 2019 at 10:06 AM Michael Paquier wrote:
> On Fri, Apr 05, 2019 at 09:59:29AM +0200, Magnus Hagander wrote:
> > A related question is, could we (for 12+) actually make the problem go
> > away? As in, can we detect the state and just have pg_rewind issue the
> > checkpoint as needed?
On Fri, Apr 05, 2019 at 09:59:29AM +0200, Magnus Hagander wrote:
> A related question is, could we (for 12+) actually make the problem go
> away? As in, can we detect the state and just have pg_rewind issue the
> checkpoint as needed?
I am not sure as you can still bump into the legit case where o
On Fri, Apr 5, 2019 at 9:56 AM Michael Paquier wrote:
> On Fri, Apr 05, 2019 at 09:41:58AM +0200, Michael Banck wrote:
> > Is there a good reason why Postgres doesn't just issue a CHECKPOINT
> > after promote itself? After all, this seems to be about making the
> > control file having the proper
On Fri, Apr 05, 2019 at 09:41:58AM +0200, Michael Banck wrote:
> Is there a good reason why Postgres doesn't just issue a CHECKPOINT
> after promote itself? After all, this seems to be about making the
> control file having the proper content, which sounds like a good thing
> to have in general.
T
On 2019-04-05 04:59, Stephen Frost wrote:
> Alright, that over-size error was a bug in the error-handling code,
> which I've just pushed a fix for. That said...
Yes, that looks better now.
> This looks like it's a real issue and it's unclear what's going on here.
> I wonder- are you certain that
Hi,
On Thu, Apr 04, 2019 at 01:11:29PM +0900, Michael Paquier wrote:
> At the same time, let's also document that we need to use a checkpoint
> on the promoted standby so as the control file gets a refresh and
> pg_rewind is able to work properly. I promised that some time ago and
> got reminded
From: Michael Paquier [mailto:mich...@paquier.xyz]
> The first letter should be upper-case.
Thank you for taking care of this patch, and sorry to cause you trouble to fix
that...
> to me that socket_timeout_v14.patch should be rejected as it could cause
> a connection to go down with no actual
On Fri, Apr 5, 2019 at 3:47 PM Kyotaro HORIGUCHI
wrote:
>
> Thank you for the rebased version.
>
> At Fri, 5 Apr 2019 13:59:36 +0900, Masahiko Sawada
> wrote in
> > Thank you for the notice. Rebased.
>
> +integer
> +
> +
> + Specifies parallel degree for PARALLEL option. The
>
On Fri, Apr 05, 2019 at 04:39:36AM +, Jamison, Kirk wrote:
> I just checked and confirmed that the TCP USER TIMEOUT patch set v20
> works. Although you should capitalize "linux" to "Linux" as already
> mentioned before. The committer can also just fix that very minor
> part, if patch is deeme
89 matches
Mail list logo
