Re: [PATCH] XLogReadRecord returns pointer to currently read page

Hello. At Tue, 23 Oct 2018 10:25:27 +0500, Andrey Lepikhov wrote in <2553f2b0-0e39-eb0e-d382-6c0ed08ca...@postgrespro.ru> > > On 23.10.2018 0:53, Heikki Linnakangas wrote: > > I'd expect the decompression to read from the on-disk buffer, and > > unpack to readRecordBuf, I still don't see a

Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process

Thank you for the fix. At Tue, 23 Oct 2018 17:26:37 +1300, Thomas Munro wrote in > On Thu, Sep 6, 2018 at 9:57 PM Kyotaro HORIGUCHI > wrote: > > And don't we need a description about this restriction in the > > function comment? > > Ok, added. Thank you. It looks good. > While

Re: [PATCH] Tab complete EXECUTE FUNCTION for CREATE (EVENT) TRIGGER

On Fri, Oct 26, 2018 at 09:31:48AM +0900, Michael Paquier wrote: > Committed 0001 now which adds tab completion for CREATE TRIGGER. > Something you missed is that we should still be able to complete with > PROCEDURE or FUNCTION (depending on the backend version) if CREATE > TRIGGER .. EXECUTE is

Re: Function to promote standby servers

On Fri, Oct 26, 2018 at 11:36:00AM +0900, Ian Barwick wrote: > Documentation for this [*] says "Returns true if promotion is > successful and false otherwise", which is not correct if "wait" is > false, as it will always return TRUE. Yes, in the case where the promotion has been initiated. > +

Re: PostgreSQL vs SQL/XML Standards

pá 26. 10. 2018 v 6:25 odesílatel Chapman Flack napsal: > On 10/25/18 23:16, Pavel Stehule wrote: > >> XMLTABLE would be the headache. Using the standard name for something > >> that ain't the standard function has not left any painless way that the > >> standard function could be added. OTOH,

Re: Ordered Partitioned Table Scans

On 26 October 2018 at 16:52, Amit Langote wrote: > I recall Ronan Dunklau and Julien Rouhaud had proposed a patch for this > last year, but the partitioning-related planning code hadn't advanced then > as much as it has today, so they sort of postponed working on it. > Eventually their patch was

Re: PostgreSQL vs SQL/XML Standards

On 10/25/18 23:16, Pavel Stehule wrote: >> XMLTABLE would be the headache. Using the standard name for something >> that ain't the standard function has not left any painless way that the >> standard function could be added. OTOH, it has only been in the wild >> since 10, so renaming it to

Re: Ordered Partitioned Table Scans

On 2018/10/26 11:50, David Rowley wrote: > RANGE partitioning of time-series data is quite a common range to use > partitioning, and such tables tend to grow fairly large. I thought > since we always store RANGE partitioned tables in the PartitionDesc in > ascending range order that it might be

Re: PostgreSQL vs SQL/XML Standards

On 10/25/18 09:56, Alvaro Herrera wrote: > Would you review Markus Winand patch here? > https://postgr.es/m/8bdb0627-2105-4564-aa76-7849f028b...@winand.at > I think doing that would probably point out a couple of ways in which > our XMLTABLE implementation is non-conformant, and then fixes it :-)

Re: PostgreSQL vs SQL/XML Standards

> > XMLTABLE would be the headache. Using the standard name for something > that ain't the standard function has not left any painless way that the > standard function could be added. OTOH, it has only been in the wild > since 10, so renaming it to something else (xpath_table?) will probably > be

Ordered Partitioned Table Scans

RANGE partitioning of time-series data is quite a common range to use partitioning, and such tables tend to grow fairly large. I thought since we always store RANGE partitioned tables in the PartitionDesc in ascending range order that it might be useful to make use of this and when the required

Re: Function to promote standby servers

Hi On 10/25/2018 09:47 AM, Michael Paquier wrote: And committed. I double-checked the code, and tweaked a bit the tests so as the test using wait_mode = false is removed as it did not seem worth the extra cycles. I also added a check on the return value of pg_promote when using the wait mode.

Re: Function to promote standby servers

Hi On 10/25/2018 09:47 AM, Michael Paquier wrote: And committed. I double-checked the code, and tweaked a bit the tests so as the test using wait_mode = false is removed as it did not seem worth the extra cycles. I also added a check on the return value of pg_promote when using the wait mode.

