Re: [HACKERS] logical decoding of two-phase transactions

Hi. Using a tablesync debugging technique as described in another mail thread [1][2] I have caused the tablesync worker to handle (e.g. apply_dispatch) a 2PC PREPARE This exposes a problem with the current 2PC logic because if/when the PREPARE is processed by the tablesync worker then the txn

Re: Terminate the idle sessions

On Nov 18, 2020, at 2:22 PM, kuroda.hay...@fujitsu.com wrote: Oops.. I forgot putting my suggestion. Sorry. How about substituting sigalrm_delivered to true in the reschedule_timeouts()? Maybe this processing looks strange, so some comments should be put too.

Re: Detecting File Damage & Inconsistencies

On Fri, Nov 13, 2020 at 7:24 PM Simon Riggs wrote: > > What I'm proposing is an option to add 16 bytes onto each COMMIT > record > Would it make sense to write this at the time we write a topxid assignment to WAL instead? Otherwise it won't be accessible to streaming-mode logical decoding.

RE: Terminate the idle sessions

Dear Li, > Yeah, it might be occurred. Any suggestions to fix it? Oops.. I forgot putting my suggestion. Sorry. How about substituting sigalrm_delivered to true in the reschedule_timeouts()? Maybe this processing looks strange, so some comments should be put too. Here is an example: ```diff @@

Re: Split copy.

On Tue, Nov 17, 2020 at 2:38 AM Heikki Linnakangas wrote: > > Thanks for feedback, attached is a new patch version. > > On 11/11/2020 21:49, Soumyadeep Chakraborty wrote: > > On Tue, Nov 3, 2020 at 1:30 AM Heikki Linnakangas wrote: > >> I also split/duplicated the CopyStateData struct into

Re: Parallel copy

On Thu, Oct 29, 2020 at 2:54 PM Amit Kapila wrote: > > 4) Worker has to hop through all the processed chunks before getting > the chunk which it can process. > > One more point, I have noticed that some time back [1], I have given > one suggestion related to the way workers process the set of

RE: Tab complete for CREATE OR REPLACE TRIGGER statement

> Okay. I have tweaked a couple of things in the patch and applied it. Thank you so much. The next time I post a patch, be careful with git --diff check and indentation. Regards, Noriyoshi Shinoda -Original Message- From: Michael Paquier [mailto:mich...@paquier.xyz] Sent: Wednesday,

Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?

On Fri, Nov 6, 2020 at 7:05 AM Ashutosh Bapat wrote: > +/* > + * Write MESSAGE to stream > + */ > +void > +logicalrep_write_message(StringInfo out, ReorderBufferTXN *txn, > XLogRecPtr lsn, > +bool transactional, const char *prefix, Size sz, > +

Re: Terminate the idle sessions

On Nov 18, 2020, at 10:40 AM, kuroda.hay...@fujitsu.com wrote: I’m not familiar with the system interrupt, however, the sigalrm_due_at is subsutitue between HOLD_INTERRUPTS() and RESUM_INTERRUPTS(), so I think it cannot be interrupted. The following comments

Re: pl/pgsql feature request: shorthand for argument and local variable references

út 17. 11. 2020 v 21:45 odesílatel Chapman Flack napsal: > On 11/17/20 15:18, Jack Christensen wrote: > >> CREATE OR REPLACE FUNCTION very_long_name(par1 int) > >> RETURNS int AS $$ > >> #routine_label lnm > >> BEGIN > >> RAISE NOTICE '%', lnm.par1; > > Could that be somehow shoehorned into

Re: Tab complete for CREATE OR REPLACE TRIGGER statement

On Mon, Nov 16, 2020 at 10:14:10PM -0500, Tom Lane wrote: > Michael Paquier writes: >> I don't think that this is a requirement for this thread, though. > > Agreed, I'm not trying to block this patch. Just wishing > there were a better way. Okay. I have tweaked a couple of things in the patch

Re: [HACKERS] logical decoding of two-phase transactions

On Wed, Nov 18, 2020 at 7:54 AM Masahiko Sawada wrote: > > On Tue, Nov 17, 2020 at 9:05 PM Amit Kapila wrote: > > > > On Tue, Nov 17, 2020 at 5:02 PM Ajin Cherian wrote: > > > > > > On Tue, Nov 17, 2020 at 10:14 PM Amit Kapila > > > wrote: > > > > > > > > > > > Doesn't this happen only if you

Re: abstract Unix-domain sockets

On Tue, Nov 17, 2020 at 7:00 PM Michael Paquier wrote: > On Tue, Nov 17, 2020 at 11:18:12PM +0100, Peter Eisentraut wrote: > > So the mention of the "port" doesn't really add any information here and > > just introduces new terminology that isn't really relevant. > > > > My idea is to change the

Re: abstract Unix-domain sockets

On Fri, Oct 9, 2020 at 3:28 PM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > During the discussion on Unix-domain sockets on Windows, someone pointed > out[0] abstract Unix-domain sockets. > This reminds me on a somewhat random note that SSPI mode authentication should work out

RE: Terminate the idle sessions

Dear Li, > I’m not familiar with the system interrupt, however, > the sigalrm_due_at is subsutitue between HOLD_INTERRUPTS() > and RESUM_INTERRUPTS(), so I think it cannot be interrupted. > The following comments comes from miscadmin.h. Right, but how about before HOLD_INTERRUPTS()? If so, only

Re: [doc] plan invalidation when statistics are update

On 2020/11/18 11:04, torikoshia wrote: Hi, AFAIU, when the planner statistics are updated, generic plans are invalidated and PostgreSQL recreates. However, the manual doesn't seem to explain it explicitly.   https://www.postgresql.org/docs/devel/sql-prepare.html I guess this case is

Re: [HACKERS] logical decoding of two-phase transactions

On Tue, Nov 17, 2020 at 9:05 PM Amit Kapila wrote: > > On Tue, Nov 17, 2020 at 5:02 PM Ajin Cherian wrote: > > > > On Tue, Nov 17, 2020 at 10:14 PM Amit Kapila > > wrote: > > > > > > > > Doesn't this happen only if you set replication origins? Because > > > otherwise both PrepareTransaction()

[doc] plan invalidation when statistics are update

Hi, AFAIU, when the planner statistics are updated, generic plans are invalidated and PostgreSQL recreates. However, the manual doesn't seem to explain it explicitly. https://www.postgresql.org/docs/devel/sql-prepare.html I guess this case is included in 'whenever database objects used in

[doc] adding way to examine the plan type of prepared statements

Hi, Currently, EXPLAIN is the only way to know whether the plan is generic or custom according to the manual of PREPARE. https://www.postgresql.org/docs/devel/sql-prepare.html After commit d05b172, we can also use pg_prepared_statements view to examine the plan types. How about adding

Re: VACUUM (DISABLE_PAGE_SKIPPING on)

On 2020-Nov-17, Simon Riggs wrote: > As an additional optimization, if we do find a row that needs freezing > on a data block, we should simply freeze *all* row versions on the > page, not just the ones below the selected cutoff. This is justified > since writing the block is the biggest cost and

Re: abstract Unix-domain sockets

On Tue, Nov 17, 2020 at 11:18:12PM +0100, Peter Eisentraut wrote: > So the mention of the "port" doesn't really add any information here and > just introduces new terminology that isn't really relevant. > > My idea is to change the message to: > > ERROR: could not bind Unix address

Re: remove spurious CREATE INDEX CONCURRENTLY wait

On Tue, Nov 17, 2020 at 02:14:53PM -0300, Alvaro Herrera wrote: > diff --git a/src/backend/replication/logical/logical.c > b/src/backend/replication/logical/logical.c > index f1f4df7d70..4324e32656 100644 > --- a/src/backend/replication/logical/logical.c > +++

Re: Move OpenSSL random under USE_OPENSSL_RANDOM

On Tue, Nov 17, 2020 at 09:24:30PM +0100, Daniel Gustafsson wrote: > I tend to agree, randomness is complicated enough without adding a compile > time > extensibility which few (if anyone) will ever use. Attached is an attempt at > this. Going down to that, it seems to me that we could just

Re: Zedstore - compressed in-core columnar storage

On Nov 13, 2020, at 2:00 PM, Tomas Vondra wrote: > > Fedora 32, nothing special. I'm not sure if I ran the tests with pglz or > lz4, maybe there's some dependence on that, but it does fail for me > quite reliably with this: > > ./configure --enable-debug --enable-cassert --enable-tap-tests >

Re: abstract Unix-domain sockets

On 2020-11-12 08:12, Michael Paquier wrote: On Wed, Nov 11, 2020 at 01:39:17PM +0100, Peter Eisentraut wrote: Thinking about it further, I think the hint in the Unix-domain socket case is bogus. A socket in the file-system namespace never reports EADDRINUSE anyway, it just overwrites the file.

Re: ERROR: too many dynamic shared memory segment

On Wed, Nov 18, 2020 at 10:55 AM Thomas Munro wrote: > a few times those ways, also due to an ancient DSM leak that was fixed > in 93745f1e (fix present in 12.4). I take that bit back -- I misremembered -- that was a leak of the actual memory once slots were exhausted, not a leak of the slot.

Re: ERROR: too many dynamic shared memory segment

On Wed, Nov 18, 2020 at 4:21 AM Ben Kanouse wrote: > My database is experiencing a 'ERROR: too many dynamic shared memory > segment' error from time to time. It seems to happen most when traffic > is high, and it happens with semi-simple select statements that run a > parallel query plan with a

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

On Wed, Nov 11, 2020 at 06:49:43AM +0100, Pavel Stehule wrote: > Perhaps this feature could co-exist with a full blown configuration for > >> pg_dump, but even then there's certainly issues with what's proposed- > >> how would you handle explicitly asking for a table which is named > >> "

Re: Protect syscache from bloating with negative cache entries

On Tue, Nov 17, 2020 at 10:46 AM Heikki Linnakangas wrote: > 0.7% degradation is probably acceptable. I haven't looked at this patch in a while and I'm pleased with the way it seems to have been redesigned. It seems relatively simple and unlikely to cause big headaches. I would say that 0.7% is

Re: Deleting older versions in unique indexes to avoid page splits

On Tue, Nov 17, 2020 at 7:24 AM Victor Yegorov wrote: > I've looked through the code and it looks very good from my end: > - plenty comments, good description of what's going on > - I found no loose ends in terms of AM integration > - magic constants replaced with defines > Code looks good.

Re: pl/pgsql feature request: shorthand for argument and local variable references

On 11/17/20 15:18, Jack Christensen wrote: >> CREATE OR REPLACE FUNCTION very_long_name(par1 int) >> RETURNS int AS $$ >> #routine_label lnm >> BEGIN >> RAISE NOTICE '%', lnm.par1; Could that be somehow shoehorned into the existing ALIAS syntax, maybe as DECLARE lnm ALIAS FOR ALL

Re: Move OpenSSL random under USE_OPENSSL_RANDOM

> On 16 Nov 2020, at 16:06, Tom Lane wrote: > > Magnus Hagander writes: >> I agree with those -- either we remove the ability to choose random source >> independently of the SSL library (and then only use the windows crypto >> provider or /dev/urandom as platform-specific choices when *no* SSL

Re: pl/pgsql feature request: shorthand for argument and local variable references

On Tue, Nov 17, 2020 at 1:36 PM Pavel Stehule wrote: > > Personally in your example I very much like notation "update_item.id", > because there is a clean signal so "id" is the function's argument. When > you use "$id", then it is not clean if "id" is a local variable or > function's argument.

Re: pg_proc.dat "proargmodes is not a 1-D char array"

Robert Haas writes: > On Tue, Nov 17, 2020 at 10:32 AM Tom Lane wrote: >> Adding the expected length to the error message might be OK though. > Certainly seems like we should do at least that much. The current > message is just wrong, right? It's incomplete, for sure. Doesn't mention nulls

Re: [patch] [doc] Clarify that signal functions have no feedback

On Tue, Nov 17, 2020 at 6:13 AM Heikki Linnakangas wrote: > On 02/11/2020 18:02, David G. Johnston wrote: > > diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml > > index bf6004f321..43bc2cf086 100644 > > --- a/doc/src/sgml/func.sgml > > +++ b/doc/src/sgml/func.sgml > > @@ -23892,7

Re: pg_proc.dat "proargmodes is not a 1-D char array"

On Tue, Nov 17, 2020 at 10:32 AM Tom Lane wrote: > Adding the expected length to the error message might be OK though. Certainly seems like we should do at least that much. The current message is just wrong, right? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise

Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit

Hi, On 2020-11-06 18:56, Anastasia Lubennikova wrote: Status update for a commitfest entry. This thread was inactive for a while and from the latest messages, I see that the patch needs some further work. So I move it to "Waiting on Author". The new status of this patch is: Waiting on Author

Re: pl/pgsql feature request: shorthand for argument and local variable references

Hi út 17. 11. 2020 v 19:04 odesílatel Jack Christensen napsal: > When arguments and other local variables in pl/pgsql functions have the > same name as columns referenced in queries it is necessary to disambiguate > the names. This can be done by prefixing the function name (e.g. >

Re: Hash support for row types

Peter Eisentraut writes: > I wrote a new patch to add a lot more tests around hash-based plans. > This is intended to apply separately from the other patch, and the other > patch would then "flip" some of the test cases. OK, that addresses my concerns. regards, tom

pl/pgsql feature request: shorthand for argument and local variable references

When arguments and other local variables in pl/pgsql functions have the same name as columns referenced in queries it is necessary to disambiguate the names. This can be done by prefixing the function name (e.g. my_func.name), using the argument number is the case of an argument (e.g. $1), or

Re: Deleting older versions in unique indexes to avoid page splits

On Tue, Nov 17, 2020 at 9:19 AM Victor Yegorov wrote: > OK. Can you explain what deprecation means here? > If this functionality is left as is, it is not really deprecation?.. It just means that we only keep it around for compatibility purposes. We would like to remove it, but can't right now.

Re: Deleting older versions in unique indexes to avoid page splits

вт, 17 нояб. 2020 г. в 17:24, Peter Geoghegan : > I prefer to continue to maintain the flag in the same way, regardless > of which B-Tree version is in use (i.e. if it's heapkeyspace or not). > Maintaining the flag is not expensive, may have some small value for > forensic or debugging purposes,

Re: [PATCH] Covering SPGiST index

вт, 17 нояб. 2020 г. в 11:36, Pavel Borisov : > I've started to review this, and I've got to say that I really disagree >> with this choice: >> >> + * If there are INCLUDE columns, they are stored after a key value, each >> + * starting from its own typalign boundary. Unlike IndexTuple, first >>

Re: remove spurious CREATE INDEX CONCURRENTLY wait

So I made the change to set the statusFlags with only LW_SHARED -- both in existing uses (see 0002) and in the new CIC code (0003). I don't think 0002 is going to have a tremendous performance impact, because it changes operations that are very infrequent. But even so, it would be weird to leave

Re: Detecting File Damage & Inconsistencies

On Fri, 13 Nov 2020 at 11:24, Simon Riggs wrote: > > On Fri, 13 Nov 2020 at 00:50, tsunakawa.ta...@fujitsu.com > wrote: > > > > From: Simon Riggs > > > If a rogue user/process is suspected, this would allow you to identify > > > more easily the changes made by specific sessions/users. > > > >

Re: planner support functions: handle GROUP BY estimates ?

On 11/17/20 5:18 PM, Justin Pryzby wrote: > On Mon, Nov 16, 2020 at 06:24:41PM +0100, Tomas Vondra wrote: >> On 1/15/20 12:44 AM, Tom Lane wrote: >>> Tomas Vondra writes: On Tue, Jan 14, 2020 at 05:37:53PM -0500, Tom Lane wrote: > I wonder just how messy it would be to add a column to

Re: Add session statistics to pg_stat_database

On Tue, Nov 17, 2020 at 4:22 PM Laurenz Albe wrote: > On Fri, 2020-10-16 at 16:24 +0500, Ahsan Hadi wrote: > > I have applied the latest patch on master, all the regression test cases > are passing > > and the implemented functionality is also looking fine. The point that > I raised about > >

Re: Commitfest 2020-11

Now that we are halfway through the commitfest, the status breakdown looks like this: Needs review: 116 Waiting on Author: 45 Ready for Committer: 22 Committed: 51 Returned with Feedback: 1 Withdrawn: 8 Rejected: 1 Total: 244 which means we have reached closure on a quarter of the patches. And

Re: Deleting older versions in unique indexes to avoid page splits

On Tue, Nov 17, 2020 at 7:05 AM Victor Yegorov wrote: > I've looked over the BTP_HAS_GARBAGE modifications, they look sane. > I've double checked that heapkeyspace indexes don't use this flag (don't rely > on it), > while pre-v4 ones still use it. Cool. > I have a question. This flag is raised

Re: enable_incremental_sort changes query behavior

On 11/17/20 3:03 PM, James Coleman wrote: > On Mon, Nov 16, 2020 at 11:23 PM Tomas Vondra > wrote: >> >> Hmm, I missed that other thread. That indeed seems like a bug in the >> same area already tweaked by ebb7ae839d033d0f2 for similar cases. > > I meant to bring it up in this thread before

Re: planner support functions: handle GROUP BY estimates ?

On Mon, Nov 16, 2020 at 06:24:41PM +0100, Tomas Vondra wrote: > On 1/15/20 12:44 AM, Tom Lane wrote: > > Tomas Vondra writes: > >> On Tue, Jan 14, 2020 at 05:37:53PM -0500, Tom Lane wrote: > >>> I wonder just how messy it would be to add a column to pg_statistic_ext > >>> whose type is the

Re: Is postgres ready for 2038?

=?UTF-8?B?5pa55b6z6Lyd?= writes: > Is there any road map for 2038 problems in Postgres? Postgres has no problem with post-2038 dates as long as you are using a system with 64-bit time_t. In other words, the road map is "get off Windows, or press Microsoft to fix their problems".

Re: remove spurious CREATE INDEX CONCURRENTLY wait

On 2020-Nov-16, Alvaro Herrera wrote: > On 2020-Nov-09, Tom Lane wrote: > > > Michael Paquier writes: > > >> +LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE); > > >> +MyProc->vacuumFlags |= PROC_IN_SAFE_IC; > > >> +

Re: Protect syscache from bloating with negative cache entries

On 09/11/2020 11:34, Kyotaro Horiguchi wrote: At Fri, 6 Nov 2020 10:42:15 +0200, Heikki Linnakangas wrote in Do you need the "ntaccess == 2" test? You could always increment the counter, and in the code that uses ntaccess to decide what to evict, treat all values >= 2 the same. Need to handle

Re: Add Information during standby recovery conflicts

On 2020/11/17 17:23, Drouvot, Bertrand wrote: On 11/17/20 2:09 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. On Mon, Nov 16, 2020 at 4:55

Is postgres ready for 2038?

Hello dear pgsql hackers I think Postgres had fix 2038 problems since 8.4, when I read in stackexchange: https://dba.stackexchange.com/a/233084/102852 So I test on my PC by simply change system date to `2040-09-25`: - Windows 10 Home edition - CPU: AMD 64 bit - Postgres version

Re: Additional improvements to extended statistics

On Thu, 12 Nov 2020 at 14:18, Tomas Vondra wrote: > > Here is an improved WIP version of the patch series, modified to address > the issue with repeatedly applying the extended statistics, as discussed > with Dean in this thread. It's a bit rough and not committable, but I > need some feedback so

Re: pg_proc.dat "proargmodes is not a 1-D char array"

Alvaro Herrera writes: > Perhaps we can improve these error messages like below. (Or maybe just > keep it one message "proargmodes is not a 1-D char array of %d > elements"?) There are about 5 places to change I think. I doubt that it's really worth expending more code on this. Certainly I see

Re: Deleting older versions in unique indexes to avoid page splits

пт, 13 нояб. 2020 г. в 00:01, Peter Geoghegan : > Attached is v8, which has the enhancements for low cardinality data > that I mentioned earlier today. It also simplifies the logic for > dealing with posting lists that we need to delete some TIDs from. > These posting list simplifications also

Re: Add session statistics to pg_stat_database

On Fri, 2020-10-16 at 16:24 +0500, Ahsan Hadi wrote: > I have applied the latest patch on master, all the regression test cases are > passing > and the implemented functionality is also looking fine. The point that I > raised about > idle connection not included is also addressed. If you

ERROR: too many dynamic shared memory segment

Hello, My database is experiencing a 'ERROR: too many dynamic shared memory segment' error from time to time. It seems to happen most when traffic is high, and it happens with semi-simple select statements that run a parallel query plan with a parallel bitmap heap scan. It is currently on version

Re: Deleting older versions in unique indexes to avoid page splits

чт, 12 нояб. 2020 г. в 23:00, Peter Geoghegan : > Another thing that I'll probably add to v8: Prefetching. This is > probably necessary just so I can have parity with the existing > heapam.c function that the new code is based on, > heap_compute_xid_horizon_for_tuples(). That will probably help

Re: Deleting older versions in unique indexes to avoid page splits

чт, 12 нояб. 2020 г. в 23:00, Peter Geoghegan : > It would be helpful if you could take a look at the nbtree patch -- > particularly the changes related to deprecating the page-level > BTP_HAS_GARBAGE flag. I would like to break those parts out into a > separate patch, and commit it in the next

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

út 17. 11. 2020 v 15:21 odesílatel torikoshia napsal: > On 2020-11-12 14:23, Pavel Stehule wrote: > > > yes, the plan self is very interesting information - and information > > if plan was generic or not is interesting too. It is other dimension > > of query - maybe there can be rule - for any

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

On 2020-11-12 14:23, Pavel Stehule wrote: yes, the plan self is very interesting information - and information if plan was generic or not is interesting too. It is other dimension of query - maybe there can be rule - for any query store max 100 most slows plans with all attributes. The next

ResourceOwner refactoring

Two recent patches that I have reviewed have reminded me that the ResourceOwner interface is a bit clunky. There are two issues: 1. Performance. It's fast enough in most use, but when I was testing Kyotaro's catcache patches [1], the Resowner functions to track catcache references

Re: logical streaming of xacts via test_decoding is broken

On Sun, Nov 15, 2020 at 11:34 AM Dilip Kumar wrote: > Pushed after minor changes. -- With Regards, Amit Kapila.

Re: enable_incremental_sort changes query behavior

On Mon, Nov 16, 2020 at 11:23 PM Tomas Vondra wrote: > > Hmm, I missed that other thread. That indeed seems like a bug in the > same area already tweaked by ebb7ae839d033d0f2 for similar cases. I meant to bring it up in this thread before we got the other patch committed, but I just ended up not

Re: Hash support for row types

I wrote a new patch to add a lot more tests around hash-based plans. This is intended to apply separately from the other patch, and the other patch would then "flip" some of the test cases. On 2020-11-13 20:51, Tom Lane wrote: * The new test in with.sql claims to be testing row hashing, but

Re: [patch] [doc] Clarify that signal functions have no feedback

On 02/11/2020 18:02, David G. Johnston wrote: diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index bf6004f321..43bc2cf086 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -23892,7 +23892,8 @@ SELECT collation for ('foo' COLLATE "de_DE"); The

Re: pg_proc.dat "proargmodes is not a 1-D char array"

On 2020-Sep-30, Craig Ringer wrote: > Hi all > > Random tip for future searchers. If you've modified pg_proc.dat and initdb > fails with "proargmodes is not a 1-D char array" - it could well actually > be that the length of proargmodes does not match the length of > proallargtypes given the

Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module

Thanks Craig! On Fri, Oct 23, 2020 at 9:37 AM Craig Ringer wrote: > > src/test/modules/test_shm_mq/worker.c appears to do the right thing the wrong > way - it has its own custom handler instead of using die() or > SignalHandlerForShutdownRequest(). > handle_sigterm() and die() are similar

Re: [HACKERS] logical decoding of two-phase transactions

On Tue, Nov 17, 2020 at 5:02 PM Ajin Cherian wrote: > > On Tue, Nov 17, 2020 at 10:14 PM Amit Kapila wrote: > > > > > Doesn't this happen only if you set replication origins? Because > > otherwise both PrepareTransaction() and > > RecordTransactionCommitPrepared() used the current timestamp. > >

Re: [HACKERS] logical decoding of two-phase transactions

On Tue, Nov 17, 2020 at 10:14 PM Amit Kapila wrote: > > Doesn't this happen only if you set replication origins? Because > otherwise both PrepareTransaction() and > RecordTransactionCommitPrepared() used the current timestamp. > I was also checking this, even if you set replicating origins, the

Re: VACUUM (DISABLE_PAGE_SKIPPING on)

On Mon, 16 Nov 2020 at 22:53, Masahiko Sawada wrote: > On Tue, Nov 17, 2020 at 5:52 AM Simon Riggs wrote: > I don't think the doc is wrong. If DISABLE_PAGE_SKIPPING is specified, > we not only set aggressive = true but also skip checking visibility > map. For instance, see line 905 and line

Re: Re: parallel distinct union and aggregate support patch

On Sun, Nov 8, 2020 at 11:54 AM Dilip Kumar wrote: > > On Tue, Nov 3, 2020 at 6:06 PM Dilip Kumar wrote: > > > > On Thu, Oct 29, 2020 at 12:53 PM bu...@sohu.com wrote: > > > > > > > 1) It's better to always include the whole patch series - including the > > > > parts that have not changed.

Re: [HACKERS] logical decoding of two-phase transactions

On Mon, Nov 16, 2020 at 3:20 PM Masahiko Sawada wrote: > > On Mon, Nov 16, 2020 at 4:25 PM Ajin Cherian wrote: > > > > Updated with a new test case > > (contrib/test_decoding/t/002_twophase-streaming.pl) that tests > > concurrent aborts during streaming prepare. Had to make a few changes > > to

Re: Heads-up: macOS Big Sur upgrade breaks EDB PostgreSQL installations

FYI, both Jonathan and I have now tested this on additional machines and have been unable to reproduce the issue, so it seems like something odd happened on my original upgrade rather than a general issue. Apologies for the noise. On Mon, Nov 16, 2020 at 9:27 AM Dave Page wrote: > Hi, > > This

Re: Asynchronous Append on postgres_fdw nodes.

On Mon, Oct 5, 2020 at 3:35 PM Etsuro Fujita wrote: > Yes, if there are no objections from you or Thomas or Robert or anyone > else, I'll update Robert's patch as such. Here is a new version of the patch (as promised in the developer unconference in PostgresConf.CN & PGConf.Asia 2020): * In

Re: Cache relation sizes?

On Tue, Nov 17, 2020 at 4:13 AM Thomas Munro wrote: > > On Mon, Nov 16, 2020 at 11:01 PM Konstantin Knizhnik > wrote: > > I will look at your implementation more precisely latter. > > Thanks! Warning: I thought about making a thing like this for a > while, but the patch itself is only a

RE: POC: postgres_fdw insert batching

Hello, Modified the patch as I talked with Tomas-san. The performance results of loading one million records into a hash-partitioned table with 8 partitions are as follows: unpatched, local: 8.6 seconds unpatched, fdw: 113.7 seconds patched, fdw: 12.5 seconds (9x

Re: Terminate the idle sessions

On Nov 17, 2020, at 2:07 PM, kuroda.hay...@fujitsu.com wrote: Dear Li, David, > Additionally, using postgres_fdw within the server doesn't cause issues, > its using postgres_fdw and the remote server having this setting set to zero > that causes a problem. I

Re: Cache relation sizes?

At Mon, 16 Nov 2020 20:11:52 +1300, Thomas Munro wrote in > After recent discussions about the limitations of relying on SEEK_END > in a nearby thread[1], I decided to try to prototype a system for > tracking relation sizes properly in shared memory. Earlier in this > thread I was talking

Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module

On 2020/11/13 20:24, Bharath Rupireddy wrote: On Thu, Nov 12, 2020 at 10:06 AM Fujii Masao wrote: Thanks for the analysis! I pushed the patch. Thanks! Since we are replacing custom SIGHUP and SIGTERM handlers with standard ones, how about doing the same thing in worker_spi.c? I posted a