On Wed, May 19, 2021 at 10:28 AM Amit Kapila wrote:
>
> On Tue, May 18, 2021 at 11:25 AM vignesh C wrote:
> >
> > Thanks for the comments, the attached patch has the changes for the same.
> >
>
> Thanks, I have pushed your patch after making minor changes in the comments.
Thanks for pushing this
On Wed, May 19, 2021 at 2:05 PM Michael Paquier wrote:
> On Wed, May 19, 2021 at 10:26:28AM +0530, Amit Kapila wrote:
> > How about moving AfterTriggerEndQuery() to apply_handle_*_internal
> > calls? That way, we might not even need to change Push/Pop calls.
>
> Isn't that going to be a problem wh
At Wed, 19 May 2021 11:19:13 +0530, Dilip Kumar wrote
in
> On Wed, May 19, 2021 at 10:16 AM Fujii Masao
> wrote:
> >
> > On 2021/05/18 15:46, Michael Paquier wrote:
> > > On Tue, May 18, 2021 at 12:48:38PM +0900, Fujii Masao wrote:
> > >> Currently a promotion causes all available WAL to be rep
On Wed, May 19, 2021 at 10:16 AM Fujii Masao
wrote:
>
> On 2021/05/18 15:46, Michael Paquier wrote:
> > On Tue, May 18, 2021 at 12:48:38PM +0900, Fujii Masao wrote:
> >> Currently a promotion causes all available WAL to be replayed before
> >> a standby becomes a primary whether it was in paused s
On Wed, May 19, 2021 at 8:28 AM Fujii Masao wrote:
> >>> I agree with throwing an error for non-numeric junk though.
> >>> Allowing that on the grounds of backwards compatibility
> >>> seems like too much of a stretch.
> >>
> >> +1.
> >
> > +1.
>
> +1
Thanks all for your inputs. PSA which uses pa
On Wed, May 19, 2021 at 10:35 AM Michael Paquier wrote:
>
> On Wed, May 19, 2021 at 10:26:28AM +0530, Amit Kapila wrote:
> > How about moving AfterTriggerEndQuery() to apply_handle_*_internal
> > calls? That way, we might not even need to change Push/Pop calls.
>
> Isn't that going to be a problem
On Wed, May 19, 2021 at 01:46:45PM +0900, Fujii Masao wrote:
> You're thinking to add the test like the following?
> #1. Pause the recovery
> #2. Confirm that pg_get_wal_replay_pause_state() returns 'paused'
> #3. Trigger standby promotion
> #4. Confirm that pg_get_wal_replay_pause_state() returns
On Wed, May 19, 2021 at 10:26:28AM +0530, Amit Kapila wrote:
> How about moving AfterTriggerEndQuery() to apply_handle_*_internal
> calls? That way, we might not even need to change Push/Pop calls.
Isn't that going to be a problem when a tuple is moved to a new
partition in the tuple routing? Thi
On Tue, May 18, 2021 at 11:25 AM vignesh C wrote:
>
> Thanks for the comments, the attached patch has the changes for the same.
>
Thanks, I have pushed your patch after making minor changes in the comments.
--
With Regards,
Amit Kapila.
On Wed, May 19, 2021 at 9:54 AM Michael Paquier wrote:
>
> On Tue, May 18, 2021 at 11:46:25PM -0400, Tom Lane wrote:
> > I was wondering if we could move the ExecCleanupTupleRouting call
> > into finish_estate. copyfrom.c, for example, does that during
> > its shutdown function. Compare also the
On Wed, May 19, 2021 at 8:28 AM osumi.takami...@fujitsu.com
wrote:
>
> On Wednesday, May 19, 2021 11:33 AM Amit Kapila
> wrote:
> > On Wed, May 19, 2021 at 7:59 AM Amit Kapila
> > wrote:
> > >
> > > On Tue, May 18, 2021 at 5:29 PM Amit Kapila
> > wrote:
> > > >
> > > > On Tue, May 18, 2021 at
On 2021/05/19 9:53, Kyotaro Horiguchi wrote:
At Tue, 18 May 2021 12:48:38 +0900, Fujii Masao
wrote in
Currently a promotion causes all available WAL to be replayed before
a standby becomes a primary whether it was in paused state or not.
OTOH, something like immediate promotion (i.e., stand
On 2021/05/18 15:46, Michael Paquier wrote:
On Tue, May 18, 2021 at 12:48:38PM +0900, Fujii Masao wrote:
Currently a promotion causes all available WAL to be replayed before
a standby becomes a primary whether it was in paused state or not.
OTOH, something like immediate promotion (i.e., stan
On Tue, May 18, 2021 at 11:46:25PM -0400, Tom Lane wrote:
> I was wondering if we could move the ExecCleanupTupleRouting call
> into finish_estate. copyfrom.c, for example, does that during
> its shutdown function. Compare also the worker.c changes proposed
> in
Yeah, the first patch I wrote for
Michael Paquier writes:
> On Tue, May 18, 2021 at 07:42:08PM -0400, Tom Lane wrote:
>> This might go away if worker.c weren't so creatively different
>> from the other code paths concerned with executor shutdown.
> The tuple routing has made the whole worker logic messier by a larger
> degree com
On Wed, May 19, 2021 at 12:04 PM Michael Paquier wrote:
> On Tue, May 18, 2021 at 07:42:08PM -0400, Tom Lane wrote:
> > I count three distinct bugs that were exposed by this attempt:
> >
> > 1. In the part of 013_partition.pl that tests firing AFTER
> > triggers on partitioned tables, we have a ca
On Wed, May 19, 2021 at 11:50:52AM +0900, Kyotaro Horiguchi wrote:
> At Tue, 18 May 2021 23:23:02 +0800, Julien Rouhaud wrote
> in
>> The change and the patch look sensible to me.
>
> +1.
Agreed.
--
Michael
signature.asc
Description: PGP signature
On Mon, May 17, 2021 at 04:44:11PM +0900, Michael Paquier wrote:
> On Sun, Mar 21, 2021 at 02:30:04PM -0500, Justin Pryzby wrote:
>
> For this patch, this is going to require a bit more in terms of library
> linking as the block decompression is done in xlogreader.c, so that's one
> thing to worry
On Tue, May 18, 2021 at 07:42:08PM -0400, Tom Lane wrote:
> I count three distinct bugs that were exposed by this attempt:
>
> 1. In the part of 013_partition.pl that tests firing AFTER
> triggers on partitioned tables, we have a case of continuing
> to access a relcache entry that's already been
On 2021/05/19 11:36, Kyotaro Horiguchi wrote:
At Tue, 18 May 2021 19:46:39 +0530, Bharath Rupireddy
wrote in
On Tue, May 18, 2021 at 7:19 PM Tom Lane wrote:
Fujii Masao writes:
On 2021/05/17 18:58, Bharath Rupireddy wrote:
It looks like the values such as '123.456', '789.123' '100$%$#
On Wednesday, May 19, 2021 11:33 AM Amit Kapila wrote:
> On Wed, May 19, 2021 at 7:59 AM Amit Kapila
> wrote:
> >
> > On Tue, May 18, 2021 at 5:29 PM Amit Kapila
> wrote:
> > >
> > > On Tue, May 18, 2021 at 1:29 PM osumi.takami...@fujitsu.com
> > > wrote:
> > > >
> > > > On Monday, May 17, 2021
On Wed, May 19, 2021 at 3:08 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-05-18 11:20:07 +0900, Masahiko Sawada wrote:
> > Yes. It depends on how much the matview refresh gets slower but I
> > think the problem here is that users always are forced to pay the cost
> > for freezing tuple during refre
At Tue, 18 May 2021 23:23:02 +0800, Julien Rouhaud wrote
in
> On Tue, May 18, 2021 at 04:50:31PM +0300, Heikki Linnakangas wrote:
> > That didn't do what I wanted. It only printed the Heap2 records, not Heap,
> > even though I specified both. The reason is that if you specify multiple
> > --rmgr
On 2021/05/18 9:57, Masahiro Ikeda wrote:
On 2021/05/17 22:34, Fujii Masao wrote:
On 2021/05/17 16:39, Masahiro Ikeda wrote:
Thanks for your comments!
+ * is executed, wal records aren't nomally generated (although HOT makes
nomally -> normally?
Yes, fixed.
+ * It's not
At Tue, 18 May 2021 19:46:39 +0530, Bharath Rupireddy
wrote in
> On Tue, May 18, 2021 at 7:19 PM Tom Lane wrote:
> >
> > Fujii Masao writes:
> > > On 2021/05/17 18:58, Bharath Rupireddy wrote:
> > >> It looks like the values such as '123.456', '789.123' '100$%$#$#',
> > >> '9,223,372,' are acc
On Wed, May 19, 2021 at 7:59 AM Amit Kapila wrote:
>
> On Tue, May 18, 2021 at 5:29 PM Amit Kapila wrote:
> >
> > On Tue, May 18, 2021 at 1:29 PM osumi.takami...@fujitsu.com
> > wrote:
> > >
> > > On Monday, May 17, 2021 6:45 PM Amit Kapila
> > > wrote:
> > > >
> > > > We allow taking locks on
On Tue, May 18, 2021 at 5:29 PM Amit Kapila wrote:
>
> On Tue, May 18, 2021 at 1:29 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > On Monday, May 17, 2021 6:45 PM Amit Kapila wrote:
> > >
> > > We allow taking locks on system catalogs, so why prohibit
> > > user_catalog_tables? However, I agree
On Thu, May 6, 2021 at 4:10 AM Matthias van de Meent
wrote:
> See below. I'm not saying we need it _right now_, but at the very
> least I'd like to argue that we should not close the door on varlena
> TIDs, because there _are_ reasons for those TID types. See also below.
Perhaps I was a bit too s
At Tue, 18 May 2021 12:48:38 +0900, Fujii Masao
wrote in
> Currently a promotion causes all available WAL to be replayed before
> a standby becomes a primary whether it was in paused state or not.
> OTOH, something like immediate promotion (i.e., standby becomes
> a primary without replaying out
On Tue, May 18, 2021 at 09:48:59AM +0900, Michael Paquier wrote:
> Okay, thanks. I don't mind taking care of that on HEAD once beta1 is
> shipped, then.
Beta1 just got tagged, so this one has been applied as of 694da19.
--
Michael
signature.asc
Description: PGP signature
On Tue, May 18, 2021 at 3:00 PM Paul A Jungwirth
wrote:
>
> I suspect I'm missing something in the
> analyze/rewriting phase, because I get this error:
>
> ERROR: no value found for parameter 1
> . . .
>
> I was hoping that transformExpr would do everything I need re
> identifying parameters, but
Thomas Munro writes:
> Forgot to post the actual values:
> r = 2563421694876090368
> r = 2563421694876090365
> Smells a bit like a precision problem in the workings of pg_erand48(),
> but as soon as I saw floating point numbers I closed my laptop and ran
> for the door.
Yup. This tes
I discovered $SUBJECT after wondering why hyrax hadn't reported
in recently, and trying to run check-world under CCA to see if
anything got stuck. Indeed it did --- although this doesn't
explain the radio silence from hyrax, because that animal doesn't
run any TAP tests. (Neither does avocet, whi
On Wed, May 19, 2021 at 11:34 AM Thomas Munro wrote:
> I don't understand any of this stuff at all, but I added a bunch of
> printfs and worked out that the first point its local variables
> diverge is here:
>
> /* Random offset */
> r = (uint64) getrand(&random_state2, 0, size - 1
On Wed, May 19, 2021 at 9:51 AM Tom Lane wrote:
> Christoph Berg writes:
> > I can reproducibly get build failures in pgbench on 32-bit i386
> > Debian, both on sid and buster. (The older Debian stretch and Ubuntu
> > bionic are unaffected. Other architectures are also fine.)
>
> The test that's
On Tue, May 18, 2021 at 12:17 PM Bruce Momjian wrote:
> I went with this release note text:
That seems reasonable -- thanks!
--
Peter Geoghegan
Hello hackers,
I'm wrapping up a patch that adds SQL:2011 FOR PORTION OF syntax and
then uses it to implement CASCADE in temporal foreign keys. The FKs
are implemented as triggers, like ordinary FKs, and the trigger
function makes a call through SPI that does `UPDATE %s FOR PORTION OF
%s FROM $%d
Christoph Berg writes:
> I can reproducibly get build failures in pgbench on 32-bit i386
> Debian, both on sid and buster. (The older Debian stretch and Ubuntu
> bionic are unaffected. Other architectures are also fine.)
The test that's failing came in with
6b258e3d688db14aadb58dde2a729393623106
On Tue, May 18, 2021 at 7:29 AM Masahiko Sawada wrote:
> I prefer to have an on/off switch just in case. I remember I also
> commented the same thing before. We’ve discussed a way to control
> whether or not to enable the skipping optimization by adding a new
> mode to INDEX_CLEANUP option, as Pet
Hi,
I can reproducibly get build failures in pgbench on 32-bit i386
Debian, both on sid and buster. (The older Debian stretch and Ubuntu
bionic are unaffected. Other architectures are also fine.)
https://pgdgbuild.dus.dg-i.net/view/Binaries/job/postgresql-14-binaries/635/
https://pgdgbuild.dus.d
On Tue, May 18, 2021 at 12:29 PM Matthias van de Meent
wrote:
> PFA the updated version of this patch. Apart from adding line pointer
> truncation in PageRepairFragmentation (as in the earlier patches), I
> also altered PageTruncateLinePointerArray to clean up all trailing
> line pointers, even if
On Mon, 3 May 2021 at 16:39, Matthias van de Meent
wrote:
> I am planning on fixing this patch sometime
> before the next commit fest so that we can truncate the LP array
> during hot pruning as well, instead of only doing so in the 2nd VACUUM
> pass.
PFA the updated version of this patch. Apart
On Tue, May 18, 2021 at 09:01:44AM -0700, Peter Geoghegan wrote:
> We do retain the reloption, but ignore it. Purely to avoid the dump and reload
> hazard. I think that you could reasonably tell users that it's gone
> completely,
> because it does nothing on either 13 or 14. It's hidden from them
Hi,
On 2021-05-18 20:43:41 +0200, Tomas Vondra wrote:
> Yeah, emitting WAL is not exactly cheap, although it's just a little bit
> more (0.44%). I haven't looked into the details, but I wonder why it has
> such disproportionate impact (although, the 32 vs. 40 sec may be off).
I couldn't reproduce
Hi,
On 2021-05-18 20:34:08 +0200, Tomas Vondra wrote:
> Yeah, I see your point. I agree it's unfortunate there's no way to disable
> freezing during REFRESH MV. For most users that trade-off is probably fine,
> but for some cases (matviews refreshed often, or cases where it's fine to
> pay more bu
On 5/18/21 8:08 PM, Andres Freund wrote:
Hi,
On 2021-05-18 11:20:07 +0900, Masahiko Sawada wrote:
Yes. It depends on how much the matview refresh gets slower but I
think the problem here is that users always are forced to pay the cost
for freezing tuple during refreshing the matview. There i
On 5/18/21 4:20 AM, Masahiko Sawada wrote:
> ...
I think the changes for heap_multi_insert() are fine so we can revert
only heap_insert() part if we revert something from the v14 tree,
although we will end up not inserting frozen tuples into toast tables.
I'd be somewhat unhappy about revert
Hi,
On 2021-05-18 11:20:07 +0900, Masahiko Sawada wrote:
> Yes. It depends on how much the matview refresh gets slower but I
> think the problem here is that users always are forced to pay the cost
> for freezing tuple during refreshing the matview. There is no way to
> disable it unlike FREEZE op
On Tue, May 18, 2021 at 1:29 PM Nitin Jadhav
wrote:
> > The CFBOT had no issues with the patches, so I suspect an issue on your
> > side.
> > http://cfbot.cputube.org/nitin-jadhav.html
>
> I am getting the following error when I try to apply in my machine.
>
> $ git apply
> ../patches/0001-Remov
> The CFBOT had no issues with the patches, so I suspect an issue on your side.
> http://cfbot.cputube.org/nitin-jadhav.html
I am getting the following error when I try to apply in my machine.
$ git apply
../patches/0001-Removed-extra-memory-allocations-from-create_list_bo.patch
../patches/0001-
The issue is non-deterministically triggered in contrib checks, either in
int or ltree, but not elsewhere. This suggests issues specific to these
modules, or triggered by these modules. Hmmm…
Hmm, yeah. A couple of different ways that ltreetest fails without crashing:
https://buildfarm.postg
We do retain the reloption, but ignore it. Purely to avoid the dump and
reload hazard. I think that you could reasonably tell users that it's gone
completely, because it does nothing on either 13 or 14. It's hidden from
them to the extent that that's possible.
Peter Geoghegan
(Sent from my phone)
On Tue, May 18, 2021 at 08:54:56AM -0700, Peter Geoghegan wrote:
> On Tue, May 18, 2021 at 8:48 AM Bruce Momjian wrote:
> > I am thiking the vacuum_cleanup_index_scale_factor existance in a PG 14
> > postgresql.conf will throw an error, unlike 13.x, so I do think we need
> > to mention this so peo
On Tue, May 18, 2021 at 8:48 AM Bruce Momjian wrote:
> I am thiking the vacuum_cleanup_index_scale_factor existance in a PG 14
> postgresql.conf will throw an error, unlike 13.x, so I do think we need
> to mention this so people will know to remove it from their
> postgresql.conf before upgrades,
On 2021-May-14, vignesh C wrote:
> While I was reviewing one of the logical decoding features, I found
> Streaming and binary options were missing in tab completion for the
> alter subscription set option, the attached patch has the changes for
> the same.
> Thoughts?
I wish we didn't have to kee
On Tue, May 18, 2021 at 08:34:55AM -0700, Peter Geoghegan wrote:
> In my opinion this should be interpreted as already handled by the
> backpatch to 13.3, and so not necessary to handle again now -- despite
> the GUC thing. It's possible that no users set the GUC at all, because
> it wasn't particu
On Tue, May 18, 2021 at 8:09 AM Bruce Momjian wrote:
> > I suppose that's true -- maybe it should be listed separately, because
> > the GUC is removed in 14 only.
>
> OK, this is a mess then. Would someone please give me the full text for
> this, including the commit hash(es)? Is the PG 13.3 rel
On Tue, May 18, 2021 at 04:50:31PM +0300, Heikki Linnakangas wrote:
> I wanted to dump all heap WAL records with pg_waldump, so I did this:
>
> > $ pg_waldump --rmgr=heap --rmgr=heap2 data/pg_wal/00010001
> > --stat=record
> > Type N
On Tue, May 18, 2021 at 07:51:00AM -0700, Peter Geoghegan wrote:
> On Tue, May 18, 2021 at 7:44 AM Justin Pryzby wrote:
> > As things stand, in this case I think it *should* be included, since the
> > backpatched change isn't the same as the change to HEAD (removing the GUC).
> > The git_changelog
On Tue, May 18, 2021 at 09:44:09AM -0500, Justin Pryzby wrote:
> As things stand, in this case I think it *should* be included, since the
> backpatched change isn't the same as the change to HEAD (removing the GUC).
> The git_changelog output might well be wrong in this case (or, arguably, the
> "r
On 5/18/21 8:05 AM, Chapman Flack wrote:
> On 05/18/21 04:54, Magnus Hagander wrote:
>
>> I mean, if you have
>> hostssl somedatabase someuser 10.0.0.0/24 gss
>> hostssl somedatabase supseruser 10.0.0.0/24 gss tls_min_version=1.3
>>
>> One would reasonably expect that "someuser" can connect with
On Tue, May 18, 2021 at 7:44 AM Justin Pryzby wrote:
> As things stand, in this case I think it *should* be included, since the
> backpatched change isn't the same as the change to HEAD (removing the GUC).
> The git_changelog output might well be wrong in this case (or, arguably, the
> "remove the
On Tue, May 18, 2021 at 10:07:25AM -0400, Bruce Momjian wrote:
> On Tue, May 18, 2021 at 06:28:49PM +0900, Masahiko Sawada wrote:
> > On Mon, May 10, 2021 at 3:03 PM Bruce Momjian wrote:
> > >
> > > I have committed the first draft of the PG 14 release notes. You can
> > > see the most current b
On Tue, May 18, 2021 at 7:46 PM Bharath Rupireddy
wrote:
>
> On Tue, May 18, 2021 at 7:19 PM Tom Lane wrote:
> >
> > Fujii Masao writes:
> > > On 2021/05/17 18:58, Bharath Rupireddy wrote:
> > >> It looks like the values such as '123.456', '789.123' '100$%$#$#',
> > >> '9,223,372,' are accepted
On Tue, May 18, 2021 at 11:07 PM Bruce Momjian wrote:
>
> On Tue, May 18, 2021 at 06:28:49PM +0900, Masahiko Sawada wrote:
> > On Mon, May 10, 2021 at 3:03 PM Bruce Momjian wrote:
> > >
> > > I have committed the first draft of the PG 14 release notes. You can
> > > see the most current build o
(I had missed this discussion due to the mismatched thread subject..)
On Fri, May 14, 2021 at 11:14 AM Michael Paquier wrote:
>
> On Thu, May 13, 2021 at 01:27:44PM -0700, Peter Geoghegan wrote:
> > Almost all of the benefit of the optimization is available with the
> > current BYPASS_THRESHOLD_P
On Tue, May 18, 2021 at 7:19 PM Tom Lane wrote:
>
> Fujii Masao writes:
> > On 2021/05/17 18:58, Bharath Rupireddy wrote:
> >> It looks like the values such as '123.456', '789.123' '100$%$#$#',
> >> '9,223,372,' are accepted and treated as valid integers for
> >> postgres_fdw options batch_size a
On Tue, May 18, 2021 at 06:28:49PM +0900, Masahiko Sawada wrote:
> On Mon, May 10, 2021 at 3:03 PM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 14 release notes. You can
> > see the most current build of them here:
> >
> > https://momjian.us/pgsql_docs/release-
I wanted to dump all heap WAL records with pg_waldump, so I did this:
$ pg_waldump --rmgr=heap --rmgr=heap2 data/pg_wal/00010001
--stat=record
Type N (%) Record size
(%) FPI size (%)Combined s
Fujii Masao writes:
> On 2021/05/17 18:58, Bharath Rupireddy wrote:
>> It looks like the values such as '123.456', '789.123' '100$%$#$#',
>> '9,223,372,' are accepted and treated as valid integers for
>> postgres_fdw options batch_size and fetch_size. Whereas this is not
>> the case with fdw_start
On 2021/05/17 18:58, Bharath Rupireddy wrote:
Hi,
It looks like the values such as '123.456', '789.123' '100$%$#$#',
'9,223,372,' are accepted and treated as valid integers for
postgres_fdw options batch_size and fetch_size. Whereas this is not
the case with fdw_startup_cost and fdw_tuple_cos
On Mon, May 17, 2021 at 7:50 PM Bharath Rupireddy
wrote:
> If we do that, then the options that are only accepting unquoted
> integers (i.e. 123, 456 etc.) and throwing errors for the quoted
> integers ('123', '456' etc.) will then start to accept the quoted
> integers. Other hackers might not agr
On Tue, May 18, 2021 at 9:41 PM houzj.f...@fujitsu.com
wrote:
>
> > To: Pengchengliu
> > Cc: Greg Nancarrow ; Andres Freund
> > ; PostgreSQL-development
> > Subject: Re: Re: Parallel scan with SubTransGetTopmostTransaction assert
> > coredump
>
> > I've also seen the reports of the same
> > A
On 05/18/21 04:54, Magnus Hagander wrote:
> I mean, if you have
> hostssl somedatabase someuser 10.0.0.0/24 gss
> hostssl somedatabase supseruser 10.0.0.0/24 gss tls_min_version=1.3
>
> One would reasonably expect that "someuser" can connect with whatever
> the default version i for tls_min_versi
On Tue, May 18, 2021 at 1:29 PM osumi.takami...@fujitsu.com
wrote:
>
> On Monday, May 17, 2021 6:45 PM Amit Kapila wrote:
> >
> > We allow taking locks on system catalogs, so why prohibit
> > user_catalog_tables? However, I agree that if we want plugins to acquire the
> > lock on user_catalog_tab
> To: Pengchengliu
> Cc: Greg Nancarrow ; Andres Freund ;
> PostgreSQL-development
> Subject: Re: Re: Parallel scan with SubTransGetTopmostTransaction assert
> coredump
> I've also seen the reports of the same
> Assert(TransactionIdFollowsOrEquals(xid, TransactionXmin)) with a subsequent
> c
On Thu, May 13, 2021 at 3:20 PM Peter Smith wrote:
>
> Please find attached the latest patch set v75*
>
Review comments for v75-0001-Add-support-for-prepared-transactions-to-built-i:
===
1.
- CREATE_REPLICATION_SLOT slo
Hi Ajin
>The above patch had some changes missing which resulted in some tap
>tests failing. Sending an updated patchset. Keeping the patchset
>version the same.
Thanks for your patch. I see a problem about Segmentation fault when using it.
Please take a look at this.
The steps to reproduce the
On Mon, May 10, 2021 at 3:03 PM Bruce Momjian wrote:
>
> I have committed the first draft of the PG 14 release notes. You can
> see the most current build of them here:
>
> https://momjian.us/pgsql_docs/release-14.html
>
I think we need to mention in the release note that
vacuum_cleanup
Thanks a lot! It works!
On Tue, May 18, 2021 at 11:15 AM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Tue, May 18, 2021 at 2:32 PM Esteban Zimanyi
> wrote:
> >
> > Dear all
> >
> > In MobilityDB we have defined parallel aggregations with a combine
> function, e.g.,
> >
On Tue, May 18, 2021 at 2:32 PM Esteban Zimanyi wrote:
>
> Dear all
>
> In MobilityDB we have defined parallel aggregations with a combine function,
> e.g.,
>
> CREATE AGGREGATE extent(tbox) (
> SFUNC = tbox_extent_transfn,
> STYPE = tbox,
> COMBINEFUNC = tbox_extent_combinefn,
> PARALLEL
On Tue, May 18, 2021 at 11:27 AM Pengchengliu wrote:
>
> Hi Greg,
>
>Actually I am very confused about ActiveSnapshot and TransactionSnapshot.
> I don't know why main process send ActiveSnapshot and TransactionSnapshot
> separately. And what is exact difference between them?
>If you kno
Dear all
In MobilityDB we have defined parallel aggregations with a combine
function, e.g.,
CREATE AGGREGATE extent(tbox) (
SFUNC = tbox_extent_transfn,
STYPE = tbox,
COMBINEFUNC = tbox_extent_combinefn,
PARALLEL = safe
);
We would like to trigger the combine functions in the coverage te
On Mon, May 17, 2021 at 11:18 PM Chapman Flack wrote:
>
> On 05/17/21 16:35, Magnus Hagander wrote:
> > So you're saying that some entries int he parameter section would
> > depend on the db/user/ip combo and some would depend just on the ip?
>
> I don't *think* that's what I was saying. What I wa
On Sun, May 16, 2021 at 12:07 AM Ajin Cherian wrote:
>
> On Thu, May 13, 2021 at 7:50 PM Peter Smith wrote:
> >
> > Please find attached the latest patch set v75*
> >
> > Differences from v74* are:
> >
> > * Rebased to HEAD @ today.
> >
> > * v75 also addresses some of the feedback comments from
On Tue, May 18, 2021 at 1:43 PM Fujii Masao wrote:
> > The fix looks fine but I think along with this we should also return
> > immediately from the pause loop if promotion is requested. Because if
> > we recheck the recovery pause then someone can pause again and we will
> > be in loop so better
I've also seen the reports of the same Assert(TransactionIdFollowsOrEquals(xid,
TransactionXmin)) with a subsequent crash in a parallel worker in
PostgreSQL v11-based build, Though I was unable to investigate deeper and
reproduce the issue. The details above in the thread make me think it is a
real
On 2021/05/18 14:53, Dilip Kumar wrote:
On Mon, May 17, 2021 at 7:59 PM Fujii Masao wrote:
If a promotion is triggered while recovery is paused, the paused state ends
and promotion continues. But currently pg_get_wal_replay_pause_state()
returns 'paused' in that case. Isn't this a bug?
Att
Hi,
I see this issue persist when I compile PG v14 beta1 on macOS Apple M1
using macOS 11.1 SDK. Even though the build didn't fail, the execution of
initdb on macOS 10.15 failed with the same error. Here is the snippet of
the build log:
--
> gcc -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdec
On Monday, May 17, 2021 6:45 PM Amit Kapila wrote:
> On Fri, May 14, 2021 at 2:20 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > On Thursday, May 13, 2021 7:21 PM Amit Kapila
> wrote:
> > > I don't think we can reproduce it with core plugins as they don't
> > > lock user catalog tables.
> > OK.
On Tue, May 18, 2021 at 2:46 PM Masahiko Sawada wrote:
>
> On Tue, May 18, 2021 at 2:42 PM Peter Geoghegan wrote:
> >
> > On Mon, May 17, 2021 at 10:29 PM Masahiko Sawada
> > wrote:
> > > +1 to fix this. Are you already working on fixing this? If not, I'll
> > > post a patch.
> >
> > I posted a
91 matches
Mail list logo