Re: [HACKERS] Restricting maximum keep segments by repslots

At Thu, 25 Oct 2018 21:55:18 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20181025.215518.189844649.horiguchi.kyot...@lab.ntt.co.jp> > > =# alter system set max_slot_wal_keep_size to '64MB'; -- while > > wal_keep_segments is 0 > > =# select pg_reload_conf(); > > =# select slot_name,

RE: PostgreSQL Limits and lack of documentation about them.

From: David Rowley [mailto:david.row...@2ndquadrant.com] > I think it's a bit strange that we don't have this information fairly > early on in the official documentation. I only see a mention of the > 1600 column limit in the create table docs. Nothing central and don't > see mention of 32 TB

Re: [PATCH] Tab complete EXECUTE FUNCTION for CREATE (EVENT) TRIGGER

On Thu, Oct 25, 2018 at 05:02:32PM +0100, Dagfinn Ilmari Mannsåker wrote: > Okay, revised patches attached. I also tweaked the CREATE EVENT TRIGGER > completion to accept multple IN () > conditions seprated by AND in the WHEN clause (but not to suggest that, > since we only actually support one

Re: [PATCH] Tab complete EXECUTE FUNCTION for CREATE (EVENT) TRIGGER

On Thu, Oct 25, 2018 at 12:52:01PM +0100, Tom Lane wrote: > Michael Paquier writes: >> To keep the code simple, you could do something like that, by checking >> the head keywords for a match with CREATE TRIGGER, and then move all the >> existing conditions within it: >> ... >> char

Re: PostgreSQL vs SQL/XML Standards

On 10/25/18 11:15, Pavel Stehule wrote: > čt 25. 10. 2018 v 17:09 odesílatel Alvaro Herrera > napsal: >> Maybe the best way forward is to implement all the JSON functionality >> and remove the SQL/XML bits. > > It can be bigger compatibility break in Postgres history. SQL/XML functions > are

Re: PostgreSQL Limits and lack of documentation about them.

On Fri, Oct 26, 2018 at 9:30 AM David Rowley wrote: > For a long time, we documented our table size, max columns, max column > width limits, etc. in https://www.postgresql.org/about/ , but that > information seems to have now been removed. The last version I can > find with the information

PostgreSQL Limits and lack of documentation about them.

For a long time, we documented our table size, max columns, max column width limits, etc. in https://www.postgresql.org/about/ , but that information seems to have now been removed. The last version I can find with the information present is back in April this year. Here's a link to what we had:

Re: Using old master as new replica after clean switchover

On Thu, Oct 25, 2018 at 6:03 AM Jehan-Guillaume de Rorthais wrote: > What about logging the shutdown checkpoint on the old master? > On the standby side, we could cross-check it with a function confirming: > 1/ the very last XLogRecord received was the old master shutdown checkpoint > 2/ the

Re: ATTACH/DETACH PARTITION CONCURRENTLY

Hello Here's my take on this feature, owing to David Rowley's version. Firstly, I took Robert's advice and removed the CONCURRENTLY keyword from the syntax. We just do it that way always. When there's a default partition, only that partition is locked with an AEL; all the rest is locked with

Re: PostgreSQL vs SQL/XML Standards

On 2018-Oct-25, Pavel Stehule wrote: > I am thinking so I can fix some issues related to XMLTABLE. Please, send me > more examples and test cases. Please see Markus Winand's patch that I referenced upthread. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development,

Re: PostgreSQL vs SQL/XML Standards

Hi > But a roadmap that could lead to eventual availability of one of the > C/C++ implementations would be nice too. > Somebody should to do some work and write patch :/. Although libxml2 is after feature freeze - it is code widely used. The change of XML support should be safe, because there

Re: PostgreSQL vs SQL/XML Standards

On 10/25/18 2:33 PM, Andrew Dunstan wrote: Yeah, very good point. xqilla/xerces-C appears to be widely available (Centos and ubuntu, at least). xqilla/xerces-c are in the Fedora/RHEL repo too. Best regards, Jesper

Re: PostgreSQL vs SQL/XML Standards

On 10/25/18 11:08 AM, Alvaro Herrera wrote: > XQilla seems to depend on Xerces, and seems to have died in 2011. ¿Eh? The latest release, 2.3.4 [1], is dated 2018-07-03. It looks like the latest development has been happening on the xquilla_2_3 branch. Sometimes project "activity" statistics

Re: PostgreSQL vs SQL/XML Standards

On 10/25/2018 11:23 AM, Andreas Karlsson wrote: On 10/25/2018 03:53 PM, Chapman Flack wrote: On 10/25/18 10:39 AM, Tom Lane wrote: I think getting out from under libxml2's idiosyncrasies and security lapses would be great, but is there a plausible alternative out there? Depends on whether

Re: libpq host/hostaddr/conninfo inconsistencies

On Thu, Oct 25, 2018 at 1:06 PM Fabien COELHO wrote: > If you do it, even by accident, there is no way to guess what is wrong > because the reported informations are inconsistent and does not reflect > the actual status. Meh. The reported information is fine. If you tell the system that

Re: Alter index rename concurrently to

On Thu, Oct 25, 2018 at 4:41 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > > On 17/10/2018 23:11, Peter Eisentraut wrote: > > On 13/10/2018 04:01, Andres Freund wrote: > >> I don't see how this could be argued. It has to be a self-conflicting > >> lockmode, otherwise you'd end

Re: libpq host/hostaddr/conninfo inconsistencies

Hello Robert, I think this patch is a solution in search of a problem. I take note of this negative opinion. [...] It's true that the above example is very confusing, but there's no reason for everybody to ever do that. If you do it, even by accident, there is no way to guess what is

Re: Log timestamps at higher resolution

On 2018-Oct-25, David Fetter wrote: > > I didn't intend to add anything else later. I don't think we have > > any variables that zero padding would be that useful for, but maybe > > someone might want to zero pad their pids or xids... ? > > They might, so I'll either put in a comment where that

Re: Log timestamps at higher resolution

On Thu, Oct 25, 2018 at 01:00:08PM +1300, David Rowley wrote: > On 25 October 2018 at 11:25, David Fetter wrote: > > Digging a teensy bit deeper, I noticed that there's already a > > "padding" (space padding, if I understand correctly) system for parts > > of the log_line_prefix specification

Re: [PATCH] Tab complete EXECUTE FUNCTION for CREATE (EVENT) TRIGGER

Tom Lane writes: > ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: >> Tom Lane writes: >>> Yeah. Why don't we keep the existing behavior of completing both >>> words at once, but make it server-version-dependent which completion >>> you get? > >> I did that initially, but

Re: PostgreSQL vs SQL/XML Standards

On 10/25/2018 03:53 PM, Chapman Flack wrote: On 10/25/18 10:39 AM, Tom Lane wrote: I think getting out from under libxml2's idiosyncrasies and security lapses would be great, but is there a plausible alternative out there? Depends on whether anything in [1] sounds plausible. The libraries

Re: PostgreSQL vs SQL/XML Standards

čt 25. 10. 2018 v 17:09 odesílatel Alvaro Herrera napsal: > On 2018-Oct-25, Chapman Flack wrote: > > > On 10/25/18 10:39 AM, Tom Lane wrote: > > > I think getting out from under libxml2's idiosyncrasies and security > > > lapses would be great, but is there a plausible alternative out there? > >

Re: PostgreSQL vs SQL/XML Standards

On 2018-Oct-25, Chapman Flack wrote: > On 10/25/18 10:39 AM, Tom Lane wrote: > > I think getting out from under libxml2's idiosyncrasies and security > > lapses would be great, but is there a plausible alternative out there? > > Depends on whether anything in [1] sounds plausible. > > [1]: >

Re: [PATCH] pg_hba.conf : new auth option : clientcert=verify-full

Hi, after talking with Marius: The last sentence in his mail concerning the progress suffers from poor translation, and can safely be ignored ;-) We didn't intend to push anybody. VlG-(Marius Timmer &) Arne Scheffer On 25.10.18 15:08, Marius Timmer wrote: Dear hackers, We (Julian and I)

