> > > Thanks! The v5 patch looks good to me. Let's see if all agree on the
> > > goto duplicate_error approach which could reduce the LOC by ~80.
> >
> > I think the "goto duplicate_error" approach looks good, it avoids
> > duplicating the same error code multiple times.
>
> Thanks. I will mark th
On Sat, May 8, 2021 at 9:09 AM houzj.f...@fujitsu.com
wrote:
>
> The error message here seems not accurate, because
>
> I can see from the code batch_size should be positive ( > 0).
>
> So, is it better to change the error message to “fetch_size requires a
> positive integer value” ?
>
> I also
On Sat, May 8, 2021 at 7:04 AM Michael Paquier wrote:
>
> On Thu, May 06, 2021 at 09:04:57PM +0900, Michael Paquier wrote:
> > Yeah, I agree that this is an improvement, so let's fix this.
>
> Just noticed that this was not applied yet, so done while I was
> looking at this thread again.
Thanks!
On Sat, May 8, 2021 at 2:30 AM Tom Lane wrote:
> May 07 03:31:39 gcc202 kernel: sunvdc: vdc_tx_trigger() failure, err=-11
That's -EAGAIN (assuming errnos match x86) and I guess it indicates
that VDC_MAX_RETRIES is exceeded here:
https://github.com/torvalds/linux/blob/master/drivers/block/sunvdc.
On Sat, 8 May 2021 at 14:04, David Rowley wrote:
> I'm not opposed to adding some new field if that's what it takes. I'd
> imagine the new field will be something like negfuncid which will be
> InvalidOid unless the hash function is set and useOr == false
Just while this is still swapped into ma
Hi,
When testing the fdw batch insert, I found a possible issue.
If I set the batch_size to 0 , it will throw an error:
-
CREATE FOREIGN TABLE test(a int, b varchar)
SERVER testserver
OPTIONS (table_name 'testlocal', batch_size '0');
ERROR: fetch_size requires a non-nega
On Fri, May 07, 2021 at 10:18:14PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2021-05-07 17:14:18 -0700, Noah Misch wrote:
> >> Having a flaky buildfarm member is bad news. I'll LD_PRELOAD the attached
> >> to
> >> prevent fsync from reaching the kernel. Hopefully, that will make the
On Sat, 8 May 2021 at 14:43, Justin Pryzby wrote:
> You could put this into a separate function called by ExecEndResultCache().
> Then anyone that breaks the memory accounting can also call the function in
> the
> places they changed to help figure out what they broke.
I almost did it that way a
On Fri, 07 May 2021 at 19:50, ahsan hadi wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:not tested
>
> I
On Fri, May 7, 2021 at 07:39:31PM -0700, Zhihong Yu wrote:
>
>
> On Fri, May 7, 2021 at 7:23 PM Bruce Momjian wrote:
>
> On Fri, May 7, 2021 at 07:23:42PM -0700, Zhihong Yu wrote:
> > On Tue, Apr 13, 2021 at 10:55 AM Bryn Llewellyn
> wrote:
> > There’s no shipped function
On Sat, May 08, 2021 at 02:26:44PM +1200, David Rowley wrote:
> On Sat, 8 May 2021 at 09:16, Tomas Vondra
> wrote:
> > On 5/7/21 11:04 PM, David Rowley wrote:
> > > Another thought I have is that maybe it would be ok just to move
> > > memory accounting debug code so it only runs once in
> > > Ex
On Fri, May 7, 2021 at 7:23 PM Bruce Momjian wrote:
> On Fri, May 7, 2021 at 07:23:42PM -0700, Zhihong Yu wrote:
> > On Tue, Apr 13, 2021 at 10:55 AM Bryn Llewellyn
> wrote:
> > There’s no shipped function that does this, and this makes me
> suspect that
> > I’d prefer to roll my own fo
On Sat, 8 May 2021 at 09:16, Tomas Vondra wrote:
>
> On 5/7/21 11:04 PM, David Rowley wrote:
> > Another thought I have is that maybe it would be ok just to move
> > memory accounting debug code so it only runs once in
> > ExecEndResultCache. I struggling to imagine that if the memory
> > trackin
On Fri, May 7, 2021 at 07:23:42PM -0700, Zhihong Yu wrote:
> On Tue, Apr 13, 2021 at 10:55 AM Bryn Llewellyn wrote:
> There’s no shipped function that does this, and this makes me suspect that
> I’d prefer to roll my own for any serious purpose.
>
> The existence of the three “justif
On Tue, Apr 13, 2021 at 10:55 AM Bryn Llewellyn wrote:
> On 12-Apr-2021, at 17:25, Bruce Momjian wrote:
>
> On Mon, Apr 12, 2021 at 05:20:43PM -0700, Bryn Llewellyn wrote:
>
> I’d argue that the fact that this:
>
> ('0.3 months'::interval) + ('0.7 months'::interval)
>
> Is reported as '30 days'
Andres Freund writes:
> On 2021-05-07 17:14:18 -0700, Noah Misch wrote:
>> Having a flaky buildfarm member is bad news. I'll LD_PRELOAD the attached to
>> prevent fsync from reaching the kernel. Hopefully, that will make the
>> hardware-or-kernel trouble unreachable. (Changing 008_fsm_truncatio
Hi,
On 2021-05-07 17:14:18 -0700, Noah Misch wrote:
> Having a flaky buildfarm member is bad news. I'll LD_PRELOAD the attached to
> prevent fsync from reaching the kernel. Hopefully, that will make the
> hardware-or-kernel trouble unreachable. (Changing 008_fsm_truncation.pl
> wouldn't avoid t
On Sat, 8 May 2021 at 13:37, James Coleman wrote:
>
> On Fri, May 7, 2021 at 9:16 PM Tom Lane wrote:
> > I don't immediately see why you can't add an "invert" boolean flag to
> > ScalarArrayOpExpr and let the executor machinery deal with this. That'd
> > have the advantage of not having to depen
On Fri, May 7, 2021 at 8:38 PM David Rowley wrote:
>
> It's important to think of other cases, I just don't think there's any
> need to do anything for that one. Remember that we have the
> restriction of requiring a set of Consts, so for that case to be met,
> someone would have to write somethi
On Fri, May 07, 2021 at 10:18:44PM +0200, Erik Rijkers wrote:
>
> The JSON doc has this example (to show the need for double backslash):
>
> $ ? (@ like_regex "^\\d+$")
>
>
> The example is not wrong exactly, and can be cast to jsonpath, but as-is can
> never match anything.
>
> I think it'd b
On Fri, May 07, 2021 at 04:42:46PM +1200, Thomas Munro wrote:
> Oh, and I see that 13 has 9989d37d "Remove XLogFileNameP() from the
> tree" to fix this exact problem.
I don't see that we'd be able to get a redesign of this area safe
enough for a backpatch, but perhaps we (I?) had better put some e
On Fri, May 7, 2021 at 9:16 PM Tom Lane wrote:
>
> David Rowley writes:
> > On Sat, 8 May 2021 at 09:15, James Coleman wrote:
> >> On Sat, Apr 24, 2021 at 6:25 AM David Rowley wrote:
> >>> I'm a bit undecided if it's safe to set the opfuncid to the negator
> >>> function. If anything were to s
On Thu, May 06, 2021 at 09:04:57PM +0900, Michael Paquier wrote:
> Yeah, I agree that this is an improvement, so let's fix this.
Just noticed that this was not applied yet, so done while I was
looking at this thread again.
--
Michael
signature.asc
Description: PGP signature
On Fri, May 07, 2021 at 04:30:00PM -0400, Tom Lane wrote:
> I can certainly see an argument for running some buildfarm animals
> with fsync on (for all tests). I don't see a reason for forcing
> them all to run some tests that way; and if I were going to do that,
> I doubt that 008_fsm_truncation.
David Rowley writes:
> On Sat, 8 May 2021 at 09:15, James Coleman wrote:
>> On Sat, Apr 24, 2021 at 6:25 AM David Rowley wrote:
>>> I'm a bit undecided if it's safe to set the opfuncid to the negator
>>> function. If anything were to set that again based on the opno then
>>> it would likely set
On Sat, 8 May 2021 at 09:15, James Coleman wrote:
>
> On Sat, Apr 24, 2021 at 6:25 AM David Rowley wrote:
> > I'm a bit undecided if it's safe to set the opfuncid to the negator
> > function. If anything were to set that again based on the opno then
> > it would likely set it to the wrong thing.
On Fri, May 07, 2021 at 01:18:19PM -0400, Tom Lane wrote:
> Realizing that 9989d37d prevents the assertion failure, I went
> to see if thorntail had shown EIO failures without assertions.
> Looking back 180 days, I found these:
>
> sysname |branch | snapshot | stage
On Fri, May 7, 2021 at 3:34 PM Greg Stark wrote:
> We've talked before about buffering inserts even just for disk-based
> indexes. Much like how GIN buffers inserts and periodically flushes
> them out. We talked about doing a local buffer in each session since
> no other session even needs to see
On Fri, 9 Apr 2021 at 16:58, Tomas Vondra wrote:
>
>
>
> On 4/9/21 7:33 PM, James Coleman wrote:
> > A specific area where this is particularly painful is btree index reads.
> > Walking the tree to leaf pages isn't naturally prefetchable, and so for
> > each level you pay the random page cost. Of
On 5/7/21 11:04 PM, David Rowley wrote:
On Sat, 8 May 2021 at 08:18, Pavel Stehule wrote:
pá 7. 5. 2021 v 21:56 odesílatel David Rowley napsal:
With USE_ASSERT_CHECKING builds, I did add some code that verifies the
memory tracking is set correctly when evicting from the cache. This
code is p
On Sat, Apr 24, 2021 at 6:25 AM David Rowley wrote:
>
> On Wed, 14 Apr 2021 at 05:40, James Coleman wrote:
> > ...and here's a draft patch. I can take this to a new thread if you'd
> > prefer; the one here already got committed, on the other hand this is
> > pretty strongly linked to this discuss
On Sat, 8 May 2021 at 08:18, Pavel Stehule wrote:
>
> pá 7. 5. 2021 v 21:56 odesílatel David Rowley napsal:
>> With USE_ASSERT_CHECKING builds, I did add some code that verifies the
>> memory tracking is set correctly when evicting from the cache. This
>> code is pretty expensive as it loops over
pá 7. 5. 2021 v 22:43 odesílatel Tomas Vondra
napsal:
>
> On 5/7/21 2:46 PM, houzj.f...@fujitsu.com wrote:
> >
> >> I am testing new features in Postgres 14, and I found bug
> >> EXPLAIN ANALYZE VERBOSE for insert to FDW table with batch_size 1000
> returns
> >>
> -
On 5/7/21 2:46 PM, houzj.f...@fujitsu.com wrote:
I am testing new features in Postgres 14, and I found bug
EXPLAIN ANALYZE VERBOSE for insert to FDW table with batch_size 1000 returns
--
Andres Freund writes:
> Isn't this a good reason to have at least some tests run with fsync=on?
Why?
I can certainly see an argument for running some buildfarm animals
with fsync on (for all tests). I don't see a reason for forcing
them all to run some tests that way; and if I were going to do
Alvaro Herrera writes:
> I suppose you're aware of this, so I just want to get it on record that
> this entry
> +
> +
> + Fix use-after-free bug in saving tuples for AFTER
> + triggers (Amit Langote)
> +
> only goes back to 12; the commit to 11 was just to add the test case.
The JSON doc has this example (to show the need for double backslash):
$ ? (@ like_regex "^\\d+$")
The example is not wrong exactly, and can be cast to jsonpath, but as-is
can never match anything.
I think it'd be helpful to provide that example so that it more probably
matches when the us
pá 7. 5. 2021 v 21:56 odesílatel David Rowley napsal:
> On Sat, 8 May 2021 at 07:18, Pavel Stehule
> wrote:
> > yes, the slowdown is related to debug assertions
>
> With USE_ASSERT_CHECKING builds, I did add some code that verifies the
> memory tracking is set correctly when evicting from the ca
On Sat, 8 May 2021 at 07:18, Pavel Stehule wrote:
> yes, the slowdown is related to debug assertions
With USE_ASSERT_CHECKING builds, I did add some code that verifies the
memory tracking is set correctly when evicting from the cache. This
code is pretty expensive as it loops over the entire cach
Hi,
On 2021-05-07 10:29:58 -0400, Tom Lane wrote:
> I wrote:
> > 1. No wonder we could not reproduce it anywhere else. I've warned
> > the cfarm admins that their machine may be having hardware issues.
>
> I heard back from the machine's admin. The time of the crash I observed
> matches exactly
On 5/7/21 11:27 AM, Andrew Dunstan wrote:
> On 5/7/21 12:38 AM, Andres Freund wrote:
>> Hi,
>>
>> On 2021-05-07 00:30:11 -0400, Tom Lane wrote:
>>> Andres Freund writes:
On 2021-05-06 21:43:32 -0400, Tom Lane wrote:
> That I'm not sure about. gdb is certainly installed, and thorntail i
On 2021-May-07, Tom Lane wrote:
> See
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7f4bab7f4a0e42ee9fa14707f726017b7869386b
I suppose you're aware of this, so I just want to get it on record that
this entry
+
+
+ Fix use-after-free bug in saving tuples for AFTER
pá 7. 5. 2021 v 21:06 odesílatel Yura Sokolov
napsal:
> Pavel Stehule писал 2021-05-07 21:45:
> >>
> >> Samples: 119K of event 'cycles', 4000 Hz, Event count (approx.):
> >> Overhead Shared Object Symbol
> >> 79.20% postgres [.] cache_reduce_memory
> >> 1.94% [kern
On 5/7/21 9:06 PM, Yura Sokolov wrote:
Pavel Stehule писал 2021-05-07 21:45:
Samples: 119K of event 'cycles', 4000 Hz, Event count (approx.):
Overhead Shared Object Symbol
79.20% postgres [.] cache_reduce_memory
1.94% [kernel] [k] native_write
Pavel Stehule писал 2021-05-07 21:45:
Samples: 119K of event 'cycles', 4000 Hz, Event count (approx.):
Overhead Shared Object Symbol
79.20% postgres [.] cache_reduce_memory
1.94% [kernel] [k] native_write_msr_safe
1.63% [kernel]
pá 7. 5. 2021 v 20:24 odesílatel Pavel Stehule
napsal:
> Hi
>
> I am testing new features of Postgres 14, and now I am trying to check the
> result cache. Unfortunately on my test data, the result is not too good.
> the behaviour is very non linear. Is it expected?
>
> create table t1(a int, t2_i
On 5/7/21 1:20 PM, Andres Freund wrote:
> Hi,
>
> On 2021-05-07 11:19:02 -0400, Andrew Dunstan wrote:
>> Here's a patch that adds the README and also adds a Makefile recipe for
>> regenerating Gen_dummy_probes.pl after the sed script is changed. On my
>> system at least the recipe is idempotent.
Hi
I am testing new features of Postgres 14, and now I am trying to check the
result cache. Unfortunately on my test data, the result is not too good.
the behaviour is very non linear. Is it expected?
create table t1(a int, t2_id int);
insert into t1 select random() * 10, random() * 10 fr
On Fri, Apr 9, 2021 at 4:57 PM Tomas Vondra
wrote:
>
>
>
> On 4/9/21 7:33 PM, James Coleman wrote:
> > $SUBJECT is still a very loosely formed idea, so forgive lack of detail
> > or things I've likely missed, but I wanted to get it out there to see if
> > it sounded at all intriguing to people.
>
Hi,
On 2015-03-03 16:49:22 +0100, Andres Freund wrote:
> I every now and then run installcheck against a primary, verify that
> replay works without errors, and then compare pg_dumpall from both
> clusters. Unfortunately that currently requires hand inspection of
> dumps, there are differences lik
"Jonathan S. Katz" writes:
> Are there going to be any tzdata changes?
Nope, they're still on 2021a:
https://www.iana.org/time-zones
regards, tom lane
On 5/7/21 12:22 PM, Tom Lane wrote:
> See
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7f4bab7f4a0e42ee9fa14707f726017b7869386b
Thanks!
> As usual, please send comments/corrections by Sunday.
==snip=
A previous bug fix caused environment variables (such as PGPORT) to
over
Hi,
On 2021-05-06 11:13:28 +0100, Dagfinn Ilmari Mannsåker wrote:
> Andres Freund writes:
>
> > I tried to regenerate Gen_dummy_probes.pl using s2p - which doesn't seem
> > to exist for modern versions of perl anymore :(
>
> It still exists, it's just not part of the core Perl distribution any
Hi,
On 2021-05-07 11:19:02 -0400, Andrew Dunstan wrote:
> Here's a patch that adds the README and also adds a Makefile recipe for
> regenerating Gen_dummy_probes.pl after the sed script is changed. On my
> system at least the recipe is idempotent.
Nice! Thanks for this work.
Greetings,
Andres F
I wrote:
> Thomas Munro writes:
>> Oh, and I see that 13 has 9989d37d "Remove XLogFileNameP() from the
>> tree" to fix this exact problem.
> Hah, so that maybe explains why thorntail has only shown this in
> the v12 branch. Should we consider back-patching that?
Realizing that 9989d37d prevents
Andrew Dunstan writes:
> Here's a patch that adds the README and also adds a Makefile recipe for
> regenerating Gen_dummy_probes.pl after the sed script is changed. On my
> system at least the recipe is idempotent.
I've not tested the Makefile recipe, but the README looks good.
Matthias van de Meent writes:
> I see similar (if not duplicate) entries for a "COMMIT AND CHAIN"
> issue, committed at nearly the same time, and both by Fujii Masao. Are
> these the same / should they be contained in one entry?
>> +Author: Fujii Masao
>> +Branch: master [8a55cb5ba] 2021-02-19 2
On Fri, 7 May 2021 at 18:23, Tom Lane wrote:
>
> See
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7f4bab7f4a0e42ee9fa14707f726017b7869386b
>
> As usual, please send comments/corrections by Sunday.
I noticed only one potential issue.
I see similar (if not duplicate) entrie
Hi,
Enabling optional ./configure features/packages using --enable-* / --with-*
will and should cause fatal errors aborting the configure process
if some dependencies are missing, letting the user install such packages,
before proceeding and resuming ./configure.
However, ./configure currently on
In a bug report back in November [1] a subthread explored why parallel
query is excluded any time we have "Plan nodes which reference a
correlated SubPlan". Amit's understanding was that the reasoning had
to do with inability to easily pass (potentially variable length)
Param values between workers
See
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7f4bab7f4a0e42ee9fa14707f726017b7869386b
As usual, please send comments/corrections by Sunday.
regards, tom lane
I noticed this while working on the
EXPLAIN-ANALYZE-for-async-capable-nodes issue:
EXPLAIN (VERBOSE, COSTS OFF)
DELETE FROM async_pt;
QUERY PLAN
Delete on public.async_pt
Foreign Delete on public.async_
On Fri, May 7, 2021 at 7:35 PM Andrey Lepikhov
wrote:
> On 6/5/21 14:11, Etsuro Fujita wrote:
> > On Tue, Apr 27, 2021 at 3:57 PM Andrey V. Lepikhov
> > wrote:
> >> One more question. Append choose async plans at the stage of the Append
> >> plan creation.
> >> Later, the planner performs some op
On Fri, May 7, 2021 at 2:12 AM Stephen Frost wrote:
> I'd suggest the language point out that it's not actually possible to do
> otherwise, since they all need to be part of the same transaction.
>
> Without that, it looks like we're just missing a trick somewhere and
> someone might think that th
On 5/7/21 12:38 AM, Andres Freund wrote:
> Hi,
>
> On 2021-05-07 00:30:11 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> On 2021-05-06 21:43:32 -0400, Tom Lane wrote:
That I'm not sure about. gdb is certainly installed, and thorntail is
visibly running the current buildfarm clien
I've pushed all three patches, with some better commit messages etc.
thanks!
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 5/6/21 9:55 AM, Andrew Dunstan wrote:
> On 5/6/21 12:59 AM, Andres Freund wrote:
>> Hi,
>>
>> On 2021-05-06 00:18:12 -0400, Tom Lane wrote:
>>> Andres Freund writes:
I understand why we don't want to rely on sed because of windows - but
it's far from obvious why we can't just use the
On 4/20/21 10:09 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I've just noticed that we have 41 perl files in our sources with
>> copyright notices of some sort and 161 without. Should we do something
>> about that?
> +1 for pasting the usual copyright notice on the rest.
>
>
I wrote:
> 1. No wonder we could not reproduce it anywhere else. I've warned
> the cfarm admins that their machine may be having hardware issues.
I heard back from the machine's admin. The time of the crash I observed
matches exactly to these events in the kernel log:
May 07 03:31:39 gcc202 ker
> While reviewing one of the 'Table partitioning' related patches,
> I found that Postgres does not support multiple column based LIST
> partitioning. Based on this understanding, I have started working on
> this feature. I also feel that 'Multi-Column List Partitioning' can
> be benefited to the P
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
I believe it is ready for committer.
The new status of this patc
On Fri, May 7, 2021 at 5:44 PM Dilip Kumar wrote:
>
> On Fri, May 7, 2021 at 5:38 PM Bharath Rupireddy
> wrote:
> >
> > On Fri, May 7, 2021 at 11:50 AM Dilip Kumar wrote:
> > >
> > > On Thu, May 6, 2021 at 7:22 PM vignesh C wrote:
> > > >
> > >
> > > Some comments:
> > > 1.
> > > I don't see an
Hi Nitin,
On Fri, May 7, 2021 at 4:21 PM Nitin Jadhav
wrote:
> Hi,
>
> I am not convinced with the following behaviour of RANGE Partitioning.
> Kindly let me know if this is expected behaviour or it should be changed.
>
> *Case-1*:
> postgres@68941=#create table r(a int, b int) partition by rang
> I am testing new features in Postgres 14, and I found bug
> EXPLAIN ANALYZE VERBOSE for insert to FDW table with batch_size 1000 returns
> ---
> Insert on public.vzdalen
On Mon, May 3, 2021 at 6:08 PM Bharath Rupireddy
wrote:
>
> Having said that, isn't it good if we can provide a subscription
> (CREATE/ALTER) level option say "cascade"(similar to other options
> such as binary, synchronous_commit, stream) default being false, when
> set to true, we send upstream
On Fri, May 7, 2021 at 5:38 PM Bharath Rupireddy
wrote:
>
> On Fri, May 7, 2021 at 11:50 AM Dilip Kumar wrote:
> >
> > On Thu, May 6, 2021 at 7:22 PM vignesh C wrote:
> > >
> >
> > Some comments:
> > 1.
> > I don't see any change in pg_dump.c, don't we need to dump this option?
>
> I don't think
On Fri, May 7, 2021 at 11:50 AM Dilip Kumar wrote:
>
> On Thu, May 6, 2021 at 7:22 PM vignesh C wrote:
> >
>
> Some comments:
> 1.
> I don't see any change in pg_dump.c, don't we need to dump this option?
I don't think it is necessary there as the default value of the
validate_publication is fal
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
I have also seen this error with logical replication using pglogi
On Fri, May 7, 2021 at 4:21 PM Nitin Jadhav
wrote:
>
> Hi,
>
> I am not convinced with the following behaviour of RANGE Partitioning.
> Kindly let me know if this is expected behaviour or it should be changed.
>
> Case-1:
> postgres@68941=#create table r(a int, b int) partition by range(a,b);
> CR
Hi,
I am not convinced with the following behaviour of RANGE Partitioning.
Kindly let me know if this is expected behaviour or it should be changed.
*Case-1*:
postgres@68941=#create table r(a int, b int) partition by range(a,b);
CREATE TABLE
postgres@68941=#create table r1 partition of r for valu
pá 7. 5. 2021 v 11:48 odesílatel Pavel Stehule
napsal:
> Hi
>
> I am testing new features in Postgres 14, and I found bug
>
> EXPLAIN ANALYZE VERBOSE for insert to FDW table with batch_size 1000
> returns
>
>
> -
On 6/5/21 14:11, Etsuro Fujita wrote:
On Tue, Apr 27, 2021 at 3:57 PM Andrey V. Lepikhov
wrote:
One more question. Append choose async plans at the stage of the Append
plan creation.
Later, the planner performs some optimizations, such as eliminating
trivial Subquery nodes. So, AsyncAppend is i
On 6/5/21 11:45, Etsuro Fujita wrote:
On Tue, Apr 27, 2021 at 9:31 PM Etsuro Fujita wrote:
The patch fixes the issue, but I don’t think it’s the right way to go,
because it requires an extra ExecProcNode() call, which wouldn’t be
efficient. Also, the patch wouldn’t address another issue I notic
On Thu, May 6, 2021 at 5:43 AM Robert Haas wrote:
>
> On Wed, May 5, 2021 at 10:42 PM David Fetter wrote:
> > We do use at least one bit and piece from around the internet to make
> > our software usable, namely libreadline, the absence of which make
> > psql pretty much unusable.
FWIW, we did g
On Wed, May 5, 2021 at 7:12 PM Robert Haas wrote:
>
> On Wed, May 5, 2021 at 12:34 PM Magnus Hagander wrote:
> > Is this really a problem we should fix ourselves? Most daemon-managers
> > today will happily be configured to automatically restart a daemon on
> > failure with a single setting since
On Thu, May 6, 2021 at 9:23 AM Andrew Dunstan wrote:
> On 5/5/21 5:12 PM, Thomas Munro wrote:
> > On Thu, May 6, 2021 at 8:58 AM Andrew Dunstan wrote:
> >> this is an open item for release 14 . The discussion seems to have gone
> >> silent for a couple of weeks. Are we in a position to make any
>
On 6/5/21 22:12, Stephen Frost wrote:
* Etsuro Fujita (etsuro.fuj...@gmail.com) wrote:
I think the user should be careful about this. How about adding a
note about it to the “Asynchronous Execution Options” section in
postgres-fdw.sgml, like the attached?
+1
... then again, it'd really be bet
Hi
I am testing new features in Postgres 14, and I found bug
EXPLAIN ANALYZE VERBOSE for insert to FDW table with batch_size 1000
returns
---
Insert on public.vzdalena_ta
Hello, Antonin.
> I'm trying to review the patch, but not sure if I understand this problem,
> please see my comment below.
Thanks a lot for your attention. It is strongly recommended to look at
version N3 (1) because it is a much more elegant, easy, and reliable
solution :) But the minRecoveryPo
On Fri, May 7, 2021 at 2:33 PM Kyotaro Horiguchi
wrote:
>
> Thanks.
>
>
> At Fri, 7 May 2021 11:04:53 +0530, Dilip Kumar wrote
> in
> > On Fri, May 7, 2021 at 8:23 AM Kyotaro Horiguchi
> > wrote:
> > >
> > > At Tue, 4 May 2021 17:41:06 +0530, Dilip Kumar
> > > wrote in
> > > Could you please
pá 7. 5. 2021 v 11:28 odesílatel Fabien COELHO napsal:
>
> >> Finally it is unclear how to add such a feature with minimal impact on
> the
> >> source code.
> >
> >
> > It is a question if this is possible without more changes or without
> > compatibility break :( Probably not. All output should
> > Thanks! It looks good!
>
> Thanks for checking. I'll mark this as RfC.
Hi,
The patch cannot be applied to the latest head branch, it will be nice if you
can rebase it.
And when looking into the patch, I have some comments on it.
1)
IIRC, After the commit c5b7ba4, the initialization of
mt
Finally it is unclear how to add such a feature with minimal impact on the
source code.
It is a question if this is possible without more changes or without
compatibility break :( Probably not. All output should be centralized.
Yes and no.
For some things we could have "void report_somety
Thanks.
At Fri, 7 May 2021 11:04:53 +0530, Dilip Kumar wrote in
> On Fri, May 7, 2021 at 8:23 AM Kyotaro Horiguchi
> wrote:
> >
> > At Tue, 4 May 2021 17:41:06 +0530, Dilip Kumar
> > wrote in
> > Could you please fix the test script so that it causes your issue
> > correctly? And/or elaborat
On Fri, May 7, 2021 at 7:08 AM Tom Lane wrote:
>
> Alvaro Herrera writes:
> > On 2021-May-06, Peter Smith wrote:
> >> PSA v3 of the patch. Same as before, but now also renames the global
> >> variable from "wrconn" to "lrep_worker_wrconn".
>
> > I think there are two patches here -- the changes t
pá 7. 5. 2021 v 9:46 odesílatel Fabien COELHO <
fabien.coe...@mines-paristech.fr> napsal:
>
> Hello,
>
> >>> When I run pgbench, I usually work with more releases together, so the
> >>> server version is important info.
> >>
> >> Ok. Yes.
>
> Here is a putative patch for this simple part.
>
+1
On 12/3/21 14:05, Hywel Carver wrote:
I've built and tested this, and it seems to function correctly to me. One question I have is
whether the added "IS NOT NULL" filters can be omitted when they're unnecessary. Some of
the resulting plans included an "IS NOT NULL" filter on a non-nullable colu
97 matches
Mail list logo
