On Sat, Aug 1, 2020 at 4:46 AM Robert Haas wrote:
> On Fri, Jun 26, 2020 at 8:36 AM Amit Langote wrote:
> > 0001 and 0002 are preparatory patches.
>
> I read through these patches a bit but it's really unclear what the
> point of them is. I think they need better commit messages, or better
> comm
Dear hackers,
I rebased my old patchset. It would be good to compare this v4 patchset to
non-volatile WAL buffer's one [1].
[1]
https://www.postgresql.org/message-id/002101d649fb$1f5966e0$5e0c34a0$@hco.ntt.co.jp_1
Regards,
Takashi
--
Takashi Menjo
v4-0001-Add-configure-option-for-PMDK.patc
On Wed, Feb 12, 2020 at 9:54 PM Thomas Munro wrote:
> In commit 3eb77eba we made it possible for any subsystem that wants a
> file to be flushed as part of the next checkpoint to ask the
> checkpointer to do that, as previously only md.c could do.
Hello,
While working on recovery performance, I
On Tue, Aug 04, 2020 at 12:00:33PM +0900, Kyotaro Horiguchi wrote:
> While poking at ssl code, I noticed that 002_scram.pl fails if
> ~/.postgresql/root.crt exists. This has been fixed once but
> d6e612f837 reintroduced one. The attached fixes that. Applies to
> 14devel and 13.
Indeed, applied.
On Wed, Jul 29, 2020 at 10:46 AM Dilip Kumar wrote:
>
> Thanks, please find the rebased patch set.
>
Few comments on v44-0001-Implement-streaming-mode-in-ReorderBuffer:
1.
+-- streaming with subxact, nothing in main
+BEGIN;
+savepoint s
2020年8月4日(火) 12:08 David Fetter :
>
> Folks,
>
> I noticed that the API document for IMPORT FOREIGN SCHEMA states in
> part:
>
> It should return a list of C strings, each of which must contain a
> CREATE FOREIGN TABLE command. These strings will be parsed and
> executed by the core ser
Folks,
I noticed that the API document for IMPORT FOREIGN SCHEMA states in
part:
It should return a list of C strings, each of which must contain a
CREATE FOREIGN TABLE command. These strings will be parsed and
executed by the core server.
A reasonable reading of the above is that it
Hello.
While poking at ssl code, I noticed that 002_scram.pl fails if
~/.postgresql/root.crt exists. This has been fixed once but
d6e612f837 reintroduced one. The attached fixes that. Applies to
14devel and 13.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From a29eceb4732ecef
On Tue, Aug 4, 2020 at 3:54 AM Konstantin Knizhnik
wrote:
> So in this thread three solutions are proposed:
> 1. "bullet-proof general shared invalidation"
> 2. recovery-only solution avoiding shared memory and invalidation
> 3. "relaxed" shared memory cache with simplified invalidation
Hi Konsta
Hi,
At the moment JIT compilation, if enabled, is applied to all
expressions in the entire plan. This can sometimes be a problem as
some expressions may be evaluated lots and warrant being JITted, but
others may only be evaluated just a few times, or even not at all.
This problem tends to become
On Tue, Jul 28, 2020 at 3:09 PM Peter Geoghegan wrote:
> Perhaps 2011's commit 520bcd9c9bb missed similar
> HEAPTUPLE_INSERT_IN_PROGRESS issues that manifest themselves within
> Justin's test case now?
Any further thoughts on this, Tom?
This is clearly a live bug that we should fix before too lo
On Sun, Aug 2, 2020 at 11:30 PM Noah Misch wrote:
>
> Interaction with dump/restore (including pg_upgrade) options:
> a. If the schema has a non-default ACL, dump/restore reproduces it.
>Otherwise, the new default prevails.
> b. Dump/restore always reproduces the schema ACL.
>
> Initial owner
On Mon, Aug 3, 2020 at 08:56:06PM +0200, Daniel Verite wrote:
> Hi,
>
> As a follow-up to bug #16570 [1] and other previous discussions
> on the mailing-lists, I'm checking out PG13 beta for Windows
> from:
> https://www.enterprisedb.com/postgresql-early-experience
> and it ships with the same
Ah, seems Tom has even more detail so we will continue to discuss on
that thread.
---
On Mon, Aug 3, 2020 at 07:51:51PM -0400, Bruce Momjian wrote:
> On Sun, Aug 2, 2020 at 08:43:53PM -0700, David G. Johnston wrote:
> > O
On Sun, Aug 2, 2020 at 08:43:53PM -0700, David G. Johnston wrote:
> On Sun, Aug 2, 2020 at 8:17 PM osdba wrote:
>
> hi all:
>
> In Document "Table 59-1. Built-in GiST Operator Classes":
>
> "range_ops any range type && &> &< >> << <@ -|- = @> @>"， exist double "@>
> "，
>
On 2020-Aug-03, Alvaro Herrera wrote:
> There was a lot of great discussion which ended up in Robert completing
> a much sought implementation of non-blocking ATTACH. DETACH was
> discussed too because it was a goal initially, but eventually dropped
> from that patch altogether. Nonetheless, that
I've been working on the ability to detach a partition from a
partitioned table, without causing blockages to concurrent activity.
I think this operation is critical for some use cases.
There was a lot of great discussion which ended up in Robert completing
a much sought implementation of non-bloc
Hi Floris:
On Thu, Jul 23, 2020 at 3:22 AM Floris Van Nee
wrote:
> Hi Andy,
>
>
>
> A small thing I found:
>
>
>
> +static List *
>
> +get_exprs_from_uniqueindex(IndexOptInfo *unique_index,
>
> +
>List *const_exprs,
>
> +
>List *const_expr_opfamilies,
>
> +
>Bitmapset *used_varattrs,
On Sun, Aug 2, 2020 at 9:07 AM Michail Nikolaev
wrote:
> Thanks for your work, the patch is looking better now.
Pushed -- thanks!
--
Peter Geoghegan
On Mon, Jul 20, 2020 at 11:46 AM Andrey M. Borodin wrote:
> In this thread [0] we decided that lock coupling is necessary for
> btree_xlog_unlink_page().
> So, maybe let's revive this patch?
Yes, let's do that. Can you resubmit it, please?
Peter Geoghegan
On 8/3/20 3:34 PM, Fabien COELHO wrote:
>
>
> I'm quite lost about Expect portability discussion wrt windows, it is
> unclear to me whether it is expected to work there or not.
Sorry if I was unclear. Expect will not work on Windows. Nor will use of
IO::Pty or IO::Tty, which are what Expect u
On Mon, Aug 3, 2020 at 11:35:50AM -0700, Peter Geoghegan wrote:
> On Thu, Jul 30, 2020 at 10:45 AM Peter Geoghegan wrote:
> > On Thu, Jul 30, 2020 at 10:32 AM Bruce Momjian wrote:
> > > I came up with a more verbose documentation suggestion, attached.
> >
> > I'm okay with this.
>
> Are you goi
Increasing checkpoint_timeout helps reduce the amount of log written to the
disk. This has several benefits like, reduced number of WAL IO, archival
load on the system, less network traffic to the standby replicas. However,
this increases the crash recovery time and impact server availability.
Inve
Re-reading this thread, I see no complaints about introducing a
dependency on Expect.
Indeed, Tom's complaint was on another thread, possibly when interactive
tests "src/bin/psql/t/010_tab_completion.pl" were added.
ISTM that one of the issue was that some farm animal would be broken.
I'm
osumi.takami...@fujitsu.com:
* I'm a little bit concerned about the semantics of changing the
tgdeferrable/tginitdeferred properties of an existing trigger. If there are
trigger
events pending, and the trigger is redefined in such a way that those events
should already have been fired, what the
Hi,
As a follow-up to bug #16570 [1] and other previous discussions
on the mailing-lists, I'm checking out PG13 beta for Windows
from:
https://www.enterprisedb.com/postgresql-early-experience
and it ships with the same obsolete ICU 53 that was used
for PG 10,11,12.
Besides not having the latest
On Sun, Aug 2, 2020 at 9:55 PM Merlin Moncure wrote:
>
> On Sun, Aug 2, 2020 at 7:18 PM Merlin Moncure wrote:
> >
> > Hackers,
> >
> > I have a situation that I am observing where dblink_is_busy returns 1
> > even though the connection is long gone. tcp keepalives are on and
> > the connection
On Thu, Jul 30, 2020 at 10:45 AM Peter Geoghegan wrote:
> On Thu, Jul 30, 2020 at 10:32 AM Bruce Momjian wrote:
> > I came up with a more verbose documentation suggestion, attached.
>
> I'm okay with this.
Are you going to push this soon, Bruce?
--
Peter Geoghegan
> On 08/03/2020 8:26 AM Robert Haas wrote:
...
> I think this is what's called a double-write buffer, or what was tried
> some years ago under that name. A significant problem is that you
> have to fsync() the double-write buffer before you can write the WAL.
I don't think it does need to be f
Rebased and updated for tests added in 13838740f.
--
Justin Pryzby
System Administrator
Telsasoft
+1-952-707-8581
>From 9272dda812d2b959d0bd536e0679f8f8527da7b1 Mon Sep 17 00:00:00 2001
From: Konstantin Knizhnik
Date: Fri, 12 Oct 2018 15:53:51 +0300
Subject: [PATCH v3 1/2] Secondary index access
On 2020-08-03 15:46, Robert Haas wrote:
However, if people are used to
being able to deposit stuff in /usr/bin and you tell them that they
now can't (because the permissions will henceforth be drwxr-xr-x or
the directly won't exist at all) then some of them are going to
complain. I don't know wha
Peter Eisentraut:
On 2019-12-31 00:07, Vik Fearing wrote:
One thing I notice is that the joined columns are still accessible from
their respective table names when they should not be per spec. That
might be one of those "silly restrictions" that we choose to ignore, but
it should probably be no
Peter Eisentraut writes:
> On 2020-08-03 14:12, Tom Lane wrote:
>> In the specific case of the stats collector, if you don't want
>> to be sending junk bytes then you'd better be memset'ing the
>> whole message buffer not just this string field. So I'm not
>> sure that the argument has any force
On 2020-08-03 14:12, Tom Lane wrote:
I wrote:
David Rowley writes:
Will mean that we'll now no longer zero the full length of the m_xlog
field after the end of the string. Won't that mean we'll start writing
junk bytes to the stats collector?
StrNCpy doesn't zero-fill the destination today
On Mon, Aug 3, 2020 at 8:09 AM Robert Haas wrote:
> I agree that there's a serious design problem with Mark's patch in
> this regard, but I disagree that the effort is pointless on its own
> terms. You're basically postulating that users don't care how corrupt
> their index is: whether there's one
po 3. 8. 2020 v 17:54 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 01.08.2020 00:56, Thomas Munro wrote:
> > On Fri, Jul 31, 2020 at 2:36 PM Thomas Munro
> wrote:
> >> There's still the matter of crazy numbers of lseeks in regular
> >> backends; looking at all proc
On 2020-08-03 14:58, Konstantin Knizhnik wrote:
May be generated and identity columns are good things. I have nothing
against them.
But what preventing us from providing the similar behavior for
serial/bigseries types?
In my mind, serial/bigserial is deprecated and it's not worth spending
effo
Tom Lane:
We don't generally act that way in other ALTER commands and I don't see
a strong argument to start doing so here. [...]
In short, I'm inclined to argue that this variant of ALTER TABLE
should replace *all* the fields of the constraint with the same
properties it'd have if you'd create
On Mon, Aug 3, 2020 at 7:06 PM Robert Haas wrote:
>
> On Mon, Aug 3, 2020 at 5:05 AM Ashutosh Sharma wrote:
> > Could you please explain this point once more in detail? I am not quite
> > able to understand under what circumstances a buffer would be modified, but
> > won't be marked as dirty or
On Mon, Aug 03, 2020 at 11:41:37AM -0400, Robert Haas wrote:
> On Sun, Aug 2, 2020 at 2:11 PM Justin Pryzby wrote:
> > Based on commit logs, I suspect this may be an "older bug", specifically
> > maybe
> > with:
> >
> > |commit 898e5e3290a72d288923260143930fb32036c00c
> > |Author: Robert Haas
>
On 01.08.2020 00:56, Thomas Munro wrote:
On Fri, Jul 31, 2020 at 2:36 PM Thomas Munro wrote:
There's still the matter of crazy numbers of lseeks in regular
backends; looking at all processes while running the above test, I get
1,469,060 (9.18 per pgbench transaction) without -M prepared, and
On Fri, Jul 31, 2020 at 11:13 PM Bharath Rupireddy
wrote:
> memory. MyLatch variable also gets created in shared mode. And having
> no shared memory access for the worker for EXEC_BACKEND cases(in
> StartBackgroundWorker, the shared memory segments get detached), the
> worker fails to receive all
On Thu, Jul 02, 2020 at 03:09:29PM +1200, Thomas Munro wrote:
On Sat, Jun 6, 2020 at 12:36 PM Stephen Frost wrote:
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> I wonder if we can collect some stats to measure how effective the
> prefetching actually is. Ultimately we want something li
On Sun, Aug 2, 2020 at 2:11 PM Justin Pryzby wrote:
> Based on commit logs, I suspect this may be an "older bug", specifically maybe
> with:
>
> |commit 898e5e3290a72d288923260143930fb32036c00c
> |Author: Robert Haas
> |Date: Thu Mar 7 11:13:12 2019 -0500
> |
> |Allow ATTACH PARTITION with
On Mon, Aug 3, 2020 at 8:59 AM Konstantin Knizhnik
wrote:
> May be generated and identity columns are good things. I have nothing
> against them.
> But what preventing us from providing the similar behavior for
> serial/bigseries types?
Backward compatibility seems like one good argument.
It kin
On Mon, Aug 3, 2020 at 5:26 AM Daniel Wood wrote:
> If we can't eliminate FPW's can we at least solve the impact of it? Instead
> of writing the before images of pages inline into the WAL, which increases
> the COMMIT latency, write these same images to a separate physical log file.
> The key
Greetings,
* Noah Misch (n...@leadboat.com) wrote:
> I'd like to reopen this. Reception was mixed, but more in favor than against.
> Also, variations on the idea trade some problems for others and may be more
> attractive. The taxonomy of variations has three important dimensions:
>
> Interacti
On Sun, Aug 2, 2020 at 11:30:50PM -0700, Noah Misch wrote:
> On Fri, Mar 23, 2018 at 07:47:39PM -0700, Noah Misch wrote:
> > In light of the mixed reception, I am withdrawing this proposal.
>
> I'd like to reopen this. Reception was mixed, but more in favor than against.
> Also, variations on th
On Mon, Aug 3, 2020 at 11:02 AM Mark Dilger
wrote:
> I was trying to limit unnecessary whitespace changes. s/ereport/econfess/
> leaves the function name nearly the same length such that the following lines
> of indented error text don't usually get moved by pgindent. Given the
> unpopularity
On Mon, Aug 3, 2020 at 12:00 AM Peter Geoghegan wrote:
> Moving on with verification of the same index in the event of B-Tree
> index corruption is a categorical mistake. verify_nbtree.c was simply
> not designed to work that way.
>
> You were determined to avoid allowing any behavior that can res
On 2020-Aug-03, Asim Praveen wrote:
> Thank you Alvaro for reviewing the patch!
>
> > On 01-Aug-2020, at 7:22 AM, Alvaro Herrera wrote:
> >
> > What happens if a replacement string happens to be split in the middle
> > by the fgets buffering? I think it'll fail to be replaced. This
> > applie
> On Aug 2, 2020, at 9:13 PM, Peter Geoghegan wrote:
>
> On Thu, Jul 30, 2020 at 10:59 AM Robert Haas wrote:
>> I don't really like the name, either. I get that it's probably
>> inspired by Perl, but I think it should be given a less-clever name
>> like report_corruption() or something.
>
>
> On Aug 2, 2020, at 8:59 PM, Peter Geoghegan wrote:
>
> What's the point in not just giving up on the index (though not
> necessarily the table or other indexes) at the first sign of trouble,
> anyway? It makes sense for the heap structure, but not for indexes.
The case that came to mind was
On Mon, Jul 20, 2020 at 4:30 PM Andres Freund wrote:
> I'm extremely doubtful this is a good idea. In all likelihood this will
> just exascerbate corruption.
>
> You cannot just stop freezing tuples, that'll lead to relfrozenxid
> getting *further* out of sync with the actual table contents. And y
Thank you Alvaro for reviewing the patch!
> On 01-Aug-2020, at 7:22 AM, Alvaro Herrera wrote:
>
> What happens if a replacement string happens to be split in the middle
> by the fgets buffering? I think it'll fail to be replaced. This
> applies to both versions.
Can a string to be replaced be
On Mon, Aug 3, 2020 at 2:30 AM Noah Misch wrote:
> Between (b)(2)(X) and (b)(3)(X), what are folks' preferences? Does anyone
> strongly favor some other option (including the option of changing nothing)
> over both of those two?
I don't think we have any options here that are secure but do not
b
On Mon, Aug 3, 2020 at 5:05 AM Ashutosh Sharma wrote:
> Could you please explain this point once more in detail? I am not quite able
> to understand under what circumstances a buffer would be modified, but won't
> be marked as dirty or a WAL won't be written for it.
Whenever this branch is take
On 03.08.2020 11:00, Peter Eisentraut wrote:
On 2020-08-01 00:06, Konstantin Knizhnik wrote:
Postgres provides serial and bigserial column types for which it
implicitly creates sequence.
As far as this mechanism is somehow hidden from user, it may be
confusing that table
created with CREATE T
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Also, for easier review, here's the `git diff -w` output, since the
> tags caused most of the page to have to be renidented.
TBH, I'd suggest just not being anal about whether the indentation
nesting is perfect ;-). There ar
I wrote:
> David Rowley writes:
>> Will mean that we'll now no longer zero the full length of the m_xlog
>> field after the end of the string. Won't that mean we'll start writing
>> junk bytes to the stats collector?
> StrNCpy doesn't zero-fill the destination today either (except for
> the very
On Mon, Aug 3, 2020 at 1:32 PM Dagfinn Ilmari Mannsåker
wrote:
> ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
>
> > Hi hackers,
> >
> > Every time I have to look up what kinds of operations each index type is
> > suitable for, I get annoyed by the index types page being virtually
> > unsk
David Rowley writes:
> - StrNCpy(msg.m_xlog, xlog, sizeof(msg.m_xlog));
> + strlcpy(msg.m_xlog, xlog, sizeof(msg.m_xlog));
> Will mean that we'll now no longer zero the full length of the m_xlog
> field after the end of the string. Won't that mean we'll start writing
> junk bytes to the stats col
Hi Andrey,
On Wed, Jul 29, 2020 at 5:36 PM Andrey V. Lepikhov
wrote:
> > Will send more comments after reading the v5 patch.
> >
> Ok. I'll be waiting for the end of your review.
Sorry about the late reply.
If you'd like to send a new version for other reviewers, please feel
free. I haven't ma
ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> Hi hackers,
>
> Every time I have to look up what kinds of operations each index type is
> suitable for, I get annoyed by the index types page being virtually
> unskimmable due to not having headings for each index type.
>
> Attached is a patc
On Tue, Jul 14, 2020 at 10:28 PM Bruce Momjian wrote:
>
> On Tue, Jul 14, 2020 at 03:38:49PM +0530, Bharath Rupireddy wrote:
> > Approach #4:
> > A postgres_fdw foreign server level option: connection idle time, the
> > amount of idle time for that server cached entry, after which the
> > cached e
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Patch applies cleanly. Tested that update/delete of tables with defer
This thread has stalled and the patch no longer applies, so I'm marking this
Returned with Feedback. Please feel free to open a new entry if this patch is
revived.
cheers ./daniel
On 31.07.2020 23:28, Robert Haas wrote:
On Tue, Jul 14, 2020 at 1:51 PM Anastasia Lubennikova
wrote:
Questions from the first review pass:
1) Do we need XLH_INSERT_ALL_VISIBLE_SET ? IIUC, in the patch it is always
implied by XLH_INSERT_ALL_FROZEN_SET.
I agree that it looks unnecessary to have
I thought that the biggest reason for the pgbench RW slowdown during a
checkpoint was the flood of dirty page writes increasing the COMMIT latency.
It turns out that the documentation which states that FPW's start "after a
checkpoint" really means after a CKPT starts. And this is the really ca
Uggg.
At Mon, 03 Aug 2020 16:19:37 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 31 Jul 2020 05:53:53 -0700, Henry B Hotz wrote in
> > A CA may issue a CRL infrequently, but issue a delta-CRL frequently. Does
> > the logic support this properly?
>
> If you are talking about regsitering
On Mon, 3 Aug 2020 at 19:54, Michael Paquier wrote:
> Worth noting that the patch set fails to apply. I have moved this
> entry to the next CF, waiting on author.
Thanks.
NB: It's not a patch set. It's 3 different versions of the patch.
They're not all meant to apply at once. Probably the CF bo
Hi Robert,
Thanks for the review.
I've gone through all your review comments and understood all of them
except this one:
You really cannot
> modify the buffer like this and then decide, oops, never mind, I think
> I won't mark it dirty or write WAL for the changes. If you do that,
> the buffer i
On Mon, 3 Aug 2020 at 18:59, Peter Eisentraut
wrote:
> I propose to replace the remaining uses of StrNCpy() with strlcpy() and
> remove the former. It's clear that strlcpy() has won the popularity
> contest, and the presence of the former is just confusing now.
It certainly would be good to get
On 2020-08-01 00:06, Konstantin Knizhnik wrote:
Postgres provides serial and bigserial column types for which it
implicitly creates sequence.
As far as this mechanism is somehow hidden from user, it may be
confusing that table
created with CREATE TABLE LIKE has no associated sequence.
That's wh
On Sun, Jul 05, 2020 at 12:15:58PM -0500, Justin Pryzby wrote:
> It looks like this needs to be additionally rebased - I will set cfbot to
> "Waiting".
... Something that has not happened in four weeks, so this is marked
as returned with feedback. Please feel free to resubmit once a rebase
is do
On Mon, Jun 29, 2020 at 09:36:56PM +1200, David Rowley wrote:
> I've attached a graph showing the results for the AMD and Intel runs
> and also csv files of the pgbench tps output. I've also attached each
> version of the patch I tested.
>
> It would be good to see some testing done on other hard
On Mon, Aug 3, 2020 at 2:54 PM Amit Langote wrote:
> However, I noticed that having system columns like ctid, xmin, etc. in
> the RETURNING list is now broken and maybe irrepairably due to the
> approach we are taking in the patch. Let me show an example:
>
> drop table foo;
> create table foo (a
At Fri, 31 Jul 2020 09:00:14 -0400, Stephen Frost wrote in
> Greetings,
>
> * Kyotaro Horiguchi (horikyota@gmail.com) wrote:
> > PostgreSQL server accepts only one CRL file. It is easy to expand
> > be_tls_init to accept a directory set in ssl_crl_file. But I'm not
> > sure CRL is actually e
At Fri, 31 Jul 2020 05:53:53 -0700, Henry B Hotz wrote in
> A CA may issue a CRL infrequently, but issue a delta-CRL frequently. Does the
> logic support this properly?
If you are talking about regsitering new revokations while server is
running, it checks newer CRLs upon each lookup according
>Fixed in global_temporary_table_v29-pg13.patch
>Please check.
I find this is the most latest mail with an attachment, so I test and reply on
this thread, several points as below:
1. I notice it produces new relfilenode when new session login and some
data insert. But the relfilenode column in p
I propose to replace the remaining uses of StrNCpy() with strlcpy() and
remove the former. It's clear that strlcpy() has won the popularity
contest, and the presence of the former is just confusing now.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 S
81 matches
Mail list logo