Re: PostgreSQL vs SQL/XML Standards

On 10/25/18 10:39 AM, Tom Lane wrote: > I think getting out from under libxml2's idiosyncrasies and security > lapses would be great, but is there a plausible alternative out there? Depends on whether anything in [1] sounds plausible. -Chap [1]:

Re: PostgreSQL vs SQL/XML Standards

Alvaro Herrera writes: > On 2018-Oct-24, Chapman Flack wrote: >> https://wiki.postgresql.org/wiki/PostgreSQL_vs_SQL/XML_Standards > Wow, that's ... overwhelming. (I do wonder if we should stop relying on > libxml2 and instead look for something supporting XQuery). I think getting out from

Re: libpq host/hostaddr/conninfo inconsistencies

On Mon, Aug 20, 2018 at 7:32 AM Fabien COELHO wrote: >sh> psql "host=localhost,127.0.0.2,, hostaddr=127.0.0.1,,127.0.0.3," ># attempt 1 is 127.0.0.1 identified as localhost ># attempt 2 is 127.0.0.2 ># attempt 3 is 127.0.0.3 identified as the default, whatever it is ># attempt

Re: PostgreSQL vs SQL/XML Standards

On 2018-Oct-24, Chapman Flack wrote: > Inspired by the wiki page on PostgreSQL vs SQL Standard in general, > I have made another wiki page specifically about $subject. I hope > this was not presumptuous, and invite review / comment. I have not > linked to it from any other page yet. > >

