Re: Remove Deprecated Exclusive Backup Mode

On 7/1/20 5:44 PM, Magnus Hagander wrote: On Wed, Jul 1, 2020 at 11:08 PM David Steele > wrote: But yeah, it would be possible to kill somebody else's session with some finagling. Still, worse case would be an error'd backup rather than a corrupt one.

Re: [PATCH] fix GIN index search sometimes losing results

ср, 1 июл. 2020 г. в 23:16, Tom Lane : > Pavel Borisov writes: > > Below is my variant how to patch Gin-Gist weights issue: > > I looked at this patch, but I'm unimpressed, because it's buggy. > Thank you, i'd noticed and made minor corrections in the patch. Now it should work correctly, As

Re: Remove Deprecated Exclusive Backup Mode

On Thu, 2 Jul 2020 12:32:14 +0200 Magnus Hagander wrote: [...] > > non-exclusive backup...this is not that easy anymore. And > > pg_is_in_backup() is quite misleading if the admin found it without reading > > doc. Maybe an admin > > Yeah, as it is now it should really be called

Re: POC: rational number type (fractions)

On 7/1/20 7:00 PM, Stephen Frost wrote: > Greetings, > > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Stephen Frost writes: >>> I disagree with this and instead lean more towards the side that Robert >>> and Jeff were taking in that this would be a useful extension and >>> something we should

Re: suggest to rename enable_incrementalsort

I think the change makes a lot of sense. The only reason I had it as enable_incrementalsort in the first place was trying to broadly following the existing GUC names, but as has already been pointed out, there's a lot of variation there, and my version of the patch already changed it to be more

Re: Reducing WaitEventSet syscall churn

> On 13 Mar 2020, at 08:21, Kyotaro Horiguchi wrote: > The attached are: > 0001-0004 Not changed > 0005 Fix interface of PQregisterEventProc > 0006 Add new libpq event for this use. > 0007 Another version of "0006 Reuse a WaitEventSet in > libpqwalreceiver.c" based on libpq event. >

Re: Remove Deprecated Exclusive Backup Mode

Greetings, * Laurenz Albe (laurenz.a...@cybertec.at) wrote: > On Wed, 2020-07-01 at 16:46 -0400, Stephen Frost wrote: > > If someone could explain what is so special about *this* part of the > > system that we absolutely can't possibly accept any change that might > > break user's scripts, and

Re: Auxiliary Processes and MyAuxProc

> On 27 Mar 2020, at 00:30, Mike Palmiotto > wrote: > Are these pieces required to make this patchset committable? Is there > anything else needed at this point to make it committable? The submitted version no longer applies, the 0009 patch has conflicts in postmaster.c. Can you please submit

Re: Built-in connection pooler

> On 2 Jul 2020, at 13:33, Konstantin Knizhnik > wrote: > On 01.07.2020 12:30, Daniel Gustafsson wrote: >>> On 24 Mar 2020, at 17:24, Konstantin Knizhnik >>> wrote: >>> Rebased version of the patch is attached. >> And this patch also fails to apply now, can you please submit a new version? >>

Re: Auxiliary Processes and MyAuxProc

On 2020-Jul-02, Daniel Gustafsson wrote: > > On 27 Mar 2020, at 00:30, Mike Palmiotto > > wrote: > > > Are these pieces required to make this patchset committable? Is there > > anything else needed at this point to make it committable? > > The submitted version no longer applies, the 0009

Re: Auxiliary Processes and MyAuxProc

> On 2 Jul 2020, at 17:03, Alvaro Herrera wrote: > > On 2020-Jul-02, Daniel Gustafsson wrote: > >>> On 27 Mar 2020, at 00:30, Mike Palmiotto >>> wrote: >> >>> Are these pieces required to make this patchset committable? Is there >>> anything else needed at this point to make it committable?

Re: MultiXact\SLRU buffers configuration

> On 15 May 2020, at 02:03, Kyotaro Horiguchi wrote: > Generally in such cases, condition variables would work. In the > attached PoC, the reader side gets no penalty in the "likely" code > path. The writer side always calls ConditionVariableBroadcast but the > waiter list is empty in almost

Re: WIP: Aggregation push-down

> On 19 May 2020, at 10:17, Antonin Houska wrote: > The next version is attached. This version now fails to apply to HEAD, with what looks like like a trivial error in the expected test output. Can you please submit a rebased version so we can see it run in the patch tester CI? I'm marking

