Re: Physical replication slot advance is not persistent

On Tue, Jun 09, 2020 at 09:01:13PM +0300, Alexey Kondratov wrote: > Yes, there was a ReplicationSlotsComputeRequiredLSN() call inside > pg_physical_replication_slot_advance() in the v5 of the patch: > > But later it has been missed and we have not noticed that. > > I think that adding it back as pe

RE: BUG #16481: Stored Procedure Triggered by Logical Replication is Unable to use Notification Events

I think you did follow all the thread. I only ask if it is a bug or not. If it as bug and last for years I understand your point our view but I have my. If you think that signal a bug is not give a contribution I am astonished. Improve PosgreSQL is the target Best Regard. Fabio Vianel

Re: Fixed the remaining old function names.

Thanks for comments. > There is a separate process for updating .po files; see > babel.postgresql.org. I'll check it. regards, 2020年6月10日(水) 9:00 U ikki : > > Thanks for comments. > > > There is a separate process for updating .po files; see > > babel.postgresql.org. > > I'll check it. > > rega

Re: [PATCH] Add support for choosing huge page size

On Wed, Jun 10, 2020 at 5:11 PM Thomas Munro wrote: > 3. Last time I checked, Solaris and illumos seemed to have the same > philosophy as FreeBSD and not give you explicit control; my info could > be out of date, and I have no clue beyond that. Ah, I was wrong about that one: memcntl(2) looks hi

Re: Parallel Seq Scan vs kernel read ahead

On Wed, 10 Jun 2020 at 17:21, Thomas Munro wrote: > I also heard from Andres that he likes this patch with his AIO > prototype, because of the way request merging works. So it seems like > there are several reasons to want it. > > But ... where should we get the maximum step size from? A GUC? I

Re: Parallel Seq Scan vs kernel read ahead

