On Tue, May 12, 2020 at 4:39 PM Amit Kapila wrote:
>
> On Thu, May 7, 2020 at 6:17 PM Dilip Kumar wrote:
> >
> > On Tue, May 5, 2020 at 7:13 PM Dilip Kumar wrote:
> >
> > I have fixed one more issue in 0010 patch. The issue was that once
> > the transaction is serialized due to the incomplete t
On Tuesday, May 12, 2020, Michael Paquier wrote:
> On Tue, May 12, 2020 at 06:48:51PM -0700, David G. Johnston wrote:
> > Whether its a style thing, or some requirement of the C-language, I found
> > it odd that the four nearly identical checks were left inline in the
> > functions instead of bei
Hello Bruce,
* e1ff780485
I was told in this email thread to not include that one.
Ok.
* 34a0a81bfb
We already have:
Reformat tables containing function information for better
clarity (Tom Lane)
so it seems it is covered as part of this.
AFAICR this one is not by
On Tue, May 12, 2020 at 06:48:51PM -0700, David G. Johnston wrote:
> Whether its a style thing, or some requirement of the C-language, I found
> it odd that the four nearly identical checks were left inline in the
> functions instead of being pulled out into a function. I've attached a
> conceptua
On Wed, May 13, 2020 at 6:15 AM Euler Taveira
wrote:
>
> On Tue, 12 May 2020 at 06:36, Masahiko Sawada
> wrote:
>>
>> On Mon, 11 May 2020 at 16:28, Michael Paquier wrote:
>> >
>> > On Sun, May 10, 2020 at 07:08:03PM -0300, Euler Taveira wrote:
>> > > I attached a patch with the described soluti
On 03/23/18 11:40, Alvaro Herrera wrote:
> Chapman Flack wrote:
>> ? Given a base backup and a bunch of WAL from a cluster that had
>> track_commit_timestamps turned off, is it possible (in principle?)
>> to do a PITR with the switch turned on, and have the commit_ts
>> cache get populated (a
Hi,
Did some performance testing by varying TAR_SEND_SIZE with Robert's
refactor patch and without the patch to check the impact.
Below are the details:
*Backup type*: local backup using pg_basebackup
*Data size*: Around 200GB (200 tables - each table around 1.05 GB)
*different TAR_SEND_SIZE val
On Tue, 2020-05-12 at 18:09 -0700, David G. Johnston wrote:
> Redirecting to -hackers for visibility. I feel there needs to be something
> done here, even if just documentation (a bullet in the usage notes section -
> and a code comment update for the macro)
> pointing this out and not changing
On Tue, May 12, 2020 at 9:54 PM Ashutosh Bapat
wrote:
> On Mon, May 11, 2020 at 8:11 PM Amit Langote wrote:
> > > Per row overhead would be incurred for every row whereas the plan time
> > > overhead is one-time or in case of a prepared statement almost free.
> > > So we need to compare it esp. w
On Wed, May 13, 2020 at 1:56 AM Robert Haas wrote:
>
> On Tue, May 12, 2020 at 4:32 AM Dilip Kumar wrote:
> > Some of the bbsink_libpq_* functions are directly calling pq_* e.g.
> > bbsink_libpq_begin_backup whereas others are calling SendCopy*
> > functions and therein those are calling pq_* fun
On Tue, May 12, 2020 at 7:07 PM Mark Dilger
wrote:
> Thank you yet again for reviewing. I really appreciate the feedback!
Happy to help. It's important work.
> Ok, I take your point that the code cannot soldier on after the first error
> is returned. I'll change that for v6 of the patch, movi
At Tue, 12 May 2020 16:38:09 -0400, Bruce Momjian wrote in
> On Tue, May 12, 2020 at 01:09:08PM +0900, Kyotaro Horiguchi wrote:
> > > > commit c6b9204
> > > > Author: Noah Misch
> > > > AuthorDate: Sat Apr 4 12:25:34 2020 -0700
> > > > Commit: Noah Misch
> > > > CommitDate: Sat Apr 4 12
Isaac Morland writes:
> ... I'm wondering because it seems
> like it might be helpful to have a system view which gives all the wait
> event types, names, and descriptions. Maybe even add a column for which
> extension (or core) it came from. The documentation could then just explain
> the genera
Thomas Munro writes:
> On Wed, May 13, 2020 at 3:16 AM Tom Lane wrote:
>> Hash/Batch/Allocating
>> Hash/Batch/Electing
>> Hash/Batch/Loading
>> Hash/GrowBatches/Allocating
> Perhaps we should also drop the 'ing' from the verbs, to be more like
> ...Read etc.
Yeah, that aspect was bothering me t
On Wed, May 13, 2020 at 3:16 AM Tom Lane wrote:
> And then somebody else, unwilling to use either of those styles,
> thought it would be cute to do
>
> Hash/Batch/Allocating
> Hash/Batch/Electing
> Hash/Batch/Loading
> Hash/GrowBatches/Allocating
Perhaps we should
At Tue, 12 May 2020 15:50:35 -0400, Tom Lane wrote in
> I happened to come across this code added by 28cac71bd:
>
> static PgStat_MsgSLRU *
> slru_entry(SlruCtl ctl)
> {
> intidx = pgstat_slru_index(ctl->shared->lwlock_tranche_name);
>
> Assert((idx >= 0) && (idx < SLRU_NUM_ELEM
On Wed, May 13, 2020 at 1:54 AM Robert Haas wrote:
>
> On Tue, May 12, 2020 at 2:23 AM Amit Kapila wrote:
> > While looking at this, I noticed that caller (perform_base_backup) of
> > do_pg_start_backup, sets the backup phase as
> > PROGRESS_BASEBACKUP_PHASE_WAIT_CHECKPOINT whereas, in
> > do_pg_
> On May 12, 2020, at 5:34 PM, Peter Geoghegan wrote:
>
> On Mon, May 11, 2020 at 10:21 AM Mark Dilger
> wrote:
>> 2) amcheck's btree checking functions have been refactored to be able to
>> operate in two modes; the original mode in which all errors are reported via
>> ereport, and a new m
On Mon, May 11, 2020 at 11:30 PM Michael Paquier
wrote:
> The second point about the check with (!currentEventTriggerState) in
> EventTriggerTableRewrite() and EventTriggerDDLCommandEnd() shows that
> both comments share the same first sentence, but there is enough
> different context to just kee
On Tue, 12 May 2020 at 18:11, Tom Lane wrote:
> Alvaro Herrera writes:
> > (Didn't we have a patch to generate the table programmatically?)
>
> Having now looked around a bit at where the names come from, I think
> such a patch would be impossible as things stand, which is a pity
> because as-th
Redirecting to -hackers for visibility. I feel there needs to be something
done here, even if just documentation (a bullet in the usage notes section
- and a code comment update for the macro) pointing this out and not
changing any behavior.
David J.
On Wed, May 6, 2020 at 8:12 PM David G. Johns
On Tue, 12 May 2020 at 06:36, Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
> On Mon, 11 May 2020 at 16:28, Michael Paquier wrote:
> >
> > On Sun, May 10, 2020 at 07:08:03PM -0300, Euler Taveira wrote:
> > > I attached a patch with the described solution. I also included a test
> that
On Mon, May 11, 2020 at 10:21 AM Mark Dilger
wrote:
> 2) amcheck's btree checking functions have been refactored to be able to
> operate in two modes; the original mode in which all errors are reported via
> ereport, and a new mode for returning errors as rows from a set returning
> function.
On 2020-May-12, Kyotaro Horiguchi wrote:
> I'm not sure the reason for wal_segment_open and WalSndSegmentOpen
> being modified different way about error handling of BasicOpenFile, I
> prefer the WalSndSegmentOpen way. However, that difference doesn't
> harm anything so I'm fine with the current p
On Wed, 13 May 2020 at 00:54, Ashutosh Bapat
wrote:
>
> On Mon, May 11, 2020 at 8:11 PM Amit Langote wrote:
> > > Per row overhead would be incurred for every row whereas the plan time
> > > overhead is one-time or in case of a prepared statement almost free.
> > > So we need to compare it esp. w
For the specific category of the heavyweight lock types, I'm
now thinking that we can't change the event names very much, because
those are also exposed in pg_locks' locktype column. We can be
darn certain, for example, that changing the spelling of "relation"
in that column would break a lot of u
Alvaro Herrera writes:
> (Didn't we have a patch to generate the table programmatically?)
Having now looked around a bit at where the names come from, I think
such a patch would be impossible as things stand, which is a pity
because as-things-stand is a totally unmaintainable situation.
Anybody a
On Tue, 12 May 2020 at 21:00, Tom Lane wrote:
> Simon Riggs writes:
> > On Tue, 12 May 2020 at 19:11, Tom Lane wrote:
> >> Anyway, I was just throwing this idea out to see if there would be
> >> howls of "you can't rename anything" anguish. Since there haven't
> >> been so far, I'll spend a bi
Robert Haas writes:
> On Tue, May 12, 2020 at 4:00 PM Tom Lane wrote:
>> Said user-facing documentation largely fails to explain that the
>> set of wait events can be enlarged by extensions; that needs to
>> be fixed, too.
> Is that true? How can they do that? I thought they were stuck with
> PG
On Tue, May 12, 2020 at 01:47:38PM -0400, Alvaro Herrera wrote:
> On 2020-May-07, Bruce Momjian wrote:
>
> > OK, I have moved her name to be first. FYI, this commit was backpatched
> > back through PG 11, though the commit message doesn't mention that.
>
> At some point I became an avid user of
On Tue, May 12, 2020 at 09:43:10AM +0200, Fabien COELHO wrote:
>
> Hello Bruce,
>
> > OK, section and item added, patch attached,
>
> Thanks!
>
> Some items that might be considered for the added documentation section:
>
> * e1ff780485
I was told in this email thread to not include that one.
Alvaro Herrera writes:
> Fixed one straggler in contrib, and while testing it I realized why
> ccache doesn't pay attention to the changes I was doing in the file:
> ccache compares the *preprocessed* version of the file and only if that
> differs from the version that was cached last, ccache send
Alvaro Herrera writes:
> I ended up using level 4 and dialling back to 3 for zic.c only
> (different make trickery though).
Meh ... if we're going to use level 4, I'm inclined to just change zic.c
to match. It's not like we're using the upstream code verbatim anyway.
We could easily add s/fallth
Robert Haas writes:
> On Tue, May 12, 2020 at 11:16 AM Tom Lane wrote:
>> I've been trying to reformat table 27.4 (wait events) to fit
>> into PDF output, which has caused me to study its contents
>> more than I ever had before.
> That reminds me that it might be easier to maintain that table if
On Tue, May 12, 2020 at 01:09:08PM +0900, Kyotaro Horiguchi wrote:
> > > commit c6b9204
> > > Author: Noah Misch
> > > AuthorDate: Sat Apr 4 12:25:34 2020 -0700
> > > Commit: Noah Misch
> > > CommitDate: Sat Apr 4 12:25:34 2020 -0700
> > >
> > > Skip WAL for new relfilenodes, under w
On Tue, May 12, 2020 at 8:16 AM Tom Lane wrote:
> I'm not sure what our stance is on version-to-version consistency
> of these names, but I'd like to think that we are not stuck for
> all time with the results of these random coin tosses.
These names are fundamentally implementation details, and
On 2020-May-12, Robert Haas wrote:
> That reminds me that it might be easier to maintain that table if we
> broke it up into one table per major category - that is, one table for
> lwlocks, one table for IPC, one table for IO, etc. - instead of a
> single table with a row-span number that is large
On Tue, May 12, 2020 at 4:32 AM Dilip Kumar wrote:
> Some of the bbsink_libpq_* functions are directly calling pq_* e.g.
> bbsink_libpq_begin_backup whereas others are calling SendCopy*
> functions and therein those are calling pq_* functions. I think
> bbsink_libpq_* function can directly call p
On 2020-May-12, Alvaro Herrera wrote:
> I get no warnings with this (gcc 8), but ccache seems to save warnings
> in one run so that they can be thrown in a later one. I'm not sure what
> to make of that, but ccache -d proved that beyond reasonable doubt and
> ccache -clear got rid of the lot.
Fi
On Tue, May 12, 2020 at 2:23 AM Amit Kapila wrote:
> While looking at this, I noticed that caller (perform_base_backup) of
> do_pg_start_backup, sets the backup phase as
> PROGRESS_BASEBACKUP_PHASE_WAIT_CHECKPOINT whereas, in
> do_pg_start_backup, we do collect the information about all
> tablespa
On Mon, May 11, 2020 at 11:38:33PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, May 11, 2020 at 11:08:35PM -0400, Chapman Flack wrote:
> >> 'specify' ?
>
> > I like that word if Tom prefers it.
>
> 'specify' works for me.
Sure, done.
--
Bruce Momjian https://momjian.u
On Mon, May 11, 2020 at 10:48 PM Tom Lane wrote:
> I have a standing note to check the permissions on /cores after any macOS
> upgrade, because every so often Apple decides that that directory ought to
> be read-only.
Thanks, that was my problem.
--
Robert Haas
EnterpriseDB: http://www.enterpri
On 2020-May-11, Julien Rouhaud wrote:
> On Mon, May 11, 2020 at 4:40 PM Tom Lane wrote:
> >
> > Julien Rouhaud writes:
> > > On Mon, May 11, 2020 at 3:41 PM Tom Lane wrote:
> > >> Why? It uses "fallthrough" which is a legal spelling per level 4.
> >
> > > GCC documentation mentions [ \t]*FALLT
On Tue, May 12, 2020 at 11:16 AM Tom Lane wrote:
> I've been trying to reformat table 27.4 (wait events) to fit
> into PDF output, which has caused me to study its contents
> more than I ever had before.
That reminds me that it might be easier to maintain that table if we
broke it up into one tab
On Tue, May 12, 2020 at 4:00 PM Tom Lane wrote:
> Said user-facing documentation largely fails to explain that the
> set of wait events can be enlarged by extensions; that needs to
> be fixed, too.
Is that true? How can they do that? I thought they were stuck with
PG_WAIT_EXTENSION.
--
Robert H
> There are a lot of other things that seem inconsistent, but I'm not sure
> how much patience people would have for judgment-call renamings. An
> example is that "ProcSignalBarrier" is under IO, but why? Shouldn't it
> be reclassified as IPC?
Hmm, that seems like a goof.
> Other than that, *al
Simon Riggs writes:
> On Tue, 12 May 2020 at 19:11, Tom Lane wrote:
>> Anyway, I was just throwing this idea out to see if there would be
>> howls of "you can't rename anything" anguish. Since there haven't
>> been so far, I'll spend a bit more time and try to create a concrete
>> list of possib
I happened to come across this code added by 28cac71bd:
static PgStat_MsgSLRU *
slru_entry(SlruCtl ctl)
{
intidx = pgstat_slru_index(ctl->shared->lwlock_tranche_name);
Assert((idx >= 0) && (idx < SLRU_NUM_ELEMENTS));
return &SLRUStats[idx];
}
which is invoked by all the pgst
On Tue, 2020-05-12 at 11:50 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > On Mon, 2020-05-11 at 15:43 -0400, Robert Haas wrote:
> > > On Fri, May 8, 2020 at 4:58 AM Laurenz Albe
> > > wrote:
> > > > I happened to notice that COPY TO releases the ACCESS SHARE lock
> > > > on the table right w
On Tue, 12 May 2020 at 19:11, Tom Lane wrote:
> Anyway, I was just throwing this idea out to see if there would be
> howls of "you can't rename anything" anguish. Since there haven't
> been so far, I'll spend a bit more time and try to create a concrete
> list of possible changes.
>
If we add
On Sun, Mar 15, 2020 at 9:27 PM Thomas Munro wrote:
> On Tue, Mar 10, 2020 at 12:20 PM Thomas Munro wrote:
> > Here's a patch set to remove the spindle stuff, add a maintenance
> > variant, and use the maintenance one in
> > heap_compute_xid_horizon_for_tuples().
>
> Pushed.
Shouldn't you close
On Tue, May 12, 2020 at 11:18 AM Tomas Vondra
wrote:
> I've pushed both patches, fixing typos and explain format.
Thanks, Tomas.
--
Peter Geoghegan
On Sun, May 10, 2020 at 02:25:23PM +0200, Tomas Vondra wrote:
On Sat, May 09, 2020 at 06:48:02PM -0700, Peter Geoghegan wrote:
On Sat, May 9, 2020 at 3:19 PM Tomas Vondra
wrote:
I'm generally OK with most of this - I'd probably keep the single-line
format, but I don't feel very strongly about
"Andrey M. Borodin" writes:
> 3. I think names observed in wait_event and wait_event_type should not
> duplicate information. i.e. "XidGenLock" is already "LWLock".
Yeah, I'd been wondering about that too: we could strip the "Lock" suffix
from all the names in the LWLock category, and make pg_st
I would appreciate opinions from the patch authors on this ordering
change (rationale in previous email). I forgot to CC Sergei and Nikita.
> diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
> index 8dca6d8bb4..9bd0bf8356 100644
> --- a/src/bin/psql/describe.c
> +++ b/src/bin/psql
> 12 мая 2020 г., в 20:16, Tom Lane написал(а):
>
> Thoughts?
>
I've been coping with cognitive load of these names recently. 2 cents of my
impressions:
1. Names are somewhat recognisable and seem to have some meaning. But there is
not so much information about them in the Internet. But I
On 2020-May-07, Bruce Momjian wrote:
> OK, I have moved her name to be first. FYI, this commit was backpatched
> back through PG 11, though the commit message doesn't mention that.
At some point I became an avid user of our src/tools/git_changelog, and
then it stopped making sense for me to high
Fujii Masao writes:
> I just wonder why standbycheck regression test doesn't run by default
> in buildfarm. Which caused us not to notice this issue long time. Maybe
> because it's difficult to set up hot-standby environment in the
> regression test? If so, we might need to merge standbycheck test
Peter Geoghegan writes:
> On Mon, May 11, 2020 at 1:04 PM Tom Lane wrote:
>> Yeah. Traditionally we've waited till the start of the next commitfest
>> (which I'm assuming is July 1, for lack of an Ottawa dev meeting to decide
>> differently). But it seems like things are slow enough that perhap
On Mon, May 11, 2020 at 1:04 PM Tom Lane wrote:
> Yeah. Traditionally we've waited till the start of the next commitfest
> (which I'm assuming is July 1, for lack of an Ottawa dev meeting to decide
> differently). But it seems like things are slow enough that perhaps
> we could branch earlier, l
Laurenz Albe writes:
> On Mon, 2020-05-11 at 15:43 -0400, Robert Haas wrote:
>> On Fri, May 8, 2020 at 4:58 AM Laurenz Albe wrote:
>>> I happened to notice that COPY TO releases the ACCESS SHARE lock
>>> on the table right when the command ends rather than holding it
>>> until the end of the tran
On Mon, 2020-05-11 at 15:43 -0400, Robert Haas wrote:
> On Fri, May 8, 2020 at 4:58 AM Laurenz Albe wrote:
> > I happened to notice that COPY TO releases the ACCESS SHARE lock
> > on the table right when the command ends rather than holding it
> > until the end of the transaction:
>
> That seems
On Tue, May 12, 2020 at 11:16 AM Tom Lane wrote:
> My inclination is to propose that we settle on the first style
> shown above, which is the majority case now, and rename the
> other events to fit that. As long as we're breaking compatibility
> anyway, I'd also like to shorten one or two of the
I've been trying to reformat table 27.4 (wait events) to fit
into PDF output, which has caused me to study its contents
more than I ever had before. The lack of consistency, or
even any weak attempt at consistency, is not just glaring;
it's embarrassing.
We have a lot of wait event names like the
Amit Langote writes:
> On Tue, May 12, 2020 at 5:25 AM Robert Haas wrote:
>> Ah, that makes sense. If we can invent dummy columns on the parent
>> rel, then most of what I was worrying about no longer seems very
>> worrying.
> IIUC, the idea is to have "dummy" columns in the top parent's
> relta
Hi,
On 5/10/20 10:08 PM, Jonathan S. Katz wrote:
> Hi,
>
> Attached is a draft of the press release for the 2020-05-14 cumulative
> update. Please let me know your feedback by 2020-05-13 :)
Thank you for the feedback. As per usual, I applied some combination of
{all, some, none}.
Please see v2.
On Tue, May 12, 2020 at 5:25 AM Robert Haas wrote:
> On Mon, May 11, 2020 at 4:22 PM Tom Lane wrote:
> > Robert Haas writes:
> > > If the parent is RTI 1, and the children are RTIs 2..6, what
> > > varno/varattno will we use in RTI 1's tlist to represent a column that
> > > exists in both RTI 2
On Mon, May 11, 2020 at 8:11 PM Amit Langote wrote:
> > Per row overhead would be incurred for every row whereas the plan time
> > overhead is one-time or in case of a prepared statement almost free.
> > So we need to compare it esp. when there are 2000 partitions and all
> > of them are being upd
I was doing some memory testing under fractional CPU allocations and it became
painfully obvious that the repeat() function needs CHECK_FOR_INTERRUPTS().
I exchanged a few emails offlist with Tom about it, and (at the risk of putting
words in his mouth) he agreed and felt it was a candidate for ba
On Thu, May 7, 2020 at 6:17 PM Dilip Kumar wrote:
>
> On Tue, May 5, 2020 at 7:13 PM Dilip Kumar wrote:
>
> I have fixed one more issue in 0010 patch. The issue was that once
> the transaction is serialized due to the incomplete toast after
> streaming the serialized store was not cleaned up so
Rebased onto current master (fb544735f1).
--
Andrey Lepikhov
Postgres Professional
https://postgrespro.com
The Russian Postgres Company
>From 29183c42a8ae31b830ab5af0dfcfdaadd6229700 Mon Sep 17 00:00:00 2001
From: "Andrey V. Lepikhov"
Date: Tue, 12 May 2020 08:29:54 +0500
Subject: [PATCH 1/3] Gl
On Tue, May 12, 2020 at 3:36 AM Robert Haas wrote:
> On Sun, May 10, 2020 at 11:21 PM Andy Fan
> wrote:
> > Looks this doesn't mean a crash. If the test case(subscription/t/
> 013_partition.pl)
> > failed, test framework kill some process, which leads the above
> message. So you can
> > igno
On Mon, 11 May 2020 at 16:28, Michael Paquier wrote:
>
> On Sun, May 10, 2020 at 07:08:03PM -0300, Euler Taveira wrote:
> > I attached a patch with the described solution. I also included a test that
> > covers this scenario.
>
> - Assert(RelationGetReplicaIndex(rel) == RelationGetRelid(idxrel))
On Sat, May 9, 2020 at 2:23 AM Robert Haas wrote:
>
> Hi,
>
> I'd like to propose a fairly major refactoring of the server's
> basebackup.c. The current code isn't horrific or anything, but the
> base backup mechanism has grown quite a few features over the years
> and all of the code knows about
Hello Bruce,
OK, section and item added, patch attached,
Thanks!
Some items that might be considered for the added documentation section:
* e1ff780485
* 34a0a81bfb
* e829337d42
* "Document color support (Peter Eisentraut)"
THIS WAS NOT DOCUMENTED BEFORE?
Not as such, AFAICR it was
75 matches
Mail list logo