Re: Report error position in partition bound check

> On 10 Apr 2020, at 23:50, Alexandra Wang wrote: > On Fri, Apr 10, 2020 at 8:37 AM Ashutosh Bapat > mailto:ashutosh.ba...@2ndquadrant.com>> > wrote: > > for a multi-key value the ^ > > points to the first column and the reader may think that that's the > > problematci column. Should it

Re: Remove Deprecated Exclusive Backup Mode

Greetings, * Magnus Hagander (mag...@hagander.net) wrote: > On Thu, Jul 2, 2020 at 1:06 AM Jehan-Guillaume de Rorthais > wrote: > > function to list in progress non-exclusive backup and related backend pid > > might > > be a good start? > > I think it would make perfect sense to show manual

Re: POC: rational number type (fractions)

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Andrew Dunstan writes: > > On 7/1/20 7:00 PM, Stephen Frost wrote: > >> ... extensions outside of PG simply don't thrive as independent projects. > >> > >> There's various potential reasons for that, from being hard to find, to > >> being hard

Re: POC and rebased patch for CSN based snapshots

Thanks for the remarks, >Some remarks on your patch: >1. The variable last_max_csn can be an atomic variable. Yes will consider. >2. GenerateCSN() routine: in the case than csn < csnState->last_max_csn >This is the case when someone changed the value of the system clock. I >think it

Re: Using Valgrind to detect faulty buffer accesses (no pin or buffer content lock held)

> On 26 Apr 2020, at 02:17, Peter Geoghegan wrote: > Attached is v2 of the patch series. This patch fails to apply to HEAD due to conflicts in nbtpage.c, can you please submit a rebased version? cheers ./daniel

Re: Recognizing superuser in pg_hba.conf

On 7/2/20 3:14 PM, Daniel Gustafsson wrote: >> On 30 Mar 2020, at 20:28, Tom Lane wrote: >> >> Tomas Vondra writes: >>> I see this patch is marked as RFC since 12/30, but there seems to be >>> quite a lot of discussion about the syntax, keywords and how exactly to >>> identify the superuser. So

Re: [Patch] Use internal pthreads reimplementation only when building with MSVC

> On 9 Apr 2020, at 23:57, Alvaro Herrera wrote: > Please do submit patches as separate attachments rather than in the > email body. Since the CF app is unable to see that there is a patch at all, I took the liberty to resubmit the posted patch rebased on top of HEAD and with the C++ replaced

Re: Auxiliary Processes and MyAuxProc

On 2020-Mar-26, Mike Palmiotto wrote: Regarding 0001: > diff --git a/src/backend/postmaster/subprocess.c > b/src/backend/postmaster/subprocess.c > new file mode 100644 > index 00..3e7a45bf10 > --- /dev/null > +++ b/src/backend/postmaster/subprocess.c > @@ -0,0 +1,62 @@ >

Re: [PATCH] Initial progress reporting for COPY command

čt 2. 7. 2020 v 14:25 odesílatel Daniel Gustafsson napsal: > The automated patchtester for the Commitfest gets confused when there are > two > versions of the same changeset attached to the email, as it tries to apply > them > both which obviously results in an application failure. I've

Re: Recognizing superuser in pg_hba.conf

> On 30 Mar 2020, at 20:28, Tom Lane wrote: > > Tomas Vondra writes: >> I see this patch is marked as RFC since 12/30, but there seems to be >> quite a lot of discussion about the syntax, keywords and how exactly to >> identify the superuser. So I'll switch it back to needs review, which I >>

Re: POC: rational number type (fractions)

Andrew Dunstan writes: > On 7/1/20 7:00 PM, Stephen Frost wrote: >> ... extensions outside of PG simply don't thrive as independent projects. >> >> There's various potential reasons for that, from being hard to find, to >> being hard to install and work with, to the fact that we don't have a >>

Re: Let people set host(no)ssl settings from initdb

The CF Patch Tester consider this patch to be malformed and is unable to apply and test it. Can you please submit a rebased version? cheers ./daniel

Re: estimation problems for DISTINCT ON with FDW

Etsuro Fujita writes: > On Wed, Jul 1, 2020 at 11:40 PM Tom Lane wrote: >> Short of sending a whole second query to the remote server, it's >> not clear to me how we could get the full table size (or equivalently >> the target query's selectivity for that table). The best we realistically >>

