Re: Resolving the python 2 -> python 3 mess

Am 17.02.2020 um 17:49 schrieb Tom Lane: We've had multiple previous discussions of $SUBJECT (eg [1][2]), without any resolution of what to do exactly. Thinking about this some more, I had an idea that I don't think has been discussed. To wit: 1. On platforms where Python 2.x is still

Re: pgbench - add \aset to store results of a combined query

On Fri, Nov 29, 2019 at 10:34:05AM +0100, Fabien COELHO wrote: >> It seems to me that there is no point to have the variable aset in >> Command because this structure includes already MetaCommand, so the >> information is duplicated. [...] Perhaps I am missing something? > > Yep. ISTM that you

Re: Some problems of recovery conflict wait events

On Tue, 24 Mar 2020 at 17:04, Fujii Masao wrote: > > > > On 2020/03/05 20:16, Fujii Masao wrote: > > > > > > On 2020/03/05 16:58, Masahiko Sawada wrote: > >> On Wed, 4 Mar 2020 at 15:21, Fujii Masao > >> wrote: > >>> > >>> > >>> > >>> On 2020/03/04 14:31, Masahiko Sawada wrote: > On Wed, 4

Re: error context for vacuum to include block number

On Thu, Mar 26, 2020 at 09:50:53AM +0530, Amit Kapila wrote: > > > after count_nondeletable_pages, and then revert it back to > > > VACUUM_ERRCB_PHASE_SCAN_HEAP phase and the number of blocks of > > > relation before truncation, after RelationTruncate(). It can be > > > repeated until no more

Re: [Proposal] Global temporary tables

> Sorry, I introduced this bug in my refactoring. > It's been fixed. > > Wenjing > > Hi Wenjing, This patch(gtt_v21_pg13.patch) is not applicable on PG HEAD, I hope you have prepared the patch on top of some previous commit. Could you please rebase the patch which we can apply on HEAD ? -- With

Re: error context for vacuum to include block number

On Wed, Mar 25, 2020 at 6:11 PM Justin Pryzby wrote: > > On Wed, Mar 25, 2020 at 09:27:44PM +0900, Masahiko Sawada wrote: > > On Wed, 25 Mar 2020 at 20:24, Amit Kapila wrote: > > > > > > On Wed, Mar 25, 2020 at 3:42 PM Justin Pryzby > > > wrote: > > > > > > > > Attached patch addressing these.

Re: pgbench - add \aset to store results of a combined query

On Tue, Mar 24, 2020 at 11:04:45AM -0400, David Steele wrote: > On 11/29/19 4:34 AM, Fabien COELHO wrote: >> MetaCommand is not enough: we need varprefix, and then distinguishing >> between aset and gset. Although this last point can be done with a >> MetaCommand, ISTM that a bool is_aset is clear

Re: Refactor compile-time assertion checks for C/C++

On Mon, Mar 23, 2020 at 12:22:48AM -0400, Tom Lane wrote: > Yeah, the comment needs an update; but if we have four implementations > then it ought to describe each of them, IMO. I got an idea as per the attached. Perhaps you have a better idea? -- Michael diff --git a/src/include/c.h

Re: [Proposal] Global temporary tables

> 2020年3月25日 下午10:16，tushar 写道： > > On 3/17/20 9:15 AM, 曾文旌(义从) wrote: >> Please check global_temporary_table_v20-pg13.patch > > There is a typo in the error message > > postgres=# create global temp table test(a int ) > with(on_commit_delete_rows=true) on commit delete rows; > ERROR: can

Re: [Proposal] Global temporary tables

> 2020年3月25日 下午6:44，tushar 写道： > > On 3/17/20 9:15 AM, 曾文旌(义从) wrote: >> reindex GTT is already supported >> >> Please check global_temporary_table_v20-pg13.patch >> > Please refer this scenario - > > > postgres=# create global temp table co(n int) ; > CREATE TABLE > > postgres=# create

Re: [PATCH] Implement INSERT SET syntax

> On 26/03/2020, at 3:17 AM, Tom Lane wrote: > > Peter Eisentraut writes: >> On 2020-03-24 18:57, Tom Lane wrote: >>> No doubt that's all fixable, but the realization that some cases of >>> this syntax are*not* just syntactic sugar for standards-compliant >>> syntax is giving me pause. Do

