On Sat, Jul 31, 2021 at 2:39 PM Amit Kapila wrote:
> Here, the test is expecting 2 prepared transactions corresponding to
> two subscriptions but it waits for just one subscription via
> appname_copy. It should wait for the second subscription using
> $appname as well.
>
> What do you think?
I a
On Wed, Jul 14, 2021 at 11:52 AM Amit Kapila wrote:
>
> On Mon, Jul 12, 2021 at 9:14 AM Peter Smith wrote:
>
> Pushed.
>
As reported by Michael [1], there is one test failure related to this
commit. The failure is as below:
# Failed test 'transaction is prepared on subscriber'
# at t/021_tw
On 7/30/21, 4:52 PM, "Alvaro Herrera" wrote:
> I think that creating files out of order might be problematic. On the
> archiver side, pgarch_readyXlog() expects to return the oldest
> archivable file; but if we create a newer segment's .ready file first,
> it is possible that a directory scan wou
On 2021-Jul-30, Alvaro Herrera wrote:
> We set archiver's latch on each XLogArchiveNotify(), but if we're doing
> it in a loop such as in NotifySegmentsReadyForArchive() perhaps it is
> better to create all the .ready files first and do PgArchWakeup() at the
> end. I'm not convinced that this is
Hi,
I spent a bit of time hacking on the Generation context, adding the two
improvements discussed in this thread:
1) internal handling of block sizes, similar to what AllocSet does (it
pretty much just copies parts of it)
2) keeper block (we keep one empry block instead of freeing it)
3)
Thomas Munro writes:
> In any case, we already do it which is why wrasse (Sun Studio
> compiler) warns about indkey in pg_index.h. Curiously, indkey is not
> always the final member of the containing struct, depending on
> CATALOG_VARLEN...
Hm? CATALOG_VARLEN is never to be defined, see genbki.
On 2021/07/30 22:27, houzj.f...@fujitsu.com wrote:
Hi,
When reviewing logicalreplication related patches, I noticed the function
param ReorderBufferTXN *txn not used in the function maybe_send_schema(). Since
this is not an external function, I think it might be better to remove the
unused p
On Sat, Jul 31, 2021 at 7:52 AM Andres Freund wrote:
> On 2021-07-30 15:35:30 -0400, Melanie Plageman wrote:
> > * I think that having TBMIterateResult inside of TBMIterator is not
> > well-defined C language behavior. In [1], it says
> >
> > "Structures with flexible array members (or unions
Hi,
On 2021-06-17 16:37:51 -0700, Jeff Davis wrote:
> In theory, it could break a client that issues Parse+Bind+Execute for a
> CopyIn/CopyBoth command without a Sync, but I'm not sure there are any
> clients that do that, and it's arguable whether the documentation
> permitted that or not anyway.
On 2021-Jul-30, Bossart, Nathan wrote:
> Yes, that was what I was worried about. However, I just performed a
> variety of tests with just 0001 applied, and I am beginning to suspect
> my concerns were unfounded. With wal_buffers set very high,
> synchronous_commit set to off, and a long sleep at
Hi,
On 2021-07-30 17:49:09 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2021-07-30 13:58:51 -0400, Tom Lane wrote:
> >> I've not read this version of the patch, but I see from the cfbot's
> >> results that it's broken postgres_fdw.
>
> > I think this may partially be an issue with the w
Hi,
I think it'd make sense to apply the first few patches now, they seem
uncontroversial and simple enough.
On 2021-07-31 00:33:34 +0300, Heikki Linnakangas wrote:
> From 0cfb852e320bd8fe83c588d25306d5b4c57b9da6 Mon Sep 17 00:00:00 2001
> From: Heikki Linnakangas
> Date: Mon, 21 Jun 2021 22:14
On 7/30/21, 3:23 PM, "Alvaro Herrera" wrote:
> That's great to hear. I'll give 0001 a look again.
Much appreciated.
Nathan
On 2021-Jul-30, Bossart, Nathan wrote:
> On 7/30/21, 11:34 AM, "Alvaro Herrera" wrote:
> > Hmm ... I'm not sure we're prepared to backpatch this kind of change.
> > It seems a bit too disruptive to how replay works. I think patch we
> > should be focusing solely on patch 0001 to surgically fix t
On Thu, Jul 29, 2021 at 12:22 PM Michael Meskes wrote:
> I just wanted to let you know that I'm well aware of this thread but
> need to get through my backlog before I can comment. Sorry for the
> delay.
The RMT discussed this recently. We are concerned about this issue,
including how it has been
On Fri, 2021-07-02 at 08:44 -0400, Robert Haas wrote:
> Right, that seems like a good goal. Thinking about this a little
> more,
> it's only holding off *cancel* interrupts, not *all* interrupts, so
> presumably you can still terminate the backend in this state. That's
> not so bad, and it's not cl
Andres Freund writes:
> On 2021-07-30 13:58:51 -0400, Tom Lane wrote:
>> I've not read this version of the patch, but I see from the cfbot's
>> results that it's broken postgres_fdw.
> I think this may partially be an issue with the way that postgres_fdw
> uses the callback than with the patch. I
Gilles Darold writes:
> Le 26/07/2021 à 21:56, Tom Lane a écrit :
>> I'm inclined to just drop the regexp_replace additions. I don't think
>> that the extra parameters Oracle provides here are especially useful.
>> They're definitely not useful enough to justify creating compatibility
>> hazards
On Fri, 2021-07-30 at 16:22 +0900, Michael Paquier wrote:
> Looking at the past, it was the intention of 05f3f9c7 to go through
> the hook even if SET TABLESPACE does not move the relation, so you
> are
> right that ALTER TABLE is inconsistent to not do the same for LOGGED,
> UNLOGGED and ACCESS ME
On 30/07/21 8:05 pm, Geoff Winkless wrote:
On Thu, 29 Jul 2021 at 22:46, Gavin Flower
wrote:
Though in code, possibly it would be better to just use 'up-to-date' in
code for consistency and to make the it easier to grep?
If it's causing an issue, perhaps using a less syntactically
problematic
Hi,
On 2021-07-30 13:58:51 -0400, Tom Lane wrote:
> Gilles Darold writes:
> > [ 1-startcommand_xact_callback-v2.diff ]
>
> I've not read this version of the patch, but I see from the cfbot's
> results that it's broken postgres_fdw. I recall that postgres_fdw
> uses the XactCallback and SubXa
On 7/30/21 10:38 PM, Andres Freund wrote:
Hi,
On 2021-07-30 18:42:18 +1200, David Rowley wrote:
While reviewing and benchmarking 91e9e89dc (Make nodeSort.c use Datum
sorts for single column sorts), I noticed that we use a separate
memory context to store tuple data and we just reset when we're
vignesh C writes:
[ v6-0001-Included-the-actual-datatype-used-in-logical-repl.patch ]
I see what you want to do here, but the way you did it seems quite
detrimental to the readability of the field descriptions.
Parenthesized interjections should be used sparingly.
I'm inclined to think that the
Bruce Momjian writes:
> On Fri, Jul 30, 2021 at 03:54:42PM -0400, Tom Lane wrote:
>> Having said that, I also agree that it's not great that '1.4 years'
>> is converted to '1 year 4 mons' (1.3... years) rather than
>> '1 year 5 mons' (1.41666... years). The latter seems like a clearly
>> sane
Hi,
On 2021-07-30 18:42:18 +1200, David Rowley wrote:
> While reviewing and benchmarking 91e9e89dc (Make nodeSort.c use Datum
> sorts for single column sorts), I noticed that we use a separate
> memory context to store tuple data and we just reset when we're done
> if the sort fits in memory, or w
On Sat, Jul 10, 2021 at 9:13 AM vignesh C wrote:
>
> On Mon, May 31, 2021 at 10:47 AM Greg Nancarrow wrote:
> >
> > On Sat, Mar 6, 2021 at 12:31 PM Thomas Munro wrote:
> > >
> > > On Tue, Mar 2, 2021 at 11:27 PM Thomas Munro
> > > wrote:
> > > > On Fri, Feb 12, 2021 at 11:02 AM Melanie Plagema
On 7/30/21, 11:34 AM, "Alvaro Herrera" wrote:
> Hmm ... I'm not sure we're prepared to backpatch this kind of change.
> It seems a bit too disruptive to how replay works. I think patch we
> should be focusing solely on patch 0001 to surgically fix the precise
> bug you see. Does patch 0002 exist
Hi,
On 2021-07-30 10:16:44 -0400, Robert Haas wrote:
> 2021-07-30 09:39:43.579 EDT [63702] LOG: redo starts at 0/14A2F48
> 2021-07-30 09:39:44.129 EDT [63702] LOG: redo done at 0/15F48230
> system usage: CPU: user: 0.25 s, system: 0.25 s, elapsed: 0.55 s
> 2021-07-30 09:39:44.129 EDT [63702] LOG
On Fri, Jul 30, 2021 at 03:54:42PM -0400, Tom Lane wrote:
> Having said that, I also agree that it's not great that '1.4 years'
> is converted to '1 year 4 mons' (1.3... years) rather than
> '1 year 5 mons' (1.41666... years). The latter seems like a clearly
> saner translation. I would reall
On Fri, Jul 30, 2021 at 03:47:53PM -0400, Robert Haas wrote:
> On Fri, Jul 30, 2021 at 3:20 PM Bruce Momjian wrote:
> > Uh, what do you suggest then? You wanted the years/months fixed, and
> > rounding at spill stop time makes sense, and fixes the problem.
>
> Hmm, maybe I misunderstood. Are you
Bruce Momjian writes:
> On Fri, Jul 30, 2021 at 03:08:56PM -0400, Robert Haas wrote:
>> Just to be clear, I am against this patch. I don't think it's a
>> minimal change for the reported problem, and I think some people will
>> be unhappy about the behavior changes.
> Uh, what do you suggest then
Hi,
On 2021-07-30 15:35:30 -0400, Melanie Plageman wrote:
> * I think that having TBMIterateResult inside of TBMIterator is not
> well-defined C language behavior. In [1], it says
>
> "Structures with flexible array members (or unions who have a
> recursive-possibly structure member with fl
On Fri, Jul 30, 2021 at 3:34 PM Andres Freund wrote:
> The lower memory usage also often will result in a better cache
> utilization - which is a crucial factor for index vacuuming when the
> index order isn't correlated with the heap order. Cache misses really
> are a crucial performance factor t
On Fri, Jul 30, 2021 at 3:20 PM Bruce Momjian wrote:
> Uh, what do you suggest then? You wanted the years/months fixed, and
> rounding at spill stop time makes sense, and fixes the problem.
Hmm, maybe I misunderstood. Are you saying that you think the patch
will fix cases like interval '-1.7 yea
On Wed, Jul 28, 2021 at 2:10 PM Andres Freund wrote:
> On 2021-07-28 13:37:48 -0400, Melanie Plageman wrote:
>
> > Each IO will have its own TBMIterateResult allocated and returned by the
> > PgStreamingRead helper and freed later by
> > heapam_scan_bitmap_next_block() before requesting the next b
Hi,
On 2021-07-30 15:13:49 -0400, Robert Haas wrote:
> On Thu, Jul 29, 2021 at 3:14 PM Andres Freund wrote:
> > I think those advantages are far outstripped by the big disadvantage of
> > needing to either size the array accurately from the start, or to
> > reallocate the whole array. Our curren
On Fri, Jul 30, 2021 at 03:08:56PM -0400, Robert Haas wrote:
> On Fri, Jul 30, 2021 at 3:03 PM Bruce Momjian wrote:
> > Here is an updated patch that includes some of your ideas.
>
> Just to be clear, I am against this patch. I don't think it's a
> minimal change for the reported problem, and I t
On Thu, Jul 29, 2021 at 3:14 PM Andres Freund wrote:
> I think those advantages are far outstripped by the big disadvantage of
> needing to either size the array accurately from the start, or to
> reallocate the whole array. Our current pre-allocation behaviour is
> very wasteful for most vacuums
On Fri, Jul 30, 2021 at 3:03 PM Bruce Momjian wrote:
> Here is an updated patch that includes some of your ideas.
Just to be clear, I am against this patch. I don't think it's a
minimal change for the reported problem, and I think some people will
be unhappy about the behavior changes.
--
Rober
On Fri, Jul 30, 2021 at 12:49:34PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Now that I think of it, I will just remove the word "rounded" from the
> > back branch docs so we are technically breaking the documented API less
> > in PG 15.
>
> I think your first idea was better. Not docum
On Tue, Jul 20, 2021 at 5:41 PM Tomas Vondra
wrote:
> I think the crucial aspect of this that needs discussion/feedback the
> most is the transactional vs. non-transactional behavior. All the other
> questions are less important / cosmetic.
Yeah, it seems really tricky to me to get this right. Th
On 2021-Jul-28, Bossart, Nathan wrote:
> On 7/27/21, 6:05 PM, "Alvaro Herrera" wrote:
> > I'm not sure I understand what's the reason not to store this value in
> > pg_control; I feel like I'm missing something. Can you please explain?
>
> Thanks for taking a look.
>
> The only reason I can t
Hi,
Here's a an updated version of this patch - rebased to current master,
and fixing some of the issues raised in Peter's review.
Mainly, this adds a TAP test to src/test/subscription, focusing on
testing the various situations with transactional and non-transactional
behavior (with subtran
Gilles Darold writes:
> [ 1-startcommand_xact_callback-v2.diff ]
I've not read this version of the patch, but I see from the cfbot's
results that it's broken postgres_fdw. I recall that postgres_fdw
uses the XactCallback and SubXactCallback mechanisms, so I'm betting
this means that you've c
On 7/30/21 1:05 PM, Tom Lane wrote:
I don't see the need for it anyway. What is different from just
putting the update actions into an extension version upgrade
script created according to the current rules, and then setting
that new extension version as the default version in the extension
buil
Jan Wieck writes:
> An alternative to this would be a recommended version number scheme for
> extensions. If extensions were numbered
> MAJOR_SERVER.MAJOR_EXTENSION.MINOR_EXTENSION
> then pg_upgrade could check the new cluster for the existence of an SQL
> script that upgrades the extension
Bruce Momjian writes:
> On Fri, Jul 30, 2021 at 12:04:39PM -0400, Bruce Momjian wrote:
>> Unless I hear more feedback, I plan to apply this doc patch to all
>> branches with the word "rounded" changed to "truncated" in the back
>> branches, and apply the rounded code changes to master.
> Now that
On 7/30/21 7:40 AM, Julien Rouhaud wrote:
On Fri, Jul 30, 2021 at 07:33:55AM -0400, Dave Cramer wrote:
Ah, ok, got it, thanks. Well I'm not sure how to deal with this.
The only thing I can think of is that we add a post_upgrade function to the
API.
All extensions would have to implement this.
On 7/30/21 7:33 AM, Dave Cramer wrote:
Yes, but as I said twice only if the currently installed version is
different
from the default version. Otherwise ALTER EXTENSION UPGRADE is a no-op.
Ah, ok, got it, thanks. Well I'm not sure how to deal with this.
The only thing I can thi
On Thu, Jul 29, 2021 at 06:19:56PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I think we need to first give clear instructions on how to find out if
> > an extension update is available, and then how to update it. I am
> > thinking we should supply a query which reports all extensions tha
On 7/30/21, 2:22 AM, "Daniel Gustafsson" wrote:
> LGTM. I took the liberty to rephrase the "and exit" part of the initdb help
> output match the other exiting options in there. Barring objections, I think
> this is ready.
LGTM. Thanks!
Nathan
On Fri, Jul 30, 2021 at 12:04:39PM -0400, Bruce Momjian wrote:
> On Wed, Jul 28, 2021 at 11:19:16AM -0400, Bruce Momjian wrote:
> > On Wed, Jul 28, 2021 at 08:42:31AM +0100, Dean Rasheed wrote:
> > > So it's equal even without calling justify_interval() on the result.
> > >
> > > FWIW, I remain of
On Wed, Jul 28, 2021 at 11:19:16AM -0400, Bruce Momjian wrote:
> On Wed, Jul 28, 2021 at 08:42:31AM +0100, Dean Rasheed wrote:
> > So it's equal even without calling justify_interval() on the result.
> >
> > FWIW, I remain of the opinion that the interval literal code should
> > just spill down to
Daniel Gustafsson writes:
> I took another look at this today, and propose to push the attached. The
> pg_dump fix goes all the way back to 9.6 whereas the pg_basebackup fix is from
> 11 and onwards. The adjacent shadowed variable bug in pg_dump is also present
> since 9.6.
> Thoughts?
Generall
I wrote:
> Alexander Pyhalov writes:
>> Do we we need to inspect only case_arg_cxt->state? Can we assert that
>> collation == case_arg_cxt->collation?
> Perhaps, but:
> ...
Oh, actually there's a third point: the shakiest part of this logic
is the assumption that we've correctly matched a CaseT
I took another look at this today, and propose to push the attached. The
pg_dump fix goes all the way back to 9.6 whereas the pg_basebackup fix is from
11 and onwards. The adjacent shadowed variable bug in pg_dump is also present
since 9.6.
Thoughts?
--
Daniel Gustafsson https://v
Daniel Gustafsson writes:
>> On 30 Jul 2021, at 17:06, Tom Lane wrote:
>> I wonder if we should convert the Assert into an actual test-and-elog, say
>>
>> /* Otherwise, we'd better have an active Portal */
>> portal = ActivePortal;
>> -Assert(portal != NULL);
>> +if (unlikely(p
> On 30 Jul 2021, at 17:06, Tom Lane wrote:
> I wonder if we should convert the Assert into an actual test-and-elog, say
>
> /* Otherwise, we'd better have an active Portal */
> portal = ActivePortal;
> - Assert(portal != NULL);
> + if (unlikely(portal == NULL))
> +
Michael Paquier writes:
> On Fri, Jul 30, 2021 at 08:57:35AM +, liuhuail...@fujitsu.com wrote:
>> When I used SPI_execute_plan function on PG12 which commit 41c6a5be is used,
>> Segment fault occurred.
> I see nothing wrong in this commit, FWIW.
> But I see an issue with your code. It seems
On Fri, Jul 30, 2021 at 7:47 AM Ranier Vilela wrote:
> The patch attached does not apply cleanly,
> please can fix it?
It applies just fine with "patch", for those wondering.
--
John Naylor
EDB: http://www.enterprisedb.com
On Fri, Jul 30, 2021 at 2:42 AM David Rowley wrote:
> Master:
>Sort Method: quicksort Memory: 5541kB
> Patched:
>Sort Method: quicksort Memory: 3197kB
Whoa.
> work_mem = '4GB';
> Testmastergen sortcompare
> Test1317.2665.6210%
> Test2228.6388.9170%
>
Alexander Pyhalov writes:
> The only thing I'm confused about is in T_CaseTestExpr case - how can it
> be that CaseTestExpr collation doesn't match case_arg_cxt->collation ?
> Do we we need to inspect only case_arg_cxt->state? Can we assert that
> collation == case_arg_cxt->collation?
Perhaps,
On Fri, Jul 30, 2021 at 4:42 AM Aleksander Alekseev
wrote:
> v2-0001 and v2-0002 look fine, but I don't like much the idea of introducing
> a new GUC in v2-0003. It's for very specific needs, which most of the users,
> I believe, don't care about. I suggest dealing with v2-0001 and v2-0002 first
Hi,
When reviewing logicalreplication related patches, I noticed the function
param ReorderBufferTXN *txn not used in the function maybe_send_schema(). Since
this is not an external function, I think it might be better to remove the
unused paramater.
Best regards,
Houzj
0001-remove-unused-par
On Friday, July 30, 2021 2:52 PM Greg Nancarrow wrote:
> On Fri, Jul 30, 2021 at 4:02 PM Amit Kapila wrote:
> >
> > > Besides, I think we need a new default value about parallel dml
> > > safety. Maybe 'auto' or 'null'(different from
> > > safe/restricted/unsafe). Because, user is likely to alter
On Thu, Jul 29, 2021 at 3:16 PM Andres Freund wrote:
> Not sure there's enough concensus on the idea for that. I personally
> think that's a good approach at reducing relevant complexity, but I
> don't know if anybody agrees...
There does seem to be agreement on the proposed patch, so I have comm
On Fri, Jul 30, 2021 at 08:57:35AM +, liuhuail...@fujitsu.com wrote:
> When I used SPI_execute_plan function on PG12 which commit 41c6a5be is used,
> Segment fault occurred.
>
> PS: If commit 41c6a5be is not used, this phenomenon will not happen.
I see nothing wrong in this commit, FWIW.
>
Em sex., 30 de jul. de 2021 às 05:57, liuhuail...@fujitsu.com <
liuhuail...@fujitsu.com> escreveu:
> Hi, all
>
> When I used SPI_execute_plan function on PG12 which commit 41c6a5be is
> used,
> Segment fault occurred.
>
> PS: If commit 41c6a5be is not used, this phenomenon will not happen.
>
> Rep
On Fri, Jul 30, 2021 at 3:30 AM Greg Nancarrow wrote:
> On Fri, Jul 30, 2021 at 6:57 PM liuhuail...@fujitsu.com
> wrote:
> >
> > When I used SPI_execute_plan function on PG12 which commit 41c6a5be is
> used,
> > Segment fault occurred.
>
> I'm not seeing any such commit.
> Can you provide a link
Em qui., 29 de jul. de 2021 às 21:34, John Naylor <
john.nay...@enterprisedb.com> escreveu:
>
> On Sun, Jul 4, 2021 at 12:27 AM Thomas Munro
> wrote:
> >
> > Since you are experimenting with tuplesort and likely thinking similar
> > thoughts, here's a patch I've been using to explore that area.
On Fri, Jul 30, 2021 at 07:33:55AM -0400, Dave Cramer wrote:
>
> Ah, ok, got it, thanks. Well I'm not sure how to deal with this.
> The only thing I can think of is that we add a post_upgrade function to the
> API.
>
> All extensions would have to implement this.
It seems like a really big hamme
>
> Yes, but as I said twice only if the currently installed version is
> different
> from the default version. Otherwise ALTER EXTENSION UPGRADE is a no-op.
>
Ah, ok, got it, thanks. Well I'm not sure how to deal with this.
The only thing I can think of is that we add a post_upgrade function to
On Fri, Jul 30, 2021 at 07:18:56AM -0400, Dave Cramer wrote:
>
> So my understanding is that upgrade is going to run all of the SQL files
> from whatever version the original instance was up to the current version.
>
> I'm at a loss as to how this would not work ? How do you upgrade your
> extens
On Fri, 30 Jul 2021 at 07:07, Julien Rouhaud wrote:
> On Fri, Jul 30, 2021 at 06:48:34AM -0400, Dave Cramer wrote:
> >
> > Well I think that's on the extension author to fix. There's only so much
> > pg_upgrade can do here.
> > It seems reasonable that upgrading the extension should upgrade the
>
On Fri, Jul 30, 2021 at 06:48:34AM -0400, Dave Cramer wrote:
>
> Well I think that's on the extension author to fix. There's only so much
> pg_upgrade can do here.
> It seems reasonable that upgrading the extension should upgrade the
> extension to the latest version.
That would only work iff the
>
>
> > On Fri, Jul 9, 2021 at 4:43 PM Tomas Vondra <
> tomas.von...@enterprisedb.com> wrote:
> >
> > The main question I have is whether this should include procedures. I'd
> > probably argue procedures should be considered different from functions
> > (i.e. requiring a separate --procedures-only
On Fri, 30 Jul 2021 at 06:39, Julien Rouhaud wrote:
> On Fri, Jul 30, 2021 at 06:03:50AM -0400, Dave Cramer wrote:
> >
> > What would happen if subsequent to the upgrade "ALTER EXTENSION UPGRADE"
> > was executed ?
>
> If the extension was already up to date on the source cluster then
> obviously
On Fri, Jul 30, 2021 at 06:03:50AM -0400, Dave Cramer wrote:
>
> What would happen if subsequent to the upgrade "ALTER EXTENSION UPGRADE"
> was executed ?
If the extension was already up to date on the source cluster then obviously
nothing.
Otherwise, the extension would be updated. But unless
On Fri, Jul 30, 2021 at 6:57 PM liuhuail...@fujitsu.com
wrote:
>
> When I used SPI_execute_plan function on PG12 which commit 41c6a5be is used,
> Segment fault occurred.
I'm not seeing any such commit.
Can you provide a link to the commit in GitHub?
Regards,
Greg Nancarrow
Fujitsu Australia
On Thu, 29 Jul 2021 at 22:03, Julien Rouhaud wrote:
> On Thu, Jul 29, 2021 at 02:14:56PM -0400, Jan Wieck wrote:
> >
> > I presume that pg_upgrade on a database with that extension installed
> would
> > silently succeed and have the pg_catalog as well as public (or wherever)
> > version of that f
Hi,
On Thu, Jul 29, 2021 at 9:46 PM Robert Haas wrote:
> On Wed, Jul 28, 2021 at 7:33 AM Amul Sul wrote:
> > I was too worried about how I could miss that & after thinking more
> > about that, I realized that the operation for ArchiveRecoveryRequested
> > is never going to be skipped in the sta
On 29/07/2021 21:34, Nikolay Samokhvalov wrote:
I was trying to check a bunch of GINs on some production after switching
from Ubuntu 16.04 to 18.04 and got many errors. So decided to check for
16.04 first (that is still used on prod for that DB), without any
OS/glibc changes.
On 16.04, I stil
> On 30 Jul 2021, at 01:37, Bossart, Nathan wrote:
>
> On 7/29/21, 2:11 AM, "Daniel Gustafsson" wrote:
>> I think removing the word "only" here is a net loss, since it IMO clearly
>> conveyed that this option isn't doing any of the other initdb duties. The
>> documentation states it in more wor
Hi, all
When I used SPI_execute_plan function on PG12 which commit 41c6a5be is used,
Segment fault occurred.
PS: If commit 41c6a5be is not used, this phenomenon will not happen.
Reproduce:
In a background process, the following steps are executed.
--
StartTransactionComm
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
v2-0001 and v2-0002 look fine, but I don't like much the idea
On Friday, July 30, 2021 12:02 PM Peter Smith wrote:
>
> Please find attached the latest patch set v100*
>
> v99-0002 --> v100-0001
>
Thanks for your patch. A few comments on the test file:
1. src/test/subscription/t/022_twophase_cascade.pl
1.1
I saw your test cases for "PREPARE / COMMIT PREP
Tom Lane писал 2021-07-29 23:54:
Alexander Pyhalov writes:
[ 0001-Allow-pushing-CASE-expression-to-foreign-server-v7.patch ]
I looked this over. It's better than before, but the collation
handling is still not at all correct. We have to consider that a
CASE's arg expression supplies the col
On Thu, 29 Jul 2021 at 22:46, Gavin Flower
wrote:
> Though in code, possibly it would be better to just use 'up-to-date' in
> code for consistency and to make the it easier to grep?
If it's causing an issue, perhaps using a less syntactically
problematic synonym like "current" might be better?
:
While testing the numeric_power() patch in [1], I found this problem
trying to use to_char() to format very small numbers:
SELECT to_char(1.2e-1001, '9.9'); -- OK
to_char
1.2e-1001
SELECT to_char(1.2e-1002, '9.9'); -- fails
ERROR: division by zero
It turns out that the
On Thu, Jul 29, 2021 at 08:55:21AM -0700, Jeff Davis wrote:
> I see that ATExecSetTableSpace() also invokes the hook even for a no-
> op. Should we do the same thing for setting the AM?
Looking at the past, it was the intention of 05f3f9c7 to go through
the hook even if SET TABLESPACE does not mov
On Wed, Jul 28, 2021 at 3:42 PM Richard Guo wrote:
> To fix this problem, I'm thinking we can leverage 'root->all_baserels'
> to tell if we are at the topmost scan/join rel, something like:
>
> --- a/src/backend/optimizer/path/allpaths.c
> +++ b/src/backend/optimizer/path/allpaths.c
> @@ -3041,7
On Fri, Jul 30, 2021 at 3:34 AM John Naylor
wrote:
> I'm also attaching your tuplesort patch so others can see what exactly I'm
> comparing.
If you're going to specialize the sort routine for unsigned integer
style abbreviated keys then you might as well cover all relevant
opclasses/types. Almos
On Mon, Jul 12, 2021 at 11:47 AM David Rowley wrote:
> v3 patches
0001 looks mostly fine, except I thought the following could be worded
to say that the bitmap members are offsets into the part_rels array.
To avoid someone confusing them with RT indexes, for example.
+ Bitmapset *live_parts;
93 matches
Mail list logo
