>On Mon, Nov 26, 2018 at 02:48:39PM +0900, myungkyu.lim wrote:
>> So I selected 'reply_time' because 'timestamp' was not used in stat
>> field.
>
>Fine by me. Could you send a new patch please? I am switching the patch
as
>waiting on author for now.
Ok.
Changed field name 'last_msg_send_time' to
A customer was complaining that the "checkpoint starting: xlog"
message was not included in the grand PG10 rename of user-visible
bits. The attached patch fixes that.
Christoph
--
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompete
On Thu, Nov 29, 2018 at 09:47:09AM +0100, Christoph Berg wrote:
> A customer was complaining that the "checkpoint starting: xlog"
> message was not included in the grand PG10 rename of user-visible
> bits. The attached patch fixes that.
At the same time it would make sense to rename CHECKPOINT_CAU
On Thu, Nov 29, 2018 at 04:35:06PM +0900, Amit Langote wrote:
> On 2018/11/29 16:27, Michael Paquier wrote:
>> Any thoughts or objections?
>
> It's an oversight. Thanks for fixing it.
Okay, done as long as I don't forget..
--
Michael
signature.asc
Description: PGP signature
Re: Michael Paquier 2018-11-29 <20181129085902.gd9...@paquier.xyz>
> On Thu, Nov 29, 2018 at 09:47:09AM +0100, Christoph Berg wrote:
> > A customer was complaining that the "checkpoint starting: xlog"
> > message was not included in the grand PG10 rename of user-visible
> > bits. The attached patch
On Thu, Nov 29, 2018 at 10:04:12AM +0100, Christoph Berg wrote:
> There's hundreds of other internal uses of xlog that were not touched
> either, only the user-facing parts were changed.
I have heard of them ;)
Just wondering if this one is worth renaming as the variable is
isolated. It is not a
Alvaro Herrera-9 wrote
> On 2018-Nov-28, Tom Lane wrote:
>
>> This would also entail rather significant overhead to find out schema
>> names and interpolate them into the text.
>
> True. I was thinking that the qualified-names version of the query
> would be obtained via ruleutils or some simila
Hi Peter,
Thank you for your reply!
> On 27/11/2018 08:42, Iwata, Aya wrote:
> > I created a new version patch. Please find attached my patch.
>
> This does not excite me. It seems mostly redundant with using tcpdump.
I will develop "log level". I'm planning not to output redundant message at t
> Is the point 3 change related to pgindent? I think even if you want
> these, then don't prepare other patches on top of this, keep it
> entirely separate.
Both removed.
>> Also, we don't quite have a consensus on the threshold value, but I
>> have set it to 4 pages for v8. If this is still con
Re: Tomas Vondra 2018-11-28
<1b4e4c5e-7007-cd61-aae5-4a1c248e3...@2ndquadrant.com>
> Wouldn't it be sufficient / better to just store the search_path used
> when executing the query? That should be enough to resolve the object
> names correctly, and the overhead would be much lower (both in terms
On Thu, 29 Nov 2018 at 20:40, Kato, Sho wrote:
> Sorry for my lack of explanation. I didn't get a generic plan with
> plan_cache_mode = auto.
> What I am worried about is that if users don't know the flow of PREPARE
> EXECUTE, query execution seems to be suddenly slow and they will be in
> trou
I was also looking at this patch, here are some things I noticed:
In remove_useless_results_recurse where it processes JOIN_SEMI there is
this comment:
* However, we can't simplify if there are PHVs to
evaluate at
* the RTE_RESULT ... but that's impossible i
> On Sun, Aug 12, 2018 at 8:48 AM Noah Misch wrote:
>
> On Wed, Sep 11, 2013 at 10:28:00PM -0400, Noah Misch wrote:
> > On Wed, Sep 11, 2013 at 11:32:01AM -0400, Stephen Frost wrote:
> > > * Noah Misch (n...@leadboat.com) wrote:
> > > > Concretely, that means
> > > > not removing postmaster.pid on
> On Thu, Aug 23, 2018 at 4:16 PM Surafel Temesgen
> wrote:
>
> The attached patch add error handling for
> Extra data
>
> missing data
>
> invalid oid
>
> null oid and
>
> row count mismatch
Hi,
Unfortunately, the patch conflict-handling-onCopy-from-v2.patch has some
conflicts now, could you r
On 2018-Nov-28, Tomas Vondra wrote:
> > v10-0004-Shared-memory-based-stats-collector.patch
> > updated not to touch guc.
> > v10-0005-Remove-the-GUC-stats_temp_directory.patch
> > collected all guc-related changes.
> > updated not to break other programs.
> > v10-0006-Split-out-backend-statu
> On Fri, Aug 24, 2018 at 7:06 AM Tatsuro Yamada
> wrote:
>
> On 2017/11/22 6:07, Peter Geoghegan wrote:
> > On Mon, Oct 2, 2017 at 6:04 AM, Robert Haas wrote:
> >> Progress reporting on sorts seems like a tricky problem to me, as I
> >> said before. In most cases, a sort is going to involve an
> On Fri, Aug 31, 2018 at 1:28 PM Peter Eisentraut
> wrote:
>
> On 20/08/2018 05:13, Michael Paquier wrote:
> > Patch v6 of this thread is failing to apply. Could you rebase?
>
> attached
>
> Changes in v7 since v6:
>
> - Added support for ssl_passphrase_command.
>
> - Test suite needed some adj
> On Sun, Sep 2, 2018 at 12:50 AM Noah Misch wrote:
>
> On Fri, Jan 26, 2018 at 04:54:08PM +0300, a.parfe...@postgrespro.ru wrote:
> > As it mentioned in pg_locale.c, the variable LC_MESSAGES is ignored in
> > Windows(pg_locale.c:162).
>
> That comment says "On Windows, setlocale(LC_MESSAGES) does
Lætitia Avrot wrote:
> I suppose you mean in the standard output when the screen is too short to
> print the whole line ?
> Because if the output is redirected to a file (with `\o myfile` for
> example), the line end naturally when the row ends.
No I meant independently of the screen, if
> On Fri, Aug 24, 2018 at 5:53 PM Alexander Korotkov
> wrote:
>
> Given I've no feedback on this idea yet, I'll try to implement a PoC
> patch for that. It doesn't look to be difficult. And we'll see how
> does it work.
Unfortunately, current version of the patch doesn't pass the tests and fai
On Thu, Nov 29, 2018 at 3:07 PM John Naylor wrote:
> > Few more comments:
> > ---
> > 1. I think we can add some test(s) to test the new functionality, may
> > be something on the lines of what Robert has originally provided as an
> > example of this behavior [1].
>
> D
Hi,
Unfortunately, current version of this patch has some conflicts, could you
rebase it?
On Mon, Nov 26, 2018 at 2:13 PM Amit Kapila wrote:
>
> On Tue, Nov 20, 2018 at 7:37 PM Dilip Kumar wrote:
> > Along with that I have merged latest changes in zheap branch committed
> > by Rafia Sabih for cleaning up the undo buffer information in abort
> > path.
> >
>
> Thanks, few more comments:
> On Wed, Aug 29, 2018 at 10:38 AM Aleksandr Parfenov
> wrote:
>
> On Tue, 28 Aug 2018 12:40:32 +0700
> Aleksandr Parfenov wrote:
>
> >On Fri, 24 Aug 2018 18:50:38 +0300
> >Alexander Korotkov wrote:
> >>Agreed, backward compatibility is important here. Probably we should
> >>leave old dictiona
On 29/11/2018 00:04, David Rowley wrote:
> On Thu, 29 Nov 2018 at 08:17, Steve Crawford
> wrote:
>> Both for my edification and as a potentially important documentation detail,
>> do operations that rebuild the table such as CLUSTER or pg_repack reclaim
>> the column space?
>
> I've never used
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Certainly, if we make a change that we know is likely to require people to
> reindex affected indexes, that should be documented in the release notes.
> But I think it's pointless to imagine that we can achieve perfection in
> identifying trouble
> On Tue, Jul 24, 2018 at 7:25 AM Thomas Munro
> wrote:
>
> Here's a new version. I did some cosmetic clean-up, and I dropped the
> changes to pg_controldata output, replication epoch/xid processing
> code and various similar non-essential changes. For this patch I want
> just the new type + ne
=# select name, short_desc, extra_desc, category from pg_settings where
category like 'Reporting%When%' ;
─[ RECORD 1
]
name │ log_min_duration_statement
short_desc │ Sets the minimum execut
> On Fri, Sep 21, 2018 at 5:52 AM Andrey Lepikhov
> wrote:
>
> The v6 version of quick vacuum, which utilizes the amtargetdelete()
> interface for retail indextuple deletion.
> Now it is more simple and laconic.
> It must be applied after Retail-IndexTuple-Deletion-Access-Method.patch.
>
> BENCHM
On 29/11/2018 13:28, Dmitry Dolgov wrote:
> Unfortunately it needs to be rebased one more time, could you do this? Also
> I'm
> wondering about this:
>
>> I'm moving this patch forward to CF 2018-09, since it's not going to be
>> ready for -07, and we're still whacking around some channel binding
Greetings,
* Christoph Berg (christoph.b...@credativ.de) wrote:
> A customer was complaining that the "checkpoint starting: xlog"
> message was not included in the grand PG10 rename of user-visible
> bits. The attached patch fixes that.
+1
Thanks!
Stephen
signature.asc
Description: PGP signat
On 28/11/2018 22:41, Tom Lane wrote:
> Peter Eisentraut writes:
>> My suggestion is to either
>> - Change the probe order to python, python3 in master, or
>> - Don't change anything until PEP 394 is updated.
>
> It's hard to evaluate the latter unless we have some idea how soon
> that update is l
> On Fri, Sep 21, 2018 at 1:30 PM Pavel Stehule wrote:
>
> Thank you for comments
>
> Attached updated patch
Unfortunately, current version of the patch doesn't pass make check, something
is missing for xml tests. Could you please rebase it?
After that I hope someone from reviewers (Kyotaro?) ca
On 29/11/2018 01:27, Lou Picciano wrote:
> Further, I’m not sure exposing details about Cert Issuer, etc. to
> non-privileged users is much of an issue. For the most part, in most use
> cases, ‘users’ should//would/ want to know what entity is the issuer. If
> we’re talking about client certs, most
Dear Mentor,
I want to be a part of the organisation by mentoring the students at Google
Code-In and share my knowledge with other students and help them gain knowledge
please allow me to be a mentor at our organisation
Thanking you
Yours faithfully
Rishabh jain
Attached Resume
Resume 11-201
> On Fri, Sep 21, 2018 at 2:29 PM Thomas Munro
> wrote:
>
> Hi Kevin, all,
>
> /me pokes ancient thread
This amazing feeling of being like Indiana Jones, thinking whether it's worth
it to touch another ancient artifact.
On Tue, Sep 25, 2018 at 4:51 PM Kevin Grittner wrote:
>
> On Fri, Sep 21,
Hi Tomas,
> Any progress on the issues discussed in the last couple of messages?
> That is:
>
> 1) removing of the sleep() from tests
>
Done. Now the test_decoding plugin takes a new option "check-xid". We
will pass the XID which is going to be aborted via this option. The
test_decoding plugin wi
On 11/27/18, 3:53 PM, "Michael Paquier" wrote:
> On Tue, Nov 27, 2018 at 09:49:29PM +, Bossart, Nathan wrote:
>> That sounds good to me. I was actually thinking of using the same
>> retry counter that we use for pgarch_archiveXlog(), but on second
>> thought, it is probably better to have two
> On Wed, Jul 25, 2018 at 1:35 PM Arseny Sher wrote:
>
> Hello,
>
> I have looked through the patches and found them pretty accurate. I'd
> fixed a lot of small issues here and there; updated patchset is
> attached.
Hi,
Thank you for working on this patch. Unfortunately, the patch has some
confl
> On Wed, Sep 26, 2018 at 5:41 PM Nikita Glukhov
> wrote:
>
> Attached 3rd version of the patches rebased onto the current master.
>
> Changes from the previous version:
> - Added support of INCLUDE columns to get_index_column_opclass() (1st patch).
> - Added parallel kNN scan support.
> - amcano
Peter Eisentraut writes:
> On 28/11/2018 22:41, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> My suggestion is to either
>>> - Change the probe order to python, python3 in master, or
>>> - Don't change anything until PEP 394 is updated.
>> It's hard to evaluate the latter unless we have some i
> On Fri, Sep 28, 2018 at 10:46 AM Yamaji, Ryo
> wrote:
>
> On Tuesday, August 7, 2018 at 0:36 AM, Konstantin Knizhnik wrote:
>
> > I have registered the patch for next commitfest.
> > For some reasons it doesn't find the latest autoprepare-10.patch and still
> > refer to autoprepare-6.patch as t
> On Tue, Sep 25, 2018 at 1:04 AM Joe Wildish
> wrote:
>
> All agreed. I’ll give the patch some TLC and get a new version that
> addresses the above.
Hi,
Just a reminder, that the patch still needs to be rebased, could you please do
this? I'm moving the item to the next CF.
> On Mon, Oct 1, 2018 at 8:30 AM Michael Paquier wrote:
>
> On Tue, Apr 17, 2018 at 05:58:44PM +0200, Vik Fearing wrote:
> > I think I handle that well enough with permission checking, but I'm open
> > to more debate on it.
>
> The recent version bump in pg_stat_statements (Sorry my fault!) is
> c
> On Mon, Oct 1, 2018 at 8:34 AM Michael Paquier wrote:
>
> On Fri, Mar 23, 2018 at 02:18:09PM +0100, Daniel Verite wrote:
> > There's a batch mode for pgbench in a patch posted in [1],
> > with \beginbatch and \endbatch commands, but nothing
> > for psql AFAICS.
> > psql is more complicated becau
> On Mon, Oct 1, 2018 at 8:54 AM Michael Paquier wrote:
>
> On Wed, Jun 06, 2018 at 07:03:47PM +0530, Amit Kapila wrote:
> > I think Robert's chash stuff [1] might be helpful to reduce the contention
> > you are seeing.
>
> Latest patch available does not apply, so I moved it to next CF. The
> th
> On Mon, Oct 1, 2018 at 9:10 AM Michael Paquier wrote:
>
> By the way, I can see that the latest patch available does not apply at
> tries to juggle with multiple concepts. I can see at least two of them:
> failover_timeout and hostorder. You should split things. I have moved
> the patch to ne
> On Mon, Oct 1, 2018 at 2:24 PM Liudmila Mantrova
> wrote:
>
> We'll continue working with Nikita and Oleg to improve the
> content before we resend an updated patch; I believe we might still need
> a separate source file if we end up having a separate chapter with usage
> examples and implement
> On Tue, Oct 2, 2018 at 3:58 AM Michael Paquier wrote:
>
> On Sun, Jul 22, 2018 at 10:22:10PM +0200, Tomas Vondra wrote:
> > Could you perhaps summarize the reasoning or at least point me to the
> > relevant parts of the sources, so that I know which parts to focus on?
>
> Teodor, this patch is w
> On Tue, Oct 2, 2018 at 4:16 AM Michael Paquier wrote:
>
> On Sat, Jun 30, 2018 at 09:19:13AM +1200, Gavin Flower wrote:
> > Additionally put an upper limit threshold on the number of combinations to
> > check, fairly large by default?
> >
> > If first threshold is exceeded, could consider checki
> On Tue, Oct 2, 2018 at 4:22 AM Michael Paquier wrote:
>
> On Thu, May 24, 2018 at 04:00:33PM +0300, Marina Polyakova wrote:
> > Here there's a 9-th version of the patches for the precalculation of stable
> > or immutable functions, stable or immutable operators and other nonvolatile
> > expressi
On 11/29/18 2:27 PM, Alvaro Herrera wrote:
=# select name, short_desc, extra_desc, category from pg_settings where
category like 'Reporting%When%' ;
─[ RECORD 1
]
name │ log_min_duration_s
The discussion around bug #15525 prompted me to go back and review
our previous go-round with parallelism issues in the ECPG build,
https://www.postgresql.org/message-id/flat/26240C1F-5AA0-41D6-B1F1-D336BFD14CEA%40logicalchaos.org
At that time we'd identified several maybe-issues with parallel
ECP
> On Tue, Oct 2, 2018 at 4:42 AM Michael Paquier wrote:
>
> On Thu, Jun 28, 2018 at 04:20:53PM +0900, Masahiko Sawada wrote:
> > If there is an up-to-date information meaning either that there is no
> > tables needing vacuum or that there is only table needing vacuum but
> > being vacuumed by othe
On 2018-Nov-29, Adrien NAYRAT wrote:
> > =# select name, short_desc, extra_desc, category from pg_settings where
> > category like 'Reporting%When%' ;
> > ─[ RECORD 1
> > ]
> > name │ log_mi
> On Tue, Oct 2, 2018 at 4:53 AM Michael Paquier wrote:
>
> On Mon, Aug 06, 2018 at 06:00:54PM +0900, Yoshimi Ichiyanagi wrote:
> > The libpmem's pmem_map_file() supported 2M/1G(the size of huge page)
> > alignment, since it could reduce the number of page faults.
> > In addition, libpmem's pmem_m
On 2018-Nov-28, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2018-Nov-28, Tom Lane wrote:
> >> This would also entail rather significant overhead to find out schema
> >> names and interpolate them into the text.
>
> > True. I was thinking that the qualified-names version of the query
> > wou
> On Mon, Oct 1, 2018 at 2:55 PM Etsuro Fujita
> wrote:
>
> (2018/10/01 19:42), Michael Paquier wrote:
> > On Mon, Jul 23, 2018 at 02:17:38PM +0530, Ashutosh Bapat wrote:
> > Fujita-san, you are registered as a reviewer of this patch. Are you
> > planning to look at it soon?
>
> Yeah, I'm planni
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2018-Nov-28, Tom Lane wrote:
> > Alvaro Herrera writes:
> > > On 2018-Nov-28, Tom Lane wrote:
> > >> This would also entail rather significant overhead to find out schema
> > >> names and interpolate them into the text.
> >
> > >
> On Tue, Oct 2, 2018 at 7:43 AM Michael Paquier wrote:
>
> On Thu, Jul 12, 2018 at 03:07:33PM -0400, Robbie Harwood wrote:
> > This patch looks good to me. +1; Álvaro, please update the CF entry
> > when you're also satisfied.
>
> The patch set does not apply anymore, so I have moved it to next
> On Tue, Oct 2, 2018 at 11:12 PM Robbie Harwood wrote:
>
> Michael Paquier writes:
>
> > On Mon, Aug 06, 2018 at 05:23:28PM -0400, Robbie Harwood wrote:
> >> If you're in a position where you're using Kerberos (or most other
> >> things from the GSSAPI) for authentication, the encryption comes a
Oh, one more thing: I see a warning without --enable-cassert in
create_resultscan_plan, because rte is only used in an Assert.
src/backend/optimizer/plan/createplan.c:3457:17: warning: variable ‘rte’
set but not used [-Wunused-but-set-variable]
RangeTblEntry *rte;
--
Alexander Kuzmenkov
Pos
> On Wed, Oct 3, 2018 at 12:51 AM Thomas Munro
> wrote:
>
> On Sat, Sep 29, 2018 at 1:07 AM Michael Banck
> wrote:
> > I've attached v4 of the patch.
>
> Hi Michael,
>
> Windows doesn't like sigaction:
>
> https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.15189
>
> I'm not s
Mark Dilger writes:
> Patch applies cleanly on master (b238527664ec6f6c9d00dba4cc2f3dab1c8b8b04),
> compiles, and passes both 'make check-world' and 'make installcheck-world'.
Thanks for reviewing!
> The patch includes changes to the expected output of a few tests, and adds
> new code comments
Alexander Kuzmenkov writes:
> I was also looking at this patch, here are some things I noticed:
Thanks for reviewing! I incorporated your suggestions in the v4
patch I just sent.
regards, tom lane
> On Mon, Aug 13, 2018 at 8:48 PM Robert Haas wrote:
>
> I agree with the critiques from Robbie Harwood and Michael Paquier
> that the way in that compression is being hooked into the existing
> architecture looks like a kludge. I'm not sure I know exactly how it
> should be done, but the current
Alexander Kuzmenkov writes:
> Oh, one more thing: I see a warning without --enable-cassert in
> create_resultscan_plan, because rte is only used in an Assert.
> src/backend/optimizer/plan/createplan.c:3457:17: warning: variable ‘rte’
> set but not used [-Wunused-but-set-variable]
> RangeTblEn
On 11/29/2018 10:47 AM, Alvaro Herrera wrote:
On 2018-Nov-28, Tom Lane wrote:
Alvaro Herrera writes:
On 2018-Nov-28, Tom Lane wrote:
This would also entail rather significant overhead to find out schema
names and interpolate them into the text.
True. I was thinking that the qualified-names
> On Wed, Oct 10, 2018 at 7:10 PM Chris Travers
> wrote:
>
>> More generally, I'd like this material to be code comments. It's the
>> kind of stuff that gets outdated before long if it's kept separate.
>
> The problem is that code comments are not going to be good places to document
> "how do I
Alvaro Herrera writes:
> On 2018-Nov-28, Tom Lane wrote:
>> Color me skeptical --- ruleutils has never especially been designed
>> to be fast, and I can't see that the overhead of this is going to be
>> acceptable to anybody who needs pg_stat_statements in production.
> Good point.
> Maybe we ca
On 11/29/2018 10:59 AM, Stephen Frost wrote:
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
On 2018-Nov-28, Tom Lane wrote:
Alvaro Herrera writes:
On 2018-Nov-28, Tom Lane wrote:
This would also entail rather significant overhead to find out schema
names and interpolate them
On 11/29/2018 12:46 PM, Tom Lane wrote:
Alvaro Herrera writes:
On 2018-Nov-28, Tom Lane wrote:
Color me skeptical --- ruleutils has never especially been designed
to be fast, and I can't see that the overhead of this is going to be
acceptable to anybody who needs pg_stat_statements in producti
On Wed, Nov 28, 2018 at 9:17 PM Stephen Frost wrote:
> > Actually, some geometric comparisons are performed counting
> > tolerance margin, the validity of which is in doubt. Their
> > behavior has been changed in recent major version and still has a
> > room for improvement, and the functions are
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Nov 28, 2018 at 9:17 PM Stephen Frost wrote:
> > > Actually, some geometric comparisons are performed counting
> > > tolerance margin, the validity of which is in doubt. Their
> > > behavior has been changed in recent major versio
On Thu, Nov 29, 2018 at 3:50 PM Stephen Frost wrote:
> I'd suggest you read through the rest of the thread and see my response
> to Tom.
I already did that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Nov 29, 2018 at 3:50 PM Stephen Frost wrote:
> > I'd suggest you read through the rest of the thread and see my response
> > to Tom.
>
> I already did that.
Great, then it's unclear, to me at least, what you're getting at in your
On 11/29/18 6:35 PM, Alvaro Herrera wrote:
>
> Sounds good to me (we -> you, I suppose?). I'd tweak the extra_desc for
> log_min_duration_statement too, because we no longer log "all" when the
> rate is <1; maybe "Zero prints all queries, subject to
> log_statement_sample_rate. -1 turns this fea
On Thu, Nov 29, 2018 at 4:01 PM Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Thu, Nov 29, 2018 at 3:50 PM Stephen Frost wrote:
> > > I'd suggest you read through the rest of the thread and see my response
> > > to Tom.
> >
> > I already did that.
>
> Great, then it's
On Fri, 30 Nov 2018 at 02:01, Peter Eisentraut
wrote:
> committed
Thanks
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Thu, Nov 29, 2018 at 8:28 AM Peter Eisentraut
wrote:
> On 29/11/2018 13:28, Dmitry Dolgov wrote:
> > Unfortunately it needs to be rebased one more time, could you do this? Also
> > I'm
> > wondering about this:
> >
> >> I'm moving this patch forward to CF 2018-09, since it's not going to be
>
On Thu, Nov 29, 2018 at 4:10 AM Michael Paquier wrote:
> On Thu, Nov 29, 2018 at 10:04:12AM +0100, Christoph Berg wrote:
> > There's hundreds of other internal uses of xlog that were not touched
> > either, only the user-facing parts were changed.
>
> I have heard of them ;)
> Just wondering if th
Robert Haas writes:
> On Thu, Nov 29, 2018 at 8:28 AM Peter Eisentraut
> wrote:
>> I have decided that I don't want to pursue this patch anymore. It has
>> served its purpose having allowed us to refine the SSL library
>> abstractions so that alternative implementations such as macOS Secure
>> T
On 29/11/2018 08:26, Lætitia Avrot wrote:
> # What stays in my mind
>
> * It's pretty difficult to handle line breaks
> * Markdown is not standardised and several flavours exist for table
> implementation (so why favor one over the others?)
>
> # The question I'd like to ask you
> So now, I thin
Hi,
On 2018-11-29 16:34:13 -0500, Tom Lane wrote:
> Yeah, I was disappointed too. OpenSSL has had a squirrelly enough track
> record that it'd be nice not to be totally dependent on it.
GnuTLS seems, if anything, worse though. There's obviously good reasons
to add support for TLS libraries that
Thanks! I pushed this with two changes -- one was to reword the docs a
bit more, and the other was to compute in_sample only if it's going to
be used (when exceeded is true). I hope this won't upset any compilers ...
I wonder if there's any sensible way to verify the behavior in an
automated fas
On 2018-Nov-29, Robert Haas wrote:
> On Thu, Nov 29, 2018 at 4:10 AM Michael Paquier wrote:
> > On Thu, Nov 29, 2018 at 10:04:12AM +0100, Christoph Berg wrote:
> > > There's hundreds of other internal uses of xlog that were not touched
> > > either, only the user-facing parts were changed.
> >
>
> On Sun, Oct 14, 2018 at 8:30 PM Matheus de Oliveira
> wrote:
>
> Updated the last patch so it can apply cleanly on HEAD.
>
> About the bugfixes, do you think it is better to move to another thread?
I think it makes sense, this way discussions on two relatively different topics
will not interfe
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> Generally, I think Andres is wrong to argue that immutability
> shouldn't mean *anything* across major versions. If we can readily
> foresee that something is going to change in the future, then we
> shouldn't mark it immutable. However:
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Thu, Nov 29, 2018 at 8:28 AM Peter Eisentraut
> > wrote:
> >> I have decided that I don't want to pursue this patch anymore. It has
> >> served its purpose having allowed us to refine the SSL library
> >> abstraction
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-11-29 16:34:13 -0500, Tom Lane wrote:
> > Yeah, I was disappointed too. OpenSSL has had a squirrelly enough track
> > record that it'd be nice not to be totally dependent on it.
>
> GnuTLS seems, if anything, worse though. There's
Hi,
On 2018-11-29 16:23:42 -0500, Robert Haas wrote:
> Generally, I think Andres is wrong to argue that immutability
> shouldn't mean *anything* across major versions. If we can readily
> foresee that something is going to change in the future, then we
> shouldn't mark it immutable. However:
I w
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2018-Nov-29, Robert Haas wrote:
> > On Thu, Nov 29, 2018 at 4:10 AM Michael Paquier wrote:
> > > On Thu, Nov 29, 2018 at 10:04:12AM +0100, Christoph Berg wrote:
> > > > There's hundreds of other internal uses of xlog that were not
On Fri, Oct 26, 2018 at 2:08 AM Marius Timmer
wrote:
> We (Julian and I) would like to show you the seventh version of this
> patch which includes all the things mentioned before. Unfortunately
> we did not find the time to do this earlier.
+case uaCert:
case uaTrust:
Maybe add
From: Christoph Berg [mailto:christoph.b...@credativ.de]
> A customer was complaining that the "checkpoint starting: xlog"
> message was not included in the grand PG10 rename of user-visible bits.
> The attached patch fixes that.
Can we make use of this chance to change elog() to ereport(), so tha
Greetings,
* Tsunakawa, Takayuki (tsunakawa.ta...@jp.fujitsu.com) wrote:
> From: Christoph Berg [mailto:christoph.b...@credativ.de]
> > A customer was complaining that the "checkpoint starting: xlog"
> > message was not included in the grand PG10 rename of user-visible bits.
> > The attached patch
On Fri, Nov 30, 2018 at 1:17 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Mon, Oct 1, 2018 at 8:54 AM Michael Paquier wrote:
> >
> > On Wed, Jun 06, 2018 at 07:03:47PM +0530, Amit Kapila wrote:
> > > I think Robert's chash stuff [1] might be helpful to reduce the contention
> > > you a
On Thu, Nov 29, 2018 at 07:31:02PM -0500, Stephen Frost wrote:
> * Tsunakawa, Takayuki (tsunakawa.ta...@jp.fujitsu.com) wrote:
>> From: Christoph Berg [mailto:christoph.b...@credativ.de]
>> > A customer was complaining that the "checkpoint starting: xlog"
>> > message was not included in the grand
On Thu, Nov 29, 2018 at 11:03:54AM +0900, Michael Paquier wrote:
> Thanks David for the input. I think that I will be able to finish
> wrapping and commit this stuff tomorrow.
And done. I kept the split into two commits for clarity as suggested by
Stephen, as bisect would actually complain only
On Thu, Nov 29, 2018 at 06:21:34PM +0100, Dmitry Dolgov wrote:
> Nothing changed since then, but also the patch got not enough review to say
> that there was substantial feedback. I'll move it to the next CF.
I would have suggested to mark the patch as returned with feedback
instead as the thing d
On Thu, Nov 29, 2018 at 12:15:08PM -0500, Tom Lane wrote:
> I'm also wondering whether to back-patch such a change. Since we've
> not heard field complaints that match up to this problem, it may be
> that it's unlikely enough that fixing it in HEAD is good enough.
HEAD sounds good enough for to m
1 - 100 of 125 matches
Mail list logo