Re: Libpq support to connect to standby server as priority

> On 18 May 2020, at 09:33, Greg Nancarrow wrote: > I'd like to submit a new version of a patch that I'd previously > submitted but was eventually Returned with Feedback (closed in > commitfest 2020-03). This patch no longer applies, can you please submit a rebased version? I've marked the

Re: [PATCH] Initial progress reporting for COPY command

The automated patchtester for the Commitfest gets confused when there are two versions of the same changeset attached to the email, as it tries to apply them both which obviously results in an application failure. I've attached just the previously submitted patch version to this email to see if

Re: [PATCH] Initial progress reporting for COPY command

> On 2 Jul 2020, at 14:42, Josef Šimánek wrote: > čt 2. 7. 2020 v 14:25 odesílatel Daniel Gustafsson > napsal: > The automated patchtester for the Commitfest gets confused when there are two > versions of the same changeset attached to the email, as it tries to apply >

Re: [PATCH] Finally split StdRdOptions into HeapOptions and ToastOptions

> On 28 Mar 2020, at 19:57, Nikolay Shaplov wrote: > > A new version of the patch. > Autovacuum options were extended in b07642db > > So I added that options to the current patch. The heapam.c hunk in this version fails to apply to HEAD, can you please submit a rebased version? Marking the CF

Re: Built-in connection pooler

On 01.07.2020 12:30, Daniel Gustafsson wrote: On 24 Mar 2020, at 17:24, Konstantin Knizhnik wrote: Rebased version of the patch is attached. And this patch also fails to apply now, can you please submit a new version? Marking the entry as Waiting on Author in the meantime. cheers ./daniel

Re: Read access for pg_monitor to pg_replication_origin_status view

> On 14 Jun 2020, at 05:46, Michael Paquier wrote: > > On Wed, Jun 10, 2020 at 12:35:49PM +0900, Michael Paquier wrote: >> On Tue, Jun 09, 2020 at 05:07:39PM +0900, Masahiko Sawada wrote: >>> I agreed with the change you proposed. >> >> OK, thanks. Then let's wait a couple of days to see if

Re: TRUNCATE on foreign tables

> On 1 Mar 2020, at 03:24, Kohei KaiGai wrote: > The attached is revised version. This version fails to apply to HEAD due to conflicts in postgres_fdw expected test output. Can you please submit a rebased version. Marking the entry Waiting on Author in the meantime. cheers ./daniel

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

It seems like the consensus over at another discussion on this topic [1] is that we ought to go ahead and print the zeros [for machine readable output formats], even though that creates some interesting scenarios like the fact that disk sorts will print 0 for memory even though that's not true.

why do we allow people to create a publication before setting wal_leve

This seems pretty strange: create publication pub1 for all tables; WARNING: wal_level is insufficient to publish logical changes HINT: Set wal_level to logical before creating subscriptions. Dave Cramer

Re: Persist MVCC forever - retain history

On Fri, Jul 3, 2020 at 6:56 AM Mitar wrote: > I was thinking and reading about how to design the schema to keep > records of all changes which happen to the table, at row granularity, > when I realized that all this is already done for me by PostgreSQL > MVCC. All rows (tuples) are already

Sync vs Flush

Hi, For an extended query that needs to get parameter types before sending them, is there a difference in doing: Parse, Describe statement, Flush, Bind, Execute, Sync vs Parse, Describe statement, Sync, Bind, Execute, Sync Of course, there will be an additional ReadyForQuery in the latter case,

Re: [PATCH] fix GIN index search sometimes losing results

Hello, On Thu, Jul 2, 2020 at 8:23 PM Pavel Borisov wrote: > > ср, 1 июл. 2020 г. в 23:16, Tom Lane : >> >> Pavel Borisov writes: >> > Below is my variant how to patch Gin-Gist weights issue: >> >> I looked at this patch, but I'm unimpressed, because it's buggy. > > > Thank you, i'd noticed and

Re: Built-in connection pooler

On 02.07.2020 17:44, Daniel Gustafsson wrote: On 2 Jul 2020, at 13:33, Konstantin Knizhnik wrote: On 01.07.2020 12:30, Daniel Gustafsson wrote: On 24 Mar 2020, at 17:24, Konstantin Knizhnik wrote: Rebased version of the patch is attached. And this patch also fails to apply now, can you

