On Mon, 30 Mar 2020 at 15:46, Masahiko Sawada
wrote:
>
> On Sun, 29 Mar 2020 at 20:44, Masahiko Sawada
> wrote:
> >
> > On Sun, 29 Mar 2020 at 20:15, Amit Kapila wrote:
> > >
> > > On Sun, Mar 29, 2020 at 1:44 PM Julien Rouhaud wrote:
> > > >
> > > > On Sun, Mar 29, 2020 at 9:52 AM Masahiko Saw
so 28. 3. 2020 v 6:30 odesílatel Pavel Stehule
napsal:
> Hi
>
> I am playing with pspg and inotify support. It is working pretty well and
> now can be nice if forwarding to output file can be configured little bit
> more. Now, only append mode is supported. But append mode doesn't work with
> psp
On Sun, Mar 29, 2020 at 09:41:01PM -0700, Noah Misch wrote:
> I think attached v41nm is ready for commit. Would anyone like to vote against
> back-patching this? It's hard to justify lack of back-patch for a data-loss
> bug, but this is atypically invasive. (I'm repeating the question, since som
At Fri, 27 Mar 2020 13:54:25 +0900, Fujii Masao
wrote in
>
>
> On 2020/03/27 10:26, Tom Lane wrote:
> > Twice in the past month [1][2], buildfarm member hoverfly has managed
> > to reach the "unreachable" Assert(false) at the end of
> > SyncRepGetSyncStandbysPriority.
>
> When I search the pa
On Sun, Mar 29, 2020 at 07:06:56PM +0200, Juan José Santamaría Flecha wrote:
> It works for the issue just fine, and more comments make a better a
> patch, so no objections from me.
+1 from me. And yes, we are still missing lc_codepage in newer
versions of VS. Locales + Windows != 2, business as
On Mon, Mar 30, 2020 at 04:01:18PM +0900, Masahiko Sawada wrote:
> On Mon, 30 Mar 2020 at 15:46, Masahiko Sawada
> wrote:
> >
> > On Sun, 29 Mar 2020 at 20:44, Masahiko Sawada
> > wrote:
> > >
> > > > > > I think we need to change parallel maintenance commands so that they
> > > > > > report buff
On Mon, Mar 30, 2020 at 01:56:43PM +0900, Fujii Masao wrote:
>
>
> On 2020/03/29 15:15, Julien Rouhaud wrote:
> > On Fri, Mar 27, 2020 at 03:42:50PM +0100, Julien Rouhaud wrote:
> > > On Fri, Mar 27, 2020 at 2:01 PM Fujii Masao
> > > wrote:
> > > >
> > >
> > > > So what I'd like to say is tha
On Sun, Mar 29, 2020 at 02:55:37PM +0200, Juan José Santamaría Flecha wrote:
> Add it to the tests done when PG_COLOR is "auto".
FWIW, I am not sure that it is a good idea to stick into the code
knowledge inherent to TERM. That would likely rot depending on how
terminals evolve in the future, and
On Sun, Mar 29, 2020 at 11:56:15AM +0200, Peter Eisentraut wrote:
> I didn't do this because it would create additional complications in the man
> pages. But there is now an index entry, so it's possible to find more
> information.
Cannot you add a link to the page for color support in each one o
On 2020-03-27 20:15, Sergei Kornilov wrote:
I think we can set wait event WAIT_EVENT_RECOVERY_PAUSE here.
+1, since we added this in recoveryPausesHere.
committed with that addition
PS: do we need to add a prototype for the RecoveryRequiredIntParameter function
in top of xlog.c?
There is
Hi,
On Wed, Mar 11, 2020 at 10:47 AM movead li wrote:
> I redo the make installcheck-world as Kyotaro Horiguchi point out and the
> result nothing wrong. And I think the patch is good in feature and performance
> here is the test result thread I made before:
> https://www.postgresql.org/message-
On Sat, Mar 28, 2020 at 07:48:22AM -0300, Ranier Vilela wrote:
> I completely disagree. My tools have proven their worth, including finding
> serious errors in the code, which fortunately have been fixed by other
> committers.
FWIW, I think that the rule to always take Coverity's reports with a
pi
Hello hackers,
I find a small issue in XLogInsertRecord() function: it checks whether it's able
to insert a wal by XLogInsertAllowed(), when refused it reports an error "cannot
make new WAL entries during recovery".
I notice that XLogInsertAllowed() reject to insert a wal record not only
sometim
On Fri, Mar 27, 2020 at 5:03 AM Justin Pryzby wrote:
>
Now that the main patch is committed, I have reviewed the other two patches.
v37-0002-Drop-reltuples
1.
@@ -2289,11 +2289,10 @@ vacuum_one_index(Relation indrel,
IndexBulkDeleteResult **stats,
/* Do vacuum or cleanup of the index */
if
On Sat, Mar 28, 2020 at 11:49 AM Ranier Vilela wrote:
>
> Em sex., 27 de mar. de 2020 às 20:49, Tom Lane escreveu:
>>
>> Ranier Vilela writes:
>> > Can someone check if there is a copy and paste error, at file:
>> > \usr\backend\commands\analyze.c, at lines 2225 and 2226?
>> > int num_mcv = stat
Hi,
Tom Lane wrote:
> Confirmed: building gistget with --enable-cassert, and all of snapper's
> compile/link options, produces something that passes regression.
Skate uses buildfarm default configuration, whereas snapper uses settings which
are used when building postgresql debian packages. Debi
On Mon, 30 Mar 2020 at 19:49, David Rowley wrote:
> I'll see if I can come up with some way to do this in a more
> deterministic way to determine which tables to add vacuums for, rather
> than waiting for and reacting post-failure.
I ended up running make installcheck on an instance with
autovacu
On Sun, Mar 29, 2020 at 5:49 PM Julien Rouhaud wrote:
>
@@ -1249,6 +1250,16 @@ XLogInsertRecord(XLogRecData *rdata,
ProcLastRecPtr = StartPos;
XactLastRecEnd = EndPos;
+ /* Provide WAL update data to the instrumentation */
+ if (inserted)
+ {
+ pgWalUsage.wal_bytes += rechdr->xl_tot_len;
+ i
Thanks Asif,
I have re-verified reported issue. expect standby backup, others are fixed.
Thanks & Regards,
Rajkumar Raghuwanshi
On Fri, Mar 27, 2020 at 11:04 PM Asif Rehman wrote:
>
>
> On Wed, Mar 25, 2020 at 12:22 PM Rajkumar Raghuwanshi <
> rajkumar.raghuwan...@enterprisedb.com> wrote:
>
>
On Fri, 27 Mar 2020 at 17:54, Fujii Masao wrote:
>
>
>
> On 2020/03/04 14:31, Masahiko Sawada wrote:
> > On Wed, 4 Mar 2020 at 13:48, Fujii Masao
> > wrote:
> >>
> >>
> >>
> >> On 2020/03/04 13:27, Michael Paquier wrote:
> >>> On Wed, Mar 04, 2020 at 01:13:19PM +0900, Masahiko Sawada wrote:
> >>
On Wednesday, March 25, 2020 3:25 PM, Kirk Jamison wrote:
> As for the performance and how it affects the read-only workloads.
> Using pgbench, I've kept the overload to a minimum, less than 1%.
> I'll post follow-up results.
Here's the follow-up results.
I executed the similar tests from top of t
Em dom., 29 de mar. de 2020 às 21:57, Kyotaro Horiguchi <
horikyota@gmail.com> escreveu:
> Hello.
>
> At Sat, 28 Mar 2020 19:04:00 -0300, Ranier Vilela
> wrote in
> > Hi,
> > This patch fixes some redundant initilization, that are safe to remove.
>
> > diff --git a/src/backend/access/gist/gis
On Sun, Mar 29, 2020 at 4:48 PM Maryam Farrukh
wrote:
>
> Hi Fabrizio,
>
Hi Maryam, please try to avoid top posting!!
Returning the discussion to pgsql-hackers.
> Thank you for reaching out. I have a question. I went through the links
you provided me. There
> are already some project ideas ove
On Sun, Mar 29, 2020 at 10:16:53PM -0400, James Coleman wrote:
On Sun, Mar 29, 2020 at 9:44 PM Tomas Vondra
wrote:
Hi,
Attached is a slightly reorganized patch series. I've merged the fixes
into the appropriate matches, and I've also combined the two patches
adding incremental sort paths to a
Em seg., 30 de mar. de 2020 às 05:16, Michael Paquier
escreveu:
> On Sat, Mar 28, 2020 at 07:48:22AM -0300, Ranier Vilela wrote:
> > I completely disagree. My tools have proven their worth, including
> finding
> > serious errors in the code, which fortunately have been fixed by other
> > committe
I wrote:
> I'm going to look into implementing timezone while awaiting comments on v6.
I attempted this in the attached v7. There are 4 new functions for
truncating timestamptz on an interval -- with and without origin, and
with and without time zone.
Parts of it are hackish, and need more work,
Em seg., 30 de mar. de 2020 às 06:06, Magnus Hagander
escreveu:
> On Sat, Mar 28, 2020 at 11:49 AM Ranier Vilela
> wrote:
> >
> > Em sex., 27 de mar. de 2020 às 20:49, Tom Lane
> escreveu:
> >>
> >> Ranier Vilela writes:
> >> > Can someone check if there is a copy and paste error, at file:
> >
On Mon, Mar 30, 2020 at 03:52:38PM +0530, Amit Kapila wrote:
> On Sun, Mar 29, 2020 at 5:49 PM Julien Rouhaud wrote:
> >
>
> @@ -1249,6 +1250,16 @@ XLogInsertRecord(XLogRecData *rdata,
> ProcLastRecPtr = StartPos;
> XactLastRecEnd = EndPos;
>
> + /* Provide WAL update data to the instrumenta
On Mon, Mar 30, 2020 at 3:44 PM Rajkumar Raghuwanshi <
rajkumar.raghuwan...@enterprisedb.com> wrote:
> Thanks Asif,
>
> I have re-verified reported issue. expect standby backup, others are fixed.
>
Yes As Asif mentioned he is working on the standby issue and adding
bandwidth throttling functional
Hi all,
While playing around with Peter E.'s unicode normalization patch [1],
I found that HEAD failed to build a perfect hash function for any of
the four sets of 4-byte keys ranging from 1k to 17k in number. It
probably doesn't help that codepoints have nul bytes and often cluster
into consecuti
On Mon, Mar 30, 2020 at 4:57 AM Michael Paquier wrote:
> On Fri, Mar 27, 2020 at 07:47:29AM +0900, Michael Paquier wrote:
> > On Thu, Mar 26, 2020 at 06:56:36PM -0300, Alvaro Herrera wrote:
> >> I don't think any such cleanup should hamper the patch at hand anyway.
> >
> > I don't think either, so
On Fri, Mar 27, 2020 at 3:27 PM Tom Lane wrote:
> Surafel Temesgen writes:
> > [ conflict-handling-copy-from-v16.patch ]
>
> I took a quick look at this patch, since it was marked "ready for
> committer", but I don't see how it can possibly be considered committable.
>
> 1. Covering only the err
On 2020-03-30 04:56, Michael Paquier wrote:
On Fri, Mar 27, 2020 at 07:47:29AM +0900, Michael Paquier wrote:
On Thu, Mar 26, 2020 at 06:56:36PM -0300, Alvaro Herrera wrote:
I don't think any such cleanup should hamper the patch at hand
anyway.
I don't think either, so I would do the split for
On Sun, Mar 29, 2020 at 9:50 PM Andres Freund wrote:
> On March 29, 2020 11:24:32 AM PDT, Alexander Korotkov
> wrote:
> > clearly a big win on majority
> >of workloads, I think we still need to investigate different workloads
> >on different hardware to ensure there is no regression.
>
> Definit
On 1/11/20 12:53 PM, David Fetter wrote:
I agree that it's a complex situation, and that many different
approaches will eventually need to be brought to bear.
What concerns me about introducing a big lump of complexity here is
disentangling the effects of each part and of their interaction term
Hi,
The Release Management Team (RMT) for the PostgreSQL 13 is assembled and
has determined that the feature freeze date for the PostgreSQL 11
release will be April 7, 2020. This means that any feature for the
PostgreSQL 13 release **must be committed by April 7, 2020 AOE**
("anywhere on earth")[1
Hi,
This patch remove reassigned values, with safety.
Plancat.c, needs a more careful review.
Best regards
Ranier Vilela
remove_reassigned_values.patch
Description: Binary data
Fabien COELHO writes:
> As I wrote about an earlier version of the patch, ISTM that instead of
> reinventing, extending, adapting various ls variants (with/without
> metadata, which show only files, which shows target of links, which shows
> directory, etc.) we would just need *one* postgres "l
Michael Paquier writes:
> On Sun, Mar 29, 2020 at 07:06:56PM +0200, Juan José Santamaría Flecha wrote:
>> It works for the issue just fine, and more comments make a better a
>> patch, so no objections from me.
> +1 from me. And yes, we are still missing lc_codepage in newer
> versions of VS. Lo
On Mon, Mar 30, 2020 at 11:47:57AM +0530, Amit Kapila wrote:
On Sun, Mar 29, 2020 at 9:01 PM Tomas Vondra
wrote:
On Sun, Mar 29, 2020 at 11:19:21AM +0530, Amit Kapila wrote:
>On Sun, Mar 29, 2020 at 6:29 AM Tomas Vondra
> wrote:
>>
>> Ummm, how is that different from what the patch is doing no
I have updated the comments in apply_handle_tuple_routing() (see 0002)
to better explain what's going on with UPDATE handling. I also
rearranged the tests a bit for clarity.
Attached updated patches.
--
Thank you,
Amit Langote
EnterpriseDB: http://www.enterprisedb.com
v1-0001-worker.c-refact
On 2020-03-27 18:52, Andrew Dunstan wrote:
I have tested this on drongo/fairywren and it works fine. The patches
apply cleanly (with a bit of fuzz) and a full buildfarm run is happy in
both cases.
Unfortunately I don't have a Windows machine that's young enough to
support git master and old enou
On 1/11/20 5:13 PM, Alexander Korotkov wrote:
On Tue, Jan 7, 2020 at 11:04 PM Tom Lane wrote:
"If the link named by the new argument exists and the file's link
count becomes 0 when it is removed and no process has the file open,
the space occupied by the file shall be freed and the file shall n
On Tue, 17 Mar 2020 at 19:32, Dave Cramer wrote:
>
>
> On Tue, 17 Mar 2020 at 19:23, Bruce Momjian wrote:
>
>> On Tue, Mar 17, 2020 at 07:15:05PM -0400, Dave Cramer wrote:
>> > On Tue, 17 Mar 2020 at 16:47, Bruce Momjian wrote:
>> > Third, the idea that individual interfaces, e.g. JDBC, sho
Hi
when I was in talk with Silvio Moioli, I found strange hash join. Hash was
created from bigger table.
https://www.postgresql.org/message-id/79dd683d-3296-1b21-ab4a-28fdc2d98807%40suse.de
Now it looks so materialized CTE disallow hash
create table bigger(a int);
create table smaller(a int);
po 30. 3. 2020 v 18:06 odesílatel Pavel Stehule
napsal:
> Hi
>
> when I was in talk with Silvio Moioli, I found strange hash join. Hash was
> created from bigger table.
>
>
> https://www.postgresql.org/message-id/79dd683d-3296-1b21-ab4a-28fdc2d98807%40suse.de
>
> Now it looks so materialized CTE
David Steele writes:
> On 1/11/20 5:13 PM, Alexander Korotkov wrote:
>> Regarding "pg_stat_tmp/global.stat", which is a problem in particular
>> case, we may evade file renaming altogether. Instead, we may
>> implement shared-memory counter for filename. So, instead of
>> renaming, new reads wil
On 2020-Feb-25, Peter Eisentraut wrote:
> An alternative would be that we make this situation fully supported. Then
> we'd probably need at least ALTER INDEX ... ALTER COLUMN ... SET STORAGE,
> and some pg_dump support.
I think this is a more promising direction.
--
Álvaro Herrera
> On Mar 30, 2020, at 7:09 AM, David Steele wrote:
>
> On 1/11/20 12:53 PM, David Fetter wrote:
>> I agree that it's a complex situation, and that many different
>> approaches will eventually need to be brought to bear.
>> What concerns me about introducing a big lump of complexity here is
>>
> ALTER TABLE ... SET STORAGE does not propagate to indexes, even though
> indexes created afterwards get the new storage setting. So depending on
> the order of commands, you can get inconsistent storage settings between
> indexes and tables.
I've absolutely noticed this behavior, I just thought
"Tom Turelinckx" writes:
> In the past, I've already switched from gcc 4.6 to gcc 4.7 as a workaround
> for a similar compiler bug, but I can't upgrade to a newer gcc without
> backporting it myself, so for the moment I've switched snapper to use -O1
> instead of -O2, for HEAD only.
Thanks! B
On Mon, Mar 30, 2020 at 02:31:53PM +0530, Amit Kapila wrote:
> Now that the main patch is committed, I have reviewed the other two patches.
Thanks for that
On Mon, Mar 30, 2020 at 02:31:53PM +0530, Amit Kapila wrote:
> The v37-0003-Avoid-some-calls-to-RelationGetRelationName.patch looks
> good to
On 3/30/20 6:05 PM, Dave Cramer wrote:
> So it appears this is currently languishing as unresolved and feature
> freeze is imminent.
>
> What has to be done to get a decision one way or another before feature
> freeze.
>
> I have provided a patch that could be reviewed and at least be considered
On 2020/03/30 17:03, Julien Rouhaud wrote:
On Mon, Mar 30, 2020 at 01:56:43PM +0900, Fujii Masao wrote:
On 2020/03/29 15:15, Julien Rouhaud wrote:
On Fri, Mar 27, 2020 at 03:42:50PM +0100, Julien Rouhaud wrote:
On Fri, Mar 27, 2020 at 2:01 PM Fujii Masao wrote:
So what I'd like to s
On Mon, Mar 30, 2020 at 06:14:42PM +0200, Pavel Stehule wrote:
po 30. 3. 2020 v 18:06 odesílatel Pavel Stehule
napsal:
Hi
when I was in talk with Silvio Moioli, I found strange hash join. Hash was
created from bigger table.
https://www.postgresql.org/message-id/79dd683d-3296-1b21-ab4a-28fdc
On 1/11/20 10:41 PM, Tomas Vondra wrote:
On Sun, Jan 12, 2020 at 03:52:48AM +0100, Tomas Vondra wrote:
...
I'm not an ecpg expert (in fact I've never even used it), so my review
is pretty superficial, but I only found a couple of minor whitespace
issues (adding/removing a line/tab) - see the at
On Sun, Mar 29, 2020 at 5:29 AM Jürgen Purtz wrote:
> On 27.03.20 21:12, Justin Pryzby wrote:
> > On Fri, Mar 20, 2020 at 11:32:25PM +0100, Jürgen Purtz wrote:
> +Archiver
> >>> Can you change that to archiver process ?
> >> I prefer the short term without the addition of 'process' - con
Tomas Vondra writes:
> That's because eqjoinsel_inner won't have any statistics for either side
> of the join, so it'll use default ndistinct values (200), resulting in
> estimate of 0.5% for the join condition.
Right.
> But this should not affect the choice of join algorithm, I think,
> because
Hi,
Tom Lane wrote:
> Thanks! But it doesn't seem to have taken: snapper just did a new run
> that still failed, and it still seems to be using -O2.
Snapper did build using -O1 a few hours ago, but it failed the check stage very
early with a different error:
FATAL: null value in column "classi
Hi,
On 2020-03-30 12:24:06 -0400, Tom Lane wrote:
> "Tom Turelinckx" writes:
> Yeah, I've got a couple of those myself. But perhaps it'd be sensible
> to move to a newer Debian LTS release? Or have they dropped Sparc
> support altogether?
I think the 32bit sparc support has been phased out. Sp
Andres Freund writes:
> On 2020-03-30 12:24:06 -0400, Tom Lane wrote:
>> (As of this weekend, it seemed to be impossible to find the wheezy sparc
>> distribution images on-line anymore.
> The installer downloads are still available at:
> https://www.debian.org/releases/wheezy/debian-installer/
A
"Tom Turelinckx" writes:
> Tom Lane wrote:
>> Thanks! But it doesn't seem to have taken: snapper just did a new run
>> that still failed, and it still seems to be using -O2.
> Snapper did build using -O1 a few hours ago, but it failed the check stage
> very early with a different error:
> FATAL:
I wrote:
> Hence, attached are two revised patches that attack the problem
> this way. The first one is somewhat unrelated to the original
> point --- it's trying to clean up the error messages in ltree_in
> and lquery_in so that they are more consistent and agree with
> the terminology used in th
On 2020-03-28 03:11, Justin Pryzby wrote:
On Thu, Mar 26, 2020 at 11:01:06PM -0500, Justin Pryzby wrote:
> Another issue is this:
> > +VACUUM ( FULL [, ...] ) [ TABLESPACE new_tablespace
] [ table_and_columns [, ...] ]
> As you mentioned in your v1 patch, in the other cases, "tablespace
> [tabl
Hi,
I'm not sure that the patch is 100% correct.
But the fix is about expression about always true.
But if this patch is correct, he fix one possible bug.
The comment says:
* Perform checking of FSM after releasing lock, the fsm is
* approximate, after all.
But this is not what the code does, app
Hi,
On 2020-03-30 19:41:43 +0900, Fujii Masao wrote:
> On 2020/03/30 16:58, Peter Eisentraut wrote:
> > Improve handling of parameter differences in physical replication
> >
> > When certain parameters are changed on a physical replication primary,
> > this is communicated to standbys using the X
On Mon, Mar 30, 2020 at 6:36 PM Fujii Masao wrote:
>
> On 2020/03/30 17:03, Julien Rouhaud wrote:
> > On Mon, Mar 30, 2020 at 01:56:43PM +0900, Fujii Masao wrote:
> >>
> >>
> >> On 2020/03/29 15:15, Julien Rouhaud wrote:
> >>> On Fri, Mar 27, 2020 at 03:42:50PM +0100, Julien Rouhaud wrote:
>
Tomas Vondra writes:
> I see this patch is marked as RFC since 12/30, but there seems to be
> quite a lot of discussion about the syntax, keywords and how exactly to
> identify the superuser. So I'll switch it back to needs review, which I
> think is a better representation of the current state.
Hi,
On 2020-03-30 21:33:14 +0800, John Naylor wrote:
> Then I used the attached program to measure various combinations of
> compiled instructions using two constant multipliers iterating over
> bytes similar to a generated hash function.
It looks like you didn't attach the program?
> -O2 -Wal
On Mon, Mar 30, 2020 at 09:02:22PM +0300, Alexey Kondratov wrote:
> Hmm, I went through the well known to me SQL commands in Postgres and a bit
> more. Parenthesized options list is mostly used in two common cases:
There's also ANALYZE(VERBOSE), REINDEX(VERBOSE).
There was debate a year ago [0] as
On Sun, Mar 29, 2020 at 10:08 PM Andres Freund wrote:
> See the attached minimal prototype for what I am thinking of.
>
> This would not correctly handle the case where the timeline changes
> while taking a base backup. But I'm not sure that'd be all that serious
> a limitation for now?
>
> I'd pe
Hi,
On 2020-03-30 14:35:40 -0400, Robert Haas wrote:
> On Sun, Mar 29, 2020 at 10:08 PM Andres Freund wrote:
> > See the attached minimal prototype for what I am thinking of.
> >
> > This would not correctly handle the case where the timeline changes
> > while taking a base backup. But I'm not su
On Mon, Mar 30, 2020 at 2:24 AM Amit Kapila wrote:
> > Between those two, I would use "pg_validatebackup" if there's a fair chance
> > it
> > will end up doing the pg_waldump check. Otherwise, I would use
> > "pg_validatemanifest".
>
> +1.
I guess I'd like to be clear here that I have no fundam
Hi,
On 2020-03-30 15:07:40 -0300, Ranier Vilela wrote:
> I'm not sure that the patch is 100% correct.
This is *NOT* correct.
> But the fix is about expression about always true.
> But if this patch is correct, he fix one possible bug.
>
> The comment says:
> * Perform checking of FSM after rel
On Tue, Mar 31, 2020 at 2:31 AM Andres Freund wrote:
>
> Hi,
>
> On 2020-03-30 21:33:14 +0800, John Naylor wrote:
> > Then I used the attached program to measure various combinations of
> > compiled instructions using two constant multipliers iterating over
> > bytes similar to a generated hash fu
Hi,
On 2020-03-30 15:04:55 -0400, Robert Haas wrote:
> I guess I'd like to be clear here that I have no fundamental
> disagreement with taking this tool in any direction that people would
> like it to go. For me it's just a question of timing. Feature freeze
> is now a week or so away, and nothing
On Mon, Mar 30, 2020 at 2:59 PM Andres Freund wrote:
> I wonder if it'd not be best, independent of whether we build in this
> verification, to include that metadata in the manifest file. That's for
> sure better than having to build a separate tool to parse timeline
> history files.
I don't thin
Hi,
On March 30, 2020 9:17:00 AM PDT, Tom Lane wrote:
>So far as pg_stat_tmp is concerned, I think there is reasonable hope
>that that problem is just going to go away in the near future.
>I've not been paying attention to the shared-memory stats collector
>thread so I'm not sure if that's anywhe
On Sun, Mar 29, 2020 at 9:05 PM David Steele wrote:
> Yeah, that seems reasonable.
>
> In our case backups are nearly always compressed and/or encrypted so
> even checking the original size is a bit of work. Getting the checksum
> at the same time seems like an obvious win.
Makes sense. If this e
Apologies for not responding earlier, busy times.
Fourth, it is not clear how many applications would break if COMMIT
>> started issuing an error rather than return success a with ROLLBACK tag.
>> Certainly SQL scripts would be fine. They would have one additional
>> error in the script output,
Hi,
On 2020-03-30 15:23:08 -0400, Robert Haas wrote:
> On Mon, Mar 30, 2020 at 2:59 PM Andres Freund wrote:
> > I wonder if it'd not be best, independent of whether we build in this
> > verification, to include that metadata in the manifest file. That's for
> > sure better than having to build a
"osumi.takami...@fujitsu.com" writes:
> Also, I'm waiting for other kind of feedbacks from anyone.
As David pointed out, this needs to be rebased, though it looks like
the conflict is pretty trivial.
A few other notes from a quick look:
* You missed updating equalfuncs.c/copyfuncs.c. Pretty mu
On 30.03.2020 21:00, Tom Lane wrote:
Hence, new patch versions that do it like that. (0002 is unchanged.)
I tried to simplify a bit loops in checkCond() by merging two of them into
one with an explicit exit condition. Also I added return statement after
this loop, so it's now clear that we c
Nikita Glukhov writes:
> On 30.03.2020 21:00, Tom Lane wrote:
>> Hence, new patch versions that do it like that. (0002 is unchanged.)
> I tried to simplify a bit loops in checkCond() by merging two of them into
> one with an explicit exit condition. Also I added return statement after
> this lo
Em seg., 30 de mar. de 2020 às 18:14, Andres Freund
escreveu:
> Hi,
>
> On 2020-03-30 14:10:29 -0700, Andres Freund wrote:
> > On 2020-03-30 17:08:01 -0300, Ranier Vilela wrote:
> > > Em seg., 30 de mar. de 2020 às 16:05, Andres Freund <
> and...@anarazel.de>
> > > escreveu:
> > >
> > > > Hi,
> >
I wrote:
> I dunno, that doesn't really seem clearer to me (although some of it
> might be that you expended no effort on making the comments match
> the new code logic).
... although looking closer, this formulation does have one very nice
advantage: for the typical non-star case with high = low
On 31.03.2020 1:12, Tom Lane wrote:
I wrote:
I dunno, that doesn't really seem clearer to me (although some of it
might be that you expended no effort on making the comments match
the new code logic).
... although looking closer, this formulation does have one very nice
advantage: for the typi
Nikita Glukhov writes:
> And we even can simply transform this tail call into a loop:
> -if (tlen > 0 && qlen > 0)
> +while (tlen > 0 && qlen > 0)
Yeah, the same occurred to me ... and then we can drop the other loop too.
I've got it down to this now:
/*
* Try to match an lquery (of qlen items
On 31.03.2020 1:35, Tom Lane wrote:
Nikita Glukhov writes:
And we even can simply transform this tail call into a loop:
-if (tlen > 0 && qlen > 0)
+while (tlen > 0 && qlen > 0)
Yeah, the same occurred to me ... and then we can drop the other loop too.
I think now it looks as simple as the
On 3/30/20 5:08 PM, Andres Freund wrote:
The data in the backup label isn't sufficient though. Without having
parsed the timeline file there's no way to verify that the correct WAL
is present. I guess we can also add client side tools to parse
timelines, add command the fetch all of the required
Nikita Glukhov writes:
> I think now it looks as simple as the whole algorithm is.
Yeah, I think we've gotten checkCond to the point of "there's no
longer anything to take away".
I've marked this RFC, and will push tomorrow unless somebody wants
to object to the loss of backwards compatibility.
I rebased this patch; it's failing to apply due to minor concurrent
changes in PostgresNode.pm. I squashed the patches in a series that
made the most sense to me.
I have a question about static variable lastFoundOldestSeg in
FindOldestXLogFileSegNo. It may be set the first time the function
runs
On 3/30/20 4:16 PM, Robert Haas wrote:
On Fri, Mar 27, 2020 at 3:51 PM David Steele wrote:
> { "Path": "backup_label", "Size": 224, "Last-Modified": "2020-03-27
18:33:18 GMT", "Checksum-Algorithm": "CRC32C", "Checksum": "b914bec9" },
Storing the checksum type with each file seems pretty red
Hi,
On 2020-03-24 18:18:12 +0900, Kyotaro Horiguchi wrote:
> At Mon, 23 Mar 2020 20:56:59 +, Teja Mupparti
> wrote in
> > The original bug reporting-email and the relevant discussion is here
> ...
> > The crux of the fix is, in the current code, engine drops the buffer and
> > then truncat
Hi
I had a look on kms_v9 patch and have some comments
--> pg_upgrade.c
keys are copied correctly, but as pg_upgrade progresses further, it will try to
start the new_cluster from "issue_warnings_and_set_wal_level()" function, which
is called after key copy. The new cluster will fail to start
On Mon, Mar 30, 2020 at 06:53:47PM -0400, James Coleman wrote:
On Mon, Mar 30, 2020 at 8:24 AM Tomas Vondra
wrote:
On Sun, Mar 29, 2020 at 10:16:53PM -0400, James Coleman wrote:
>On Sun, Mar 29, 2020 at 9:44 PM Tomas Vondra
> wrote:
>>
>> Hi,
>>
>> Attached is a slightly reorganized patch seri
On 2020/03/31 3:10, Andres Freund wrote:
Hi,
On 2020-03-30 19:41:43 +0900, Fujii Masao wrote:
On 2020/03/30 16:58, Peter Eisentraut wrote:
Improve handling of parameter differences in physical replication
When certain parameters are changed on a physical replication primary,
this is commun
On Wed, Jan 29, 2020 at 12:15:59PM +0100, Julien Rouhaud wrote:
> Rebase due to conflict with 3ec20c7091e97.
This is failing to apply probably since
4a539a25ebfc48329fd656a95f3c1eb2cda38af3.
Could you rebase? (Also, not sure if this can be set as RFC?)
--
Justin
Hi,
heapam_index_build_range_scan() has the following, long standing,
comment:
/*
* When dealing with a HOT-chain of updated tuples, we want to
index
* the values of the live tuple (if any), but index it under
the TID
* of the c
On Sun, 29 Mar 2020 at 20:50, Andy Fan wrote:
> Some other changes made in the new patch:
> 1. Fixed bug for UniqueKey calculation for OUTER join.
> 2. Fixed some typo error in comments.
> 3. Renamed the field "grantee" as "guarantee".
I've had a look over this patch. Thank for you doing fu
1 - 100 of 120 matches
Mail list logo