Re: [Proposal] Global temporary tables

> 2020年3月25日 下午8:52，Prabhat Sahu 写道： > > Hi All, > > Please check the behavior of GTT having column with "SERIAL" datatype and > column with default value as "SEQUENCE" as below: > > Session1: > postgres=# create sequence gtt_c3_seq; > CREATE SEQUENCE > postgres=# create global temporary

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/03/26 2:17, Sergei Kornilov wrote: Hello WAL usage patch [1] increments this version to 1_4 instead of 1_8. I *guess* that's because previously this version was maintained independently from pg_stat_statements' version. For example, pg_stat_statements 1.4 seems to have used

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

Because I replied the old thread, cfbot run a test based on the old patch on that thread. I have detached the old thread from commitfest. Reply this email again to wake up Mr. cfbot with the right information. v2-0001-Maintain-the-uniqueness-of-a-Query-from-bottom-to.patch Description:

Re: AllocSetEstimateChunkSpace()

On Wed, 2020-03-25 at 15:09 -0700, Andres Freund wrote: > > The overhead comes from two places: (a) the chunk header; and (b) > > the > > round-up-to-nearest-power-of-two behavior. > > > > Combining the group tuple and per-group states only saves the > > overhead > > from (a); it does nothing to

Re: allow online change primary_conninfo

On 2020-Mar-24, Alvaro Herrera wrote: > I think the startup sighup handler should be in startup.c, not xlog.c, > which has enough random code already. We can add an accessor in xlog.c > to let changing the walrcv status flag, to be called from the signal > handler. ... as in the attached

Re: plan cache overhead on plpgsql expression

Andres Freund writes: > I'm still confused by the comment I was reacting to - the code > explicitly is about creating the *shared* resowner: Right, this is because of the choice I mentioned earlier about creating this resowner the same way as the one for the inline case. I guess the comments

Re: plan cache overhead on plpgsql expression

