On Tue, Aug 23, 2022 at 12:06 AM Robert Haas wrote:
> Nothing that uses xlogreader is going to be able to bridge the gap
> between file #4 and file #5. In this case it doesn't matter very much,
> because we immediately write a checkpoint record into file #5, so if
> we crash we won't try to
On Wed, Aug 24, 2022 at 12:15 AM Nathan Bossart
wrote:
>
> On Tue, Aug 23, 2022 at 01:03:03PM +0700, John Naylor wrote:
> > On Tue, Aug 23, 2022 at 10:32 AM Nathan Bossart
> >> Here's a new version of the patch with the 32-bit changes and calls to
> >> lfind() removed.
> >
> > LGTM overall. My
Michael Paquier writes:
> On Tue, Aug 23, 2022 at 10:04:30AM -0700, Jacob Champion wrote:
>> When can we rely on static initialization, and when can't we? Is there a
>> concern that the memory could have been polluted from before the
>> postmaster's fork?
> My main worry here is EXEC_BACKEND,
On Tue, Aug 23, 2022 at 08:59:02PM +0300, Marina Polyakova wrote:
> My colleague Andrew Bille found another bug in master
> (b4e936859dc441102eb0b6fb7a104f3948c90490) and REL_15_STABLE
> (2c63b0930aee1bb5c265fad4a65c9d0b62b1f9da): pg_collation.colliculocale is
> not dumped. See
On Wed, Aug 24, 2022 at 10:48:01AM +0900, Kyotaro Horiguchi wrote:
> By the way, I think we use INSTR_TIME_* macros to do masure internal
> durations (mainly for the monotonic clock characteristics, and to
> reduce performance degradation on Windows?). I'm not sure that's
> crutial here but I
Andres Freund writes:
> On 2022-08-24 00:18:27 -0400, Tom Lane wrote:
>> But if the regression tests are triggering use of uninitialized values, how
>> could we have failed to detect that? Either valgrind or unstable behavior
>> should have found this ages ago.
> I think it's just different
On Wed, Aug 17, 2022 at 04:48:42PM +0200, Drouvot, Bertrand wrote:
> That way one could test the SYSTEM_USER behavior without the need to have
> kerberos enabled.
I was looking at this patch and noticed that SYSTEM_USER returns a
"name", meaning that the value would be automatically truncated at
Hi,
On 2022-08-24 00:18:27 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-08-23 20:36:55 -0700, Andres Freund wrote:
> >> Running the ecpg regression tests interactively (to try to find a different
> >> issue), triggered a crash on windows due to an uninitialized variable
> >>
Andres Freund writes:
> On 2022-08-23 20:36:55 -0700, Andres Freund wrote:
>> Running the ecpg regression tests interactively (to try to find a different
>> issue), triggered a crash on windows due to an uninitialized variable (after
>> pressing "ignore" in that stupid gui window that we've only
On Wed, Aug 24, 2022 at 11:55 AM Amit Langote wrote:
> On Wed, Aug 24, 2022 at 6:29 AM Nikita Glukhov
> wrote:
> > Here is my plan:
> >
> > 0. Take my last v7-0001 patch as a base. It already contains refactoring
> > of JsonCoercion code. (Fix 0002 is not needed anymore, because it is for
> >
On Tue, Aug 23, 2022 at 4:15 AM Nathan Bossart wrote:
>
> On Mon, Aug 22, 2022 at 11:50:35AM +0700, John Naylor wrote:
> > Is this also ever defined on 32-bit? If so, is it safe, meaning the
> > compiler will not emit these instructions without additional flags?
> > I'm wondering if __aarch64__
On Tue, Aug 23, 2022 at 10:04:30AM -0700, Jacob Champion wrote:
> On 8/23/22 01:53, Drouvot, Bertrand wrote:
>> @@ -2688,6 +2689,7 @@ InitProcessGlobals(void)
>>
>> MyProcPid = getpid();
>>
>>
At Thu, 18 Aug 2022 16:58:24 +0530, Pavan Deolasee
wrote in
> Hi,
>
> On Thu, Aug 18, 2022 at 5:38 AM Andres Freund wrote:
>
> > We can't move pgstat shutdown into on_dsm callback because that's too late
> > to
> > allocate *new* dsm segments, which we might need to do while flushing
> > out
Hi,
On 2022-08-23 20:36:55 -0700, Andres Freund wrote:
> Running the ecpg regression tests interactively (to try to find a different
> issue), triggered a crash on windows due to an uninitialized variable (after
> pressing "ignore" in that stupid gui window that we've only disabled for the
>
Hi,
I occasionally
Running the ecpg regression tests interactively (to try to find a different
issue), triggered a crash on windows due to an uninitialized variable (after
pressing "ignore" in that stupid gui window that we've only disabled for the
backend).
"The variable 'replace_val' is being
Hi Nikita,
On Wed, Aug 24, 2022 at 6:29 AM Nikita Glukhov wrote:
> Here is my plan:
>
> 0. Take my last v7-0001 patch as a base. It already contains refactoring
> of JsonCoercion code. (Fix 0002 is not needed anymore, because it is for
> json[b] domains, which simply will not be supported.)
>
Andres Freund writes:
> FWIW, while trying to mirror the same logic in meson I learned that the new
> logic removes the rpath setting from the parameters on at least netbsd and
> suse. We'll add them back - unless --disable-rpath is used.
Hmm ... on my shiny new netbsd buildfarm animal, I see:
On Wed, Aug 24, 2022 at 12:37:29PM +1200, David Rowley wrote:
> On Tue, 23 Aug 2022 at 14:14, Justin Pryzby wrote:
> > Actually, they didn't sneak in - what I sent are the patches which are
> > ready to
> > be reviewed, excluding the set of "this" and "tmp" and other renames which
> > you
> >
Hi,
On 2022-08-22 08:37:40 -0700, Andres Freund wrote:
> On 2022-08-22 16:32:36 +0200, Peter Eisentraut wrote:
> > On 20.08.22 23:44, Andres Freund wrote:
> > > On 2022-08-20 16:53:31 -0400, Tom Lane wrote:
> > > > Andres Freund writes:
> > > > > Maybe a daft question: Why do want any of the -l
Hi,
On 2022-08-23 01:34:36 -0700, Andres Freund wrote:
> On 2019-04-23 06:23:13 +0100, Andrew Gierth wrote:
> > I wonder if it's the use of -Bsymbolic that causes this (buildfarm logs
> > don't seem to go back far enough to check). (Note to original poster:
> > -Bsymbolic is there for a reason,
Hi,
On 2022-08-23 19:50:00 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Aug 23, 2022 at 7:24 PM Andres Freund wrote:
> >> Just to make sure I understand - you're just trying to get rid of the
> >> #define
> >> frontends, not the -DFRONTENDs passed in from the Makefile? Because
At Tue, 23 Aug 2022 10:49:40 -0700, Nathan Bossart
wrote in
> On Wed, Aug 17, 2022 at 11:17:24AM +0530, Bharath Rupireddy wrote:
> > + "logical decoding file(s)
> > processing time=%ld.%03d s",
>
> I would suggest shortening this to something like
At Tue, 16 Aug 2022 18:40:49 +0200, Alvaro Herrera
wrote in
> On 2022-Aug-16, Andrew Dunstan wrote:
>
> > I don't think there's a hard and fast rule about it. Certainly the case
> > would be more compelling if the functions were used across different TAP
> > suites. The SSL suite has
On Wed, Aug 24, 2022 at 3:04 AM Robert Haas wrote:
> I haven't been paying attention to this thread, but my attention was
> just drawn to it, and I'm wondering if the issue you're trying to
> track down here is actually the same as what I reported yesterday
> here:
>
>
On Tue, 23 Aug 2022 at 14:14, Justin Pryzby wrote:
> Actually, they didn't sneak in - what I sent are the patches which are ready
> to
> be reviewed, excluding the set of "this" and "tmp" and other renames which you
> disliked. In the branch (not the squished patch) the first ~15 patches were
>
Robert Haas writes:
> On Tue, Aug 23, 2022 at 7:24 PM Andres Freund wrote:
>> Just to make sure I understand - you're just trying to get rid of the #define
>> frontends, not the -DFRONTENDs passed in from the Makefile? Because afaics we
>> still need those, correct?
> Oh, yeah, this only fixes
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jul 26, 2022 at 1:50 PM David G. Johnston
> wrote:
> >> Still, it seems somewhat appealing to give
> >> people fine-grained control over this, rather than just "on" or "off".
> > Appealing enough to consume a couple of permission
On Tue, Aug 23, 2022 at 7:24 PM Andres Freund wrote:
> Just to make sure I understand - you're just trying to get rid of the #define
> frontends, not the -DFRONTENDs passed in from the Makefile? Because afaics we
> still need those, correct?
Oh, yeah, this only fixes the #define ones. But maybe
Hi,
On 2022-08-23 17:24:30 -0400, Robert Haas wrote:
> On Sat, Aug 20, 2022 at 3:46 PM Andres Freund wrote:
> > Unfortunately, the remaining uses of FRONTEND are required. That's:
> > - pg_controldata, via #define
> > - pg_resetwal, via #define
> > - pg_rewind, via -DFRONTEND, due to
On Tue, Aug 23, 2022 at 5:56 PM Tom Lane wrote:
> Robert Haas writes:
> > Actually, I think we could fix these pretty easily too. See attached.
>
> Hmm, do these headers still pass headerscheck/cpluspluscheck?
I didn't check before sending the patch, but now I ran it locally, and
I did get
On Tue, Aug 23, 2022 at 3:43 PM Tom Lane wrote:
> Thomas Munro writes:
> > I was nerd-sniped by the historical context of this single line of
> > code. I'd already wondered many times (not just in PostgreSQL)
> > whether and when that became a cargo-cult practice, replicated from
> > other
On 2022-08-23 Tu 17:29, Nikita Glukhov wrote:
>
>
> On 23.08.2022 22:31, Jonathan S. Katz wrote:
>> On 8/23/22 2:10 PM, Andrew Dunstan wrote:
>>>
>>> On 2022-08-23 Tu 13:24, Tom Lane wrote:
"Jonathan S. Katz" writes:
> I saw Andrew suggest that the controversial parts of the patchset
Robert Haas writes:
> Actually, I think we could fix these pretty easily too. See attached.
Hmm, do these headers still pass headerscheck/cpluspluscheck?
I might quibble a bit with the exact placement of the #ifndef FRONTEND
tests, but overall this looks pretty plausible.
On 23.08.2022 22:31, Jonathan S. Katz wrote:
On 8/23/22 2:10 PM, Andrew Dunstan wrote:
On 2022-08-23 Tu 13:24, Tom Lane wrote:
"Jonathan S. Katz" writes:
I saw Andrew suggest that the controversial parts of the patchset
may be
severable from some of the new functionality, so I would like
On Sat, Aug 20, 2022 at 3:46 PM Andres Freund wrote:
> Unfortunately, the remaining uses of FRONTEND are required. That's:
> - pg_controldata, via #define
> - pg_resetwal, via #define
> - pg_rewind, via -DFRONTEND, due to xlogreader.c
> - pg_waldump, via #define and -DFRONTEND, due to
Peter Eisentraut writes:
> Here is a new patch with more comments.
LGTM
regards, tom lane
Andrew Dunstan writes:
> On 2022-08-23 Tu 15:32, Jonathan S. Katz wrote:
>> On 8/23/22 1:26 PM, Andres Freund wrote:
>>> We could decide to revert this for 15, but leave it in tree for HEAD.
>> If it comes to that, I think that is a reasonable suggestion so long
>> as we're committed to making
út 23. 8. 2022 v 21:54 odesílatel Tom Lane napsal:
> Andres Freund writes:
> > On 2022-08-23 13:28:50 -0400, Tom Lane wrote:
> >> I agree with the upthread comments that we only need/want to catch
> >> foreseeable incorrect-input errors, and that the way to make that
> >> happen is to refactor
Andres Freund writes:
> On 2022-08-23 13:28:50 -0400, Tom Lane wrote:
>> I agree with the upthread comments that we only need/want to catch
>> foreseeable incorrect-input errors, and that the way to make that
>> happen is to refactor the related type input functions, and that
>> a lot of the
On 2022-08-23 Tu 15:32, Jonathan S. Katz wrote:
> On 8/23/22 1:26 PM, Andres Freund wrote:
>> Hi,
>>
>> On 2022-08-23 13:18:49 -0400, Jonathan S. Katz wrote:
>>> Taking RMT hat off, if the outcome is "revert", I do want to ensure
>>> we don't
>>> lose momentum on getting this into v16. I know a
On 8/23/22 1:26 PM, Andres Freund wrote:
Hi,
On 2022-08-23 13:18:49 -0400, Jonathan S. Katz wrote:
Taking RMT hat off, if the outcome is "revert", I do want to ensure we don't
lose momentum on getting this into v16. I know a lot of time and effort has
gone into this featureset and it seems to
On 8/23/22 2:10 PM, Andrew Dunstan wrote:
On 2022-08-23 Tu 13:24, Tom Lane wrote:
"Jonathan S. Katz" writes:
I saw Andrew suggest that the controversial parts of the patchset may be
severable from some of the new functionality, so I would like to see
that proposal and if it is enough to
On 16.08.22 15:50, Tom Lane wrote:
Peter Eisentraut writes:
Looking to tidy up c.h a bit, I think the NON_EXEC_STATIC #define
doesn't need to be known globally, and it's not related to establishing
a portable C environment, so I propose to move it to a more localized
header, such as
On Thu, Jul 28, 2022 at 12:32 PM tushar wrote:
> On 7/28/22 8:03 PM, Robert Haas wrote:
> > No, it seems to me that's behaving as intended. REVOKE BLAH OPTION ...
> > is intended to be a way of switching an option off.
> Ok, Thanks, Robert. I tested with a couple of more scenarios like
>
Hi,
On 2022-08-23 13:28:50 -0400, Tom Lane wrote:
> I agree with the upthread comments that we only need/want to catch
> foreseeable incorrect-input errors, and that the way to make that
> happen is to refactor the related type input functions, and that
> a lot of the heavy lifting for that has
Hi,
On 2022-08-23 13:33:42 -0400, Robert Haas wrote:
> On Tue, Aug 23, 2022 at 1:23 PM Andres Freund wrote:
> > > But that's exactly what I'm complaining about. Catching an error that
> > > unwound a bunch of stack frames where complicated things are happening
> > > is fraught with peril.
On 23.08.2022 20:38, Pavel Stehule wrote:
út 23. 8. 2022 v 19:27 odesílatel Andres Freund
napsal:
Hi,
On 2022-08-23 18:06:22 +0200, Pavel Stehule wrote:
> The errors that should be handled are related to json structure
errors. I
> don't think so we have to handle all
On 2022-08-23 Tu 13:24, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> I saw Andrew suggest that the controversial parts of the patchset may be
>> severable from some of the new functionality, so I would like to see
>> that proposal and if it is enough to overcome concerns.
> It's an
On 2022-Aug-23, Zhihong Yu wrote:
> Toggling enable_seqscan on / off using the example from `parenting a PK
> constraint to a self-FK one` thread, it can be shown that different
> constraint Id would be detached which is incorrect.
> However, I am not sure whether toggling enable_seqscan mid-test
On Wed, Aug 17, 2022 at 12:39:26PM +0530, Bharath Rupireddy wrote:
> + /*
> + * We're only handling directories here, skip if it's not ours. Also,
> skip
> + * if the caller has already performed this check.
> + */
> + if (!slot_dir_checked &&
> + lstat(path, )
On Tue, Aug 23, 2022 at 10:53 AM Alvaro Herrera
wrote:
> On 2022-Aug-23, Zhihong Yu wrote:
>
> > This is what I came up with.
>
> I suggest you provide a set of SQL commands that provoke some wrong
> behavior with the original code, and show that they generate good
> behavior after the patch.
Alvaro Herrera writes:
> If this is OK, we should make this API quirkiness very explicit in the
> comments, so the patch needs to be a few lines larger in order to be
> committable. Also, perhaps the check should be that contype equals
> either primary or unique, rather than it doesn't equal
My colleague Andrew Bille found another bug in master
(b4e936859dc441102eb0b6fb7a104f3948c90490) and REL_15_STABLE
(2c63b0930aee1bb5c265fad4a65c9d0b62b1f9da): pg_collation.colliculocale
is not dumped. See check_icu_locale.sh:
In the old cluster:
SELECT collname, colliculocale FROM
On 2022-Aug-23, Zhihong Yu wrote:
> This is what I came up with.
I suggest you provide a set of SQL commands that provoke some wrong
behavior with the original code, and show that they generate good
behavior after the patch. Otherwise, it's hard to evaluate the
usefulness of this.
--
Álvaro
On 2022-Aug-23, Zhihong Yu wrote:
> A bigger question I have, even with the additional filtering, is what if
> there are multiple constraints ?
> How do we decide which unique / primary key constraint to return ?
>
> Looks like there is no known SQL statements leading to such state, but
> should
On Wed, Aug 17, 2022 at 11:17:24AM +0530, Bharath Rupireddy wrote:
> + "logical decoding file(s)
> processing time=%ld.%03d s",
I would suggest shortening this to something like "logical decoding
processing" or "logical replication processing."
>
Nathan Bossart writes:
> I don't know if it makes sense to document this in basic_archive. On one
> hand, it seems like folks will commonly encounter this behavior with this
> module, so this feels like a natural place for such a note. But on the
> other hand, this is generic behavior for any
Pavel Stehule writes:
> út 23. 8. 2022 v 19:27 odesílatel Andres Freund napsal:
>> I think that's not true unfortunately. You can specify return types, and
>> composite types can be populated. Which essentially requires arbitrary
>> coercions.
> Please, can you send an example? Maybe we try to
On Tue, Aug 23, 2022 at 04:18:52PM +0200, talk to ben wrote:
> --- a/doc/src/sgml/basic-archive.sgml
> +++ b/doc/src/sgml/basic-archive.sgml
> @@ -68,6 +68,19 @@ basic_archive.archive_directory =
> '/path/to/archive/directory'
> to any archiving still in progress, but users should use extra
út 23. 8. 2022 v 19:27 odesílatel Andres Freund napsal:
> Hi,
>
> On 2022-08-23 18:06:22 +0200, Pavel Stehule wrote:
> > The errors that should be handled are related to json structure errors. I
> > don't think so we have to handle all errors and all conversions.
> >
> > The JSON knows only
On Tue, Aug 23, 2022 at 1:23 PM Andres Freund wrote:
> > But that's exactly what I'm complaining about. Catching an error that
> > unwound a bunch of stack frames where complicated things are happening
> > is fraught with peril. There's probably a bunch of errors that could
> > be thrown from
Andres Freund writes:
> On 2022-08-23 12:26:55 -0400, Robert Haas wrote:
>> But that's exactly what I'm complaining about. Catching an error that
>> unwound a bunch of stack frames where complicated things are happening
>> is fraught with peril. There's probably a bunch of errors that could
>> be
Hi,
On 2022-08-23 18:06:22 +0200, Pavel Stehule wrote:
> The errors that should be handled are related to json structure errors. I
> don't think so we have to handle all errors and all conversions.
>
> The JSON knows only three types - and these conversions can be written
> specially for this
Hi,
On 2022-08-23 13:18:49 -0400, Jonathan S. Katz wrote:
> Taking RMT hat off, if the outcome is "revert", I do want to ensure we don't
> lose momentum on getting this into v16. I know a lot of time and effort has
> gone into this featureset and it seems to be trending in the right
> direction.
"Jonathan S. Katz" writes:
> I saw Andrew suggest that the controversial parts of the patchset may be
> severable from some of the new functionality, so I would like to see
> that proposal and if it is enough to overcome concerns.
It's an interesting suggestion. Do people have the cycles
Hi,
On 2022-08-23 12:26:55 -0400, Robert Haas wrote:
> On Tue, Aug 23, 2022 at 11:55 AM Andres Freund wrote:
> > I don't think that's quite realistic - that's the input/output functions for
> > all types, basically. I'd be somewhat content if we'd a small list of very
> > common coercion paths
On Tue, Aug 23, 2022 at 10:10 AM Zhihong Yu wrote:
> Hi,
> I was looking at the following code in DetachPartitionFinalize():
>
> /* If there's a constraint associated with the index, detach it
> too */
> constrOid =
> get_relation_idx_constraint_oid(RelationGetRelid(partRel),
>
On 8/23/22 11:08 AM, Tom Lane wrote:
Robert Haas writes:
At the end of the day, the RMT is going to have to take a call here.
It seems to me that Andres's concerns about code quality and lack of
comments are probably somewhat legitimate, and in particular I do not
think the use of
On Tue, Aug 23, 2022 at 01:03:03PM +0700, John Naylor wrote:
> On Tue, Aug 23, 2022 at 10:32 AM Nathan Bossart
>> Here's a new version of the patch with the 32-bit changes and calls to
>> lfind() removed.
>
> LGTM overall. My plan is to split out the json piece, adding tests for
> that, and
On 8/23/22 01:53, Drouvot, Bertrand wrote:
> That sounds all good to me, except a typo for the author in the commit
> message: s/Jocob/Jacob/
Thanks, I missed that on my readthrough! :D
Patch looks good to me, too, with one question:
> @@ -2688,6 +2689,7 @@ InitProcessGlobals(void)
Hi,
I was looking at the following code in DetachPartitionFinalize():
/* If there's a constraint associated with the index, detach it too
*/
constrOid =
get_relation_idx_constraint_oid(RelationGetRelid(partRel),
idxid);
As
On Tue, Aug 23, 2022 at 9:47 AM Alvaro Herrera
wrote:
> On 2022-Aug-23, Zhihong Yu wrote:
>
> > I was thinking of the following patch.
> > Basically, if there is only one matching constraint. we still return it.
> >
> > diff --git a/src/postgres/src/backend/catalog/pg_constraint.c
> >
On 2022-Aug-22, Amit Langote wrote:
> Yeah, I think it makes sense to think of the NOT NULL constraints on
> their own in this case, without worrying about the PK constraint that
> created them in the first place.
Cool, that's enough votes that I'm comfortable implementing things that
way.
>
On 2022-Aug-23, Zhihong Yu wrote:
> I was thinking of the following patch.
> Basically, if there is only one matching constraint. we still return it.
>
> diff --git a/src/postgres/src/backend/catalog/pg_constraint.c
> b/src/postgres/src/backend/catalog/pg_constraint.c
> index
On 23.08.2022 19:06, Pavel Stehule wrote:
Hi
út 23. 8. 2022 v 17:55 odesílatel Andres Freund
napsal:
Hi,
On 2022-08-23 10:51:04 -0400, Robert Haas wrote:
> I do not think that using subtransactions as part of the expression
> evaluation process is a sound idea pretty much
On Tue, Aug 23, 2022 at 9:30 AM Alvaro Herrera
wrote:
> On 2022-Aug-23, Jehan-Guillaume de Rorthais wrote:
>
> Hi,
>
> [...]
>
> > However, it seems get_relation_idx_constraint_oid(), introduced in
> eb7ed3f3063,
> > assume there could be only ONE constraint depending to an index. But in
> fact,
On 2022-Aug-23, Jehan-Guillaume de Rorthais wrote:
Hi,
[...]
> However, it seems get_relation_idx_constraint_oid(), introduced in
> eb7ed3f3063,
> assume there could be only ONE constraint depending to an index. But in fact,
> multiple constraints can rely on the same index, eg.: the PK and a
On Mon, Aug 22, 2022 at 1:50 PM Ibrar Ahmed wrote:
> This will help to complete the tasks. I start looking at that; I will let you
> know how we both
> manage to share the load
I have updated the CFM checklist through the "2 days before CF"
section. Let me know if you have
On Tue, Aug 23, 2022 at 11:55 AM Andres Freund wrote:
> I don't think that's quite realistic - that's the input/output functions for
> all types, basically. I'd be somewhat content if we'd a small list of very
> common coercion paths we knew wouldn't error out, leaving things like OOM
> aside.
Hi,
Thanks for the review!
>
> 1.
> In FilterOutNotSuitablePathsForReplIdentFull(), is
> "nonPartialIndexPathList" a
> good name for the list? Indexes on only expressions are also be filtered.
>
> +static List *
> +FilterOutNotSuitablePathsForReplIdentFull(List *pathlist)
> +{
> +
Hi
út 23. 8. 2022 v 17:55 odesílatel Andres Freund napsal:
> Hi,
>
> On 2022-08-23 10:51:04 -0400, Robert Haas wrote:
> > I do not think that using subtransactions as part of the expression
> > evaluation process is a sound idea pretty much under any
> > circumstances. Maybe if the
Hi,
On 2022-08-23 10:51:04 -0400, Robert Haas wrote:
> I do not think that using subtransactions as part of the expression
> evaluation process is a sound idea pretty much under any
> circumstances. Maybe if the subtransations aren't commonly created and
> don't usually get XIDs there wouldn't be
On Tue, Aug 23, 2022 at 8:07 AM Jehan-Guillaume de Rorthais
wrote:
> Hi all,
>
> I've been able to work on this issue and isolate where in the code the
> oddity
> is laying.
>
> During ATExecAttachPartition(), AttachPartitionEnsureIndexes() look for
> existing
> required index on the partition
On 2022-08-23 Tu 11:08, Tom Lane wrote:
> Robert Haas writes:
>> At the end of the day, the RMT is going to have to take a call here.
>> It seems to me that Andres's concerns about code quality and lack of
>> comments are probably somewhat legitimate, and in particular I do not
>> think the use
Hi,
On 2022-08-23 11:08:31 -0400, Tom Lane wrote:
> As you say, we've delegated this sort of decision to the RMT, but
> if I were on the RMT I'd be voting to revert.
Yea, I don't really see an alternative at this point. If we really wanted we
could try to cut the more complicated pieces out,
Robert Haas writes:
> At the end of the day, the RMT is going to have to take a call here.
> It seems to me that Andres's concerns about code quality and lack of
> comments are probably somewhat legitimate, and in particular I do not
> think the use of subtransactions is a good idea. I also don't
Hi all,
I've been able to work on this issue and isolate where in the code the oddity
is laying.
During ATExecAttachPartition(), AttachPartitionEnsureIndexes() look for existing
required index on the partition to attach. It creates missing index, or sets the
parent's index when a matching one
On Tue, Aug 23, 2022 at 12:33 AM Thomas Munro wrote:
> On Tue, Aug 23, 2022 at 4:21 PM Michael Paquier wrote:
> > On Mon, Aug 08, 2022 at 06:15:46PM +1200, Thomas Munro wrote:
> > > The attached patch that simply moves the cache invalidation into
> > > report_invalid_record(), so that it's
On Mon, Aug 22, 2022 at 9:52 PM Jonathan S. Katz wrote:
> > Andres, Robert: Do these changes address your concerns about the use of
> > substransactions and reduce the risk of xid wraparound?
>
> Andres, Andrew, Amit, Robert -- as you have either worked on this or
> expressed opinions -- any
On 8/23/22 12:13 AM, Michael Paquier wrote:
On Mon, Aug 22, 2022 at 07:57:29PM -0700, Andres Freund wrote:
To me it feels like there's a probably too much work here to cram it at this
point. If several other committers shared the load of working on this it'd
perhaps be doable, but I've not seen
On Tue, Aug 23, 2022 at 2:06 AM Dilip Kumar wrote:
> OTOH, if we keep the two separate ranges for the user and system table
> then we don't need all this complex logic of conflict checking.
True. That's the downside. The question is whether it's worth adding
some complexity to avoid needing
Would this addition to the documentation be ok ? I hope the english is not
too broken ..
From 8ea8c21413eeac8fbd37527e64820cbdca3a5d7a Mon Sep 17 00:00:00 2001
From: benoit
Date: Mon, 22 Aug 2022 12:00:46 +0200
Subject: [PATCH] basic_archive parameter visibility doc patch
Module parameters are
On Mon, Aug 22, 2022 at 9:29 PM Kyotaro Horiguchi
wrote:
> Today, I see some error messages have been added, two of which look
> somewhat inconsistent.
>
> commands/user.c
> @707:
> >errmsg("must have admin option on role \"%s\" to add members",
> @1971:
> >errmsg("grantor must have ADMIN
On Mon, Aug 22, 2022 at 10:38 PM Nathan Bossart
wrote:
> There was some previous discussion on this [0] [1].
>
> [0] https://postgr.es/m/2B4510B2-3D70-4990-BFE3-0FE64041C08A%40amazon.com
> [1]
> https://postgr.es/m/20220127.100738.1985658263632578184.horikyota.ntt%40gmail.com
Thanks. It seems
On Tue, Aug 23, 2022 at 11:27:45AM +0200, Pavel Stehule wrote:
> út 23. 8. 2022 v 7:56 odesílatel Julien Rouhaud napsal:
>
> >
> > I've been thinking a bit more about the shadowing, and one scenario we
> > didn't
> > discuss is something like this naive example:
> >
> > CREATE TABLE tt(a text, b
On 2022-Aug-23, Kyotaro Horiguchi wrote:
> commands/user.c
> @707:
> >errmsg("must have admin option on role \"%s\" to add members",
> @1971:
> >errmsg("grantor must have ADMIN OPTION on \"%s\"",
>
> A grep'ing told me that the latter above is the only outlier among 6
> occurrences in
On Tue, 23 Aug 2022 at 11:00, Dave Page wrote:
>
> Often it is beneficial to review one's schema with a view to removing indexes
> (and sometimes tables) that are no longer required. It's very difficult to
> understand when that is the case by looking at the number of scans of a
> relation as,
On Tue, 23 Aug 2022 at 05:29, Greg Stark wrote:
> Having this function would be great (I admit I never responded because
> I never figured out if your suggestion was right or not:). But should
> it also be added to the pg_stat_activity view? Perhaps even just in
> the SQL view using the
On Tue, Aug 23, 2022 at 3:16 PM Amit Kapila wrote:
>
> > OTOH, if we keep the two separate ranges for the user and system table
> > then we don't need all this complex logic of conflict checking. From
> > the old cluster, we can just remember the relfilenumbr of the
> > pg_largeobject, and in
Often it is beneficial to review one's schema with a view to removing
indexes (and sometimes tables) that are no longer required. It's very
difficult to understand when that is the case by looking at the number of
scans of a relation as, for example, an index may be used infrequently but
may be
1 - 100 of 115 matches
Mail list logo