Re: Using Valgrind to detect faulty buffer accesses (no pin or buffer content lock held)

On Thu, Jul 2, 2020 at 7:48 AM Daniel Gustafsson wrote: > This patch fails to apply to HEAD due to conflicts in nbtpage.c, can you > please > submit a rebased version? I attach the rebased patch series. Thanks -- Peter Geoghegan v3-0002-Add-nbtree-Valgrind-buffer-lock-checks.patch

Re: Use of "long" in incremental sort code

On Mon, Jun 29, 2020 at 9:13 PM David Rowley wrote: > I noticed the incremental sort code makes use of the long datatype a > few times, e.g in TuplesortInstrumentation and > IncrementalSortGroupInfo. I agree that long is terrible, and should generally be avoided. > Maybe Size would be better

Re: pg_read_file() with virtual files returns empty string

On 7/1/20 6:22 PM, Tom Lane wrote: > Joe Conway writes: >> The only downside is that the max filesize is reduced to (MaxAllocSize - >> MIN_READ_SIZE - 1) compared to MaxAllocSize with the old method. > > Hm, I was expecting that the last successful iteration of > enlargeStringInfo would increase

Re: Use of "long" in incremental sort code

On Thu, Jul 2, 2020 at 10:53 AM James Coleman wrote: > Do you think it's reasonable to use int64 across the board for memory > and disk space numbers then? If so, I can update the patch. Using int64 as a replacement for long is the safest general strategy, and so ISTM that it might be worth

Persist MVCC forever - retain history

Hi! (Sorry if this was already discussed, it looks pretty obvious, but I could not find anything.) I was thinking and reading about how to design the schema to keep records of all changes which happen to the table, at row granularity, when I realized that all this is already done for me by

Re: proposal: unescape_text function

> On 23 Jun 2020, at 11:51, Pavel Stehule wrote: > I changed the name to more accurately "unicode_unescape". Patch is assigned You've made this function return Oid, where it used to be void. Was that a copy-paste mistake? Else the code needs fixing as it doesn't return an Oid. +Oid

Re: Use of "long" in incremental sort code

On Tue, Jun 30, 2020 at 7:21 AM Peter Eisentraut wrote: > > On 2020-06-30 06:24, David Rowley wrote: > > On Tue, 30 Jun 2020 at 16:20, Tom Lane wrote: > >> There is a fairly widespread issue that memory-size-related GUCs and > >> suchlike variables are limited to represent sizes that fit in a

Re: [PATCH] fix GIN index search sometimes losing results

чт, 2 июл. 2020 г. в 19:38, Artur Zakirov : > Hello, > > On Thu, Jul 2, 2020 at 8:23 PM Pavel Borisov > wrote: > > > > ср, 1 июл. 2020 г. в 23:16, Tom Lane : > >> > >> Pavel Borisov writes: > >> > Below is my variant how to patch Gin-Gist weights issue: > >> > >> I looked at this patch, but I'm

Re: cannot restore schema with is not distinct from on hstore since PG 9.6.8

