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
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
>
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
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
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
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.
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_*
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,
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
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
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
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 <
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
> >
> 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
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
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
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.
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
>
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
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.
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
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
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
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
>
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
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
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
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
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
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
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
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.
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
>
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
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:
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 [
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
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
> 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,
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
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 [idx];
}
which is invoked by all the
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
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
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
> +++
> 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
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
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
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,
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
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
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
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
>
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
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
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
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]
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
> >
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) ==
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
On Mon, May 11, 2020 at 05:13:38PM -0700, David G. Johnston wrote:
> Skimming through the code in event_trigger.c and noticed that while most of
> the stanzas that reference IsUnderPostmaster refer back to the code comment
> beginning on line 675 the block for table rewrite copied it in
> verbatim
On Thu, May 7, 2020 at 9:44 PM Robert Haas wrote:
>
> On Wed, May 6, 2020 at 11:15 AM Robert Haas wrote:
> > Oh, good point. v2 attached.
>
While looking at this, I noticed that caller (perform_base_backup) of
do_pg_start_backup, sets the backup phase as
At Tue, 12 May 2020 14:45:22 +0900, Michael Paquier wrote
in
> On Mon, May 11, 2020 at 02:22:36PM +0900, Michael Paquier wrote:
> > Looks right to me, so will fix if there are no objections.
> > read_local_xlog_page() uses the replay location when in recovery.
>
> Done this part now.
Thanks!
On Tue, May 12, 2020 at 12:55:37PM +0900, Fujii Masao wrote:
> On 2020/05/12 9:42, Paul Guo wrote:
>> 1. StartupXLOG() does fsync on the whole data directory early in
>> the crash recovery. I'm wondering if we could skip some
>> directories (at least the pg_log/, table directories) since wal,
>>
78 matches
Mail list logo
