Re: BufFileRead() error signalling

2020-06-07 Thread Thomas Munro
On Fri, Jun 5, 2020 at 8:14 PM Michael Paquier wrote: > On Fri, Jun 05, 2020 at 06:03:59PM +1200, Thomas Munro wrote: > > I didn't change BufFileWrite() to be void, to be friendly to existing > > callers outside the tree (if there are any), though I removed all the > > code that checks the return

Re: Vacuuming the operating system documentation

2020-06-07 Thread Peter Eisentraut
On 2020-06-07 17:00, Tom Lane wrote: Relevant to the current discussion: this creates a possible positive reason for setting dynamic_shared_memory_type to "sysv", namely if it's the best available way to get around RemoveIPC in a particular situation. Should we document that? It sounds like

Bump default wal_level to logical

2020-06-07 Thread David Fetter
Hi, I'd like to propose $subject, as embodied in the attached patch. This makes it possible to discover and fulfill a need for logical replication that can arise at a time when bouncing the server has become impractical, i.e. when there is already high demand on it. Best, David. -- David Fetter

Re: race condition when writing pg_control

2020-06-07 Thread Bossart, Nathan
On 6/7/20, 7:50 PM, "Thomas Munro" wrote: > I pushed 0001 and 0002, squashed into one commit. I'm not sure about > 0003. If we're going to do that, wouldn't it be better to just > acquire the lock in that one extra place in StartupXLOG(), rather than > introducing the extra parameter? Thanks!

Re: race condition when writing pg_control

2020-06-07 Thread Thomas Munro
On Wed, Jun 3, 2020 at 2:03 PM Michael Paquier wrote: > On Wed, Jun 03, 2020 at 10:56:13AM +1200, Thomas Munro wrote: > > Sorry for my radio silence, I got tangled up with a couple of > > conferences. I'm planning to look at 0001 and 0002 shortly. > > Thanks! I pushed 0001 and 0002, squashed

Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762

2020-06-07 Thread Michael Paquier
On Thu, Jun 04, 2020 at 11:07:29AM +0900, Michael Paquier wrote: > Are there any objections in fixing the issue first then? As far as I > can see there is no objection to this part, like here: > https://www.postgresql.org/message-id/20200603214448.GA901@alvherre.pgsql Hearing nothing, I have

Re: Vacuuming the operating system documentation

2020-06-07 Thread Tom Lane
Thomas Munro writes: > On Mon, Jun 8, 2020 at 3:00 AM Tom Lane wrote: >> ... Unfortunately it seems there's nothing >> equivalent for POSIX shmem, so (2) is possible. See > Ah, I see. Ok, I propose we update the example symptom to (2), and > back-patch to 10. See attached. +1, except

Re: Vacuuming the operating system documentation

2020-06-07 Thread Thomas Munro
On Mon, Jun 8, 2020 at 3:00 AM Tom Lane wrote: > Thomas Munro writes: > > Not sure > > what to put in its place... I guess the remaining symptoms would be > > (1) the little "interlock" shmem segment is unregistered, which is > > probably symptom-free (until you start a second postmaster in the

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

2020-06-07 Thread Alexander Korotkov
Hi! On Sat, Jun 6, 2020 at 8:49 PM Peter Eisentraut wrote: > > On 2020-03-31 08:48, Michael Paquier wrote: > > On Mon, Mar 30, 2020 at 05:00:01PM +0300, Alexey Kondratov wrote: > >> What do think about adding following sanity check into xlogarchive.c? > >> > >> +#ifdef FRONTEND > >> +#error

Re: how to create index concurrently on paritioned table

2020-06-07 Thread Justin Pryzby
On Sat, Jun 06, 2020 at 09:23:32AM -0500, Justin Pryzby wrote: > On Wed, Jun 03, 2020 at 08:22:29PM +0800, 李杰(慎追) wrote: > > Partitioning is necessary for very large tables. > > However, I found that postgresql does not support create index > > concurrently on partitioned tables. > > The

Re: Debian Sid broke Perl

2020-06-07 Thread Tom Lane
I wrote: > Having said that ... it does not appear to me that the Debian perl > maintainer foresaw all the consequences of this change, so I went > ahead and filed some push-back at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798626 > I'll wait to see the reply before changing anything.

Re: Vacuuming the operating system documentation

2020-06-07 Thread Tom Lane
Thomas Munro writes: > One more thing I spotted, post commit: the example symptom of > systemd's RemoveIPC feature trashing your cluster is an error from > semctl(), but that can't happen anymore on a standard build. Good point. > Not sure > what to put in its place... I guess the remaining

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

2020-06-07 Thread Dilip Kumar
On Fri, Jun 5, 2020 at 11:37 AM Amit Kapila wrote: > > On Fri, May 29, 2020 at 8:31 PM Dilip Kumar wrote: > > > > Apart from this one more fix in 0005, basically, CheckLiveXid was > > never reset, so I have fixed that as well. > > > > I have made a number of modifications in the 0001 patch and

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

2020-06-07 Thread Dilip Kumar
On Thu, Jun 4, 2020 at 2:05 PM Dilip Kumar wrote: > > On Wed, Jun 3, 2020 at 2:43 PM Amit Kapila wrote: > > > > On Tue, Jun 2, 2020 at 7:53 PM Dilip Kumar wrote: > > > > > > On Tue, Jun 2, 2020 at 4:56 PM Amit Kapila > > > wrote: > > > > > > > > On Tue, Jun 2, 2020 at 3:59 PM Dilip Kumar >

Re: Vacuuming the operating system documentation

2020-06-07 Thread Thomas Munro
On Sun, Jun 7, 2020 at 3:42 PM Tom Lane wrote: > Thomas Munro writes: > > Yeah, I wasn't planning on changing anything in backbranches. It > > sounds like we're OK with doing this for 13. Here's a version with a > > few more changes: > > Looks pretty good to me. I attach a delta patch with a

Re: Improving connection scalability: GetSnapshotData()

2020-06-07 Thread Michail Nikolaev
Hello, hackers. Andres, nice work! Sorry for the off-top. Some of my work [1] related to the support of index hint bits on standby is highly interfering with this patch. Is it safe to consider it committed and start rebasing on top of the patches? Thanks, Michail. [1]:

Re: TAP tests not enabled in pg_dump

2020-06-07 Thread Thomas Munro
On Sun, Jun 7, 2020 at 7:51 PM Dong Wook Lee wrote: > TAP tests not enabled Did you use --enable-tap-tests when running the configure script?

Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)

2020-06-07 Thread Fabien COELHO
Hello Justin, Rebased onto 7b48f1b490978a8abca61e9a9380f8de2a56f266 and renumbered OIDs. Some feedback about v18, seen as one patch. Patch applies cleanly & compiles. "make check" is okay. pg_stat_file() and pg_stat_dir_files() now return a char type, as well as the function which call

TAP tests not enabled in pg_dump

2020-06-07 Thread Dong Wook Lee
I want to execute some testing code but I conflict against error. Please tell me how to fix it :) Environment: = OSX: 10.14.6 postgresql: version 13 current development In postgresql/src/bin/pg_dump dir I command below $ make check

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

2020-06-07 Thread David Rowley
On Sat, 6 Jun 2020 at 21:15, Dmitry Dolgov <9erthali...@gmail.com> wrote: > My concerns are more about having two different sets of distinct > uniquekeys: > > * one prepared in standard_qp_callback for skip scan (I guess those > should be added to PlannerInfo?) Yes. Those must be set so that we