[ just to tie back to this old thread ] I wrote: > I poked into this area for awhile, and it turns out to be even a > worse can of worms than I thought. I looked through gram.y and > parse_expr.c, and identified several distinct classes of issue. > (I'm not promising that I found everything.)

Re: Use of "long" in incremental sort code

On Thu, Jul 2, 2020 at 1:36 PM Peter Geoghegan wrote: > > On Mon, Jun 29, 2020 at 9:13 PM David Rowley wrote: > > I noticed the incremental sort code makes use of the long datatype a > > few times, e.g in TuplesortInstrumentation and > > IncrementalSortGroupInfo. > > I agree that long is

Re: [PATCH] fix GIN index search sometimes losing results

Pavel Borisov writes: > чт, 2 июл. 2020 г. в 19:38, Artur Zakirov : >> So it seems we are losing some results with RUM as well. > For me it is 100% predictable that unmodified RUM is still losing results > as it is still using binary callback. Right, that's in line with what I expected as well.

Re: proposal: unescape_text function

čt 2. 7. 2020 v 17:27 odesílatel Daniel Gustafsson napsal: > > On 23 Jun 2020, at 11:51, Pavel Stehule wrote: > > > I changed the name to more accurately "unicode_unescape". Patch is > assigned > > You've made this function return Oid, where it used to be void. Was that a > copy-paste mistake?

Re: Sync vs Flush

Hehe, that's exactly what I am doing, which is why I thought of just sending two Syncs. Good to hear it's OK. >From reading the Extended query protocol docs, I somehow got the impression that you need to do everything within one cycle, and send Sync only at the end of the cycle: - "The extended

Re: Persist MVCC forever - retain history

On Thursday, July 2, 2020, Mitar wrote: > make queries asking for > results at the particular historical version of table state? Even for a single table how would you go about specifying this in a user-friendly way? Then consider joins. > Is this something I would have to run a custom

Re: [patch] demote

Hi, Here is a small activity summary since last report. On Thu, 25 Jun 2020 19:27:54 +0200 Jehan-Guillaume de Rorthais wrote: [...] > I hadn't time to investigate Robert's concern about shared memory for snapshot > during recovery. I hadn't time to dig very far, but I suppose this might be

Re: pg_read_file() with virtual files returns empty string

Joe Conway writes: > On 7/1/20 6:22 PM, Tom Lane wrote: >> Hm, I was expecting that the last successful iteration of >> enlargeStringInfo would increase the buffer size to MaxAllocSize, >> so that we'd really only be losing one byte (which we can't avoid >> if we use stringinfo). But you're

Re: pg_read_file() with virtual files returns empty string

On 7/2/20 3:36 PM, Tom Lane wrote: > Joe Conway writes: >> On 7/1/20 6:22 PM, Tom Lane wrote: >>> Hm, I was expecting that the last successful iteration of >>> enlargeStringInfo would increase the buffer size to MaxAllocSize, >>> so that we'd really only be losing one byte (which we can't avoid

Re: pg_read_file() with virtual files returns empty string

Joe Conway writes: > When I saw originally MaxAllocSize - 5 fail I skipped to something smaller by > 4096 and it worked. But here I see that the actual max size is MaxAllocSize - > 6. Huh, I wonder why it's not max - 5. Probably not worth worrying about, though.

Re: pg_read_file() with virtual files returns empty string

On 7/2/20 4:27 PM, Tom Lane wrote: > Joe Conway writes: >> When I saw originally MaxAllocSize - 5 fail I skipped to something smaller by >> 4096 and it worked. But here I see that the actual max size is MaxAllocSize >> - 6. > > Huh, I wonder why it's not max - 5. Probably not worth worrying

Re: Sync vs Flush

=?UTF-8?B?SmFrYSBKYW7EjWFy?= writes: > What is a common situation for using Flush instead of Sync? > When would you need and wait for the output, get an error, yet still > proceed to send further messages that you would want the server to ignore? The only case I can think of offhand is bursting

Re: pg_read_file() with virtual files returns empty string

Joe Conway writes: > On 7/2/20 4:27 PM, Tom Lane wrote: >> Huh, I wonder why it's not max - 5. Probably not worth worrying about, >> though. > Well this part: > + rbytes = fread(sbuf.data + sbuf.len, 1, > +(size_t) (sbuf.maxlen - sbuf.len - 1), file); > could actually be: > +

Re: Enabling B-Tree deduplication by default

On Thu, Jun 25, 2020 at 4:28 PM Peter Geoghegan wrote: > It's now time to make a final decision on this. Does anyone have any > reason to believe that leaving deduplication enabled by default is the > wrong way to go? I marked the open item resolved just now -- B-Tree deduplication will remain

Re: pg_read_file() with virtual files returns empty string

On 7/2/20 5:37 PM, Tom Lane wrote: > Joe Conway writes: >> In fact, in principle there is no reason we can't get to max - 4 with this >> code >> except that when the filesize is exactly 1073741819, we need to try to read >> one >> more byte to find the EOF that way I did in my patch. I.e.: > >

Re: Use of "long" in incremental sort code

Peter Geoghegan writes: > On Thu, Jul 2, 2020 at 10:53 AM James Coleman wrote: >> Do you think it's reasonable to use int64 across the board for memory >> and disk space numbers then? If so, I can update the patch. > Using int64 as a replacement for long is the safest general strategy, mumble

Re: Use of "long" in incremental sort code

On Thu, Jul 2, 2020 at 12:47 PM James Coleman wrote: > But wouldn't that mean we'd get int on 32-bit systems, and since we're > accumulating data we could go over that value in both memory and disk? > > My assumption is that it's preferable to have the "this run value" and > the "total used