Re: Support custom socket directory in pg_upgrade

Hi, I reviewed `pg_upgrade_sockdir-v2.patch`. I checked `-s` option on OSX. I confirmed that all tools, which are internally invoked such as pg_dumpall and pg_restore, used the specified socket and pg_upgrade worked as expected. I think this patch is fine. Best regards, On 2018/10/09

Re: Using old master as new replica after clean switchover

On Thu, Oct 25, 2018 at 11:15:51AM +0200, Jehan-Guillaume de Rorthais wrote: > On Thu, 25 Oct 2018 02:57:18 -0400 > Nikolay Samokhvalov wrote: >> My research shows that some people already rely on the following when >> planned failover (aka switchover) procedure, doing it in production: >> >>

Re: Question about xmloption and pg_restore

On 10/25/18 05:02, Tom Lane wrote: > Chapman Flack writes: >> a difference between the 2003 SQL/XML standard (which PG implements) and >> the later versions, which changed the data model so there really is a >> containment relationship between 'content' and 'document'. >>

[PATCH] pg_hba.conf : new auth option : clientcert=verify-full

Dear hackers, We (Julian and I) would like to show you the seventh version of this patch which includes all the things mentioned before. Unfortunately we did not find the time to do this earlier. On 07/19/2018 03:00 AM, Thomas Munro wrote: > you could just have one common code path to reach

Re: Using old master as new replica after clean switchover

On Thu, 25 Oct 2018 20:45:57 +0900 Michael Paquier wrote: > On Thu, Oct 25, 2018 at 11:15:51AM +0200, Jehan-Guillaume de Rorthais wrote: > > On Thu, 25 Oct 2018 02:57:18 -0400 > > Nikolay Samokhvalov wrote: > >> My research shows that some people already rely on the following when > >>

Re: [HACKERS] Restricting maximum keep segments by repslots

Hello. At Mon, 22 Oct 2018 19:35:04 +0900, Masahiko Sawada wrote in > On Thu, Sep 13, 2018 at 6:30 PM Kyotaro HORIGUCHI > wrote: > Sorry for the late response. The patch still can be applied to the It's alright. Thanks. > curent HEAD so I reviewed the latest patch. > The value of 'remain'

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

On 22.10.2018 20:19, Alvaro Herrera wrote: I didn't actually try patch yet, but the idea seems interesting. Will you add it to the commitfest? I am willing to add it to the November commitfest, but I have some concerns regarding frontend version of GUC parser. Probably, it is possible to

Re: Problem with EDB 11.0 Windows x64 distributions

* Sandeep Thakkar wrote: > On Thu, Oct 25, 2018 at 4:58 PM Christian Ullrich > wrote: > The file download on your web site is still 11.0-2, and the files are > still missing from it. Should it have updated (to -3?) by now? > > You talking about Zip archive?

Re: Problem with EDB 11.0 Windows x64 distributions

On Thu, Oct 25, 2018 at 4:58 PM Christian Ullrich wrote: > * Sandeep Thakkar wrote: > > > There shouldn't be any problem with the installer (in non extract-only > > mode) and all the dependencies should be in place. Let us know if any > > binary is not working. For extract-only mode, let me