On Wed, Jun 10, 2020 at 5:06 PM David Rowley wrote: > I repeated this test on an up-to-date Windows 10 machine to see if the > later kernel is any better at the readahead. > > Results for the same test are: > > Master: > > max_parallel_workers_per_gather = 0: Time: 148481.244 ms (02:28.481) > (706

Re: Terminate the idle sessions

On Jun 9, 2020, at 10:35 PM, David G. Johnston mailto:david.g.johns...@gmail.com>> wrote: I’m curious as to the use case because I cannot imagine using this. Idle connections are normal. Seems better to monitor them and conditionally execute the disconnect backend function from the monitori

Re: [PATCH] Add support for choosing huge page size

On Wed, Jun 10, 2020 at 2:24 AM Odin Ugedal wrote: > Attached v2 of patch, updated with the comments from Thomas (again, > thanks). I also changed the mmap flags to only set size if the > selected huge page size is not the default on (on linux). The support > for this functionality was added in Li

Re: Parallel Seq Scan vs kernel read ahead

On Thu, 21 May 2020 at 17:06, David Rowley wrote: > create table t (a int, b text); > -- create a table of 100GB in size. > insert into t select x,md5(x::text) from > generate_series(1,100*1572.7381809)x; -- took 1 hr 18 mins > vacuum freeze t; > > query = select count(*) from t; > Disk = Sams

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

On Mon, Jun 08, 2020 at 02:16:32PM +0300, Alexey Kondratov wrote: > Do not like it either. Having the same naming and a guarantee that this code > is always compiled separately looks more convenient for me. > > [1] > https://www.postgresql.org/message-id/784fa7dc-414b-9dc9-daae-138033db298c%40pos

Re: [PATCH] Leading minus for negative time interval in ISO 8601

On Wed, Jun 3, 2020 at 11:25 PM, Tom Lane wrote: > ... > Maybe we should just take the position that negative intervals aren't > standardized, and if you want to transport them using ISO format then > you first need to lobby ISO to fix that. Apparently ISO did "fix" this. I managed to get a copy

Re: proposal: possibility to read dumped table's name from file

On Wed, Jun 10, 2020 at 05:03:49AM +0200, Pavel Stehule wrote: > st 10. 6. 2020 v 0:30 odesílatel Justin Pryzby napsal: > > > On Tue, Jun 09, 2020 at 11:46:24AM +0200, Pavel Stehule wrote: > > > po 8. 6. 2020 v 23:30 odesílatel Justin Pryzby > > > napsal: > > > > > I still wonder if a better sy

Re: Resetting spilled txn statistics in pg_stat_replication

On Tue, Jun 9, 2020 at 1:54 PM Magnus Hagander wrote: > > On Tue, Jun 9, 2020 at 9:12 AM Masahiko Sawada > wrote: >> >> On Tue, 2 Jun 2020 at 18:34, Amit Kapila wrote: >> > >> > I see your point but I don't see a pressing need for such a function >> > for PG13. Basically, these counters will b

Re: FailedAssertion at ReorderBufferCheckMemoryLimit()

On 2020/06/10 12:00, Amit Kapila wrote: On Tue, Jun 9, 2020 at 2:28 PM Amit Kapila wrote: On Tue, Jun 9, 2020 at 1:56 PM Fujii Masao wrote: I wonder if we may need to keep evicting the transactions until we don't exceed memory limit. Yes, that should be the right fix here. Can y

Re: Read access for pg_monitor to pg_replication_origin_status view

On Tue, Jun 09, 2020 at 05:07:39PM +0900, Masahiko Sawada wrote: > Oh, I see. There might be room for improvement but it's a separate issue. > > I agreed with the change you proposed. OK, thanks. Then let's wait a couple of days to see if anybody has any objections with the removal of the hardco

Re: Global snapshots

On 09.06.2020 11:41, Fujii Masao wrote: On 2020/05/12 19:24, Andrey Lepikhov wrote: Rebased onto current master (fb544735f1). Thanks for the patches! These patches are no longer applied cleanly and caused the compilation failure. So could you rebase and update them? Rebased onto 57cb806

Re: Asynchronous Append on postgres_fdw nodes.

Hello, Andrey. At Tue, 9 Jun 2020 14:20:42 +0500, Andrey Lepikhov wrote in > On 6/4/20 11:00 AM, Kyotaro Horiguchi wrote: > > Removed a useless variable PgFdwScanState.result_ready. > > Removed duplicate code from remove_async_node() by using > > move_to_next_waiter(). > > Done some minor clean

Re: proposal: possibility to read dumped table's name from file

st 10. 6. 2020 v 0:30 odesílatel Justin Pryzby napsal: > On Tue, Jun 09, 2020 at 11:46:24AM +0200, Pavel Stehule wrote: > > po 8. 6. 2020 v 23:30 odesílatel Justin Pryzby > napsal: > > > I still wonder if a better syntax would use a unified --filter option, > whose > > > argument would allow inc

Re: FailedAssertion at ReorderBufferCheckMemoryLimit()

On Tue, Jun 9, 2020 at 2:28 PM Amit Kapila wrote: > > On Tue, Jun 9, 2020 at 1:56 PM Fujii Masao > wrote: > > > > > I wonder if we may > > need to keep evicting the transactions until we don't exceed > > memory limit. > > > > Yes, that should be the right fix here. > Can you please check whethe

Re: Default setting for enable_hashagg_disk

On Tue, Jun 09, 2020 at 06:20:13PM -0700, Melanie Plageman wrote: > On Thu, Apr 9, 2020 at 1:02 PM Jeff Davis wrote: > > > 2. enable_groupingsets_hash_disk (default false): > > > > This is about how we choose which grouping sets to hash and which to > > sort when generating mixed mode paths. > >

Re: Is it useful to record whether plans are generic or custom?

On 2020-06-08 20:45, Masahiro Ikeda wrote: BTW, I found that the dependency between function's comments and the modified code is broken at latest patch. Before this is committed, please fix it. ``` diff --git a/src/backend/commands/prepare.c b/src/backend/commands/prepare.c index 990782e77f..

Re: Default setting for enable_hashagg_disk

On Thu, Apr 9, 2020 at 1:02 PM Jeff Davis wrote: > 2. enable_groupingsets_hash_disk (default false): > > This is about how we choose which grouping sets to hash and which to > sort when generating mixed mode paths. > > Even before this patch, there are quite a few paths that could be > generated.

Re: elog(DEBUG2 in SpinLocked section.

Hi, On 2020-06-09 15:20:08 -0400, Robert Haas wrote: > If you're worried about space, an LWLock is only 16 bytes, and the > slock_t that we'd be replacing is currently at the end of the struct > so presumably followed by some padding. I don't think the size is worth of concern in this case, and I

Re: Speedup usages of pg_*toa() functions

On Tue, 9 Jun 2020 at 22:08, Andrew Gierth wrote: > > > "David" == David Rowley writes: > > David> This allows us to speed up a few cases. int2vectorout() should > David> be faster and int8out() becomes a bit faster if we get rid of > David> the strdup() call and replace it with a palloc()

Re: elog(DEBUG2 in SpinLocked section.

Hi, On 2020-06-09 19:24:15 -0400, Tom Lane wrote: > Robert Haas writes: > > On Tue, Jun 9, 2020 at 1:59 PM Tom Lane wrote: > >> When I went through the existing spinlock stanzas, the only thing that > >> really made me acutely uncomfortable was the chunk in pg_stat_statement's > >> pgss_store(),

Re: elog(DEBUG2 in SpinLocked section.

Robert Haas writes: > On Tue, Jun 9, 2020 at 1:59 PM Tom Lane wrote: >> When I went through the existing spinlock stanzas, the only thing that >> really made me acutely uncomfortable was the chunk in pg_stat_statement's >> pgss_store(), lines 1386..1438 in HEAD. > I mean, what would be wrong wit

Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)

Hi, On 2020-06-09 17:04:42 -0400, Robert Haas wrote: > On Tue, Jun 9, 2020 at 3:37 PM Andres Freund wrote: > > Hm. Looking at this again, perhaps the better fix would be to simply not > > look at the concrete values of the barrier inside the signal handler? > > E.g. we could have a new PROCSIG_GL

Re: Auto-vectorization speeds up multiplication of large-precision numerics

On 2020-06-09 13:50, Amit Khandekar wrote: Also, the regress/sql/numeric_big test itself speeds up by 80% That's nice. I can confirm the speedup: -O3 without the patch: numeric ... ok 737 ms test numeric_big ... ok 1014 ms -O3 with

Re: proposal: possibility to read dumped table's name from file

On Tue, Jun 09, 2020 at 11:46:24AM +0200, Pavel Stehule wrote: > po 8. 6. 2020 v 23:30 odesílatel Justin Pryzby napsal: > I still wonder if a better syntax would use a unified --filter option, whose > > argument would allow including/excluding any type of object: > I tried to implement simple for

Re: Fixed the remaining old function names.

On 2020-06-09 17:53, U ikki wrote: Here is a small patch to fix function names. Some pg_xlog_replay_resume() was still left in po file. Fixed these into pg_wal_replay_resume(). There is a separate process for updating .po files; see babel.postgresql.org. -- Peter Eisentraut htt

Re: Fast DSM segments

On Sat, Apr 11, 2020 at 1:55 AM Robert Haas wrote: > On Thu, Apr 9, 2020 at 1:46 AM Thomas Munro wrote: > > The attached highly experimental patch adds a new GUC > > dynamic_shared_memory_main_size. If you set it > 0, it creates a > > fixed sized shared memory region that supplies memory for "fa

Re: Speedup usages of pg_*toa() functions

Em ter., 9 de jun. de 2020 às 17:42, Andrew Gierth < and...@tao11.riddles.org.uk> escreveu: > > "Ranier" == Ranier Vilela writes: > > Ranier> So I would change, just the initialization (var uvalue), even > though it is > Ranier> irrelevant. > > Ranier> int > Ranier> pg_lltoa(int64 value,

Re: Why is pq_begintypsend so slow?

On Tue, Jun 9, 2020 at 3:23 PM Andres Freund wrote: > ISTM that it'd be pretty broken if it could happen. We cannot have two > different parts of the system send messages to the client > independently. The protocol is pretty stateful... There's a difference between building messages concurrently

Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)

On Tue, Jun 9, 2020 at 3:37 PM Andres Freund wrote: > Hm. Looking at this again, perhaps the better fix would be to simply not > look at the concrete values of the barrier inside the signal handler? > E.g. we could have a new PROCSIG_GLOBAL_BARRIER, which just triggers > ProcSignalBarrierPending t

Re: Speedup usages of pg_*toa() functions

> "Ranier" == Ranier Vilela writes: Ranier> So I would change, just the initialization (var uvalue), even though it is Ranier> irrelevant. Ranier> int Ranier> pg_lltoa(int64 value, char *a) Ranier> { Ranier> int len = 0; Ranier> uint64 uvalue; Ranier> if (value < 0) Ranier> { Ran

Re: Speedup usages of pg_*toa() functions

Em ter., 9 de jun. de 2020 às 15:53, Andrew Gierth < and...@tao11.riddles.org.uk> escreveu: > > "Ranier" == Ranier Vilela writes: > > Ranier> Where " ends up with two copies of pg_ultoa_n inlined into it", > Ranier> in this simplified example? > > The two references to sprintf are both inli

global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)

Hi, On 2020-06-08 23:08:47 -0700, Andres Freund wrote: > On 2020-06-05 17:19:26 -0700, Andres Freund wrote: > > I wrote a patch for this, and when I got around to to testing it, I > > found that our tests currently don't pass when using both > > --disable-spinlocks and --disable-atomics. Turns out

Re: Why is pq_begintypsend so slow?

Hi, On 2020-06-09 11:46:09 -0400, Robert Haas wrote: > On Wed, Jun 3, 2020 at 2:10 PM Andres Freund wrote: > > Why do we need multiple buffers? ISTM we don't want to just send > > messages at endmsg() time, because that implies unnecessary syscall > > overhead. Nor do we want to imply the overhea

Re: elog(DEBUG2 in SpinLocked section.

On Tue, Jun 9, 2020 at 1:59 PM Tom Lane wrote: > Robert Haas writes: > > Removing some of these spinlocks and replacing them with LWLocks might > > also be worth considering. > > When I went through the existing spinlock stanzas, the only thing that > really made me acutely uncomfortable was the

Re: Speedup usages of pg_*toa() functions

> "Ranier" == Ranier Vilela writes: Ranier> Where " ends up with two copies of pg_ultoa_n inlined into it", Ranier> in this simplified example? The two references to sprintf are both inlined copies of your pg_utoa. Ranier> (b) I call this tail cut, I believe it saves time, for sure. You

Re: Speedup usages of pg_*toa() functions

Em ter., 9 de jun. de 2020 às 13:01, Andrew Gierth < and...@tao11.riddles.org.uk> escreveu: > > "Ranier" == Ranier Vilela writes: > > Ranier> Written like that, wouldn't it get better? > > Ranier> int > Ranier> pg_lltoa(int64 value, char *a) > Ranier> { > Ranier> if (value < 0) > Ra

Re: Disallow cancellation of waiting for synchronous replication

On Sat, 2019-12-21 at 11:34 +0100, Marco Slot wrote: > The GUCs are not re-checked in the main loop in SyncRepWaitForLSN, so > backends will remain stuck there even if synchronous replication has > been (temporarily) disabled while they were waiting. If you do: alter system set synchronous_stan

Re: Physical replication slot advance is not persistent

On 2020-06-09 20:19, Andres Freund wrote: Hi, On 2020-01-28 17:01:14 +0900, Michael Paquier wrote: So attached is an updated patch which addresses the problem just by marking a physical slot as dirty if any advancing is done. Some documentation is added about the fact that an advance is persis

Re: elog(DEBUG2 in SpinLocked section.

Robert Haas writes: > Removing some of these spinlocks and replacing them with LWLocks might > also be worth considering. When I went through the existing spinlock stanzas, the only thing that really made me acutely uncomfortable was the chunk in pg_stat_statement's pgss_store(), lines 1386..1438

Re: elog(DEBUG2 in SpinLocked section.

On Wed, Jun 3, 2020 at 12:36 AM Tom Lane wrote: > Should we think about adding automated detection of this type of > mistake? I don't like the attached as-is because of the #include > footprint expansion, but maybe we can find a better way. I think it would be an excellent idea. Removing some o

Re: Bump default wal_level to logical

Hi, On 2020-06-09 08:52:24 +0200, Peter Eisentraut wrote: > On 2020-06-08 23:32, Andres Freund wrote: > > On 2020-06-08 13:27:50 -0400, Tom Lane wrote: > > > If we can allow wal_level to be changed on the fly, I agree that would > > > help reduce the pressure to make the default setting more expen

Re: Physical replication slot advance is not persistent

Hi, On 2020-01-28 17:01:14 +0900, Michael Paquier wrote: > So attached is an updated patch which addresses the problem just by > marking a physical slot as dirty if any advancing is done. Some > documentation is added about the fact that an advance is persistent > only at the follow-up checkpoint

Re: Verifying embedded oids in *recv is a bad idea

So I ran into this as well and I think this should actually be considered a bug, since COPY ... BINARY does not work between nodes now. Which is why I have posted it to the pgsql-bugs list with some reproducible steps to trigger the bug: https://www.postgresql.org/message-id/16485-f7b2dddca52ef2ae

Re: Inlining of couple of functions in pl_exec.c improves performance

po 1. 6. 2020 v 15:59 odesílatel Amit Khandekar napsal: > On Mon, 1 Jun 2020 at 12:27, Pavel Stehule > wrote: > > po 1. 6. 2020 v 8:15 odesílatel Amit Khandekar > napsal: > >> > >> On Sat, 30 May 2020 at 11:11, Pavel Stehule > wrote: > >> > I think so the effect of these patches strongly depen

Fixed the remaining old function names.

Hi, Here is a small patch to fix function names. Some pg_xlog_replay_resume() was still left in po file. Fixed these into pg_wal_replay_resume(). Best regards, -- Kazuki Uehara diff --git a/src/backend/po/id.po b/src/backend/po/id.po index d5d4841..55eb8aa 100644 --- a/src/backend/po/id.po +++

Re: Speedup usages of pg_*toa() functions

> "Ranier" == Ranier Vilela writes: Ranier> Written like that, wouldn't it get better? Ranier> int Ranier> pg_lltoa(int64 value, char *a) Ranier> { Ranier> if (value < 0) Ranier> { Ranier> int len = 0; Ranier> uint64 uvalue = (uint64) 0 - uvalue;

Re: Why is pq_begintypsend so slow?

On Wed, Jun 3, 2020 at 2:10 PM Andres Freund wrote: > Why do we need multiple buffers? ISTM we don't want to just send > messages at endmsg() time, because that implies unnecessary syscall > overhead. Nor do we want to imply the overhead of the copy from the > message buffer to the network buffer.

Re: BUG #16481: Stored Procedure Triggered by Logical Replication is Unable to use Notification Events

On Tue, Jun 9, 2020 at 12:36 AM Vianello Fabio < fabio.viane...@salvagninigroup.com> wrote: > Is PostgreSQL a serious product? For me the answer is "NO". A product with > a bug that last for years and the community knows. > > It is not serious. > If you are trying to be a troll just go away, we d

Re: [PATCH] Add support for choosing huge page size

Hi, Thank you so much for the feedback David and Thomas! Attached v2 of patch, updated with the comments from Thomas (again, thanks). I also changed the mmap flags to only set size if the selected huge page size is not the default on (on linux). The support for this functionality was added in Lin

Re: Terminate the idle sessions

On Tuesday, June 9, 2020, Li Japin wrote: > Hi, hackers > > When some clients connect to database in idle state, postgres do not close > the idle sessions, > here i add a new GUC idle_session_timeout to let postgres close the idle > sessions, it samilar > to idle_in_transaction_session_timeout >

Re: Speedup usages of pg_*toa() functions

Em ter., 9 de jun. de 2020 às 07:55, David Rowley escreveu: > On Tue, 9 Jun 2020 at 22:08, Andrew Gierth > wrote: > > > > > "David" == David Rowley writes: > > > > David> This allows us to speed up a few cases. int2vectorout() should > > David> be faster and int8out() becomes a bit faster

Re: Postgres installer with pgAdmin 4.22

On Tuesday, June 9, 2020, Joel Mariadasan (jomariad) wrote: > > We would like to know when we will get Postgres installer with latest > pgAdmin 4.22 bundled. > > The latest Postgres installer (12.3) has only 4.21 which doesn’t have fix > for certain vulnerabilities related to python. > > Ask the p

Re: text coverage for EXTRACT()

Vik Fearing writes: > On 6/9/20 1:36 PM, Peter Eisentraut wrote: >> During the discussion in [0] I noticed that the extract()/date_part() >> variants for time, timetz, and interval had virtually no test coverage. >> So I put some more tests together, which should be useful if we decide >> to make

pg_dump and concurrent DDL activity

Hi All, prologue of pg_dump.c says * Note that pg_dump runs in a transaction-snapshot mode transaction, * so it sees a consistent snapshot of the database including system * catalogs. However, it relies in part on various specialized backend * functions like pg_get_indexdef(), and those thi

Re: Bump default wal_level to logical

On Tue, Jun 9, 2020 at 6:57 PM Amit Kapila wrote: > > On Tue, Jun 9, 2020 at 3:02 AM Andres Freund wrote: > > > > Hi, > > > > On 2020-06-08 13:27:50 -0400, Tom Lane wrote: > > > If we can allow wal_level to be changed on the fly, I agree that would > > > help reduce the pressure to make the defau

Re: Bump default wal_level to logical

On Tue, Jun 9, 2020 at 3:02 AM Andres Freund wrote: > > Hi, > > On 2020-06-08 13:27:50 -0400, Tom Lane wrote: > > If we can allow wal_level to be changed on the fly, I agree that would > > help reduce the pressure to make the default setting more expensive. > > I don't recall why it's PGC_POSTMAST

Re: Include access method in listTables output

‐‐‐ Original Message ‐‐‐ On Tuesday, June 9, 2020 1:34 PM, David Rowley wrote: > On Tue, 9 Jun 2020 at 23:03, Georgios gkokola...@protonmail.com wrote: > > > A small patch is attached [1] to see if you think it makes sense. I have > > not included any > > differences in the tests outp

Re: Bump default wal_level to logical

On Tue, Jun 9, 2020 at 4:58 PM Magnus Hagander wrote: > > On Tue, Jun 9, 2020 at 1:20 PM Amit Kapila wrote: >> >> On Tue, Jun 9, 2020 at 2:31 PM Magnus Hagander wrote: >> > >> > On Tue, Jun 9, 2020 at 10:53 AM Kyotaro Horiguchi >> > wrote: >> >> >> >> At Tue, 9 Jun 2020 08:52:24 +0200, Peter E

Re: text coverage for EXTRACT()

On 6/9/20 1:36 PM, Peter Eisentraut wrote: > During the discussion in [0] I noticed that the extract()/date_part() > variants for time, timetz, and interval had virtually no test coverage. > So I put some more tests together, which should be useful if we decide > to make any changes in this area pe

Re: [Proposal] Global temporary tables

On Wed, Apr 29, 2020 at 8:52 AM 曾文旌 wrote: > 2020年4月27日 下午9:48，Prabhat Sahu 写道： > > Thanks Wenjing, for the fix patch for previous issues. > I have verified the issues, now those fix look good to me. > But the below error message is confusing(for gtt2). > > postgres=# drop table gtt1; > ERROR:

Postgres installer with pgAdmin 4.22

Hi, We would like to know when we will get Postgres installer with latest pgAdmin 4.22 bundled. The latest Postgres installer (12.3) has only 4.21 which doesn't have fix for certain vulnerabilities related to python. Regards, Joel

Auto-vectorization speeds up multiplication of large-precision numerics

There is this for loop in mul_var() : /* * Add the appropriate multiple of var2 into the accumulator. * * As above, digits of var2 can be ignored if they don't contribute, * so we only include digits for which i1+i2+2 <= res_ndigits - 1. */ for (i2 = Min(var2ndigits - 1, res_ndigits - i1 - 3),

text coverage for EXTRACT()

During the discussion in [0] I noticed that the extract()/date_part() variants for time, timetz, and interval had virtually no test coverage. So I put some more tests together, which should be useful if we decide to make any changes in this area per [0]. [0]: https://www.postgresql.org/messa

Re: Include access method in listTables output

On Tue, 9 Jun 2020 at 23:03, Georgios wrote: > A small patch is attached [1] to see if you think it makes sense. I have not > included any > differences in the tests output yet, as the idea might get discarded. However > if the patch is > found useful. I shall ament the test results as needed.

Re: Bump default wal_level to logical

On Tue, Jun 9, 2020 at 1:20 PM Amit Kapila wrote: > On Tue, Jun 9, 2020 at 2:31 PM Magnus Hagander > wrote: > > > > On Tue, Jun 9, 2020 at 10:53 AM Kyotaro Horiguchi < > horikyota@gmail.com> wrote: > >> > >> At Tue, 9 Jun 2020 08:52:24 +0200, Peter Eisentraut < > peter.eisentr...@2ndquadrant

Re: Add A Glossary

On 17.05.20 17:28, Alvaro Herrera wrote: I think the terms under discussion are just * cluster * instance * server Despite the short period of its existence the glossary achieved some importance, see: https://www.postgresql.org/message-id/b8e12875ebec9e6d3107df5fa1129e1e%40postgrespro.ru .

Re: Bump default wal_level to logical

On Tue, Jun 9, 2020 at 2:31 PM Magnus Hagander wrote: > > On Tue, Jun 9, 2020 at 10:53 AM Kyotaro Horiguchi > wrote: >> >> At Tue, 9 Jun 2020 08:52:24 +0200, Peter Eisentraut >> wrote in >> > On 2020-06-08 23:32, Andres Freund wrote: >> > > On 2020-06-08 13:27:50 -0400, Tom Lane wrote: >> > >>

Include access method in listTables output

Hi, Postgres 12 introduced TableAm api. Although as far as I can see, currently only heap is included as access method, it is fair to imagine that users will start adding their own methods and more methods to be included in Postgres core. With that in mind, it might be desirable for a user to s

Re: Speedup usages of pg_*toa() functions

On Tue, 9 Jun 2020 at 22:08, Andrew Gierth wrote: > > > "David" == David Rowley writes: > > David> This allows us to speed up a few cases. int2vectorout() should > David> be faster and int8out() becomes a bit faster if we get rid of > David> the strdup() call and replace it with a palloc()

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

> On Sun, Jun 07, 2020 at 06:51:22PM +1200, David Rowley wrote: > > > * one in create_distinct_paths as per current implementation > > > > with what seems to be similar content. > > I think we need to have UniqueKeys in RelOptInfo so we can describe > what a relation is unique by. There's no point

Re: TAP tests and symlinks on Windows

Juan José Santamaría Flecha writes: > On Tue, Jun 9, 2020 at 9:28 AM Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: > >> On 2020-06-09 09:19, Michael Paquier wrote: >> > On Mon, Jun 08, 2020 at 02:44:31PM +0200, Peter Eisentraut wrote: >> >> both contain a TAP skip notice "symlinks

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Tue, Jun 9, 2020 at 3:39 PM Amit Kapila wrote: > > On Thu, Jun 4, 2020 at 5:06 PM Mahendra Singh Thalor > wrote: >> >> On Fri, 29 May 2020 at 15:52, Amit Kapila wrote: >> > >> >> >> To see all the operations(DDL's and DML's), please see test_results >> >> Testing summary: >> Basically, we ar

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Thu, Jun 4, 2020 at 5:06 PM Mahendra Singh Thalor wrote: > On Fri, 29 May 2020 at 15:52, Amit Kapila wrote: > > > > To see all the operations(DDL's and DML's), please see test_results > > >

Re: Speedup usages of pg_*toa() functions

> "David" == David Rowley writes: David> This allows us to speed up a few cases. int2vectorout() should David> be faster and int8out() becomes a bit faster if we get rid of David> the strdup() call and replace it with a palloc()/memcpy() call. What about removing the memcpy entirely? I do

Re: proposal: possibility to read dumped table's name from file

po 8. 6. 2020 v 23:30 odesílatel Justin Pryzby napsal: > On Mon, Jun 08, 2020 at 07:18:49PM +0200, Pavel Stehule wrote: > > pá 29. 5. 2020 v 20:25 odesílatel Justin Pryzby > napsal: > > > > > On Fri, May 29, 2020 at 04:21:00PM +0200, Pavel Stehule wrote: > > > > one my customer has to specify du

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Mon, Jun 8, 2020 at 11:53 AM Amit Kapila wrote: > > I think one of the usages we still need is in ReorderBufferForget > because it can be called when we skip processing the txn. See the > comments in DecodeCommit where we call this function. If I am > correct, we need to probably collect all

Re: Asynchronous Append on postgres_fdw nodes.

On 6/4/20 11:00 AM, Kyotaro Horiguchi wrote: Removed a useless variable PgFdwScanState.result_ready. Removed duplicate code from remove_async_node() by using move_to_next_waiter(). Done some minor cleanups. I am reviewing your code. A couple of variables are no longer needed (see changes.patch

Terminate the idle sessions

Hi, hackers When some clients connect to database in idle state, postgres do not close the idle sessions, here i add a new GUC idle_session_timeout to let postgres close the idle sessions, it samilar to idle_in_transaction_session_timeout. Best, regards. Japin Li 0001-Allow-terminating-the-

Re: Bump default wal_level to logical

On Tue, Jun 9, 2020 at 10:53 AM Kyotaro Horiguchi wrote: > At Tue, 9 Jun 2020 08:52:24 +0200, Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote in > > On 2020-06-08 23:32, Andres Freund wrote: > > > On 2020-06-08 13:27:50 -0400, Tom Lane wrote: > > >> If we can allow wal_level to be ch

Re: FailedAssertion at ReorderBufferCheckMemoryLimit()

On Tue, Jun 9, 2020 at 1:56 PM Fujii Masao wrote: > > Hi, > > I encountered the following assertion failure when I changed > logical_decoding_work_mem to lower value while logical replication > is running. This happend in the master branch. > > TRAP: FailedAssertion("rb->size < logical_decoding_wo

Re: Bump default wal_level to logical

At Tue, 9 Jun 2020 08:52:24 +0200, Peter Eisentraut wrote in > On 2020-06-08 23:32, Andres Freund wrote: > > On 2020-06-08 13:27:50 -0400, Tom Lane wrote: > >> If we can allow wal_level to be changed on the fly, I agree that would > >> help reduce the pressure to make the default setting more ex

Re: Read access for pg_monitor to pg_replication_origin_status view

At Tue, 9 Jun 2020 15:11:04 +0900, Michael Paquier wrote in > On Mon, Jun 08, 2020 at 05:44:56PM +0900, Kyotaro Horiguchi wrote: > > Mmm. Right. > > Yep. I bumped on that myself. I am not sure about 0002 and 0004 yet, > and IMO they are not mandatory pieces, but from what I can see in the > s

Re: WIP: Generic functions for Node types using generated metadata

On Fri, 20 Sep 2019 at 17:19, Andres Freund wrote: > 3) WIP: Improve and expand stringinfo.[ch]. > >Expands the set of functions exposed, to allow appending various >numeric types etc. Also improve efficiency by moving code to inline >functions - that's beneficial because the size is o

FailedAssertion at ReorderBufferCheckMemoryLimit()

Hi, I encountered the following assertion failure when I changed logical_decoding_work_mem to lower value while logical replication is running. This happend in the master branch. TRAP: FailedAssertion("rb->size < logical_decoding_work_mem * 1024L", File: "reorderbuffer.c", Line: 2403) 0 postg

Re: Resetting spilled txn statistics in pg_stat_replication

On Tue, Jun 9, 2020 at 9:12 AM Masahiko Sawada < masahiko.saw...@2ndquadrant.com> wrote: > On Tue, 2 Jun 2020 at 18:34, Amit Kapila wrote: > > > > On Tue, Jun 2, 2020 at 11:48 AM Masahiko Sawada > > wrote: > > > > > > Hi all, > > > > > > Tracking of spilled transactions has been introduced to PG

Re: Read access for pg_monitor to pg_replication_origin_status view

At Tue, 9 Jun 2020 16:35:55 +0900, Michael Paquier wrote in > On Tue, Jun 09, 2020 at 03:32:24PM +0900, Masahiko Sawada wrote: > > One thing I'm concerned with this change is that we will end up > > needing to grant both execute on pg_show_replication_origin_status() > > and select on pg_replica

Re: Read access for pg_monitor to pg_replication_origin_status view

On Tue, 9 Jun 2020 at 16:36, Michael Paquier wrote: > > On Tue, Jun 09, 2020 at 03:32:24PM +0900, Masahiko Sawada wrote: > > One thing I'm concerned with this change is that we will end up > > needing to grant both execute on pg_show_replication_origin_status() > > and select on pg_replication_ori

Re: Speedup usages of pg_*toa() functions

On Tue, 9 Jun 2020 at 19:24, Andrew Gierth wrote: > > > "David" == David Rowley writes: > > David> As you can see, this squeezes about 5% extra out of a copy of a > David> 10 million row bigint table but costs us almost 3% on an > David> equivalent int table. > > And once again I have to i

Re: Unify drop-by-OID functions

On 2020-05-05 18:05, Robert Haas wrote: This reminds me: I think that the issues in http://postgr.es/m/ca+tgmoyafyrrdrz94p_qdt+1oong6smovbkghkvsftoncrf...@mail.gmail.com should be considered here - we should guarantee that there's a snapshot registered continuously from before the call to SearchS

Re: Unify drop-by-OID functions

On 2020-05-04 20:57, Peter Eisentraut wrote: New patch attached. I'll park it until PG14 opens. committed -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

RE: BUG #16481: Stored Procedure Triggered by Logical Replication is Unable to use Notification Events

Is PostgreSQL a serious product? For me the answer is "NO". A product with a bug that last for years and the community knows. It is not serious. BR, Fabio. From: Euler Taveira [mailto:euler.tave...@2ndquadrant.com] Sent: lunedì 8 giugno 2020 12:51 To: Kyotaro Horiguchi Cc: Vianello Fabio ; pgs

Re: Read access for pg_monitor to pg_replication_origin_status view

On Tue, Jun 09, 2020 at 03:32:24PM +0900, Masahiko Sawada wrote: > One thing I'm concerned with this change is that we will end up > needing to grant both execute on pg_show_replication_origin_status() > and select on pg_replication_origin_status view when we want a > non-super user to access pg_re

Re: TAP tests and symlinks on Windows

On Tue, Jun 9, 2020 at 9:28 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2020-06-09 09:19, Michael Paquier wrote: > > On Mon, Jun 08, 2020 at 02:44:31PM +0200, Peter Eisentraut wrote: > >> both contain a TAP skip notice "symlinks not supported on Windows". > >> > >> This is

Re: TAP tests and symlinks on Windows

On 2020-06-09 09:19, Michael Paquier wrote: On Mon, Jun 08, 2020 at 02:44:31PM +0200, Peter Eisentraut wrote: both contain a TAP skip notice "symlinks not supported on Windows". This is untrue. Symlinks certainly work on Windows, and we have other TAP tests using them, for example for tablespa

Re: Speedup usages of pg_*toa() functions

> "David" == David Rowley writes: David> As you can see, this squeezes about 5% extra out of a copy of a David> 10 million row bigint table but costs us almost 3% on an David> equivalent int table. And once again I have to issue the reminder: you can have gains or losses of several percen

  1   2   >