On Sat, Apr 24, 2021 at 11:43 AM Michael Paquier wrote:
>
> On Fri, Apr 23, 2021 at 07:03:40AM +, wangyu...@fujitsu.com wrote:
> > Agree. Please see the v2 patch which delete the number in comment.
>
> Indeed, this set of comments became a bit obsolete after 1375422, as
> you saied upthread.
On Fri, Apr 23, 2021 at 07:03:40AM +, wangyu...@fujitsu.com wrote:
> Agree. Please see the v2 patch which delete the number in comment.
Indeed, this set of comments became a bit obsolete after 1375422, as
you saied upthread. This simplification looks fine to me, so
applied. I am in a mood fo
On Thu, Apr 22, 2021, at 19:32, Alvaro Herrera wrote:
> On 2021-Apr-22, Joel Jacobson wrote:
>
> > Is $SUBJECT intentional, or would it be desirable to add support it?
> >
> > Example:
> >
> > SELECT * FROM pg_catalog.pg_event_trigger;
> > oid|evtname|evtevent | evtowner
On Fri, Apr 23, 2021 at 08:10:01AM -0400, Andrew Dunstan wrote:
> Yeah, I think it's ok for comparison purposes just to lump them all
> together. Here's a patch that does that and some consequent cleanup.
> Note we now cache the string rather than trying to reconstruct it.
No objections from here
On Sat, Apr 24, 2021 at 10:50:21AM +0900, Michael Paquier wrote:
> On Fri, Apr 23, 2021 at 01:23:26PM -0500, Justin Pryzby wrote:
> > The patch seems to apply cleanly on v12 but cherry-pick needs help for other
> > branches...
>
> FWIW, this did not seem bad enough to me to require a back-patch.
>
On Fri, Apr 23, 2021 at 7:53 PM Andres Freund wrote:
> I mainly suggested it because to me the current seems hard to
> understand. I do think it'd be better to check more often. But checking
> depending on the amount of dead tuples at the right time doesn't strike
> me as a good idea - a lot of an
On Fri, Apr 23, 2021 at 6:45 PM Tom Lane wrote:
>
> Greg Nancarrow writes:
> > I'm curious. The FmgrBuiltin struct includes the "strict" flag, so
> > that would "lock down the value" of the strict flag, wouldn't it?
>
> It does, but that's much more directly a property of the function's
> C code
Hi,
On 2021-04-23 19:42:30 -0700, Peter Geoghegan wrote:
> On Fri, Apr 23, 2021 at 7:33 PM Andres Freund wrote:
> > Check it every so often, independent of whether there are indexes or
> > dead tuples? Or just check it at the boundaries.
>
> I think that the former suggestion might be better -- I
On Fri, Apr 23, 2021 at 7:33 PM Andres Freund wrote:
> Check it every so often, independent of whether there are indexes or
> dead tuples? Or just check it at the boundaries.
I think that the former suggestion might be better -- I actually
thought about doing it that way myself.
The latter sugge
Hi,
On 2021-04-23 19:15:43 -0700, Peter Geoghegan wrote:
> > The failsafe mode affects the table scan itself by disabling cost
> > limiting. As far as I can see the ways it triggers for the table scan (vs
> > truncation or index processing) are:
> >
> > 1) Before vacuuming starts, for heap phases
On Fri, Apr 23, 2021 at 5:29 PM Andres Freund wrote:
> On 2021-04-23 16:12:33 -0700, Peter Geoghegan wrote:
> > The only reason that I chose 4GB for FAILSAFE_MIN_PAGES is because the
> > related VACUUM_FSM_EVERY_PAGES constant was 8GB -- the latter limits
> > how often we'll consider the failsafe
On Fri, Apr 23, 2021 at 01:23:26PM -0500, Justin Pryzby wrote:
> The patch seems to apply cleanly on v12 but cherry-pick needs help for other
> branches...
FWIW, this did not seem bad enough to me to require a back-patch.
This parameter got introduced in 2016 and this was the only report
related t
On Fri, Apr 23, 2021 at 01:43:38PM -0500, Justin Pryzby wrote:
> More fixes like the one Peter committed as 9bd563aa9.
> I eyeballed the HTML to make sure this looks right.
- Conflicting Lock Modes
+ Conflicting Lock Modes
That's a nice regex-fu here to detect cases like this one.
Thanks
Hi,
On 2021-04-23 19:28:27 -0500, Justin Pryzby wrote:
> This (combination of) thread(s) seems relevant.
>
> Subject: pg_upgrade failing for 200+ million Large Objects
> https://www.postgresql.org/message-id/flat/12601596dbbc4c01b86b4ac4d2bd4d48%40EX13D05UWC001.ant.amazon.com
> https://www.postgr
On Fri, Apr 23, 2021 at 02:18:10PM +0900, Kyotaro Horiguchi wrote:
> AFAICS it fixes the all remaining LSN parameters.
Thanks for double-checking. I was not sure if I got all of them or
not. Applied that now as of 4aba61b.
--
Michael
signature.asc
Description: PGP signature
Hi,
On 2021-04-23 16:12:33 -0700, Peter Geoghegan wrote:
> The only reason that I chose 4GB for FAILSAFE_MIN_PAGES is because the
> related VACUUM_FSM_EVERY_PAGES constant was 8GB -- the latter limits
> how often we'll consider the failsafe in the single-pass/no-indexes
> case.
I don't really und
On Fri, Apr 23, 2021 at 04:42:56PM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-06-15 11:37:59 -0700, Noah Misch wrote:
> > On Tue, May 21, 2019 at 03:23:00PM -0700, Peter Geoghegan wrote:
> > > On Mon, May 20, 2019 at 3:10 AM Jason Harvey wrote:
> > > > This week I upgraded one of my large(2.8T
Hi,
On 2019-06-15 11:37:59 -0700, Noah Misch wrote:
> On Tue, May 21, 2019 at 03:23:00PM -0700, Peter Geoghegan wrote:
> > On Mon, May 20, 2019 at 3:10 AM Jason Harvey wrote:
> > > This week I upgraded one of my large(2.8TB), high-volume databases from 9
> > > to 11. The upgrade itself went fine
On 2021-Apr-23, Alvaro Herrera wrote:
> I think the patch I posted was too simple. I think a real fix requires
> us to keep track of exactly in what way the partdesc is outdated, so
> that we can compare to the current situation in deciding to use that
> partdesc or build a new one. For example,
Hi,
On 2021-04-23 18:08:12 -0500, Justin Pryzby wrote:
> On Fri, Apr 23, 2021 at 01:43:06PM -0700, Andres Freund wrote:
> > 2) FAILSAFE_MIN_PAGES is 4GB - which seems to make it infeasible to test the
> >failsafe mode, we can't really create 4GB relations on the BF. While
> >writing the te
On Fri, Apr 23, 2021 at 1:43 PM Andres Freund wrote:
> I started to write a test for $Subject, which I think we sorely need.
+1
> Currently my approach is to:
> - start a cluster, create a few tables with test data
> - acquire SHARE UPDATE EXCLUSIVE in a prepared transaction, to prevent
> auto
On Fri, Apr 23, 2021 at 01:43:06PM -0700, Andres Freund wrote:
> 2) FAILSAFE_MIN_PAGES is 4GB - which seems to make it infeasible to test the
>failsafe mode, we can't really create 4GB relations on the BF. While
>writing the tests I've lowered this to 4MB...
> For 2), I don't really have a
On Wed, Apr 21, 2021 at 10:10 PM Bharath Rupireddy
wrote:
> In the PageGetItemIdCareful() introduced by commit a9ce839a, it seems
> like we are using btree page pd_special structure BTPageOpaqueData for
> error case without max aligning it.
> if (ItemIdGetOffset(itemid) + ItemIdGetLength(itemi
> On Apr 23, 2021, at 1:31 PM, Robert Haas wrote:
>
> Perhaps something like this, closer to the way you had it?
>
> expected_size = chunk_seq < last_chunk_seq ? TOAST_MAX_CHUNK_SIZE
> : extsize - (last_chunk_seq * TOAST_MAX_CHUNK_SIZE);
It still suffers the same failures
Hi,
I started to write a test for $Subject, which I think we sorely need.
Currently my approach is to:
- start a cluster, create a few tables with test data
- acquire SHARE UPDATE EXCLUSIVE in a prepared transaction, to prevent
autovacuum from doing anything
- cause dead tuples to exist
- resta
On Fri, Apr 23, 2021 at 2:36 PM Mark Dilger
wrote:
> > What's different?
>
> for one thing, if a sequence of chunks happens to fit perfectly, the final
> chunk will have size TOAST_MAX_CHUNK_SIZE, but you're expecting no larger
> than one less than that, given how modulo arithmetic works.
Good
On Thu, Apr 22, 2021 at 1:01 PM Andres Freund wrote:
> The gin case seems a bit easier than the partial index case. Keeping
> stats about the number of new entries in a GIN index doesn't seem too
> hard, nor does tracking the number of cleaned up index entries. But
> knowing which indexes are affe
On Fri, Apr 23, 2021 at 8:44 AM Robert Haas wrote:
> On Thu, Apr 22, 2021 at 4:52 PM Peter Geoghegan wrote:
> > Mostly what I'm saying is that I would like to put together a rough
> > list of things that we could do to improve VACUUM along the lines
> > we've discussed -- all of which stem from $
More fixes like the one Peter committed as 9bd563aa9.
I eyeballed the HTML to make sure this looks right.
>From a8b782cde7c5d6eef1e3876636feb652bc5f3711 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Thu, 22 Apr 2021 21:10:49 -0500
Subject: [PATCH] Remove extraneous whitespace in tags
git gr
> On Apr 23, 2021, at 11:29 AM, Robert Haas wrote:
>
> + expected_size = chunk_seq < last_chunk_seq ? TOAST_MAX_CHUNK_SIZE
> + : extsize % TOAST_MAX_CHUNK_SIZE;
>
> What's different?
for one thing, if a sequence of chunks happens to fit perfectly, the final
chunk will ha
> On Apr 23, 2021, at 11:29 AM, Robert Haas wrote:
>
> On Fri, Apr 23, 2021 at 2:15 PM Mark Dilger
> wrote:
>> Another difference I should probably mention is that a bunch of unrelated
>> tests are failing with errors like:
>>
>>toast value 13465 chunk 0 has size 1995, but expected size
On Fri, Apr 23, 2021 at 2:15 PM Mark Dilger
wrote:
> Another difference I should probably mention is that a bunch of unrelated
> tests are failing with errors like:
>
> toast value 13465 chunk 0 has size 1995, but expected size 1996
>
> which leads me to suspect your changes to how the size i
On Wed, Apr 14, 2021 at 03:57:21PM +0900, Michael Paquier wrote:
> On Tue, Apr 13, 2021 at 07:31:39AM -0500, Justin Pryzby wrote:
> > Good point.
>
> Thanks. I have used the wording that Tom has proposed upthread, added
> one GUC_NOT_IN_SAMPLE that you forgot, and applied the
> force_parallel_mod
> On Apr 23, 2021, at 11:05 AM, Mark Dilger
> wrote:
>
> Here are the differences between master and you patch:
Another difference I should probably mention is that a bunch of unrelated tests
are failing with errors like:
toast value 13465 chunk 0 has size 1995, but expected size 1996
On Fri, Apr 23, 2021 at 2:05 PM Mark Dilger
wrote:
> Here are the differences between master and you patch:
Thanks. Those messages look reasonable to me.
--
Robert Haas
EDB: http://www.enterprisedb.com
> On Apr 23, 2021, at 10:31 AM, Mark Dilger
> wrote:
>
> I will test your patch and see what differs.
Here are the differences between master and you patch:
UPDATE $toastname SET chunk_seq = chunk_seq + 1000 WHERE chunk_id =
$value_id_to_corrupt
- qr/${header}toast v
On Thu, Apr 22, 2021 at 12:43:46PM -0500, Justin Pryzby wrote:
> Maybe the behavior should be documented, though. Actually, I thought the
> pre-existing (non)behavior of autoanalyze would've been documented, and we'd
> now update that. All I can find is this:
>
> https://www.postgresql.org/docs/
> On Apr 23, 2021, at 10:28 AM, Robert Haas wrote:
>
> On Thu, Apr 22, 2021 at 7:28 PM Mark Dilger
> wrote:
>> I have refactored the patch to address your other concerns. Breaking the
>> patch into multiple pieces didn't add any clarity, but refactoring portions
>> of it made things simple
On Thu, Apr 22, 2021 at 7:28 PM Mark Dilger
wrote:
> I have refactored the patch to address your other concerns. Breaking the
> patch into multiple pieces didn't add any clarity, but refactoring portions
> of it made things simpler to read, I think, so here it is as one patch file.
I was hopin
Hi,
On 2021-04-23 13:13:15 -0400, Tom Lane wrote:
> contrib/bloom is indeed the only(?) case within contrib, but in my mind
> that's a proxy for what people will be needing to test out-of-core AMs.
> It might not be a test to run by default, but there needs to be a way
> to do it.
Hm. My experien
Andres Freund writes:
> On 2021-04-23 11:53:35 -0400, Tom Lane wrote:
>> Yeah. I found out earlier that wal_consistency_checking=all is an
>> absolute PIG. Running the regression tests that way requires tens of
>> gigabytes of disk space, and a significant amount of time if your
>> disk is not v
On 2021-Apr-23, Amit Langote wrote:
> Back in the 1st session:
>
> end;
> insert into fk select generate_series(1, 1);
> INSERT 0 1
> Time: 47400.792 ms (00:47.401)
I guess I was wrong about that ... the example I tried didn't have 1000s
of partitions, and I used debug print-outs to show
Hi,
On 2021-04-23 11:53:35 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Hm. I wonder if running with wal_consistency_checking=all doesn't also
> > reduce coverage of some aspects of recovery, by increasing record sizes
> > etc.
>
> Yeah. I found out earlier that wal_consistency_checking=a
On 2021/04/23 19:56, Bharath Rupireddy wrote:
On Fri, Apr 23, 2021 at 1:39 PM Fujii Masao wrote:
+
+ Note that information about ONLY options specified
+ in the original TRUNCATE command is not passed to
I think it is not "information about", no? We just don't pass ONLY
option i
Robert Haas writes:
> On Fri, Apr 23, 2021 at 9:15 AM Tom Lane wrote:
>> Greg Nancarrow writes:
>>> I'm curious. The FmgrBuiltin struct includes the "strict" flag, so
>>> that would "lock down the value" of the strict flag, wouldn't it?
>> It does, but that's much more directly a property of th
Andres Freund writes:
> On 2021-04-23 17:37:48 +1200, Thomas Munro wrote:
>> We have automated tests for many specific replication and recovery
>> scenarios, but nothing that tests replay of a wide range of records.
> Yay.
+1
>> Add a new TAP test under src/test/recovery that runs the regressio
On Fri, Apr 23, 2021 at 9:15 AM Tom Lane wrote:
> Greg Nancarrow writes:
> > I'm curious. The FmgrBuiltin struct includes the "strict" flag, so
> > that would "lock down the value" of the strict flag, wouldn't it?
>
> It does, but that's much more directly a property of the function's
> C code th
On Thu, Apr 22, 2021 at 4:52 PM Peter Geoghegan wrote:
> Mostly what I'm saying is that I would like to put together a rough
> list of things that we could do to improve VACUUM along the lines
> we've discussed -- all of which stem from $SUBJECT. There are
> literally dozens of goals (some of whic
On Thu, Apr 22, 2021 at 4:51 PM houzj.f...@fujitsu.com
wrote:
>
> > BACKGROUND
> >
> >
> > We want to realize parallel INSERT SELECT in the following steps:
> > 1) INSERT + parallel SELECT
> > 2) Parallel INSERT + parallel SELECT
> >
> > Below are example u
On 4/23/21 1:37 AM, Thomas Munro wrote:
> Hi,
>
> We have automated tests for many specific replication and recovery
> scenarios, but nothing that tests replay of a wide range of records.
> People working on recovery code often use installcheck (presumably
> along with other custom tests) to exer
On Fri, Apr 23, 2021 at 7:04 AM Masahiko Sawada wrote:
> I think we can divide the TID fork into 16MB or 32MB chunks like WAL
> segment files so that we can easily remove old chunks. Regarding the
> efficient search part, I think we need to consider the case where the
> TID fork gets bigger than m
Hi,
On 2021-04-23 17:37:48 +1200, Thomas Munro wrote:
> We have automated tests for many specific replication and recovery
> scenarios, but nothing that tests replay of a wide range of records.
> People working on recovery code often use installcheck (presumably
> along with other custom tests) to
On Saturday, April 17, 2021 4:13 PM Amit Kapila wrote:
> On Sat, Apr 17, 2021 at 12:05 PM Japin Li wrote:
> >
> > On Sat, 17 Apr 2021 at 14:09, Amit Kapila
> wrote:
> > > On Thu, Apr 15, 2021 at 4:53 PM Amit Kapila
> wrote:
> > >>
> > >> On Thu, Apr 15, 2021 at 4:00 PM Japin Li wrote:
> > >> >
Bharath Rupireddy writes:
> I'm trying to test Postgres code for any unaligned memory accesses. I
> used a hack shown at [1] and put it in exec_simple_query, then I'm
> seeing a SIGBUS error from SplitIdentifierString's strncpy, see [2].
Regardless of Postgres' policy about alignment safety, glib
On Friday, April 23, 2021 6:03 PM I wrote:
> I've combined v5 with above accepted comments.
>
> Just in case, I've conducted make check-world, the test of
> clobber_cache_always mode again for v6 and tight loop test of 100 times for
> 010_truncate.pl.
> The result is that all passed with no failur
Ashutosh Bapat писал 2021-04-14 16:01:
On Tue, Apr 13, 2021 at 6:58 PM Alexander Pyhalov
wrote:
I believe step2 is needed to avoid materializing rows which will never
be selected. That would be a good improvement. However, care needs to
be taken for volatile quals. I think, the quals on CTE w
Greg Nancarrow writes:
> I'm curious. The FmgrBuiltin struct includes the "strict" flag, so
> that would "lock down the value" of the strict flag, wouldn't it?
It does, but that's much more directly a property of the function's
C code than parallel-safety is.
regards, tom
On 05.12.20 03:22, Michael Paquier wrote:
On Fri, Dec 04, 2020 at 02:34:26PM +0100, Peter Eisentraut wrote:
On 2020-12-02 15:04, Alvaro Herrera wrote:
I do wonder if it'd be a good idea to move the syscall
name itself out of the message, too; that would reduce the number of
messages to translat
On Thu, Apr 22, 2021 at 1:45 PM Michael Paquier wrote:
> On Wed, Apr 21, 2021 at 09:58:10PM +0900, Amit Langote wrote:
> > Okay, done.
>
> So, I have been working on that today, and tried to apply the full set
> before realizing when writing the commit message that this was a set
> of bullet point
On 4/23/21 12:41 AM, Michael Paquier wrote:
> On Thu, Apr 22, 2021 at 08:43:10PM -0400, Andrew Dunstan wrote:
>> Interesting point. Maybe we need to do something like devel = -4, alpha
>> = -3, beta = -2, rc = -1. Or maybe that's overkill.
> And after that it would come to how many betas, alphas o
On Fri, Apr 23, 2021 at 3:47 AM Robert Haas wrote:
>
> On Thu, Apr 22, 2021 at 10:28 AM Masahiko Sawada
> wrote:
> > The dead TID fork needs to also be efficiently searched. If the heap
> > scan runs twice, the collected dead TIDs on each heap pass could be
> > overlapped. But we would not be ab
On Fri, Apr 23, 2021 at 1:39 PM Fujii Masao wrote:
> > +
> > + Note that information about ONLY options specified
> > + in the original TRUNCATE command is not passed to
> >
> > I think it is not "information about", no? We just don't pass ONLY
> > option instead we skip it. IMO, we c
On Sat, 17 Apr 2021 at 01:05, Peter Geoghegan wrote:
>
> On Fri, Apr 16, 2021 at 2:20 PM Matthias van de Meent
> wrote:
> > > Interesting approach. I think that in an ideal world we would have a
> > > tuple format with attribute lengths/offsets right in the header.
> >
> > I believe that that wou
On 2021/04/23 19:11, Magnus Hagander wrote:
On Fri, Apr 23, 2021 at 12:04 PM Fujii Masao
wrote:
On 2021/04/23 18:46, Magnus Hagander wrote:
On Fri, Apr 23, 2021 at 9:10 AM Fujii Masao wrote:
On 2021/04/22 18:23, Julien Rouhaud wrote:
On Thu, Apr 22, 2021 at 12:28:11AM +0900, Fujii
Hi,
I'm trying to test Postgres code for any unaligned memory accesses. I
used a hack shown at [1] and put it in exec_simple_query, then I'm
seeing a SIGBUS error from SplitIdentifierString's strncpy, see [2].
It looks like the SIGBUS error occurs even if a simple memcpy(for
testing purpose) is do
Hi Aleksander!
Thanks for looking into this.
> 23 апр. 2021 г., в 14:30, Aleksander Alekseev
> написал(а):
>
> Hi hackers,
>
After using a patch for a while it became obvious that PANICing during
termination is not a good idea. Even when we wait for synchronous
replication. I
On 2021/04/23 18:46, Magnus Hagander wrote:
On Fri, Apr 23, 2021 at 9:10 AM Fujii Masao wrote:
On 2021/04/22 18:23, Julien Rouhaud wrote:
On Thu, Apr 22, 2021 at 12:28:11AM +0900, Fujii Masao wrote:
I found another small issue in pg_stat_statements docs. The following
description in th
On Fri, Apr 23, 2021 at 12:04 PM Fujii Masao
wrote:
>
>
>
> On 2021/04/23 18:46, Magnus Hagander wrote:
> > On Fri, Apr 23, 2021 at 9:10 AM Fujii Masao
> > wrote:
> >>
> >>
> >>
> >> On 2021/04/22 18:23, Julien Rouhaud wrote:
> >>> On Thu, Apr 22, 2021 at 12:28:11AM +0900, Fujii Masao wrote:
> >
On Wed, Apr 21, 2021 at 7:04 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Wed, Apr 21, 2021 at 8:12 AM tsunakawa.ta...@fujitsu.com
> > wrote:
> >> From: Tom Lane
> >>> [ raised eyebrow... ] I find it very hard to understand why that would
> >>> be necessary, or even a good idea.
>
> > IIU
On Fri, Apr 23, 2021 at 9:10 AM Fujii Masao wrote:
>
>
>
> On 2021/04/22 18:23, Julien Rouhaud wrote:
> > On Thu, Apr 22, 2021 at 12:28:11AM +0900, Fujii Masao wrote:
> >>
> >> I found another small issue in pg_stat_statements docs. The following
> >> description in the docs should be updated so t
On Fri, Apr 23, 2021 at 4:26 AM Alvaro Herrera wrote:
> On 2021-Apr-22, Amit Langote wrote:
> > -* The reason for this check is that we want to avoid seeing the
> > +* The reason for this hack is that we want to avoid seeing the
> > * partition as alive in RI queries durin
Hi hackers,
> >> After using a patch for a while it became obvious that PANICing during
> >> termination is not a good idea. Even when we wait for synchronous
> >> replication. It generates undesired coredumps.
> >> I think in presence of SIGTERM it's reasonable to say that we cannot
> >> prote
On Mon, Apr 19, 2021 at 4:28 PM vignesh C wrote:
>
> I have made the changes to update the replication statistics at
> replication slot release. Please find the patch attached for the same.
> Thoughts?
>
Thanks, the changes look mostly good to me. The slot stats need to be
initialized in RestoreS
On Friday, April 23, 2021 3:43 PM Amit Kapila wrote:
> On Fri, Apr 23, 2021 at 12:04 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > On Thursday, April 22, 2021 6:33 PM Amit Kapila
> wrote:
> > > On Tue, Apr 20, 2021 at 9:00 AM osumi.takami...@fujitsu.com
> > > wrote:
> > > >
> > > > On Tuesd
>
>
> Yeah, that's what I was thinking as well -- dumping snapshot at
> regular intervals, so that on crash recovery we lose a "controlled
> amount" of recent starts instead of losing *everything*.
>
> I think in most situations a fairly long interval is OK -- if you have
> tables that take so many
On Fri, 2021-04-23 at 14:44 +0900, Kyotaro Horiguchi wrote:
> > The two examples I know of offhand are in German (eszett "ß" downcases to
> > "ss") and Turkish (dotted "Í" downcases to "i", likewise dotless "I"
>
> According to Wikipedia, "ss" is equivalent to "ß" and their upper case
> letters ar
On Fri, Apr 23, 2021 at 12:41 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-04-21 14:38:44 +0200, Magnus Hagander wrote:
> > Andres mentioned at least once over in the thread about shared memory
> > stats collection that being able to have persistent stats could come
> > out of that one in the futur
On 2021/04/22 20:27, Bharath Rupireddy wrote:
On Thu, Apr 22, 2021 at 12:06 PM Fujii Masao
wrote:
On 2021/04/22 9:39, Bharath Rupireddy wrote:
One comment on truncate_foreign_table_docs_v1.patch:
1) I think it is "to be truncated"
+ rels is a list of Relation
+ data structures for ea
On 2021/04/22 17:56, Justin Pryzby wrote:
On Thu, Apr 22, 2021 at 03:36:25PM +0900, Fujii Masao wrote:
diff --git a/doc/src/sgml/fdwhandler.sgml b/doc/src/sgml/fdwhandler.sgml
index 553524553b..69aa66e73e 100644
--- a/doc/src/sgml/fdwhandler.sgml
+++ b/doc/src/sgml/fdwhandler.sgml
@@ -1076,27
On Fri, Apr 23, 2021 at 6:27 PM tsunakawa.ta...@fujitsu.com
wrote:
> From: Thomas Munro
> > I'm not quite sure where it belongs, though. The attached initial sketch
> > patch
>
> I think that's a good attempt. It'd be better to confirm that the database
> contents are identical on the primary
On Wed, Apr 21, 2021 at 12:22 PM Tom Lane wrote:
>
> "tsunakawa.ta...@fujitsu.com" writes:
> > From: Tom Lane
> >> No. You'd have to be superuser anyway to do that, and we're not in the
> >> habit of trying to put training wheels on superusers.
>
> > Understood. However, we may add the paralle
On Fri, Apr 23, 2021, at 09:30, Joel Jacobson wrote:
> fix-pg_identify_object_as_address-for-event-triggers.patch
Also, since this is a problem also in v13 maybe this should also be back-ported?
I think it's a bug since both pg_identify_object_as_address() and event
triggers exists in v13,
so the
On Fri, Apr 23, 2021, at 08:54, Joel Jacobson wrote:
> pg_describe_object| event trigger ddl_postgrest
> pg_identify_object| ("event trigger",,ddl_postgrest,ddl_postgrest)
> pg_identify_object_as_address | ("event trigger",{},{})
>
> I therefore think the evtname should be
On 22.04.21 11:16, Justin Pryzby wrote:
It looks like we all missed that I misspelled "date_bin" as
"date_trunc"...sorry. I will include this with my next round of doc review, in
case you don't want to make a separate commit for it.
fixed
On 2021/04/23 10:25, Andres Freund wrote:
Hi,
On 2021-04-23 09:26:17 +0900, Masahiro Ikeda wrote:
On 2021/04/23 0:36, Andres Freund wrote:
On Thu, Apr 22, 2021, at 06:42, Fujii Masao wrote:
On 2021/04/21 18:31, Masahiro Ikeda wrote:
BTW, is it better to change PgStat_Counter from int64 to
On 2021/04/22 18:23, Julien Rouhaud wrote:
On Thu, Apr 22, 2021 at 12:28:11AM +0900, Fujii Masao wrote:
I found another small issue in pg_stat_statements docs. The following
description in the docs should be updated so that toplevel is included?
This view contains one row for each distinct
Hi, Amul
Thank you for reviewing.
> How about simply removing these numbering?
Agree. Please see the v2 patch which delete the number in comment.
Best wishes
Yukun Wang
-Original Message-
From: Amul Sul
Sent: Friday, April 23, 2021 3:51 PM
To: Wang, Yukun/王 俞坤
Cc: pgsql-hack...@post
87 matches
Mail list logo