Re: [PATCH] Tab complete EXECUTE FUNCTION for CREATE (EVENT) TRIGGER

Michael Paquier writes: > To keep the code simple, you could do something like that, by checking > the head keywords for a match with CREATE TRIGGER, and then move all the > existing conditions within it: > ... > char *execute_keyword; > ... > blah and use execute_keyword in the

Re: pg_stat_replication vs StandbyReplyMessage

On Thu, Oct 25, 2018 at 08:13:53AM +0200, Laurenz Albe wrote: > MyungKyu LIM wrote: >> I saw this topic in todo list, >> >> so I implemented simple patch. >> >> https://www.postgresql.org/message-id/flat/1657809367.407321.1533027417725.JavaMail.jboss%40ep2ml404 > > For the archives' sake,

Re: [PATCH] Tab complete EXECUTE FUNCTION for CREATE (EVENT) TRIGGER

On Thu, Oct 25, 2018 at 12:25:33PM +0100, Dagfinn Ilmari Mannsåker wrote: > I did that initially, but because COMPLETE_WITH() requres constant > arguments, I had to repeat the whole list with just changing PROCEDURE > to FUNCTION, which I thought was undesirably repetitive. If there's a > more

Re: [PATCH] Tab complete EXECUTE FUNCTION for CREATE (EVENT) TRIGGER

Michael Paquier writes: > + else if (HeadMatches("CREATE", "TRIGGER") && TailMatches("WHEN", "(*)")) > + COMPLETE_WITH("EXECUTE"); > > It seems to me that this should be removed, it would fail at parsing if > completed. The * is a wildcard, so it completes EXECUTE after CREATE TRIGGER

Re: [PATCH] Tab complete EXECUTE FUNCTION for CREATE (EVENT) TRIGGER

ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > Tom Lane writes: >> Yeah. Why don't we keep the existing behavior of completing both >> words at once, but make it server-version-dependent which completion >> you get? > I did that initially, but because COMPLETE_WITHc()

Re: Problem with EDB 11.0 Windows x64 distributions

* Sandeep Thakkar wrote: > There shouldn't be any problem with the installer (in non extract-only > mode) and all the dependencies should be in place. Let us know if any > binary is not working. For extract-only mode, let me confirm and fix the > issues if any. Sorry, I do not use the

Re: [PATCH] Tab complete EXECUTE FUNCTION for CREATE (EVENT) TRIGGER

Tom Lane writes: > Michael Paquier writes: >> On Wed, Oct 24, 2018 at 10:36:41AM +0100, Dagfinn Ilmari Mannsåker wrote: >>> Fair point. I was unsure about whether to complete every supported >>> variant or just the new one. Updated patches attached. > >> One problem with this approach is that

Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?

On Mon, Oct 22, 2018 at 7:47 PM Tom Lane wrote: > > Amit Langote writes: > > On Sat, Jul 14, 2018 at 11:29 PM Tom Lane wrote: > >> Peter Eisentraut writes: > >>> ... For > >>> partitioning, we can rely on all the columns being inherited, but not > >>> for plain inheritance. > > >> Uh, what? >

RE: [PROPOSAL]a new data type 'bytea' for ECPG

Hi Michael Thank you for your comment. # Please call me Ryo. Matsumura is too long. > > I think that set/put data for host variable should be more simple. > > The following is an example of Oracle Pro *C program for RAW type > > column. > > Just to be clear, Oracle can use varchars for binary

Re: [PATCH] Tab complete EXECUTE FUNCTION for CREATE (EVENT) TRIGGER

Michael Paquier writes: > On Wed, Oct 24, 2018 at 10:36:41AM +0100, Dagfinn Ilmari Mannsåker wrote: >> Fair point. I was unsure about whether to complete every supported >> variant or just the new one. Updated patches attached. > One problem with this approach is that a user needs to use twice

Re: Using old master as new replica after clean switchover

On Thu, 25 Oct 2018 02:57:18 -0400 Nikolay Samokhvalov wrote: ... > My research shows that some people already rely on the following when > planned failover (aka switchover) procedure, doing it in production: > > 1) shutdown the current master > 2) ensure that the "master candidate" replica

Re: Question about xmloption and pg_restore

