Re: Option to dump foreign data in pg_dump

> On 23 Mar 2020, at 21:40, Alvaro Herrera wrote: > I don't understand why this code specifically disallows the empty string > as an option to --dump-foreign-data. The other pattern-matching options > don't do that. This seems to have been added in response to Daniel's > review[1], but I don't

Re: recovery_target_action=pause with confusing hint

On 2020/03/10 2:27, Robert Haas wrote: On Mon, Mar 9, 2020 at 12:03 PM Fujii Masao wrote: I started the discussion about the topic very related to this. I'm thinking to apply the change that Sergei proposes after applying the patch I attached in this thread. https://postgr.es/m/00c194b2-dbbb-

Re: weird hash plan cost, starting with pg10

On Mon, Mar 23, 2020 at 01:50:59PM -0300, Alvaro Herrera wrote: > While messing with EXPLAIN on a query emitted by pg_dump, I noticed that > current Postgres 10 emits weird bucket/batch/memory values for certain > hash nodes: > > -> Hash (cost=0.11..0.11 rows=10 width=12

Re: improve transparency of bitmap-only heap scans

On Tue, Mar 24, 2020 at 11:36 AM Justin Pryzby wrote: > > On Tue, Mar 24, 2020 at 10:54:05AM +0530, Amit Kapila wrote: > > On Fri, Mar 20, 2020 at 7:09 AM James Coleman wrote: > > > > > > Awesome, thanks for confirming with an actual plan. > > > > > > > I don't think it matters in nontext mode, b

Re: improve transparency of bitmap-only heap scans

On Tue, Mar 24, 2020 at 10:54:05AM +0530, Amit Kapila wrote: > On Fri, Mar 20, 2020 at 7:09 AM James Coleman wrote: > > > > Awesome, thanks for confirming with an actual plan. > > > > > I don't think it matters in nontext mode, but at least in text mode, I > > > think > > > maybe the Unfetched bl

Re: Why does [auto-]vacuum delay not report a wait event?

Hi, On 2020-03-21 17:24:57 -0700, Andres Freund wrote: > > diff --git a/src/include/pgstat.h b/src/include/pgstat.h > > index 851d0a7246..4db40e23cc 100644 > > --- a/src/include/pgstat.h > > +++ b/src/include/pgstat.h > > @@ -848,7 +848,8 @@ typedef enum > > WAIT_EVENT_BASE_BACKUP_THROTTLE = P

Re: Unqualified pg_catalog casts in pg_dump

On Mon, Mar 23, 2020 at 05:57:37PM +0100, Daniel Gustafsson wrote: > Correct, there is no functional importance with this. IMO the value is in > readability and grep-ability. This may cause extra conflicts when back-patching. -- Michael signature.asc Description: PGP signature

Re: Internal key management system

On Tue, 24 Mar 2020 at 07:15, Bruce Momjian wrote: > > On Mon, Mar 23, 2020 at 03:55:34PM +0900, Masahiko Sawada wrote: > > On Sat, 21 Mar 2020 at 23:50, Bruce Momjian wrote: > > > Actually, I think we need three files: > > > > > > * TDE WAL key file > > > * TDE block key file > > > * SQL-leve

Re: improve transparency of bitmap-only heap scans

On Fri, Mar 20, 2020 at 7:09 AM James Coleman wrote: > > Awesome, thanks for confirming with an actual plan. > > > I don't think it matters in nontext mode, but at least in text mode, I think > > maybe the Unfetched blocks should be output after the exact and lossy > > blocks, > > in case someone

Re: error context for vacuum to include block number

On Tue, Mar 24, 2020 at 9:46 AM Justin Pryzby wrote: > > On Mon, Mar 23, 2020 at 02:25:14PM +0530, Amit Kapila wrote: > > > Yea, and it would be misleading if we reported "while scanning block..of > > > relation" if we actually failed while writing its FSM. > > > > > > My previous patches did this

Re: pgsql: Improve autovacuum logging for aggressive and anti-wraparound ru

On Mon, Mar 23, 2020 at 06:41:50PM -0700, Andres Freund wrote: > Which valid scenario can lead to this? Neither the comment, nor commit > message explain it. The commit message mentions that concurrent autovacuum jobs can lead to the creation of non-aggressive and anti-wraparound jobs, which have

Re: range_agg

Thanks Alvaro! On Mon, Mar 23, 2020 at 4:33 PM Alvaro Herrera wrote: > > Thinking about the on-disk representation, can we do better than putting > the contained ranges in long-varlena format, including padding; also we > include the type OID with each element.  Sounds wasteful.  A more > comp

Re: error context for vacuum to include block number

On Mon, Mar 23, 2020 at 02:25:14PM +0530, Amit Kapila wrote: > > Yea, and it would be misleading if we reported "while scanning block..of > > relation" if we actually failed while writing its FSM. > > > > My previous patches did this: > > > > + case VACUUM_ERRCB_PHASE_VACUUM_FSM: > >

Re: Negative cost is seen for plan node

At Mon, 23 Mar 2020 21:13:48 +0800, Richard Guo wrote in > Hi all, > > With the following statements on latest master (c81bd3b9), I find > negative cost for plan nodes. > > create table a (i int, j int); > insert into a select i%10, i from generate_series(1,100)i; > analyze a; > > # e

Re: replay pause vs. standby promotion

On 2020/03/24 0:57, Fujii Masao wrote: On 2020/03/24 0:17, Sergei Kornilov wrote: Hello You meant that the promotion request should cause the recovery to finish immediately even if there are still outstanding WAL records, and cause the standby to become the master? Oh, I get your point.

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

On 2020-Mar-23, James Coleman wrote: > 4. nodeIncrementalSort.c ExecReScanIncrementalSort: This whole chunk > is suspect. I've mentioned previously I don't have a great mental > model of how rescan works and its invariants (IIRC someone said it was > about moving around a result set in a cursor).

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

On Mon, Mar 23, 2020 at 07:17:13PM +0300, Alexander Korotkov wrote: > On Mon, Mar 23, 2020 at 6:16 PM Alvaro Herrera > wrote: >> Hi, I didn't realize that this was waiting on me. It looks good to me >> -- I'd just remove the comment on the function prototype in archiver.h, >> which is not custom

Re: Parallel grouping sets

On Fri, Mar 20, 2020 at 07:57:02PM +0800, Pengzhou Tang wrote: Hi Tomas, I rebased the code and resolved the comments you attached, some unresolved comments are explained in 0002-fixes.patch, please take a look. I also make the hash spill working for parallel grouping sets, the plan looks like:

Re: weird hash plan cost, starting with pg10

On Tue, Mar 24, 2020 at 9:55 AM Thomas Munro wrote: > On Tue, Mar 24, 2020 at 6:01 AM Tom Lane wrote: > > Alvaro Herrera writes: > > > While messing with EXPLAIN on a query emitted by pg_dump, I noticed that > > > current Postgres 10 emits weird bucket/batch/memory values for certain > > > hash

Re: Define variables in the approprieate scope

Michael Paquier writes: > On Mon, Mar 23, 2020 at 08:50:55PM -0400, Bruce Momjian wrote: >> I am fine with either usage, frankly. I was just pointing out what >> might be the benefit of the current coding. > Personal opinion here. I tend to prefer putting variable declarations > into the inner

Re: Wait event that should be reported while waiting for WAL archiving to finish

On 2020/03/23 15:56, Fujii Masao wrote: On 2020/03/19 19:39, Atsushi Torikoshi wrote: On Wed, Feb 26, 2020 at 9:19 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:     I have no idea about this. But I wonder how much that change     is helpful to reduce the power consumption bec

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

At Mon, 23 Mar 2020 12:47:36 -0700, Andres Freund wrote in > Hi, > > On 2020-03-23 10:37:16 +0100, Peter Eisentraut wrote: > > On 2020-03-05 08:06, Kyotaro Horiguchi wrote: > > > | [20866] LOG: replication terminated by primary server > > > | [20866] DETAIL: End of WAL reached on timeline 1 at

Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side

On 2020/03/19 17:22, Fujii Masao wrote: On 2020/03/19 12:02, Amit Langote wrote: On Thu, Mar 19, 2020 at 11:45 AM Fujii Masao wrote: On 2020/03/19 11:32, Amit Langote wrote: On Thu, Mar 19, 2020 at 11:24 AM Alvaro Herrera wrote: On 2020-Mar-19, Amit Langote wrote: Magnus' idea of che

Re: pgsql: Improve autovacuum logging for aggressive and anti-wraparound ru

Hi, On 2019-03-29 20:51:38 +0900, Michael Paquier wrote: > So, coming back to this thread, and studying the problem again, it > looks that the diagnostic that a non-aggressive, anti-wraparound > vacuum could be triggered because the worker sees trouble in the > force because of some activity happe

Re: Additional improvements to extended statistics

On Mon, Mar 23, 2020 at 08:21:42AM +, Dean Rasheed wrote: On Sat, 21 Mar 2020 at 21:59, Tomas Vondra wrote: Ah, right. Yeah, I think that should work. I thought there would be some volatility due to groups randomly not making it into the MCV list, but you're right it's possible to construc

Re: Define variables in the approprieate scope

On Mon, Mar 23, 2020 at 08:50:55PM -0400, Bruce Momjian wrote: > On Mon, Mar 23, 2020 at 01:00:24PM -0300, Alvaro Herrera wrote: >> If we're talking about personal preference, my own is what Antonin >> shows. However, since disagreement has been expressed, I think we >> should only change it if th

Re: Define variables in the approprieate scope

On Mon, Mar 23, 2020 at 01:00:24PM -0300, Alvaro Herrera wrote: > On 2020-Mar-18, Bruce Momjian wrote: > > > On Tue, Feb 25, 2020 at 09:35:52AM +0100, Antonin Houska wrote: > > > I've noticed that two variables in RelationCopyStorage() are defined in a > > > scope higher than necessary. Please see

Autovacuum vs vac_update_datfrozenxid() vs ?

Hi, While looking to understand what could be going on with [1], I think I might have stumbled on a few issues that could at least explain parts of the problem. First, it seems to me that vac_update_datfrozenxid() can spuriously (but temporarily) fail due to the 'bogus' logic. vac_update_datfroze

Re: range_agg

On 2020-Mar-19, Paul A Jungwirth wrote: > On Thu, Mar 19, 2020 at 1:43 PM Paul A Jungwirth > wrote: > > On Thu, Mar 19, 2020 at 1:42 PM Alvaro Herrera > > wrote: > > > There's been another flurry of commits in the polymorphic types area. > > > Can you please rebase again? > > > > I noticed that

Re: Option to dump foreign data in pg_dump

On 2020-Jan-29, Peter Eisentraut wrote: > On 2020-01-21 10:36, Luis Carril wrote: > > > Yes we can support --include-foreign-data without parallel option and > > > later add support for parallel option as a different patch. > > > >     I've attached a new version of the patch in which an error i

Re: Option to dump foreign data in pg_dump

v8 attached. I modified Luis' v7 a little bit by putting the ftserver acquisition in the main pg_class query instead of adding one separate query for each foreign table. That seems better overall. I don't understand why this code specifically disallows the empty string as an option to --dump-for

Re: Option to dump foreign data in pg_dump

On 2020-Mar-23, Alvaro Herrera wrote: > > This seems like an overreaction. The whole point of lockTableForWorker() is > > to avoid deadlocks, but foreign tables don't have locks, so it's not a > > problem. I think you can just skip foreign tables in lockTableForWorker() > > using the same logic

Re: GSoC chat link not working

Greetings, * Ananya Srivastava (ananyavsrivat...@gmail.com) wrote: > irc://irc.freenode.net/postgresql link is not working and I am not able to > use the chat option to clear some doubt. here is an ss if you require it. You simply need a client that works with irc links to utilize that link. Fo

Re: backup manifests

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > I think I forgot an initializer. Try this version. Just took a quick look through this. I'm pretty sure David wants to look at it too. Anyway, some comments below. > diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml >

Re: backend type in log_line_prefix?

On Thu, Mar 19, 2020 at 01:37:17PM -0300, Fabrízio de Royes Mello wrote: > > On Sun, Mar 15, 2020 at 7:32 AM Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: > > > > > > I have committed that last one also, after some corrections. > > > > IMHO we should also update file_fdw documenta

Re: Improve heavyweight locks instead of building new lock managers?

Hi, On 2020-02-21 12:40:06 +1300, Thomas Munro wrote: > On Thu, Feb 20, 2020 at 5:14 PM Andres Freund wrote: > > 16 files changed, 569 insertions(+), 1053 deletions(-) > > Nice! Thanks! > Some comments on 0001, 0003, 0004: > > > Subject: [PATCH v1 1/6] Add additional prev/next & detached no

Re: Internal key management system

On Mon, Mar 23, 2020 at 03:55:34PM +0900, Masahiko Sawada wrote: > On Sat, 21 Mar 2020 at 23:50, Bruce Momjian wrote: > > Actually, I think we need three files: > > > > * TDE WAL key file > > * TDE block key file > > * SQL-level file > > > > Primaries and standbys have to use the same TDE WAL k

Re: Missing errcode() in ereport

Andres Freund writes: > I wondered before whether there's a way we could move the elevel check > in errstart to the macro. For it to be a win we'd presumably have to > have a "synthesized" log_level variable, basically > min(log_min_messages, client_min_messages, ERROR). > Probably not worth it.

Re: ALTER INDEX fails on partitioned index

On Thu, Feb 27, 2020 at 09:11:14PM -0300, Alvaro Herrera wrote: > On 2020-Feb-27, Justin Pryzby wrote: > > The attached allows CREATE/ALTER to specify reloptions on a partitioned > > table > > which are used as defaults for future children. > > > > I think that's a desirable behavior, same as for

Re: Missing errcode() in ereport

Hi, On 2020-03-23 17:24:49 -0400, Tom Lane wrote: > I wrote: > > On balance I'm leaning towards keeping the parens as preferred style > > for now, adjusting v12 so that the macro will allow paren omission > > but we don't break ABI, and not touching the older branches. > > Hearing no objections,

Re: Missing errcode() in ereport

I wrote: > On balance I'm leaning towards keeping the parens as preferred style > for now, adjusting v12 so that the macro will allow paren omission > but we don't break ABI, and not touching the older branches. Hearing no objections, I started to review Andres' patchset with that plan in mind. I

Re: Additional size of hash table is alway zero for hash aggregates

Hi, On 2020-03-23 13:29:02 -0700, Jeff Davis wrote: > On Sat, 2020-03-21 at 18:26 -0700, Andres Freund wrote: > > I don't see how? That'd require making the hash bucket addressing > > deal > > with variable sizes, which'd be bad for performance reasons. Since > > there > > can be a aggstate->numtr

Corruption during WAL replay

This is my *first* attempt to submit a Postgres patch, please let me know if I missed any process or format of the patch (I used this link https://wiki.postgresql.org/wiki/Working_with_Git

Re: weird hash plan cost, starting with pg10

On Tue, Mar 24, 2020 at 6:01 AM Tom Lane wrote: > Alvaro Herrera writes: > > While messing with EXPLAIN on a query emitted by pg_dump, I noticed that > > current Postgres 10 emits weird bucket/batch/memory values for certain > > hash nodes: > > > -> Hash (cost=0.11..0.1

Re: Additional size of hash table is alway zero for hash aggregates

On Sat, 2020-03-21 at 18:26 -0700, Andres Freund wrote: > I don't see how? That'd require making the hash bucket addressing > deal > with variable sizes, which'd be bad for performance reasons. Since > there > can be a aggstate->numtrans AggStatePerGroupDatas for each hash table > entry, I don't se

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

Hi, On 2020-03-23 10:43:09 -0700, Ashwin Agrawal wrote: > Plus, I am hoping message will improve for pg_waldump as well? > Since it reads confusing and every-time have to explain new developer it's > expected behavior which is annoying. > > pg_waldump: fatal: error in WAL record at 0/1553F70: inv

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

Hi, On 2020-03-23 10:37:16 +0100, Peter Eisentraut wrote: > On 2020-03-05 08:06, Kyotaro Horiguchi wrote: > > | [20866] LOG: replication terminated by primary server > > | [20866] DETAIL: End of WAL reached on timeline 1 at 0/30001C8. > > | [20866] FATAL: could not send end-of-streaming message

Re: Assert() failures during RI checks

Hi, On 2020-03-23 13:54:31 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2020-03-22 18:30:04 -0400, Tom Lane wrote: > >> Yeah, I was wondering about giving that a new result code, too. > >> It would be a little bit invasive and not at all back-patchable, > >> but (say) TM_SerializationVio

Re: Collation versions on Windows (help wanted, apply within)

On Mon, Mar 23, 2020 at 5:59 AM Thomas Munro wrote: > > Done in this new 0002 patch (untested). 0001 removes the comment that > individual collations can't have a NULL version, reports NULL for > Linux/glibc collations like C.UTF-8 by stripping the suffix and > comparing with C and POSIX as sugg

Re: Making psql error out on output failures

Peter Eisentraut wrote: > > If there's no more review to do, would you consider moving it to > > Ready for Committer? > > committed Thanks! Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite

Re: RFC: Add 'taint' field to pg_control.

On Wed, Feb 28, 2018 at 04:16:53PM -0600, Justin Pryzby wrote: > On Wed, Feb 28, 2018 at 01:43:11PM -0800, Andres Freund wrote: > > a significant number of times during investigations of bugs I wondered > > whether running the cluster with various settings, or various tools > > could've caused the

Re: Assert() failures during RI checks

Andres Freund writes: > On 2020-03-22 18:30:04 -0400, Tom Lane wrote: >> Yeah, I was wondering about giving that a new result code, too. >> It would be a little bit invasive and not at all back-patchable, >> but (say) TM_SerializationViolation seems like a cleaner output --- >> and we could define

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

On Mon, Mar 23, 2020 at 2:37 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2020-03-05 08:06, Kyotaro Horiguchi wrote: > > | [20866] LOG: replication terminated by primary server > > | [20866] DETAIL: End of WAL reached on timeline 1 at 0/30001C8. > > | [20866] FATAL: could

Re: SQL/JSON: functions

Attached 47th version of the patches. On 21.03.2020 22:38, Pavel Stehule wrote: On 21. 3. 2020 v 11:07 Nikita Glukhov > wrote: Attached 46th version of the patches. On 20.03.2020 22:34, Pavel Stehule wrote: On 19.03.2020 23:57 Nikita Glukhov mail

Re: Assert() failures during RI checks

Hi, On 2020-03-22 18:30:04 -0400, Tom Lane wrote: > Andres Freund writes: > > I wonder if we shouldn't just change the crosscheck case to set > > something other than TM_Updated, as it's not really accurate to say the > > tuple was updated. > > Yeah, I was wondering about giving that a new result

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

On Mon, Mar 23, 2020 at 1:05 PM Tom Lane wrote: > > Alvaro Herrera writes: > > ... all plan types that use only one child use the outer one. They > > could use either, as long as it does that consistently, I think. > > Yeah, exactly. The outer/inner terminology is really only sensible > for joi

RE: ASLR support for Postgres12

Thanks Tom for the quick Update. Can you please point me to a link or give the list of OSes where ASLR is officially supported by Postgres? Regards, Joel -Original Message- From: Tom Lane Sent: Monday, March 23, 2020 8:16 PM To: Joel Mariadasan (jomariad) Cc: pgsql-hack...@postgresq

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

Alvaro Herrera writes: > ... all plan types that use only one child use the outer one. They > could use either, as long as it does that consistently, I think. Yeah, exactly. The outer/inner terminology is really only sensible for join nodes, but there isn't a third child-plan pointer reserved f

Re: weird hash plan cost, starting with pg10

Alvaro Herrera writes: > While messing with EXPLAIN on a query emitted by pg_dump, I noticed that > current Postgres 10 emits weird bucket/batch/memory values for certain > hash nodes: > -> Hash (cost=0.11..0.11 rows=10 width=12) (actual > time=0.002..0.002 rows=1 loop

Re: Unqualified pg_catalog casts in pg_dump

> On 23 Mar 2020, at 17:54, Tom Lane wrote: > > Daniel Gustafsson writes: >> When looking at something different, I happened to notice that pg_dump is a >> bit >> inconsistent in how it qualifies casts to pg_catalog entities like regclass >> and >> oid. Most casts are qualified, but not all.

Re: Unqualified pg_catalog casts in pg_dump

Daniel Gustafsson writes: > When looking at something different, I happened to notice that pg_dump is a > bit > inconsistent in how it qualifies casts to pg_catalog entities like regclass > and > oid. Most casts are qualified, but not all. Even though it functionally is > the same, being consi

weird hash plan cost, starting with pg10

Hello While messing with EXPLAIN on a query emitted by pg_dump, I noticed that current Postgres 10 emits weird bucket/batch/memory values for certain hash nodes: -> Hash (cost=0.11..0.11 rows=10 width=12) (actual time=0.002..0.002 rows=1 loops=8)

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

On 2020-Mar-22, James Coleman wrote: > One question I have while I work on that: I've noticed some confusion > in the patch as to whether we should refer to the node below the > incremental sort node in the plan tree (i.e., the node we get tuples > from) as the inner node or the outer node. Intuit

Re: Unicode normalization SQL functions

Peter Eisentraut wrote: > What is that status of this patch set? I think we have nailed down the > behavior, but there were some concerns about certain performance > characteristics. Do people feel that those are required to be addressed > in this cycle? Not finding any other issue w

Re: SQL/JSON: JSON_TABLE

Hi This patch needs rebase Regards Pavel

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

On Mon, Mar 23, 2020 at 6:16 PM Alvaro Herrera wrote: > On 2020-Mar-23, Alexander Korotkov wrote: > > On Fri, Mar 13, 2020 at 3:18 AM Michael Paquier wrote: > > > No issues with that either. Are you fine with the updated version > > > attached for 0001? > > > > I think patchset is almost ready f

some AppVeyor files

Many people enjoy the Windows testing the cfbot runs on the AppVeyor service. You can also run this yourself without the detour through the commit fest app. Attached are three patches that add .appveyor.yml files, for MSVC, MinGW, and Cygwin respectively. (An open problem is to combine them

Re: ASLR support for Postgres12

"Joel Mariadasan (jomariad)" writes: > Can you please point me to a link or give the list of OSes where ASLR is > officially supported by Postgres? Everything except Windows. regards, tom lane

Re: Define variables in the approprieate scope

On 2020-Mar-18, Bruce Momjian wrote: > On Tue, Feb 25, 2020 at 09:35:52AM +0100, Antonin Houska wrote: > > I've noticed that two variables in RelationCopyStorage() are defined in a > > scope higher than necessary. Please see the patch. > > It seems cleaner to me to allocate the variables once bef

Re: replay pause vs. standby promotion

On 2020/03/24 0:17, Sergei Kornilov wrote: Hello You meant that the promotion request should cause the recovery to finish immediately even if there are still outstanding WAL records, and cause the standby to become the master? Oh, I get your point. But yes, I expect that in case of promoti

Re: replay pause vs. standby promotion

On 2020/03/23 23:55, Robert Haas wrote: On Mon, Mar 23, 2020 at 10:36 AM Fujii Masao wrote: If we would like to have the promotion method to finish recovery immediately, IMO we should implement something like "pg_ctl promote -m fast". That is, we need to add new method into the promotion.

Re: optimisation? collation "C" sorting for GroupAggregate for all deterministic collations

> Perhaps this is what you mean by "deterministic", but isn't it > possible for some collations to treat multiple byte sequences as equal > values? And those multiple byte sequences wouldn't necessarily occur > sequentially in C collation, so it wouldn't be possible to work around > that by havin

Re: replay pause vs. standby promotion

Hello > You meant that the promotion request should cause the recovery > to finish immediately even if there are still outstanding WAL records, > and cause the standby to become the master? Oh, I get your point. But yes, I expect that in case of promotion request during a pause, the user (me too

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

On 2020-Mar-23, Alexander Korotkov wrote: > Dear Alvaro, > > On Fri, Mar 13, 2020 at 3:18 AM Michael Paquier wrote: > > No issues with that either. Are you fine with the updated version > > attached for 0001? > > I think patchset is almost ready for commit. Michael is waiting for > your answe

Re: replay pause vs. standby promotion

On Mon, Mar 23, 2020 at 10:36 AM Fujii Masao wrote: > If we would like to have the promotion method to finish recovery > immediately, IMO we should implement something like > "pg_ctl promote -m fast". That is, we need to add new method into > the promotion. I think 'immediate' would be a better c

Re: ASLR support for Postgres12

"Joel Mariadasan (jomariad)" writes: > We would like to know if there is a roadmap to enable ASLR support for > postgre. Not on Windows --- since that OS doesn't support fork(), it's too difficult to get different child processes to map shared memory at the same address if ASLR is active. If th

Re: is somewhere documented x LIKE ANY(ARRAY)?

Pavel Stehule writes: > po 23. 3. 2020 v 13:54 odesílatel Dagfinn Ilmari Mannsåker < > ilm...@ilmari.org> napsal: >> It's documented in >> https://www.postgresql.org/docs/current/functions-comparisons.html, and >> has been around since at least 7.4. Well, to be fair, we don't really say anywhere

Re: replay pause vs. standby promotion

On 2020/03/23 22:46, Sergei Kornilov wrote: Hello (I am trying to find an opportunity to review this patch...) Thanks for the review! It's really helpful! Consider test case with streaming replication: on primary: create table foo (i int); on standby: postgres=# select pg_wal_replay_pa

Re: WAL usage calculation patch

On 2020/03/23 21:01, Fujii Masao wrote: On 2020/03/23 7:32, Kirill Bychik wrote: I'm attaching a v5 with fp records only for temp tables, so there's no risk of instability.  As I previously said I'm fine with your two patches, so unless you have objections on the fpi test for temp tables or

Re: replay pause vs. standby promotion

Hello (I am trying to find an opportunity to review this patch...) Consider test case with streaming replication: on primary: create table foo (i int); on standby: postgres=# select pg_wal_replay_pause(); pg_wal_replay_pause - (1 row) postgres=# select pg_is_wal_replay_

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

On Tue, Mar 17, 2020 at 1:44 PM Etsuro Fujita wrote: > > > + /* > > + * If this segment of the join is empty, it means that this segment > > > > "partition of the join" looks consistent with other usages than "segment of > > the > > join". > > Actually, "segment" is used in the existing comments

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

On Fri, 2020-03-20 at 14:43 +0100, Laurenz Albe wrote: > I.e. with the default settings we will perform a whole-index scan > > (without visibility map or such) after every 10% growth of the > > table. Which means that, even if the visibility map prevents repeated > > tables accesses, increasing the

Negative cost is seen for plan node

Hi all, With the following statements on latest master (c81bd3b9), I find negative cost for plan nodes. create table a (i int, j int); insert into a select i%10, i from generate_series(1,100)i; analyze a; # explain select i from a group by i; QUERY PLAN ---

Re: is somewhere documented x LIKE ANY(ARRAY)?

po 23. 3. 2020 v 13:54 odesílatel Dagfinn Ilmari Mannsåker < ilm...@ilmari.org> napsal: > Pavel Stehule writes: > > > Hi > > > > I try to search notice about it, to get info about release date of this > > feature, but I cannot find it. > > It's documented in > https://www.postgresql.org/docs/curr

Re: is somewhere documented x LIKE ANY(ARRAY)?

Pavel Stehule writes: > Hi > > I try to search notice about it, to get info about release date of this > feature, but I cannot find it. It's documented in https://www.postgresql.org/docs/current/functions-comparisons.html, and has been around since at least 7.4. > Regards > > Pavel - ilmari --

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

Dear Alvaro, On Fri, Mar 13, 2020 at 3:18 AM Michael Paquier wrote: > No issues with that either. Are you fine with the updated version > attached for 0001? I think patchset is almost ready for commit. Michael is waiting for your answer on whether you're fine with current shape of 0001. Could

is somewhere documented x LIKE ANY(ARRAY)?

Hi I try to search notice about it, to get info about release date of this feature, but I cannot find it. Regards Pavel

Re: WAL usage calculation patch

On 2020/03/23 7:32, Kirill Bychik wrote: I'm attaching a v5 with fp records only for temp tables, so there's no risk of instability. As I previously said I'm fine with your two patches, so unless you have objections on the fpi test for temp tables or the documentation changes, I believe those

Re: Created feature for to_date() conversion using patterns 'YYYY-WW', 'YYYY-WW-D', 'YYYY-MM-W' and 'YYYY-MM-W-D'

Hi Tom, with a bit space to this issue, I re-read your comments. I am beginning to understand what you mean or - better - what's wrong with my thoughts. When I understand you correctly, you say, the WW can start at any weekday, and is not fixed to Sunday, right? In your opinion the WW starts

Re: Index Skip Scan

> > > On Mon, Mar 23, 2020 at 1:55 AM Floris Van Nee > wrote: > > I'm unsure which version number to give this patch (to continue with > numbers from previous skip scan patches, or to start numbering from scratch > again). It's a rather big change, so one could argue it's mostly a separate > patch

Unqualified pg_catalog casts in pg_dump

When looking at something different, I happened to notice that pg_dump is a bit inconsistent in how it qualifies casts to pg_catalog entities like regclass and oid. Most casts are qualified, but not all. Even though it functionally is the same, being consistent is a good thing IMO and I can't see

[PATCH] Keeps tracking the uniqueness with UniqueKey

Greetings. This thread is a follow-up thread for [1], where I submit a patch for erasing the distinct node if we have known the data is unique for sure. But since the implementation has changed a lot from the beginning and they are not very related, so I start this new thread to discuss the new s

Re: error context for vacuum to include block number

On Sat, Mar 21, 2020 at 1:33 PM Justin Pryzby wrote: > > On Sat, Mar 21, 2020 at 01:00:03PM +0530, Amit Kapila wrote: > > I have addressed your comments in the attached patch. Today, while > > testing error messages from various phases, I noticed that the patch > > fails to display error context

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

On 2020-03-05 08:06, Kyotaro Horiguchi wrote: | [20866] LOG: replication terminated by primary server | [20866] DETAIL: End of WAL reached on timeline 1 at 0/30001C8. | [20866] FATAL: could not send end-of-streaming message to primary: no COPY in progress | [20851] LOG: reached end of WAL at

Re: error context for vacuum to include block number

On Mon, Mar 23, 2020 at 1:46 PM Justin Pryzby wrote: > > On Mon, Mar 23, 2020 at 04:39:54PM +0900, Masahiko Sawada wrote: > > I've already commented on earlier patch but I personally think we'd be > > better to report freespace map vacuum as a separate phase. The > > progress report of vacuum comm

Re: color by default

On 2020-03-23 06:04, Michael Paquier wrote: On Fri, Mar 20, 2020 at 11:22:07PM -0400, Bruce Momjian wrote: On Fri, Mar 20, 2020 at 11:15:07PM -0400, Tom Lane wrote: Yeah, but the point is precisely that pg_logging_init() also responds to PG_COLORS, which is not documented anywhere. Oh, I thou

Re: Additional improvements to extended statistics

On Sat, 21 Mar 2020 at 21:59, Tomas Vondra wrote: > > Ah, right. Yeah, I think that should work. I thought there would be some > volatility due to groups randomly not making it into the MCV list, but > you're right it's possible to construct the data in a way to make it > perfectly deterministic.

Re: [HACKERS] WAL logging problem in 9.4.3?

Thanks for the labour on this. At Sat, 21 Mar 2020 15:49:20 -0700, Noah Misch wrote in > On Sat, Mar 21, 2020 at 12:01:27PM -0700, Noah Misch wrote: > > Pushed, after adding a missing "break" to gist_identify() and tweaking two .. > The proximate cause is the RelFileNodeSkippingWAL() call that w

Re: shared-memory based stats collector

Thank you for looking this. At Thu, 19 Mar 2020 16:51:59 +1300, Thomas Munro wrote in > > This seems like a failure prone API. > > If I understand correctly, the only purpose of the seqscan_running > variable is to control that behaviour ^^^. That is, to make > dshash_delete_entry() keep the

Re: error context for vacuum to include block number

On Mon, Mar 23, 2020 at 04:39:54PM +0900, Masahiko Sawada wrote: > I've already commented on earlier patch but I personally think we'd be > better to report freespace map vacuum as a separate phase. The > progress report of vacuum command is used to know the progress but > this error context would

  1   2   >