Re: Use of "long" in incremental sort code

James Coleman writes: > On Thu, Jul 2, 2020 at 3:39 PM Tom Lane wrote: >> mumble ssize_t mumble > But wouldn't that mean we'd get int on 32-bit systems, and since we're > accumulating data we could go over that value in both memory and disk? Certainly, a number that's meant to represent the

Re: Sync vs Flush

Makes sense, thanks! On Thu, Jul 2, 2020 at 15:29 Tom Lane wrote: > =?UTF-8?B?SmFrYSBKYW7EjWFy?= writes: > > What is a common situation for using Flush instead of Sync? > > When would you need and wait for the output, get an error, yet still > > proceed to send further messages that you would

Re: Use of "long" in incremental sort code

On Thu, Jul 2, 2020 at 3:39 PM Tom Lane wrote: > > Peter Geoghegan writes: > > On Thu, Jul 2, 2020 at 10:53 AM James Coleman wrote: > >> Do you think it's reasonable to use int64 across the board for memory > >> and disk space numbers then? If so, I can update the patch. > > > Using int64 as a

Re: Enabling B-Tree deduplication by default

On Thu, Jul 2, 2020 at 02:59:47PM -0700, Peter Geoghegan wrote: > On Thu, Jun 25, 2020 at 4:28 PM Peter Geoghegan wrote: > > It's now time to make a final decision on this. Does anyone have any > > reason to believe that leaving deduplication enabled by default is the > > wrong way to go? > > I

Re: Use of "long" in incremental sort code

Peter Geoghegan writes: > On Thu, Jul 2, 2020 at 12:39 PM Tom Lane wrote: >> mumble ssize_t mumble > That's from POSIX, though. I imagine MSVC won't be happy (surprise!). We've got quite a few uses of it already, so apparently it's fine. regards, tom lane

Re: Use of "long" in incremental sort code

On Thu, Jul 2, 2020 at 12:39 PM Tom Lane wrote: > mumble ssize_t mumble That's from POSIX, though. I imagine MSVC won't be happy (surprise!). -- Peter Geoghegan

Re: Use of "long" in incremental sort code

On Thu, Jul 2, 2020 at 12:44 PM Tom Lane wrote: > > That's from POSIX, though. I imagine MSVC won't be happy (surprise!). > > We've got quite a few uses of it already, so apparently it's fine. Oh, looks like we have a compatibility hack for MSVC within win32_port.h, where ssize_t is typedef'd to

Re: estimation problems for DISTINCT ON with FDW

Concretely, I now propose the attached, which seems entirely safe to back-patch. regards, tom lane diff --git a/doc/src/sgml/fdwhandler.sgml b/doc/src/sgml/fdwhandler.sgml index 6587678af2..1e997c218b 100644 --- a/doc/src/sgml/fdwhandler.sgml +++

Re: Warn when parallel restoring a custom dump without data offsets

David Gilman writes: > I've attached the latest patches after further review from Justin Pryzby. I guess I'm completely confused about the purpose of these patches. Far from coping with the situation of an unseekable file, they appear to change pg_restore so that it fails altogether if it can't

Re: pg_read_file() with virtual files returns empty string

Joe Conway writes: > On 7/2/20 5:37 PM, Tom Lane wrote: >> I still can't get excited about contorting the code to remove that >> issue. > It doesn't seem much worse than the oom test that was there before -- see > attached. Personally I would not bother, but it's your patch. > Are we in

Re: Add Information during standby recovery conflicts

On Wed, 1 Jul 2020 at 21:52, Drouvot, Bertrand wrote: > > Hey, > > On 6/29/20 10:55 AM, Masahiko Sawada wrote: > > CAUTION: This email originated from outside of the organization. Do not > > click links or open attachments unless you can confirm the sender and know > > the content is safe. > >

Re: Persist MVCC forever - retain history

> On Jul 2, 2020, at 5:58 PM, Mitar wrote: > >> Plus, wrap-around and freezing aren’t just nice-to-have features. > > Oh, I forgot about that. ctid is still just 32 bits? So then for such > table with permanent MVCC this would have to be increased, to like 64 > bits or something. Then one

Re: Default setting for enable_hashagg_disk