Chapman Flack writes: > On 05/18/18 15:50, Robert Haas wrote: >> Hmm. I thought that xmloption = 'content' was supposed to be strictly >> more permissive than xmloption = 'document'. > In the spirit of not leaving a good question hanging, this turns out to be > a difference between the 2003

Re: UNLISTEN, DISCARD ALL and readonly standby

Thanks for explanation. > I guess there's an argument to be made that it'd be OK to allow UNLISTEN > but not LISTEN, but I find that argument fairly fishy. I think issuing > UNLISTEN to a standby is a likely sign of application misdesign, so I'm > not convinced we'd be doing anyone any favors by

Re: More issues with pg_verify_checksums and checksum verification in base backups

Mmm. It took too long time than expected because I was repeatedly teased by git.. At Wed, 24 Oct 2018 14:31:37 +0900, Michael Paquier wrote in <20181024053137.gl1...@paquier.xyz> > On Sun, Oct 21, 2018 at 08:56:32PM -0400, Stephen Frost wrote: > > All of this pie-in-the-sky about what pluggable

Re: UNLISTEN, DISCARD ALL and readonly standby

Shay Rojansky writes: > The documentation for DISCARD ALL[1] state that it is equivalent to a > series of commands which includes UNLISTEN *. On the other hand, the docs > for hot standby mode[1], state that UNLISTEN * is unsupported while DISCARD > is (although the docs don't specify whether

UNLISTEN, DISCARD ALL and readonly standby

Hi hackers. The documentation for DISCARD ALL[1] state that it is equivalent to a series of commands which includes UNLISTEN *. On the other hand, the docs for hot standby mode[1], state that UNLISTEN * is unsupported while DISCARD is (although the docs don't specify whether this includes DISCARD

Re: Pull up sublink of type 'NOT NOT (expr)'

Hi Alex, Yes hashed SubPlan preserves order and may be faster than hash join in some cases. But I don't think that is a reason good enough to prevent the subplan from being converted to join. Let's suppose the subplan is uncorrelated, otherwise hashed SubPlan would not be used. Hashed SubPlan

Re: Alter index rename concurrently to

On 17/10/2018 23:11, Peter Eisentraut wrote: > On 13/10/2018 04:01, Andres Freund wrote: >> I don't see how this could be argued. It has to be a self-conflicting >> lockmode, otherwise you'd end up doing renames of tables where you >> cannot see the previous state. And you'd get weird errors about

RE: [Todo item] Add entry creation timestamp column to pg_stat_replication

Thanks for your feedback! Include documentation for new column. Attached new patch file : 0001-Implement-following-TODO-list-item-v3.patch Best regards, Myungkyu, Lim   - Original Message - Sender : Laurenz Albe  Date : 2018-10-25 15:14 (GMT+9) Title : Re: [Todo item] Add

Using old master as new replica after clean switchover

Currently, the documentation explicitly states, that after failover, the old master must be recreated from scratch, or pg_rewind should be used (requiring wal_log_hints to be on, which is off by default): > The former standby is now the primary, but the former primary is down and might stay down.

Re: pgbench - add pseudo-random permutation function

Hello Alvaro, although not comment changes which break the logic of the algorithm descriptions. I have not found how to tell pgindent to let comments indentation alone. You can use /*- for such comments. Thanks for the hint. Here is an updated patch using this marker. I noticed that

Re: [Todo item] Add entry creation timestamp column to pg_stat_replication

MyungKyu LIM wrote: > I have worked on following todo list item. > > - Add entry creation timestamp column to pg_stat_replication > http://archives.postgresql.org/pgsql-hackers/2011-08/msg00694.php > > This item looks like simple because necessary data was already exist. > So, I wrote a

Re: pg_stat_replication vs StandbyReplyMessage

MyungKyu LIM wrote: > I saw this topic in todo list, > > so I implemented simple patch. > > https://www.postgresql.org/message-id/flat/1657809367.407321.1533027417725.JavaMail.jboss%40ep2ml404 For the archives' sake, please always reply on the original thread. Yours, Laurenz Albe

Re: pg_stat_replication vs StandbyReplyMessage

Hello hackers, Still need to solve this topic? https://www.postgresql.org/message-id/flat/CABUevEwA%3DAFWXr-7cCpZ9MDdxHL2wFGsxFiB6uyFDTOhRudGrA%40mail.gmail.com I saw this topic in todo list, so I implemented simple patch.