Hi, On 2020-03-25 19:15:28 -0400, Tom Lane wrote: > >> The comment is there because the regression tests fall over if you try > >> to do it the other way :-(. The failure I saw was specific to a > >> transaction being done in a DO block, and maybe we could handle that > >> differently from the

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On Thu, Mar 12, 2020 at 08:08:46PM +0300, Alexey Kondratov wrote: > On 09.03.2020 23:04, Justin Pryzby wrote: >> On Sat, Feb 29, 2020 at 08:53:04AM -0600, Justin Pryzby wrote: >>> On Sat, Feb 29, 2020 at 03:35:27PM +0300, Alexey Kondratov wrote: >>> tests for that. (I'm including your v8

Re: plan cache overhead on plpgsql expression

Andres Freund writes: > On 2020-03-25 17:51:50 -0400, Tom Lane wrote: >> Perhaps, but I'm not sure that either of those functions represent >> material overhead in cases besides this one. > That's not huge, but also not nothing. I see. So maybe worth the trouble --- but still, seems like

Re: plan cache overhead on plpgsql expression

Hi, On 2020-03-25 17:51:50 -0400, Tom Lane wrote: > Andres Freund writes: > > I wonder if it'd make sense to store the locks needed for > > AcquirePlannerLocks/AcquireExecutorLocks in a better form. > > Perhaps, but I'm not sure that either of those functions represent > material overhead in

Re: AllocSetEstimateChunkSpace()

Hi, On 2020-03-25 14:43:43 -0700, Jeff Davis wrote: > On Wed, 2020-03-25 at 12:42 -0700, Andres Freund wrote: > > As mention on im/call: I think this is mainly an argument for > > combining > > the group tuple & per-group state allocations. I'm kind of fine with > > afterwards taking the

Re: plan cache overhead on plpgsql expression

Andres Freund writes: > I wonder if it'd make sense to store the locks needed for > AcquirePlannerLocks/AcquireExecutorLocks in a better form. Perhaps, but I'm not sure that either of those functions represent material overhead in cases besides this one. > Would it make sense to instead compute

Re: AllocSetEstimateChunkSpace()

On Wed, 2020-03-25 at 12:42 -0700, Andres Freund wrote: > As mention on im/call: I think this is mainly an argument for > combining > the group tuple & per-group state allocations. I'm kind of fine with > afterwards taking the allocator overhead into account. The overhead comes from two places:

Re: plan cache overhead on plpgsql expression

Hi, On 2020-03-21 14:24:05 -0400, Tom Lane wrote: > So while there's clearly something worth pursuing here, I do not like > anything about the way it was done. I think that the right way to > think about this problem is "how can the plan cache provide a fast > path for checking validity of

Re: backup manifests

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Mar 25, 2020 at 9:31 AM Stephen Frost wrote: > > I get that the default for manifest is 'no', but I don't really see how > > that means that the lack of saying anything about checksums should mean > > "give me crc32c checksums".

Re: Allow continuations in "pg_hba.conf" files

Hello Justin, thanks for the feedback. - Records cannot be continued across lines. + Records can be backslash-continued across lines. Maybe say: "lines ending with a backslash are logically continued on the next line", or similar. I tried to change it along that. Since it puts a

Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding

Noah Misch writes: > On Thu, Mar 19, 2020 at 06:04:52PM -0400, Tom Lane wrote: >> 1. It seems like this discussion is conflating two different issues. > When the newest XID and the oldest XID fall in "opposite" segments in the XID > space, we must not unlink the segment containing the newest

Re: plan cache overhead on plpgsql expression

On Sat, Mar 21, 2020 at 2:24 PM Tom Lane wrote: > With this patch, perf shows the hotspots on Pavel's original example > as being > > + 19.24%19.17% 46470 postmaster plpgsql.so > [.] exec_eval_expr > + 15.19%15.15% 36720 postmaster

Re: Berserk Autovacuum (let's save next Mandrill)

On Wed, Mar 25, 2020 at 10:26 PM Andres Freund wrote: > On 2020-03-25 11:05:21 -0500, Justin Pryzby wrote: > > Since we talked about how scale_factor can be used to effectively disable > > this > > new feature, I thought that scale=100 was too small and suggesed 1e10 (same > > as > > max for

Re: [DOC] Document concurrent index builds waiting on each other

On 2020-Mar-25, Andres Freund wrote: > > I don't know if my approach is exactly what Andres has in mind > > Not quite. I don't think it's generally correct for CIC to set > PROC_IN_VACUUM. I'm doubtful it's the case even just for plain indexes - > we don't want rows to be pruned away from under

Re: [DOC] Document concurrent index builds waiting on each other

Hi, On 2020-03-25 16:30:10 -0300, Alvaro Herrera wrote: > I posted this in November > https://postgr.es/m/20191101203310.GA12239@alvherre.pgsql but I didn't > put time to go through the issues there. Oh, missed that. > I don't know if my approach is exactly what Andres has in mind Not quite.

Re: [DOC] Document concurrent index builds waiting on each other

Hi, On 2020-03-25 15:24:44 -0400, James Coleman wrote: > Andres: If we got this fixed in current PG would you be opposed to > documenting the caveat in previous versions? Not really. I'm just not confident it's going to be useful, given the amount of details needed to be provided to really make

Re: plan cache overhead on plpgsql expression

Pavel Stehule writes: > I'll mark this patch as ready for commiters. Thanks for reviewing! Amit, do you have any thoughts on this? regards, tom lane

Re: AllocSetEstimateChunkSpace()

Hi, On 2020-03-24 18:12:03 -0700, Jeff Davis wrote: > Attached is a small patch that introduces a simple function, > AllocSetEstimateChunkSpace(), and uses it to improve the estimate for > the size of a hash entry for hash aggregation. > > Getting reasonable estimates for the hash entry size

Re: Allow continuations in "pg_hba.conf" files

Hi, On Wed, Mar 25, 2020 at 07:09:38PM +0100, Fabien COELHO wrote: > > Hello, > > After writing an unreadable and stupidly long line for ldap authentification > in a "pg_hba.conf" file, I figured out that allowing continuations looked > simple enough and should just be done. I tried this

Re: [DOC] Document concurrent index builds waiting on each other

On 2020-Mar-25, James Coleman wrote: > Alvaro: I think you had some ideas on this too; any chance you've know > of a patch that anyone's got cooking? I posted this in November https://postgr.es/m/20191101203310.GA12239@alvherre.pgsql but I didn't put time to go through the issues there. I don't

Re: Include sequence relation support in logical replication

Hi, On 2020-03-24 16:19:21 -0700, Cary Huang wrote: > I have shared a patch that allows sequence relation to be supported in > logical replication via the decoding plugin ( test_decoding for > example ); it does not support sequence relation in logical > replication between a PG publisher and a

Re: Berserk Autovacuum (let's save next Mandrill)

Hi, On 2020-03-25 11:05:21 -0500, Justin Pryzby wrote: > Since we talked about how scale_factor can be used to effectively disable this > new feature, I thought that scale=100 was too small and suggesed 1e10 (same as > max for vacuum_cleanup_index_scale_factor since 4d54543ef). That should allow

Re: [DOC] Document concurrent index builds waiting on each other

On Wed, Mar 25, 2020 at 3:19 PM Andres Freund wrote: > > Hi, > > On 2019-09-18 13:51:00 -0400, James Coleman wrote: > > In my experience it's not immediately obvious (even after reading the > > documentation) the implications of how concurrent index builds manage > > transactions with respect to

Re: [DOC] Document concurrent index builds waiting on each other

Hi, On 2019-09-18 13:51:00 -0400, James Coleman wrote: > In my experience it's not immediately obvious (even after reading the > documentation) the implications of how concurrent index builds manage > transactions with respect to multiple concurrent index builds in > flight at the same time. > >

Re: plan cache overhead on plpgsql expression

so 21. 3. 2020 v 21:29 odesílatel Pavel Stehule napsal: > > > so 21. 3. 2020 v 19:24 odesílatel Tom Lane napsal: > >> Pavel Stehule writes: >> > So the patch has a problem with constant casting - unfortunately the >> mix of >> > double precision variables and numeric constants is pretty often

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

Hi, I've started reviewing the patch a couple days ago. I haven't done any extensive testing, but I do have a bunch of initial comments that I can share now. 1) I wonder if this needs to update src/backend/optimizer/README, which does have a section about partitionwise joins. It seems

Re: AllocSetEstimateChunkSpace()

On Tue, 2020-03-24 at 18:12 -0700, Jeff Davis wrote: > I considered making it a method of a memory context, but the planner > will call this function before the hash agg memory context is > created. I implemented this approach also; attached. It works a little better by having access to the

Re: [HACKERS] make async slave to wait for lsn to be replayed

On 2020-03-21 14:16, Kartyshov Ivan wrote: As it was discussed earlier, I added wait for statement into begin/start statement. Thanks! To address the discussion: I like the idea of having WAIT as a part of BEGIN statement rather than a separate command, as Thomas Munro suggested. That way, the

Allow continuations in "pg_hba.conf" files

Hello, After writing an unreadable and stupidly long line for ldap authentification in a "pg_hba.conf" file, I figured out that allowing continuations looked simple enough and should just be done. Patch attached. -- Fabien.diff --git a/doc/src/sgml/client-auth.sgml

Re: Planning counters in pg_stat_statements (using pgss_store)

Hello > WAL usage patch [1] increments this version to 1_4 instead of 1_8. > I *guess* that's because previously this version was maintained > independently from pg_stat_statements' version. For example, > pg_stat_statements 1.4 seems to have used PGSS_V1_3. As far as I remember, this was my

Re: Columns correlation and adaptive query optimization

Hello, This sounded like an interesting addition to postgresql. I gave some time to it today to review, here are few comments, On Wed, 25 Mar 2020 at 14:28, Konstantin Knizhnik wrote: > > > > On 25.03.2020 16:00, David Steele wrote: > > On 3/25/20 6:57 AM, Konstantin Knizhnik wrote: > >> > >> >

Re: [PATCH] Check operator when creating unique index on partition table

Guancheng Luo writes: > I found that things could go wrong in some cases, when the unique index and > the partition key use different opclass. I agree that this is an oversight, but it seems like your solution is overcomplicated and probably still too forgiving. Should we not just insist that

Re: potential stuck lock in SaveSlotToPath()

On Wed, Mar 25, 2020 at 6:13 AM Peter Eisentraut wrote: > Any concerns about applying and backpatching the patch I posted? Not from me. > The talk about reorganizing this code doesn't seem very concrete at the > moment and would probably not be backpatch material anyway. +1. -- Robert Haas

Re: backup manifests

On Wed, Mar 25, 2020 at 9:31 AM Stephen Frost wrote: > I get that the default for manifest is 'no', but I don't really see how > that means that the lack of saying anything about checksums should mean > "give me crc32c checksums". It's really rather common that if we don't > specify something,

Re: Some improvements to numeric sqrt() and ln()

Dean Rasheed writes: > Here is an updated patch with the following updates based on your comments: This resolves all my concerns. I've marked it RFC in the CF app. regards, tom lane

Re: Option to dump foreign data in pg_dump

On 2020-Mar-24, Alvaro Herrera wrote: > Hmm, but travis is failing on the cfbot, and I can't see why ... My only guess, without further output, is that getopt_long is not liking the [ "--include-foreign-data", "xxx" ] style of arguments in the Perl array of the command to run (which we don't use

Re: Missing errcode() in ereport

I wrote: > Thomas Munro writes: >> I think this caused anole to say: >> "reloptions.c", line 1362: error #2042: operand types are incompatible >> ("void" and "int") >> errdetail_internal("%s", _(optenum->detailmsg)) : 0)); > Yeah, I was just looking at that :-( > We could revert the change to

Re: Berserk Autovacuum (let's save next Mandrill)

On Wed, Mar 25, 2020 at 12:46:52PM -0300, Alvaro Herrera wrote: > On 2020-Mar-25, Justin Pryzby wrote: > > > Maybe in the docs you can write this with thousands separators: 10,000,000 > > > > It looks like the GUC uses scale factor max=1e10, but the relopt is still > > max=100, which means it's

Re: Berserk Autovacuum (let's save next Mandrill)

On 2020-Mar-25, Justin Pryzby wrote: > Maybe in the docs you can write this with thousands separators: 10,000,000 > > It looks like the GUC uses scale factor max=1e10, but the relopt is still > max=100, which means it's less possible to disable for a single rel. I have paid no attention to this

Re: [PATCH] Erase the distinctClause if the result is unique by definition

I have started the new thread [1] to continue talking about this. Mr. cfbot is happy now. [1] https://www.postgresql.org/message-id/flat/CAKU4AWrwZMAL%3DuaFUDMf4WGOVkEL3ONbatqju9nSXTUucpp_pw%40mail.gmail.com Thanks >

Re: Berserk Autovacuum (let's save next Mandrill)

On Mon, Mar 23, 2020 at 02:27:29PM +0100, Laurenz Albe wrote: > Here is version 10 of the patch, which uses a scale factor of 0.2. Thanks > Any table that has received more inserts since it was > last vacuumed (and that is not vacuumed for another > reason) will be autovacuumed. Since this

Re: [Patch] Invalid permission check in pg_stats for functional indexes

Hi Pierre, On 12/26/19 6:46 PM, Tom Lane wrote: Awhile back I wrote: Actually ... maybe we don't need to change the view definition at all, but instead just make has_column_privilege() do something different for indexes than it does for other relation types. It's dubious that applying that

Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits

On Tue, Mar 24, 2020 at 10:06 PM Ibrar Ahmed wrote: > > > On Fri, Mar 13, 2020 at 6:58 AM Justin Pryzby > wrote: > >> >> Thanks for picking up this patch. There's a minor typo: >> >> +* readable outside of this sessoin. Therefore >> doing IO here isn't >> >> => session

Re: Berserk Autovacuum (let's save next Mandrill)

On Mon, 2020-03-23 at 14:27 +0100, Laurenz Albe wrote: > Here is version 10 of the patch, which uses a scale factor of 0.2. This patch should be what everybody can live with. It would be good if we can get at least that committed before feature freeze. Yours, Laurenz Albe

Re: weird hash plan cost, starting with pg10

On 25.03.2020 13:36, Richard Guo wrote: On Tue, Mar 24, 2020 at 3:36 PM Richard Guo > wrote: On Tue, Mar 24, 2020 at 11:05 AM Thomas Munro mailto:thomas.mu...@gmail.com>> wrote: I think there might be a case like this: *

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

On Mon, Mar 23, 2020 at 6:21 PM Andy Fan wrote: > Greetings. > > This thread is a follow-up thread for [1], where I submit a patch for > erasing the > distinct node if we have known the data is unique for sure. But since the > implementation has changed a lot from the beginning and they are not

Re: [PATCH] Implement INSERT SET syntax

Peter Eisentraut writes: > On 2020-03-24 18:57, Tom Lane wrote: >> No doubt that's all fixable, but the realization that some cases of >> this syntax are*not* just syntactic sugar for standards-compliant >> syntax is giving me pause. Do we really want to get out front of >> the SQL committee on

Re: [Proposal] Global temporary tables

On 3/17/20 9:15 AM, 曾文旌(义从) wrote: Please check global_temporary_table_v20-pg13.patch There is a typo in the error message postgres=# create global temp table test(a int ) with(on_commit_delete_rows=true) on commit delete rows; ERROR:  can not defeine global temp table with on commit and

Re: Applying for GSOC 2020 | Need review of proposal

Greetings, * Gyati Mittal (gmitt...@horizon.csueastbay.edu) wrote: > I am trying to submit a draft proposal for this task: > > Develop Performance Farm Benchmarks and Website (2020) Great! I'd suggest you reach out to the mentor listed on the wiki page for that project to chat about what a

Re: Planning counters in pg_stat_statements (using pgss_store)

On Wed, Mar 25, 2020 at 10:09:37PM +0900, Fujii Masao wrote: > > On 2020/03/21 4:30, Julien Rouhaud wrote: > > On Fri, Mar 20, 2020 at 05:09:05PM +0300, Sergei Kornilov wrote: > > > Hello > > > > > > Yet another is missed in docs: total_time > > > > Oh good catch! I rechecked many time the

Re: potential stuck lock in SaveSlotToPath()

On 2020-Mar-25, Peter Eisentraut wrote: > On 2020-03-20 16:38, Robert Haas wrote: > > On Fri, Mar 20, 2020 at 11:32 AM Peter Eisentraut > > wrote: > > > On 2020-03-19 16:38, Robert Haas wrote: > > > > Incidentally, the wait-event handling in SaveSlotToPath() doesn't look > > > > right for the

Re: where EXEC_BACKEND is defined

On 2020-03-20 17:36, Tom Lane wrote: One small point is that I believe the existing code has the effect of "#define EXEC_BACKEND 1" not just "#define EXEC_BACKEND". I don't think this matters to anyplace in the core code, but it's conceivable that somebody has extension code written to assume

Re: backup manifests

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Mar 23, 2020 at 6:42 PM Stephen Frost wrote: > > While I get the desire to have a default here that includes checksums, > > the way the command is structured, it strikes me as odd that the lack of > > MANIFEST_CHECKSUMS in the

Re: Columns correlation and adaptive query optimization

On 25.03.2020 16:00, David Steele wrote: On 3/25/20 6:57 AM, Konstantin Knizhnik wrote: On 24.03.2020 20:12, David Steele wrote: On 12/24/19 3:15 AM, Konstantin Knizhnik wrote: New version of patch implicitly adding multicolumn statistic in auto_explain extension and using it in optimizer

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/03/21 4:30, Julien Rouhaud wrote: On Fri, Mar 20, 2020 at 05:09:05PM +0300, Sergei Kornilov wrote: Hello Yet another is missed in docs: total_time Oh good catch! I rechecked many time the field, and totally missed that the documentation is referring to the view, which has an

Re: Columns correlation and adaptive query optimization

On 3/25/20 6:57 AM, Konstantin Knizhnik wrote: On 24.03.2020 20:12, David Steele wrote: On 12/24/19 3:15 AM, Konstantin Knizhnik wrote: New version of patch implicitly adding multicolumn statistic in auto_explain extension and using it in optimizer for more precise estimation of join

Re: [Proposal] Global temporary tables

st 25. 3. 2020 v 13:53 odesílatel Prabhat Sahu < prabhat.s...@enterprisedb.com> napsal: > Hi All, > > Please check the behavior of GTT having column with "SERIAL" datatype and > column with default value as "SEQUENCE" as below: > > > *Session1:*postgres=# create sequence gtt_c3_seq; > CREATE

Re: [Proposal] Global temporary tables

Hi All, Please check the behavior of GTT having column with "SERIAL" datatype and column with default value as "SEQUENCE" as below: *Session1:*postgres=# create sequence gtt_c3_seq; CREATE SEQUENCE postgres=# create global temporary table gtt(c1 int, c2 serial, c3 int default

Re: Make mesage at end-of-recovery less scary.

On 2020-03-24 02:52, Kyotaro Horiguchi wrote: I don't find that very satisfying, but I can't come up with something that provides the current information, while being less scary than my suggestion? The 0-length record is not an "invalid" state during recovery, so we can add the message for the

Re: [PATCH] Implement INSERT SET syntax

On 2020-03-24 18:57, Tom Lane wrote: No doubt that's all fixable, but the realization that some cases of this syntax are*not* just syntactic sugar for standards-compliant syntax is giving me pause. Do we really want to get out front of the SQL committee on extending INSERT in an incompatible

Re: pg_upgrade fails with non-standard ACL

On Wed, Mar 25, 2020 at 11:12:05AM +0900, Artur Zakirov wrote: > Hello David, > > On 3/25/2020 2:08 AM, David Steele wrote: > > On 12/17/19 3:10 AM, Arthur Zakirov wrote: > > > > > > I attached new version of the patch. It still uses > > > pg_identify_object(), I'm not sure about other ways to

Re: error context for vacuum to include block number

On Wed, Mar 25, 2020 at 09:27:44PM +0900, Masahiko Sawada wrote: > On Wed, 25 Mar 2020 at 20:24, Amit Kapila wrote: > > > > On Wed, Mar 25, 2020 at 3:42 PM Justin Pryzby wrote: > > > > > > Attached patch addressing these. > > > > > > > Thanks, you forgot to remove the below declaration which I

Re: adding partitioned tables to publications

On 2020-03-23 06:02, Amit Langote wrote: Okay, added some tests. Attached updated patches. I have committed the worker.c refactoring patch. "Add subscription support to replicate into partitioned tables" still has lacking test coverage. Your changes in relation.c are not exercised at all

Re: error context for vacuum to include block number

On Wed, 25 Mar 2020 at 20:24, Amit Kapila wrote: > > On Wed, Mar 25, 2020 at 3:42 PM Justin Pryzby wrote: > > > > Attached patch addressing these. > > > > Thanks, you forgot to remove the below declaration which I have > removed in attached. > > @@ -724,20 +758,20 @@ lazy_scan_heap(Relation

Re: improve transparency of bitmap-only heap scans

On Tue, Mar 24, 2020 at 11:02 PM Amit Kapila wrote: > > On Wed, Mar 25, 2020 at 12:44 AM Tom Lane wrote: > > > > I took a quick look through this patch. While I see nothing to complain > > about implementation-wise, I'm a bit befuddled as to why we need this > > reporting when there is no

Re: error context for vacuum to include block number

On Wed, Mar 25, 2020 at 04:54:41PM +0530, Amit Kapila wrote: > On Wed, Mar 25, 2020 at 3:42 PM Justin Pryzby wrote: > > > > Attached patch addressing these. > > > > Thanks, you forgot to remove the below declaration which I have > removed in attached. Yes I saw.. > Apart from this, I have ran

Re: error context for vacuum to include block number

On Wed, Mar 25, 2020 at 3:42 PM Justin Pryzby wrote: > > Attached patch addressing these. > Thanks, you forgot to remove the below declaration which I have removed in attached. @@ -724,20 +758,20 @@ lazy_scan_heap(Relation onerel, VacuumParams *params, LVRelStats *vacrelstats,

Generated column and inheritance: strange default error

Hello dear Hackers, I encountered a strange issue with generated column and inheritance. The core of the problem is that when inheriting from a table, you can re-declare the same column (provided it has the same type). But when doing this and introducing a generated column, an error is raised

Re: Columns correlation and adaptive query optimization

On 24.03.2020 20:12, David Steele wrote: On 12/24/19 3:15 AM, Konstantin Knizhnik wrote: New version of patch implicitly adding multicolumn statistic in auto_explain extension and using it in optimizer for more precise estimation of join selectivity. This patch fixes race condition while

Re: [Proposal] Global temporary tables

On 3/17/20 9:15 AM, 曾文旌(义从) wrote: reindex GTT is already supported Please check global_temporary_table_v20-pg13.patch Please refer this scenario - postgres=# create global temp table co(n int) ; CREATE TABLE postgres=# create index fff on co(n); CREATE INDEX Case 1- postgres=# reindex

[PATCH] Check operator when creating unique index on partition table

Hi, I found that things could go wrong in some cases, when the unique index and the partition key use different opclass. For example: ``` CREATE TABLE ptop_test (a int, b int, c int) PARTITION BY LIST (a); CREATE TABLE ptop_test_p1 PARTITION OF ptop_test FOR VALUES IN ('1'); CREATE TABLE

Re: replay pause vs. standby promotion

Hi >>  Could we add a few words in func.sgml to clarify the behavior? Especially >> for users from my example above. Something like: >> >>>  If a promotion is triggered while recovery is paused, the paused state >>> ends, replay of any WAL immediately available in the archive or in pg_wal >>>

Re: weird hash plan cost, starting with pg10

On Tue, Mar 24, 2020 at 3:36 PM Richard Guo wrote: > On Tue, Mar 24, 2020 at 11:05 AM Thomas Munro > wrote: > >> >> I think there might be a case like this: >> >> * ExecRescanHashJoin() decides it can't reuse the hash table for a >> rescan, so it calls ExecHashTableDestroy(), clears

Re: truncating timestamps on arbitrary intervals

On Tue, Mar 24, 2020 at 9:34 PM Tels wrote: > > Hello John, > > this looks like a nice feature. I'm wondering how it relates to the > following use-case: > > When drawing charts, the user can select pre-defined widths on times > (like "15 min", "1 hour"). > > The data for these slots is fitted

Re: potential stuck lock in SaveSlotToPath()

On 2020-03-20 16:38, Robert Haas wrote: On Fri, Mar 20, 2020 at 11:32 AM Peter Eisentraut wrote: On 2020-03-19 16:38, Robert Haas wrote: Incidentally, the wait-event handling in SaveSlotToPath() doesn't look right for the early-exit cases either. There appear to be appropriate

Re: error context for vacuum to include block number

On Wed, Mar 25, 2020 at 09:16:46AM +0530, Amit Kapila wrote: > I think by mistake you have re-introduced this chunk of code. We > don't need this as we have done it in the caller. Yes, sorry. I used too much of git-am and git-rebase to make sure I didn't lose your changes and instead

Re: [proposal] de-TOAST'ing using a iterator

On Fri, Mar 13, 2020 at 10:19 PM Alvaro Herrera wrote: > > So let's move forward with v10 (submitted on Sept 10th). In the attached v12, based on v10, I've made some progress to address some of the remaining issues. There's still some work to be done, in particular to think about how to hide the

Re: Some improvements to numeric sqrt() and ln()

On Sun, 22 Mar 2020 at 22:16, Tom Lane wrote: > > With resolutions of the XXX items, I think this'd be committable. > Thanks for looking at this! Here is an updated patch with the following updates based on your comments: * Now uses integer arithmetic to compute res_weight and res_ndigits,

Re: Internal key management system

On Tue, 24 Mar 2020 at 23:15, Bruce Momjian wrote: > > On Tue, Mar 24, 2020 at 02:29:57PM +0900, Masahiko Sawada wrote: > > That seems to work fine. > > > > So we will have pg_cryptokeys within PGDATA and each key is stored > > into separate file named the key id such as "sql", "tde-wal" and > >

Re: Index Skip Scan

> On Wed, Mar 25, 2020 at 11:31:56AM +0530, Dilip Kumar wrote: > > Seems like you forgot to add the uniquekey.c file in the > v33-0001-Unique-key.patch. Oh, you're right, thanks. Here is the corrected patch. >From 15989c5250214fea8606a56afd1eeaf760b8723e Mon Sep 17 00:00:00 2001 From: Dmitrii

Small computeRegionDelta optimization.

Hi hackers, Playing with my undo-log storage, I found out that its performance is mostly limited by generic WAL record mechanism, and particularly by computeRegionDelta function which  computes page delta for each logged operation. I noticed that computeRegionDelta also becomes bottleneck in

Re: Autovacuum vs vac_update_datfrozenxid() vs ?

On Mon, Mar 23, 2020 at 04:50:36PM -0700, Andres Freund wrote: > Which all in theory makes sense - but there's two fairly sizable races > here: > 1) Because lastSaneFrozenXid is determined *before* the snapshot for >the pg_class, it's entirely possible that concurrently another vacuum on >

Re: pg_upgrade fails with non-standard ACL

> On 25 Mar 2020, at 03:12, Artur Zakirov wrote: > Regression tests fail because cfbot applies > "test_rename_catalog_objects.patch". Regression tests pass without it. > > This patch shouldn't be applied by cfbot. I'm not sure how to do this. But > maybe it is possible to use different

  1   2   >