On Mon, Jun 29, 2020 at 2:46 PM Peter Geoghegan wrote: > On Mon, Jun 29, 2020 at 2:22 PM Tomas Vondra > wrote: > > I agree with this, and I'm mostly OK with having hash_mem. In fact, from > > the proposals in this thread I like it the most - as long as it's used > > both during planning and

Re: track_planning causing performance regression

On 2020/07/01 7:37, Peter Geoghegan wrote: On Tue, Jun 30, 2020 at 6:40 AM Fujii Masao wrote: Ants and Andres suggested to replace the spinlock used in pgss_store() with LWLock. I agreed with them and posted the POC patch doing that. But I think the patch is an item for v14. The patch may

Re: Creating a function for exposing memory usage of backend process

On Wed, Jul 1, 2020 at 10:15 PM torikoshia wrote: I'm going to do some renaming and transportations. - view name: pg_memory_contexts - function name: pg_get_memory_contexts() - source file: mainly src/backend/utils/mmgr/mcxt.c Attached an updated patch. On Wed, Jul 1, 2020 at 10:58 PM Fujii

Re: Persist MVCC forever - retain history

Hi! On Thu, Jul 2, 2020 at 12:12 PM David G. Johnston wrote: > Even for a single table how would you go about specifying this in a > user-friendly way? Then consider joins. One general answer: you use query rewriting. But what is user-friendly depends on the use case. For me, the main

Re: POC and rebased patch for CSN based snapshots

On 7/2/20 7:31 PM, Movead Li wrote: Thanks for the remarks, >Some remarks on your patch: >1. The variable last_max_csn can be an atomic variable. Yes will consider. >2. GenerateCSN() routine: in the case than csn < csnState->last_max_csn >This is the case when someone changed the value of

Re: Persist MVCC forever - retain history

