On Wed, Oct 07, 2020 at 03:18:44PM +0900, Michael Paquier wrote:
> About 0001, the new set of multipliers looks fine to me. Even if this
> adds an extra item from 901 to 902 because this can be divided by 17
> in kwlist_d.h, I also don't think that this is really much bothering
> and. As mentione
Hi Kirk san,
(1)
+ * This returns an InvalidBlockNumber when smgr_cached_nblocks is not
+ * available and when not in recovery path.
+ /*
+* We cannot believe the result from smgr_nblocks is always accurate
+* because lseek of buggy Linux kernels doesn't account for a recen
Hi,
as this does not get any attention on the docs-list, once again here.
Any thoughts on this?
Regards
Daniel
From: Daniel Westermann (DWE)
Sent: Sunday, September 27, 2020 17:58
To: Pg Docs
Subject: Wrong example in the bloom documentation
Hi,
I've briefly discussed this with Bruce so
On Tue, Oct 6, 2020 at 10:23 AM peter.b.sm...@fujitsu.com
wrote:
>
> ==
> Patch V6-0001, File: src/include/replication/reorderbuffer.h
> ==
>
> QUESTION
> Line 116
> @@ -162,9 +163,13 @@ typedef struct ReorderBufferChange
> #define RBTXN_HAS_CATALOG_CHANGES 0x0001
> #define RBTXN
On Thu, Oct 8, 2020 at 2:58 PM Amit Langote wrote:
> On Wed, Oct 7, 2020 at 12:51 AM Tom Lane wrote:
> > Ashutosh Bapat writes:
> > > On Mon, Oct 5, 2020 at 11:59 PM Tom Lane wrote:
> > >> ... we could avoid the growth in eclass members for large partition sets
> > >> if we simply didn't store
On Wed, Oct 7, 2020 at 12:51 AM Tom Lane wrote:
> Ashutosh Bapat writes:
> > On Mon, Oct 5, 2020 at 11:59 PM Tom Lane wrote:
> >> ... we could avoid the growth in eclass members for large partition sets
> >> if we simply didn't store child eclass members, instead translating
> >> on-the-fly when
On Tue, Sep 29, 2020 at 6:30 PM Amit Kapila wrote:
>
> On Mon, Sep 28, 2020 at 12:19 PM Amit Kapila wrote:
> >
> > Few additional comments:
> > ==
>
> Some more comments:
>
> v5-0002-Framework-for-leader-worker-in-parallel-copy
> ===
> 1
On Mon, Sep 28, 2020 at 6:37 PM Ashutosh Sharma wrote:
>
> On Mon, Sep 28, 2020 at 3:01 PM Amit Kapila wrote:
> >
> > On Tue, Sep 22, 2020 at 2:44 PM vignesh C wrote:
> > >
> > > Thanks Ashutosh for your comments.
> > >
> > > On Wed, Sep 16, 2020 at 6:36 PM Ashutosh Sharma
> > > wrote:
> > > >
On Thu, Oct 8, 2020 at 7:46 AM Masahiko Sawada
wrote:
>
> On Wed, 7 Oct 2020 at 17:52, Amit Kapila wrote:
> >
> > On Wed, Oct 7, 2020 at 11:24 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, 6 Oct 2020 at 17:56, Amit Kapila wrote:
> > > >
> > > > On Tue, Oct 6, 2020 at 9:34 AM Masahiko Sawada
On Tue, Oct 6, 2020 at 10:52 PM Masahiko Sawada
wrote:
>
> On Fri, 2 Oct 2020 at 18:20, tsunakawa.ta...@fujitsu.com
> wrote:
> >
> > From: Masahiko Sawada
> > > You proposed the first idea
> > > to avoid such a situation that FDW implementor can write the code
> > > while trying to reduce the po
Hi
I have a look over this patch and find some typos in 0002.
1.Some typos about unique:
There are some spelling mistakes about "unique" in code comments and README.
Such as: "+However we define the UnqiueKey as below."
2.function name about initililze_uniquecontext_for_joinrel:
May be it should
On Thu, Oct 8, 2020 at 5:44 AM vignesh C wrote:
> Attached v6 patch with the fixes.
>
Hi Vignesh,
I noticed a couple of issues when scanning the code in the following patch:
v6-0003-Allow-copy-from-command-to-process-data-from-file.patch
In the following code, it will put a junk uint16 va
From: Jamison, Kirk/ジャミソン カーク
> With the latest patches attached, and removing the recovery check in
> smgrnblocks, I tested the performance of vacuum.
> (3 trial runs, 3.5 GB db populated with 1000 tables)
>
> Execution Time (seconds)
> | s_b | master | patched | %reg |
> |---|
Hello Tomas san,
Thank you for picking up this. I'm interested in this topic, too. (As an
aside, we'd like to submit a bulk insert patch for ECPG in the near future.)
As others referred, Andrey-san's fast COPY to foreign partitions is also
promising. But I think your bulk INSERT is a separa
On Wed, 7 Oct 2020 at 17:52, Amit Kapila wrote:
>
> On Wed, Oct 7, 2020 at 11:24 AM Masahiko Sawada
> wrote:
> >
> > On Tue, 6 Oct 2020 at 17:56, Amit Kapila wrote:
> > >
> > > On Tue, Oct 6, 2020 at 9:34 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > Looking at pgstat_reset_replslot_counter()
On Monday, October 5, 2020 8:50 PM, Amit Kapila wrote:
> On Mon, Oct 5, 2020 at 3:04 PM k.jami...@fujitsu.com
> > > 2. Also, the other thing is I have asked for some testing to avoid
> > > the small regression we have for a smaller number of shared buffers
> > > which I don't see the results nor a
On Mon, Oct 5, 2020 at 5:24 PM Mark Dilger wrote:
> > I don't see how verify_heapam will avoid raising an error during basic
> > validation from PageIsVerified(), which will violate the guarantee
> > about not throwing errors. I don't see that as a problem myself, but
> > presumably you will.
>
>
On Wed, Oct 07, 2020 at 02:31:54PM +0300, Maksim Kita wrote:
> Fix progname memory leak in ecpg client.
> Issue taken from todo list https://wiki.postgresql.org/wiki/Todo.
FWIW, I don't see much point in doing that. For one, we have a
more-or-less established rule that progname remains set until
On Wed, Oct 7, 2020 at 9:55 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Wed, Sep 09, 2020 at 07:51:12AM +0800, Andy Fan wrote:
> >
> > Thank you Michael for checking it, I can reproduce the same locally after
> > rebasing to the latest master. The attached v11 has fixed it and includes
On Thu, Oct 08, 2020 at 01:15:35AM +, Hou, Zhijie wrote:
> Hi
>
> In multixact.c I found some comments like the following:
>
> * Similar to AtEOX_MultiXact but for COMMIT PREPARED
> * Discard the local MultiXactId cache like in AtEOX_MultiXact
>
> Since there's no function called
Hi
In multixact.c I found some comments like the following:
* Similar to AtEOX_MultiXact but for COMMIT PREPARED
* Discard the local MultiXactId cache like in AtEOX_MultiXact
Since there's no function called "AtEOX_MultiXact" in the code,
I think the "AtEOX_MultiXact" may be a typo
On Thu, Oct 8, 2020 at 6:14 AM Robert Haas wrote:
> So, for an ordinary transaction, rollback implies an explicit user
> action, but an abort could either be an explicit user action (ABORT;
> or ROLLBACK;) or an error. I agree that calling that case "abort"
> rather than "rollback" is better. How
On Wed, Oct 7, 2020 at 6:22 PM Tomas Vondra
wrote:
>
> On Wed, Oct 07, 2020 at 04:01:27PM -0400, James Coleman wrote:
> >On Wed, Oct 7, 2020 at 3:52 PM Robert Haas wrote:
> >>
> >> On Thu, Oct 1, 2020 at 9:03 AM James Coleman wrote:
> >> > The plan (obtained by replacing the volatile function wi
> On Oct 6, 2020, at 11:27 PM, Andrey Borodin wrote:
>
>
>
>> 7 окт. 2020 г., в 04:20, Mark Dilger
>> написал(а):
>>
>>
>>
>>> On Oct 5, 2020, at 5:24 PM, Mark Dilger
>>> wrote:
>>>
>>> - This version does not change clog handling, which leaves Andrey's concern
>>> unaddressed. Pet
On Tue, Jun 30, 2020 at 5:03 PM Peter Geoghegan wrote:
> Attached is a POC patch that teaches nbtree to delete old duplicate
> versions from unique indexes. The optimization targets non-HOT
> duplicate version bloat. Although the patch is rather rough, it
> nevertheless manages to more or less eli
Hi,
Sorry for the second send of this email, but somehow I managed to mangle
the headers in the last version I sent.
On 2020-10-03 19:01:27 -0700, Andres Freund wrote:
> On 2020-10-03 18:30:46 -0500, Justin Pryzby wrote:
> > On Sat, Oct 03, 2020 at 04:01:49PM -0700, Andres Freund wrote:
> > > > I
Hi,
On 2020-10-03 19:01:27 -0700, Andres Freund wrote:
> On 2020-10-03 18:30:46 -0500, Justin Pryzby wrote:
> > On Sat, Oct 03, 2020 at 04:01:49PM -0700, Andres Freund wrote:
> > > > I was able to make a small, apparent leak like so. This applies to
> > > > postgis3.0/postgres12/LLVM5/centos7, an
On Wed, Oct 7, 2020 at 10:18 PM Michael Banck wrote:
> Am Mittwoch, den 07.10.2020, 21:11 +1300 schrieb Thomas Munro:
> > On Wed, Oct 7, 2020 at 8:58 PM Michael Banck
> > wrote:
> > > "starting archive recovery" appears) took 20 minutes and during the
> > Nice data point.
> In the thread you poi
On Wed, Oct 07, 2020 at 06:22:04PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Wed, Oct 07, 2020 at 06:03:16PM -0400, Tom Lane wrote:
> >> After thinking about it a bit more, I'm not even convinced that what
> >> xlc seems to be doing is illegal per C spec. There are no sequence
> >> point
On Wed, Oct 07, 2020 at 03:52:04PM -0400, Robert Haas wrote:
On Thu, Oct 1, 2020 at 9:03 AM James Coleman wrote:
The plan (obtained by replacing the volatile function with a stable one):
Unique
-> Nested Loop
-> Gather Merge
Workers Planned: 2
-> S
On Wed, Oct 07, 2020 at 04:01:27PM -0400, James Coleman wrote:
On Wed, Oct 7, 2020 at 3:52 PM Robert Haas wrote:
On Thu, Oct 1, 2020 at 9:03 AM James Coleman wrote:
> The plan (obtained by replacing the volatile function with a stable one):
>
> Unique
>-> Nested Loop
> -> Gath
Noah Misch writes:
> On Wed, Oct 07, 2020 at 06:03:16PM -0400, Tom Lane wrote:
>> After thinking about it a bit more, I'm not even convinced that what
>> xlc seems to be doing is illegal per C spec. There are no sequence
>> points within
>>
>> return list_make2(list_concat(directargs, ordere
On Wed, Oct 07, 2020 at 06:03:16PM -0400, Tom Lane wrote:
> I wrote:
> > I'm tempted to propose the attached small code rearrangement, which
> > might dissuade the compiler from thinking it can get away with this.
That patch does get hornet's -O2 build to again pass "make check". It doesn't
harm
I wrote:
> I'm tempted to propose the attached small code rearrangement, which
> might dissuade the compiler from thinking it can get away with this.
> While I concur with your point that an old xlc version might not be
> that exciting, there could be other compilers doing the same thing
> in the f
On Wed, Oct 7, 2020 at 6:17 PM Thomas Munro wrote:
> On Mon, Oct 5, 2020 at 2:38 PM Thomas Munro wrote:
> > On Wed, Sep 9, 2020 at 3:49 PM Thomas Munro wrote:
> > > For the record, Andres Freund mentioned a few problems with this
> > > off-list and suggested we consider calling Linux syncfs() fo
Noah Misch writes:
> On Thu, Oct 08, 2020 at 09:15:12AM +1300, David Rowley wrote:
>> It would be interesting to see gram.s from both cc99baa4~1 and cc99baa4.
> Attached. Both generated like this:
Hm. I'm too lazy to go bone up on PPC64 ABI conventions, but this does
look suspiciously like the
I like the idea, during prototype I added additional column and modified
enum_in method. But enum_in is called in contexts that can be important
for user (like comparisons).
Example:
postgres=# CREATE TYPE test_enum AS enum ('1', '2', '3');
CREATE TYPE
postgres=# CREATE TABLE test_table ( value
Thanks for investigating this, Noah.
On Thu, 8 Oct 2020 at 06:13, Tom Lane wrote:
>
> Noah Misch writes:
> > gram.o was it. (The way I rebuilt gram.o also rebuilt parser.o and scan.o,
> > but those seem far less likely.)
>
> This suggests that the problem is misoptimization of gram.y's
> makeOr
On Wed, Oct 7, 2020 at 3:52 PM Robert Haas wrote:
>
> On Thu, Oct 1, 2020 at 9:03 AM James Coleman wrote:
> > The plan (obtained by replacing the volatile function with a stable one):
> >
> > Unique
> >-> Nested Loop
> > -> Gather Merge
> >Workers Planned: 2
> >
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I tested the patch at hand, and it performs as expected. Files larger
On Thu, Oct 1, 2020 at 9:03 AM James Coleman wrote:
> The plan (obtained by replacing the volatile function with a stable one):
>
> Unique
>-> Nested Loop
> -> Gather Merge
>Workers Planned: 2
>-> Sort
> Sort Key: ref_0.i, (md5(
On Mon, Oct 5, 2020 at 2:29 PM Tom Lane wrote:
> Actually, the reason I have been looking at equivclass.c is that I've
> been attacking the problem from a different direction. I'm fairly
> unexcited about making the definition of Var looser as you suggest
> here --- I actually think that it's dan
Greetings,
* James Coleman (jtc...@gmail.com) wrote:
> I'm breaking out a few questions I'd posed on another thread about the
> release timeline [1] into this new thread.
>
> I noticed on the PG13 release announcement that the link for
> incremental sort goes to the GUC docs [2] because (as Jonat
On Wed, Oct 7, 2020 at 1:24 AM Amit Kapila wrote:
> > There is a confusing mix of terminology where sometimes things are
> > referred as ROLLBACK/rollback and other times apparently the same
> > operation is referred as ABORT/abort. I do not know the root cause of
> > this mixture. IIUC maybe the
Greetings,
* Andrey M. Borodin (x4...@yandex-team.ru) wrote:
> > 18 сент. 2020 г., в 11:59, Michael Paquier написал(а):
> > On Fri, Sep 18, 2020 at 11:31:26AM +0500, Andrey M. Borodin wrote:
> >> This is whole point of having prefetch. restore_command just links
> >> file from the same partition.
Greetings,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 18/09/2020 10:17, Alexander Kukushkin wrote:
> >At the same time, pg_rewind due to such "fatal" error leaves PGDATA in
> >an inconsistent state with empty pg_control file, this is totally bad
> >and easily fixable. We want the specific
On Mon, Sep 28, 2020 at 3:01 PM Amit Kapila wrote:
>
> On Tue, Sep 22, 2020 at 2:44 PM vignesh C wrote:
> >
> > Thanks Ashutosh for your comments.
> >
> > On Wed, Sep 16, 2020 at 6:36 PM Ashutosh Sharma
> > wrote:
> > >
> > > Hi Vignesh,
> > >
> > > I've spent some time today looking at your ne
On Tue, Sep 29, 2020 at 3:16 PM Greg Nancarrow wrote:
>
> Hi Vignesh and Bharath,
>
> Seems like the Parallel Copy patch is regarding RI_TRIGGER_PK as
> parallel-unsafe.
> Can you explain why this is?
Yes we don't need to restrict parallelism for RI_TRIGGER_PK cases as
we don't do any command cou
On Wed, Sep 16, 2020 at 3:33 PM Robert Haas wrote:
> I don't mind a loop, but that one looks broken. We have to clear the
> bit before we call the function that processes that type of barrier.
> Otherwise, if we succeed in absorbing the barrier but a new instance
> of the same barrier arrives mean
Noah Misch writes:
> On Tue, Oct 06, 2020 at 09:56:49PM -0400, Tom Lane wrote:
>> Now that *is* surprising. Could you poke a little further to determine
>> which module is getting miscompiled? (gram.o seems like the next most
>> likely bet.)
> gram.o was it. (The way I rebuilt gram.o also rebu
>
>
> 2. One suggestion for generation of partition names is to append a
>> unique id to
>
> avoid conflicts.
>>
>> Can you please give an example of such a conflict? I agree that current
>> naming scheme is far from perfect, but I think that 'tablename'_partnum
>> provides unique name for eac
I wrote:
> That TODO item should either be removed or marked with a warning stating
> that it's next door to impossible. (Unfortunately, a lot of our TODO
> items are like that ... there's usually a good reason why they're not
> done already.)
Actually ... I'm not sure if this idea has been discu
Maksim Kita writes:
> There is a question related to TODO task with name "Allow deleting enumerated
> values from an existing enumerated data type".
> I made simple changes in parser and implement RemoveEnumLabel function, but
> as I understand if enum value that we want to
> delete is in use b
"A prepared statement has a name and a CachedPlanSource. They are stored
in a hash table. See StorePreparedStatement() function. If you grep for
callers of StorePreparedStatement(), you'll see that there are two: one
in processing an EXECUTE statement, and one in handling the Extended
Query Protoco
Hi,
There is a question related to TODO task with name "Allow deleting enumerated
values from an existing enumerated data type".
I made simple changes in parser and implement RemoveEnumLabel function, but as
I understand if enum value that we want to
delete is in use by some tables, we have to
On 28.09.2020 17:41, Andrey M. Borodin wrote:
Hi, Anastasia!
28 авг. 2020 г., в 23:08, Anastasia Lubennikova
написал(а):
1) The first patch is sensible and harmless, so I think it is ready for
committer. I haven't tested the performance impact, though.
2) I like the initial proposal to mak
> On Wed, Sep 09, 2020 at 07:51:12AM +0800, Andy Fan wrote:
>
> Thank you Michael for checking it, I can reproduce the same locally after
> rebasing to the latest master. The attached v11 has fixed it and includes
> the fix Floris found.
>
> The status of this patch is we are still in discussion ab
Andrew Dunstan writes:
> It looks like you've since discovered the cause here. Do you need me to
> dig more?
Nah, I've got it. Thanks.
regards, tom lane
On Wed, Oct 7, 2020 at 5:05 PM Andy Fan wrote:
>
>
> On Sun, Oct 4, 2020 at 3:10 PM Andy Fan wrote:
>
>>
>>>
>>> Now, in my experience, the current system for custom plans vs. generic
>>> plans doesn't approach the problem in this way at all, and in my
>>> experience that results in some pretty
Thank you Amit and Ashutosh for your reply!
On Wed, Oct 7, 2020 at 8:41 PM Amit Langote wrote:
> Hi Ashutosh,
>
> On Wed, Oct 7, 2020 at 8:40 PM Ashutosh Bapat
> wrote:
> > On Wed, Oct 7, 2020 at 11:20 AM Andy Fan
> wrote:
> > > On Mon, Oct 5, 2020 at 9:27 PM Ashutosh Bapat <
> ashutosh.bapat.
On 05.10.2020 09:36, Rahila Syed wrote:
Hi,
Couple of comments:
1. The syntax used omits the { IMMEDIATE | DEFERRED} keywords
suggested in
the earlier discussions. I think it is intuitive to
include IMMEDIATE with the current implementation
so that the syntax can be ext
On 10/6/20 5:19 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Thanks, Committed. Further investigation shows this was introduced in
>> release 12, so that's how far back I went.
> Still further investigation shows that this patch caused bug #16655 [1].
> It should *not* have been designed to u
Hi Ashutosh,
On Wed, Oct 7, 2020 at 8:40 PM Ashutosh Bapat
wrote:
> On Wed, Oct 7, 2020 at 11:20 AM Andy Fan wrote:
> > On Mon, Oct 5, 2020 at 9:27 PM Ashutosh Bapat
> > wrote:
> >> What happens when we
> >> execute plans with values that have estimates similar to the generic
> >> plan later w
On Wed, Oct 7, 2020 at 8:00 AM Bharath Rupireddy
wrote:
>
> On Tue, Oct 6, 2020 at 11:41 AM Bharath Rupireddy
> wrote:
> >
> > On Tue, Oct 6, 2020 at 11:20 AM Fujii Masao
> > wrote:
> > >
> > > +1 Or it's also ok to make each patch separately.
> > > Anyway, thanks!
> > >
> >
> > Thanks. +1 to h
On Tue, Sep 29, 2020 at 5:09 PM Bharath Rupireddy
wrote:
>
> On Mon, Sep 28, 2020 at 7:48 PM Tom Lane wrote:
> >
> > Bharath Rupireddy writes:
> > > In case of CTAS with no data, we actually do not insert the tuples
> > > into the created table, so we can skip checking for the insert
> > > permi
On 07/10/2020 15:27, Andrey Borodin wrote:
Here's draft patch with implementation of sortsupport for ints and floats.
+static int
+gbt_int4_cmp(Datum a, Datum b, SortSupport ssup)
+{
+ int32KEY *ia = (int32KEY *) DatumGetPointer(a);
+ int32KEY *ib = (int32KEY *) DatumGetPointer
Hi Alvaro san,
Thank you for your update :)
> Opinions? I experimented by patching psql as below (not intended for
> commit) and it looks good. Only ErrorResponse prints the terminator as a
> control character, or something:
I check code, changes and email. I agree with all of this.
I will re
> 29 сент. 2020 г., в 23:04, Andrey M. Borodin
> написал(а):
>
>
> Also I'm working on btree_gist opclasses and found out that new sortsupport
> function is not mentioned in gistadjustmembers(). I think this can be fixed
> with gist_btree patch.
Here's draft patch with implementation of so
On 07/10/2020 12:50, Amit Langote wrote:
On Tue, Oct 6, 2020 at 12:45 AM Heikki Linnakangas wrote:
It would be better to set it in make_modifytable(), just
after calling PlanDirectModify().
Actually, that's how it was done in earlier iterations but I think I
decided to move that into the FDW'
On Wed, Oct 7, 2020 at 11:20 AM Andy Fan wrote:
>
> Hi Ashutosh:
>
> Thanks for coming.
>
> On Mon, Oct 5, 2020 at 9:27 PM Ashutosh Bapat
> wrote:
>>
>> On Thu, Oct 1, 2020 at 9:34 PM Andy Fan wrote:
>> >
>> > Given the plan example:
>> >
>> > CREATE TABLE measurement (
>> > city_id
Hi,
Fix progname memory leak in ecpg client.
Issue taken from todo list https://wiki.postgresql.org/wiki/Todo.
Best regards,
Maksim Kita
>From 2f730117cbff1207c6b0bffc3097831fe5028fec Mon Sep 17 00:00:00 2001
From: Maksim Kita
Date: Wed, 7 Oct 2020 14:15:52 +0300
Subject: [PATCH] ecpg: fix progn
On Tue, Oct 6, 2020 at 7:22 PM Masahiko Sawada
wrote:
>
> On Fri, 2 Oct 2020 at 18:20, tsunakawa.ta...@fujitsu.com
> wrote:
> >
> > From: Masahiko Sawada
> > > You proposed the first idea
> > > to avoid such a situation that FDW implementor can write the code
> > > while trying to reduce the pos
On Tue, Oct 6, 2020 at 10:23 AM peter.b.sm...@fujitsu.com
wrote:
>
>
> ==
> Patch V6-0001, File: doc/src/sgml/logicaldecoding.sgml
> ==
>
> COMMENT/QUESTION
> Section 48.6.1
> @ -387,6 +387,10 @@ typedef struct OutputPluginCallbacks
> LogicalDecodeTruncateCB truncate_cb;
> Logica
Hekki,
Thanks a lot for the review!
On Tue, Oct 6, 2020 at 12:45 AM Heikki Linnakangas wrote:
> On 13/07/2020 08:47, Amit Langote wrote:
> > It's been over 11 months since there was any significant commentary on
> > the contents of the patches themselves, so perhaps I should reiterate
> > what t
Hi,
Am Mittwoch, den 07.10.2020, 21:11 +1300 schrieb Thomas Munro:
> On Wed, Oct 7, 2020 at 8:58 PM Michael Banck
> wrote:
> > we had a customer incident recently where they needed to do a PITR.
> > Their data directory is on a NetApp NFS and they have several hundred
> > databases in their inst
On Sun, Oct 4, 2020 at 3:10 PM Andy Fan wrote:
>
>>
>> Now, in my experience, the current system for custom plans vs. generic
>> plans doesn't approach the problem in this way at all, and in my
>> experience that results in some pretty terrible behavior. It will do
>> things like form a custom p
st 29. 7. 2020 v 8:18 odesílatel Pavel Stehule
napsal:
> Hi
>
>
>>
>> Hi Pavel,
>>
>> Since the idea originated from unescaping unicode string literals i.e.
>>select unescape('Odpov\u011Bdn\u00E1 osoba');
>>
>> Shouldn't the built-in function support the above syntax as well?
>>
>
> good
On Wed, Oct 7, 2020 at 11:24 AM Masahiko Sawada
wrote:
>
> On Tue, 6 Oct 2020 at 17:56, Amit Kapila wrote:
> >
> > On Tue, Oct 6, 2020 at 9:34 AM Masahiko Sawada
> > wrote:
> > >
> > > Looking at pgstat_reset_replslot_counter() in the v8 patch, even if we
> > > pass a physical slot name to pg_st
On Wed, Oct 7, 2020 at 2:43 PM Andy Fan wrote:
>
>> 2. Associate them with RelationOid, and we can record such information in
>> the
>> Append node as well. The bad part is the same relation Oid may appear
>> multiple
>> times in a query. for example: SELECT .. FROM p p1, p p2 where
>> p1.part
On Wed, Oct 7, 2020 at 12:40 AM Bharath Rupireddy
wrote:
> In parallel, we are not doing anything(due to the same reason
> explained in above comment) to find whether there is a foreign
> partition or not while deciding to go with parallel/non-parallel copy,
> we are just throwing an error during
On Fri, Sep 25, 2020 at 08:53:27AM +0200, Michael Banck wrote:
> Oh right, I've fixed up the commit message in the attached V4.
Not much a fan of what's proposed here, for a couple of reasons:
- If the page is not new, we should check if the header is sane or
not.
- It may be better to actually co
On Wed, Oct 7, 2020 at 8:58 PM Michael Banck wrote:
> we had a customer incident recently where they needed to do a PITR.
> Their data directory is on a NetApp NFS and they have several hundred
> databases in their instance. The startup sync (i.e. before the message
> "starting archive recovery" a
Hi,
we had a customer incident recently where they needed to do a PITR.
Their data directory is on a NetApp NFS and they have several hundred
databases in their instance. The startup sync (i.e. before the message
"starting archive recovery" appears) took 20 minutes and during the
first try[1] they
>
> Do you think that it is a bug? For now, I removed this statement from
> tests just to calm down the CI.
>
It is in accordance with changes in tests for vanilla
decralarive partitioning as per
commit 2dfa3fea88bc951d0812a18649d801f07964c9b9
Author: Tom Lane
Date: Mon Sep 28 13:44:01 2020 -0
84 matches
Mail list logo
