On Thu, Apr 22, 2021, at 19:32, Alvaro Herrera wrote:
> On 2021-Apr-22, Joel Jacobson wrote:
> > SELECT * FROM
> > pg_identify_object_as_address('pg_event_trigger'::regclass,289361636,0);
> > ERROR: requested object address for unsupported object class 32: text
> > result "ddl_postgrest"
>
> Hm
On 2021/04/22 13:25, Kyotaro Horiguchi wrote:
At Thu, 22 Apr 2021 13:06:50 +0900, Fujii Masao
wrote in
Either works for me. I didn't add "()" because I just used the same
description
as that in func.sgml.
it may be useful to run pg_switch_wal on the
primary in order to tr
On Fri, Apr 23, 2021 at 12:12 PM wangyu...@fujitsu.com
wrote:
>
> Hi, Hackers:
>
> In function ExecGetTriggerResultRel, we can see comments:
>
> > /* First, search through the query result relations */ ...
> > /*
> > * Third, search through the result relations that were created during
> > * tuple
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 Tuesday, April 20, 2021 10:53 AM Ajin Cherian
> > wrote:
> > > >
> > > > I
Hi, Hackers:
In function ExecGetTriggerResultRel, we can see comments:
> /* First, search through the query result relations */ ...
> /*
> * Third, search through the result relations that were created during
> * tuple routing, if any.
> */
But the 'Second' was deleted since commit 1375422c78.
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 Tuesday, April 20, 2021 10:53 AM Ajin Cherian
> wrote:
> > >
> > > I reviewed the patch, ran make check, no issues. One minor comment:
> > >
> > > Could you a
From: Thomas Munro
> 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 exercise it, sometimes with
> wal_
An earlier comment from Anders:
> We could e.g. have a new LogicalDecodingContext callback that is
> called whenever WalSndWaitForWal() would wait. That'd check if there's
> a pending "need" to send out a 'empty transaction'/feedback request
> message. The "need" flag would get cleared whenever we
On Mon, Apr 19, 2021 at 6:22 PM Peter Smith wrote:
>
> Here are a some review comments:
>
> --
>
> 1. The patch v3 applied OK but with whitespace warnings
>
> [postgres@CentOS7-x64 oss_postgres_2PC]$ git apply
>
> ../patches_misc/v3-0001-Skip-empty-transactions-for-logical-replication.patch
>
FWIW...
At Fri, 23 Apr 2021 00:17:35 -0400, Tom Lane wrote in
> Kyotaro Horiguchi writes:
> > At Thu, 22 Apr 2021 23:17:19 -0400, Tom Lane wrote in
> >> Doesn't seem like a good idea, because that locks us into an assumption
> >> that the downcasing conversion doesn't change the string's phys
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 exercise it, sometimes with
wal_consistency_check enabled
At Fri, 23 Apr 2021 13:54:15 +0900, Michael Paquier wrote
in
> Hi all,
>
> As $subject says, I noticed that while scanning the area. Any
> objections to make all that more consistent with the style of HEAD?
> Please see the attached.
AFAICS it fixes the all remaining LSN parameters.
regards.
At Fri, 23 Apr 2021 13:26:09 +0900, Michael Paquier wrote
in
> On Fri, Apr 23, 2021 at 09:43:09AM +0900, Kyotaro Horiguchi wrote:
> > At Thu, 22 Apr 2021 09:29:46 -0400, Tom Lane wrote in
> >> But what I thought Michael was griping about is the use of "int",
> >> which is a noise word here. E
Kyotaro Horiguchi writes:
> At Thu, 22 Apr 2021 12:44:28 +, "tanghy.f...@fujitsu.com"
> wrote in
>> When try to improve the tab compleation feature in [1], I found an existing
>> problem and a typo.
>> The patch was attached, please kindly to take a look at it. Thanks.
> That doesn't matt
Michael Paquier writes:
> As $subject says, I noticed that while scanning the area. Any
> objections to make all that more consistent with the style of HEAD?
> Please see the attached.
+1, it's not surprising some places didn't get that memo yet.
regards, tom lane
Hi all,
As $subject says, I noticed that while scanning the area. Any
objections to make all that more consistent with the style of HEAD?
Please see the attached.
--
Michael
diff --git a/src/backend/access/transam/xlogreader.c b/src/backend/access/transam/xlogreader.c
index 3ae4127b8a..c0e7c3707d
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 or RCs you
have, but you can never be sure of how m
On Thu, Apr 22, 2021 at 11:44:10AM +, houzj.f...@fujitsu.com wrote:
> I found some possible redundant comments in fmgr.c
Thanks, fixed. I have noticed one extra inconsistency at the top of
fmgr_symbol().
> I guess the comment here was miscopied from fmgr_info_cxt_security:
Right, coming rig
On Fri, Apr 23, 2021 at 09:43:09AM +0900, Kyotaro Horiguchi wrote:
> At Thu, 22 Apr 2021 09:29:46 -0400, Tom Lane wrote in
>> But what I thought Michael was griping about is the use of "int",
>> which is a noise word here. Either "long long int" or "long long"
>> will work, but I think we've pre
Kyotaro Horiguchi writes:
> At Thu, 22 Apr 2021 23:17:19 -0400, Tom Lane wrote in
>> Doesn't seem like a good idea, because that locks us into an assumption
>> that the downcasing conversion doesn't change the string's physical
>> length. There are a lot of counterexamples to that :-(. I'm not
At Thu, 22 Apr 2021 12:44:28 +, "tanghy.f...@fujitsu.com"
wrote in
> Hi
>
> When try to improve the tab compleation feature in [1], I found an existing
> problem and a typo.
> The patch was attached, please kindly to take a look at it. Thanks.
>
> [1]
> htdrop
> indetps://www.postgresql.
> I don't think here we need to restart to get a stable list of indexes
> as we do in RelationGetIndexAttrBitmap. The reason is here we build
> the cache entry using a historic snapshot and all the later changes
> are absorbed while decoding WAL. I have updated that and modified few
> comments in t
At Thu, 22 Apr 2021 23:17:19 -0400, Tom Lane wrote in
> Kyotaro Horiguchi writes:
> > All usages of pg_string_tolower don't need a copy.
> > So don't we change the function to in-place converter?
>
> Doesn't seem like a good idea, because that locks us into an assumption
> that the downcasing c
At Fri, 23 Apr 2021 11:58:12 +0900 (JST), Kyotaro Horiguchi
wrote in
> > Any further comment is very welcome.
Oh, I accidentally found a doubious behsbior.
=# alter table public.
public.c1public.d1public."t" public.t public."tt"
The "t" and "tt" are needlessly lower-cased.
#
Kyotaro Horiguchi writes:
> All usages of pg_string_tolower don't need a copy.
> So don't we change the function to in-place converter?
Doesn't seem like a good idea, because that locks us into an assumption
that the downcasing conversion doesn't change the string's physical
length. There are a
On Thu, Apr 22, 2021 at 12:30 PM Etsuro Fujita wrote:
> > > +* We'll prefer to consider this join async-capable if
> > > any table from
> > > +* either side of the join is considered async-capable.
> > > +*/
> > > + fpinfo->async_capa
On Thu, Apr 22, 2021 at 2:01 PM Kyotaro Horiguchi
wrote:
>
> I found some doubious messages.
>
> catalog.c:380, 404
> > errdetail("OID candidates were checked \"%llu\" times, but no unused OID
> > is yet found.",
> > (errmsg("new OID has been assigned in relation \"%s\" after \"%llu\"
> > retri
At Thu, 22 Apr 2021 12:43:42 +, "tanghy.f...@fujitsu.com"
wrote in
> On Wednesday, April 21, 2021 1:24 PM, Peter Smith
> Wrot> >4. Memory not freed in multiple places?
> oops. Memory free added.
All usages of pg_string_tolower don't need a copy.
So don't we change the function to in-place
I suggest to add some kind of reference to stats expressions here.
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
Updating Planner Statistics
statistics
of the planner
[...]
@@ -330,10 +330,12 @@
Also, by default there is limited inf
On Thu, Apr 22, 2021 at 11:36 AM Dilip Kumar wrote:
>
> On Thu, Apr 22, 2021 at 10:40 AM Bharath Rupireddy
> wrote:
> >
> > Hi,
> >
> > In the PageGetItemIdCareful() introduced by commit a9ce839a, it seems
> > like we are using btree page pd_special structure BTPageOpaqueData for
> > error case w
On Fri, Apr 23, 2021 at 10:08 AM Amit Langote wrote:
> On Fri, Apr 23, 2021 at 12:49 AM Tom Lane wrote:
> > Amit Langote writes:
> > >> (I've not looked at porting this to v12 or v11 yet.)
> >
> > > I did that; patches attached. (I haven't changed them to incorporate
> > > the above comment tho
From: Hou, Zhijie/侯 志杰
> For approach 1): I think it could result in infinite recursion.
>
> For example:
> If we first access one built-in function A which have not been cached,
> it need access the pg_proc, When accessing the pg_proc, it internally still
> need
> some built-in function B to sc
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 uint64 because>
> there ar
On Fri, Apr 23, 2021 at 12:49 AM Tom Lane wrote:
> Amit Langote writes:
> > I think we should also add slot != srcSlot to this condition.
>
> Good idea, should save useless comparisons of identical tupdescs.
> Done.
>
> >> (I've not looked at porting this to v12 or v11 yet.)
>
> > I did that; pat
On 2021/04/23 9:26, Masahiro Ikeda wrote:
On 2021/04/23 0:36, Andres Freund wrote:
Hi
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 uint64 because> there
aren't any counters with ne
At Thu, 22 Apr 2021 09:29:46 -0400, Tom Lane wrote in
> Julien Rouhaud writes:
> > On Thu, Apr 22, 2021 at 07:49:23PM +0900, Michael Paquier wrote:
> >> May I ask why you are using "unsigned long long int" rather uint64?
>
> > My understanding is that it's the project standard. See e.g.
> > ht
On 4/22/21 5:08 PM, Michael Paquier wrote:
> On Thu, Apr 22, 2021 at 02:35:13PM -0400, Alvaro Herrera wrote:
>> WFM, thanks :-)
> Also, do we need to worry about beta releases? Just recalled that
> now.
Interesting point. Maybe we need to do something like devel = -4, alpha
= -3, beta = -2, rc
On Thu, Apr 22, 2021 at 3:52 PM Peter Geoghegan wrote:
> On Thu, Apr 22, 2021 at 11:16 AM Robert Haas wrote:
> > > My most ambitious goal is finding a way to remove the need to freeze
> > > or to set hint bits. I think that we can do this by inventing a new
> > > kind of VACUUM just for aborted t
> > BACKGROUND
> >
> >
> > We want to realize parallel INSERT SELECT in the following steps:
> > 1) INSERT + parallel SELECT
> > 2) Parallel INSERT + parallel SELECT
> >
> > Below are example use cases. We don't expect high concurrency or an
> > empty data
On 2021/04/23 0:36, Andres Freund wrote:
> Hi
>
> 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 uint64 because>
there aren't any counters with negative number?
>> On second tho
(moved to -hackers)
https://www.postgresql.org/message-id/flat/54d30e66-dbd6-5485-aaf6-a291ed55919d%40oss.nttdata.com
On Thu, Apr 15, 2021 at 11:24:07PM +0900, Fujii Masao wrote:
> On 2021/04/15 11:54, Michael Paquier wrote:
> > May I ask at the same time why gram.y (TableLikeOption) and
> > par
> On Apr 19, 2021, at 5:07 PM, Mark Dilger wrote:
>
>
>
>> On Apr 19, 2021, at 12:50 PM, Robert Haas wrote:
>>
>> On Thu, Apr 15, 2021 at 1:07 PM Mark Dilger
>> wrote:
>>> I have added the verb "has" rather than "contains" because "has" is more
>>> consistent with the phrasing of other si
On 4/22/21 3:25 PM, Andres Freund wrote:
Hi,
On 2021-04-22 09:35:48 -0700, Tom Stellard wrote:
On 4/21/21 6:40 AM, Honza Horak wrote:
I wrote a new patch based on the bug discussion[1]. It works around
the issue specifically on s390x rather than disabling specific
CPUs and features for all tar
On Thu, Apr 22, 2021 at 11:16 AM Robert Haas wrote:
> > My most ambitious goal is finding a way to remove the need to freeze
> > or to set hint bits. I think that we can do this by inventing a new
> > kind of VACUUM just for aborted transactions, which doesn't do index
> > vacuuming. You'd need so
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 future. Whatever is done on the topic should
> probably be done based on
Peter Geoghegan writes:
> We already *almost* pay the full cost of durably storing the
> information used by autovacuum.c's relation_needs_vacanalyze() to
> determine if a VACUUM is required -- we're only missing
> new_dead_tuples/tabentry->n_dead_tuples. Why not go one tiny baby step
> further to
Hi,
On 2021-04-22 09:35:48 -0700, Tom Stellard wrote:
> On 4/21/21 6:40 AM, Honza Horak wrote:
> I wrote a new patch based on the bug discussion[1]. It works around
> the issue specifically on s390x rather than disabling specific
> CPUs and features for all targets. The patch is attached.
Cool,
On Wed, Apr 21, 2021 at 5:39 AM Magnus Hagander wrote:
> I'm pretty sure everybody would *want* this. At least nobody would be
> against it. The problem is the potential performance cost of it.
VACUUM remembers vacrel->new_live_tuples as the pg_class.reltuples for
the heap relation being vacuumed
On Thu, Apr 22, 2021 at 02:35:13PM -0400, Alvaro Herrera wrote:
> WFM, thanks :-)
Also, do we need to worry about beta releases? Just recalled that
now.
--
Michael
signature.asc
Description: PGP signature
On Thu, Apr 22, 2021 at 12:27 PM Robert Haas wrote:
> I agree strongly with this. In fact, I seem to remember saying similar
> things to you in the past. If something wins $1 in 90% of cases and
> loses $5 in 10% of cases, is it a good idea? Well, it depends on how
> the losses are distributed. If
Would anyone oppose me pushing this for tab-completing the new keywords
of
ALTER TABLE .. DETACH PARTITION?
--
Álvaro Herrera Valdivia, Chile
"Por suerte hoy explotó el califont porque si no me habría muerto
de aburrido" (Papelucho)
>From 4ab605c1e1ed87ef92370bc6205a8b786739f774 Mon Sep
On 4/22/21 6:35 PM, Tom Stellard wrote:
On 4/21/21 6:40 AM, Honza Horak wrote:
On 3/19/21 8:15 PM, Tom Lane wrote:
Andres Freund writes:
I think the error above comes from a "mismatch" between the clang used
to compile bitcode, and the LLVM version linked to. Normally we're
somewhat tolerant
Hi,
Michael Paquier (running locally I think), and subsequently Thomas Munro
(noticing [1]), privately reported that they noticed an assertion failure in
GetSnapshotData(). Both reasonably were wondering if that's related to the
snapshot scalability patches.
Michael reported the following asserti
I wrote:
> So I don't think there's any code change required (unless you are still
> worried about speed). What we do need is documentation fixes:
> * clarify the above bit about local vs UTC midnight
> * document the existence of the julian field for date_part/extract
> * fix this bit in the to_c
On Wed, Apr 7, 2021 at 3:55 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
>
> Committed. Thanks!
>
>
This commit break line continuation prompts for unbalanced parentheses in
the psql binary. Skimming through this thread, I don't see that this is
intentional or has been noticed
Hi,
On 2021-04-22 12:15:27 -0400, Robert Haas wrote:
> On Wed, Apr 21, 2021 at 5:38 PM Andres Freund wrote:
> > I'm not sure that's the only way to deal with this. While some form of
> > generic "conveyor belt" infrastructure would be a useful building block,
> > and it'd be sensible to use it he
On Thu, Apr 22, 2021 at 3:11 PM Peter Geoghegan wrote:
> I think that everybody's beliefs about VACUUM tend to be correct. It
> almost doesn't matter if scenario A is the problem in 90% or cases
> versus 10% of cases for scenario B (or vice-versa). What actually
> matters is that we have good hand
On 2021-Apr-22, Amit Langote wrote:
> On Thu, Apr 22, 2021 at 5:39 AM Alvaro Herrera
> wrote:
> Reading through the latest one, seeing both include_detached and
> omit_detached being used in different parts of the code makes it a bit
> hard to keep in mind what a given code path is doing wrt de
On Thu, Apr 22, 2021 at 11:44 AM Andres Freund wrote:
> I'm honestly getting a bit annoyed about this stuff.
You're easily annoyed.
> Yes it's a cool
> improvement, but no, it doesn't mean that there aren't still relevant
> issues in important cases. It doesn't help that you repeatedly imply
> t
Hi,
On 2021-04-22 14:47:14 -0400, Robert Haas wrote:
> On Thu, Apr 22, 2021 at 10:28 AM Masahiko Sawada
> wrote:
> > Right. Given decoupling index vacuuming, I think the index’s garbage
> > statistics are important which preferably need to be fetchable without
> > accessing indexes. It would be
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 able to merge them if we did index
> vacuuming on one of indexes at
Hi,
On 2021-04-22 11:30:21 -0700, Peter Geoghegan wrote:
> I think that you're both missing very important subtleties here.
> Apparently the "quantitative vs qualitative" distinction I like to
> make hasn't cleared it up.
I'm honestly getting a bit annoyed about this stuff. Yes it's a cool
improv
On Thu, Apr 22, 2021 at 7:51 AM Dilip Kumar wrote:
> How do we decide this target, I mean at a given point how do we decide
> that what is the limit of dead TID's at which we want to trigger the
> index vacuuming?
It's tricky. Essentially, it's a cost-benefit analysis. On the "cost"
side, the exp
On 2021-Apr-22, Andrew Dunstan wrote:
> # Accept standard formats, in case caller has handed us the
> output of a
> # postgres command line tool
> my $devel;
> ($arg,$devel) = ($1, $2)
> if ($arg =~ m/^(?:\(?PostgreSQL\)? )?(\d+(?:\.\d+)*)(devel)?/);
On Thu, Apr 22, 2021 at 9:15 AM Robert Haas wrote:
> > Have you thought about how we would do the scheduling of vacuums for the
> > different indexes? We don't really have useful stats for the number of
> > dead index entries to be expected in an index. It'd not be hard to track
> > how many entri
On Wed, Apr 21, 2021 at 7:51 PM Peter Geoghegan wrote:
> I'm very happy to see that you've taken an interest in this work! I
> believe it's an important area. It's too important to be left to only
> two contributors. I welcome your participation as an equal partner in
> the broader project to fix
On 4/22/21 11:09 AM, Alvaro Herrera wrote:
> On 2021-Apr-21, Andrew Dunstan wrote:
>
>> +=head1 DESCRIPTION
>> +
>> +PostgresVersion encapsulated Postgres version numbers, providing parsing
>> +of common version formats and comparison operations.
> Small typo here: should be "encapsulates"
>
>> +
On Mon, May 27, 2019 at 4:44 PM Antonin Houska wrote:
> David Rowley wrote:
>
> > On Wed, 6 Mar 2019 at 12:54, David Rowley
> wrote:
> > > The latest patch is attached.
> >
> > Rebased version after pgindent run.
>
> I've spent some time looking into this.
>
> One problem I see is that SubLink
On Wed, Apr 21, 2021 at 07:06:49PM -0400, Alvaro Herrera wrote:
> On 2021-Apr-09, Robert Haas wrote:
> > Does this need to worry about new partitions getting attached to a
> > partitioned table, or old ones getting detached? (Maybe it does
> > already, not sure.)
>
> I was pinged because this is l
On Thu, Apr 22, 2021 at 07:41:06AM -0700, Zhihong Yu wrote:
> > > > + Note that ONLY option specified in
> > >
> > > add "the" to say: "the ONLY"
> >
> > +1.
>
> Since 'the only option' is legitimate English phrase, I think the following
> would be clearer:
>
> Note that the option ONLY ...
I t
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 | evtfoid |
> evtenabled | evttags
> ---+---+--
Hi,
Is $SUBJECT intentional, or would it be desirable to add support it?
Example:
SELECT * FROM pg_catalog.pg_event_trigger;
oid|evtname|evtevent | evtowner | evtfoid |
evtenabled | evttags
---+---+-+--+---+--
On 4/22/21 11:46 AM, Mark Dilger wrote:
>
>> On Apr 22, 2021, at 8:09 AM, Alvaro Herrera wrote:
>>
>>> + # Accept standard formats, in case caller has handed us the output of a
>>> + # postgres command line tool
>>> + $arg = $1
>>> + if ($arg =~ m/\(?PostgreSQL\)? (\d+(?:\.\d+)*(
On 4/21/21 6:40 AM, Honza Horak wrote:
On 3/19/21 8:15 PM, Tom Lane wrote:
Andres Freund writes:
I think the error above comes from a "mismatch" between the clang used
to compile bitcode, and the LLVM version linked to. Normally we're
somewhat tolerant of differences between the two, but there
On Wed, Apr 21, 2021 at 5:38 PM Andres Freund wrote:
> I'm not sure that's the only way to deal with this. While some form of
> generic "conveyor belt" infrastructure would be a useful building block,
> and it'd be sensible to use it here if it existed, it seems feasible to
> dead tids in a differ
Amit Langote writes:
> I think we should also add slot != srcSlot to this condition.
Good idea, should save useless comparisons of identical tupdescs.
Done.
>> (I've not looked at porting this to v12 or v11 yet.)
> I did that; patches attached. (I haven't changed them to incorporate
> the abov
> On Apr 22, 2021, at 8:09 AM, Alvaro Herrera wrote:
>
>>
>> +# Accept standard formats, in case caller has handed us the output of a
>> +# postgres command line tool
>> +$arg = $1
>> +if ($arg =~ m/\(?PostgreSQL\)? (\d+(?:\.\d+)*(?:devel)?)/);
>> +
>> +# Split int
Hi
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 uint64 because>
> >> there aren't any counters with negative number?
>
> On second thought, it's ok even if the counters like wal
On 4/22/21 2:52 AM, Michael Paquier wrote:
> On Wed, Apr 21, 2021 at 10:04:40AM -0400, Andrew Dunstan wrote:
>> Here's a patch with these things attended to.
> Thanks. Reading through it, that seems pretty much fine to me. I
> have not spent time checking _version_cmp in details though :)
p
On 2021-Apr-21, Andrew Dunstan wrote:
> +=head1 DESCRIPTION
> +
> +PostgresVersion encapsulated Postgres version numbers, providing parsing
> +of common version formats and comparison operations.
Small typo here: should be "encapsulates"
> + # Accept standard formats, in case caller has hand
On Thu, Apr 22, 2021 at 4:39 AM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Thu, Apr 22, 2021 at 2:26 PM 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/fdwhand
On Thu, Apr 22, 2021 at 8:51 AM Peter Geoghegan wrote:
>
> On Wed, Apr 21, 2021 at 8:21 AM Robert Haas wrote:
> > We are used to thinking about table vacuum and index vacuum as parts
> > of a single, indivisible operation. You vacuum the table -- among
> > other things by performing HOT pruning a
On Thu, Apr 22, 2021 at 05:09:02PM +0530, Bharath Rupireddy wrote:
> > should it say "specified" instead of requested ?
> > Or should it say "requested the RESTART IDENTITY behavior" ?
> >
> > Also, I think it should say "..otherwise, the CONTINUE IDENTITY behavior was
> > requested".
>
> The orig
On 2021/04/21 18:31, Masahiro Ikeda wrote:
BTW, is it better to change PgStat_Counter from int64 to uint64 because> there
aren't any counters with negative number?
On second thought, it's ok even if the counters like wal_records get overflowed.
Because they are always used to calculate the
Julien Rouhaud writes:
> On Thu, Apr 22, 2021 at 07:49:23PM +0900, Michael Paquier wrote:
>> May I ask why you are using "unsigned long long int" rather uint64?
> My understanding is that it's the project standard. See e.g.
> https://www.postgresql.org/message-id/1730584.1617836...@sss.pgh.pa.us
On 4/22/21 2:52 AM, Michael Paquier wrote:
> On Wed, Apr 21, 2021 at 10:04:40AM -0400, Andrew Dunstan wrote:
>> Here's a patch with these things attended to.
> Thanks. Reading through it, that seems pretty much fine to me. I
> have not spent time checking _version_cmp in details though :)
Ok,
Hi
When try to improve the tab compleation feature in [1], I found an existing
problem and a typo.
The patch was attached, please kindly to take a look at it. Thanks.
[1]
https://www.postgresql.org/message-id/OS0PR01MB61131A4347D385F02F60E123FB469%40OS0PR01MB6113.jpnprd01.prod.outlook.com
Regar
On Wednesday, April 21, 2021 1:24 PM, Peter Smith Wrote
>I tried playing a bit with your psql patch V5 and I did not find any
>problems - it seemed to work as advertised.
>
>Below are a few code review comments.
Thanks for you review. I've updated the patch to V6 according to your comments.
>1.
897795240cfaaed724af2f53ed2c50c9862f951f forgot to reduce the lock
level for CHECK constraints when allowing them to be NOT VALID.
This is simple and safe, since check constraints are not used in
planning until validated.
--
Simon Riggshttp://www.EnterpriseDB.com/
alter_table_a
On Wed, Apr 21, 2021 at 8:51 PM Robert Haas wrote:
> Now, the reason for this is that when we discover dead TIDs, we only
> record them in memory, not on disk. So, as soon as VACUUM ends, we
> lose all knowledge of whether those TIDs were and must rediscover
> them. Suppose we didn't do this, and
The docs don't explicitly mention the reduced lock level for this subcommand.
--
Simon Riggshttp://www.EnterpriseDB.com/
alter_table_validate_lock_level.patch
Description: Binary data
Hi,
I found some possible redundant comments in fmgr.c
1.
fmgr_symbol(Oid functionId, char **mod, char **fn)
{
HeapTuple procedureTuple;
Form_pg_proc procedureStruct;
bool isnull;
Datum prosrcattr
On Thu, Apr 22, 2021 at 2:26 PM 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/f
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 each foreign table to truncated.
>
>
> BACKGROUND
>
>
> We want to realize parallel INSERT SELECT in the following steps:
> 1) INSERT + parallel SELECT
> 2) Parallel INSERT + parallel SELECT
>
> Below are example use cases. We don't expect high concurrency or an empty
> data source.
> * Data
On Thu, Apr 22, 2021 at 08:12:25PM +0900, Michael Paquier wrote:
> On Thu, Apr 22, 2021 at 06:56:28PM +0800, Julien Rouhaud wrote:
> > My understanding is that it's the project standard. See e.g.
> > https://www.postgresql.org/message-id/1730584.1617836...@sss.pgh.pa.us
>
> FWIW, I am not questio
On Thu, Apr 22, 2021 at 06:56:28PM +0800, Julien Rouhaud wrote:
> My understanding is that it's the project standard. See e.g.
> https://www.postgresql.org/message-id/1730584.1617836...@sss.pgh.pa.us
FWIW, I am not questioning the format of the specifiers, which is
something I heard about, but th
On Wed, Apr 21, 2021 at 11:57 PM Peter Eisentraut
wrote:
> The multirange constructors created in makeMultirangeConstructors() are:
>
> multirange_constructor0 -> not strict
> multirange_constructor1 -> strict
> multirange_constructor2 -> not strict
>
> And both multirange_constructor1 and multira
On Thu, Apr 22, 2021 at 07:49:23PM +0900, Michael Paquier wrote:
>
> May I ask why you are using "unsigned long long int" rather uint64?
My understanding is that it's the project standard. See e.g.
https://www.postgresql.org/message-id/1730584.1617836...@sss.pgh.pa.us
On Thu, Apr 22, 2021 at 1:02 PM Masahiko Sawada wrote:
>
Thanks, it looks good to me now. I'll review/test some more before
committing but at this stage, I would like to know from Andres or
others whether they see any problem with this approach to fixing a few
of the problems reported in this thr
1 - 100 of 114 matches
Mail list logo