Hi! On Thu, Jul 2, 2020 at 12:16 PM Thomas Munro wrote: > This was a research topic in ancient times (somewhere I read that in > some ancient version, VACUUM didn't originally remove tuples, it moved > them to permanent write-only storage). Even after the open source > project began, there was

Re: Default setting for enable_hashagg_disk (hash_mem)

On Thu, Jul 2, 2020 at 8:00 PM Bruce Momjian wrote: > Also, I feel this is all out of scope for PG 13, frankly. I think our > only option is to revert the hash spill entirely, and return to PG 13 > behavior, if people are too worried about hash performance regression. But the problem isn't

Re: Read access for pg_monitor to pg_replication_origin_status view

On Thu, Jul 02, 2020 at 03:03:22PM +0200, Daniel Gustafsson wrote: > AFAICT from the thread there is nothing left of this changeset to consider, so > I've marked the entry as committed in the CF app. Feel free to update in case > I've missed something. A second item discussed in this thread was

Re: [POC] Fast COPY FROM command for the table with foreign partitions

On 6/22/20 5:11 PM, Ashutosh Bapat wrote: mailto:a.lepik...@postgrespro.ru>> wrote: It looks like we call BeginForeignInsert and EndForeignInsert even though actual copy is performed using BeginForeignCopy, ExecForeignCopy and EndForeignCopy. BeginForeignInsert constructs the INSERT query

Re: track_planning causing performance regression

On 2020/07/02 1:54, Andres Freund wrote: Hi, On 2020-07-01 22:20:50 +0900, Fujii Masao wrote: On 2020/07/01 4:03, Andres Freund wrote: Why did you add the hashing here? It seems a lot better to just add an lwlock in-place instead of the spinlock? The added size is neglegible compared to

Re: Default setting for enable_hashagg_disk (hash_mem)

On Thu, Jul 02, 2020 at 07:05:48PM -0700, Peter Geoghegan wrote: > On Mon, Jun 29, 2020 at 2:46 PM Peter Geoghegan wrote: > > On Mon, Jun 29, 2020 at 2:22 PM Tomas Vondra > > wrote: > > > I agree with this, and I'm mostly OK with having hash_mem. In fact, from > > > the proposals in this thread

Re: track_planning causing performance regression

On 2020/07/03 11:43, Peter Geoghegan wrote: On Thu, Jul 2, 2020 at 7:39 PM Fujii Masao wrote: So I pushed the patch and changed default of track_planning to off. I have closed out the open item I created for this. Thanks!! I added the patch that replaces spinlock with lwlock in pgss,

Re: Persist MVCC forever - retain history

Hi! On Thu, Jul 2, 2020 at 7:51 PM Mark Dilger wrote: > I expect these issues to be less than half what you would need to resolve, > though much of the rest of it is less clear to me. Thank you for this insightful input. I will think it over. Mitar -- http://mitar.tnode.com/

Re: Default setting for enable_hashagg_disk (hash_mem)

On Thu, Jul 2, 2020 at 7:46 PM Justin Pryzby wrote: > Thanks for putting it together, I agree that hash_mem seems to be an obvious > "escape hatch" that generalizes existing GUCs and independently useful. It is independently useful. It's a natural consequence of "being honest" about work_mem and

Re: Sync vs Flush

=?UTF-8?B?SmFrYSBKYW7EjWFy?= writes: > For an extended query that needs to get parameter types before sending > them, is there a difference in doing: > Parse, Describe statement, Flush, Bind, Execute, Sync > vs > Parse, Describe statement, Sync, Bind, Execute, Sync Sync is a resync point after

Re: Binary support for pgoutput plugin

rebased Thanks, Dave Cramer On Wed, 1 Jul 2020 at 06:43, Dave Cramer wrote: > Honestly I'm getting a little weary of fixing this up only to have the > patch not get reviewed. > > Apparently it has no value so unless someone is willing to review it and > get it committed I'm just going to let

Re: why do we allow people to create a publication before setting wal_leve

On Thu, Jul 02, 2020 at 12:37:29PM -0400, Dave Cramer wrote: This seems pretty strange: create publication pub1 for all tables; WARNING: wal_level is insufficient to publish logical changes HINT: Set wal_level to logical before creating subscriptions. pg_dump restoring a database with

Re: Additional improvements to extended statistics

On Wed, Jul 01, 2020 at 01:19:40PM +0200, Daniel Gustafsson wrote: On 24 Mar 2020, at 15:33, Tomas Vondra wrote: On Tue, Mar 24, 2020 at 01:20:07PM +, Dean Rasheed wrote: Sounds like a reasonable approach, but I think it would be better to preserve the current public API by having

Re: Persist MVCC forever - retain history

On Thu, Jul 2, 2020 at 2:56 PM Mitar wrote: > Hi! > > (Sorry if this was already discussed, it looks pretty obvious, but I > could not find anything.) There have been a couple timetravel extensions done, each with their own limitations. I don’t believe a perfect implementation could be done

Re: track_planning causing performance regression

On Thu, Jul 2, 2020 at 7:39 PM Fujii Masao wrote: > So I pushed the patch and changed default of track_planning to off. I have closed out the open item I created for this. Thanks! -- Peter Geoghegan

Re: estimation problems for DISTINCT ON with FDW

On Thu, Jul 2, 2020 at 11:46 PM Tom Lane wrote: > Etsuro Fujita writes: > > On Wed, Jul 1, 2020 at 11:40 PM Tom Lane wrote: > >> Short of sending a whole second query to the remote server, it's > >> not clear to me how we could get the full table size (or equivalently > >> the target query's

Re: Default setting for enable_hashagg_disk (hash_mem)

On Thu, Jul 2, 2020 at 10:58:34PM -0400, Bruce Momjian wrote: > On Thu, Jul 2, 2020 at 09:46:49PM -0500, Justin Pryzby wrote: > > On Thu, Jul 02, 2020 at 07:05:48PM -0700, Peter Geoghegan wrote: > > > anything else). I still think that the new GUC should work as a > > > multiplier of work_mem,

Re: Default setting for enable_hashagg_disk (hash_mem)

On Thu, Jul 2, 2020 at 09:46:49PM -0500, Justin Pryzby wrote: > On Thu, Jul 02, 2020 at 07:05:48PM -0700, Peter Geoghegan wrote: > > anything else). I still think that the new GUC should work as a > > multiplier of work_mem, or something else along those lines, though > > for now it's just an

Re: track_planning causing performance regression

Hi pá 3. 7. 2020 v 4:39 odesílatel Fujii Masao napsal: > > > On 2020/07/01 7:37, Peter Geoghegan wrote: > > On Tue, Jun 30, 2020 at 6:40 AM Fujii Masao > wrote: > >> Ants and Andres suggested to replace the spinlock used in pgss_store() > with > >> LWLock. I agreed with them and posted the POC

  1   2   >