Re: pg_receivewal starting position

Le jeudi 29 juillet 2021, 07:32:37 CEST Kyotaro Horiguchi a écrit : > I didn't thought in details. But I forgot that ordinary SQL commands > have been prohibited in physical replication connection. So we need a > new replication command but it's not that a big deal. Thank you for your feedback

Re: Doc: Fixed the result of the bit_count example

> On 29 Jul 2021, at 11:23, wangzk.fns...@fujitsu.com wrote: > > Hello: > > There is a small problem with the documentation for the previously added SQL > function “bit_count”. > > In the doc, (https://www.postgresql.org/docs/14/functions-binarystring.html) > “bit_count('\x1234567890'::bytea)”

Re: Out-of-memory error reports in libpq

(This is not a code review - this is just to satisfy my curiosity) I've seen lots of code like this where I may have been tempted to use a ternary operator for readability, so I was wondering is there a PG convention to avoid such ternary operator assignments, or is it simply a personal taste

Re: Replace l337sp34k in comments.

On 7/27/21 7:39 PM, Peter Smith wrote: > IMO the PG code comments are not an appropriate place for leetspeak > creativity. > > PSA a patch to replace a few examples that I recently noticed. > > "up2date" --> "up-to-date" > Personally, I would have written this as just "up to date", I don't

Re: [Patch] ALTER SYSTEM READ ONLY

On Thu, Jul 29, 2021 at 4:47 PM Dilip Kumar wrote: > > On Wed, Jul 28, 2021 at 5:03 PM Amul Sul wrote: > > > > I was too worried about how I could miss that & after thinking more > > about that, I realized that the operation for ArchiveRecoveryRequested > > is never going to be skipped in the

Re: Slightly improve initdb --sync-only option's help message

> On 26 Jul 2021, at 20:05, Bossart, Nathan wrote: > Here are my suggestions in patch form. - printf(_(" -S, --sync-only only sync data directory\n")); + printf(_(" -S, --sync-only safely write all database files to disk and exit\n")); I think removing the

Doc: Fixed the result of the bit_count example

Hello: There is a small problem with the documentation for the previously added SQL function “bit_count”. In the doc, (https://www.postgresql.org/docs/14/functions-binarystring.html) “bit_count('\x1234567890'::bytea)” result is "31" , but the actual result is "15". Similar problems have been

Re: [PoC] Improve dead tuple storage for lazy vacuum

On Thu, Jul 29, 2021 at 3:53 AM Andres Freund wrote: > > Hi, > > On 2021-07-27 13:06:56 +0900, Masahiko Sawada wrote: > > Apart from performance and memory usage points of view, we also need > > to consider the reusability of the code. When I started this thread, I > > thought the best data

Re: Some code cleanup for pgbench and pg_verifybackup

On Wed, Jul 28, 2021 at 10:28:13AM -0400, Robert Haas wrote: > I think all of these are reasonable fixes. In the case of > pg_basebackup, a chmod() failure doesn't necessarily oblige us to give > up and exit; we could presumably still write the data. But it may be > best to give up and exit. The

Re: Out-of-memory error reports in libpq

On 7/29/21 3:01 AM, Peter Smith wrote: > (This is not a code review - this is just to satisfy my curiosity) > > I've seen lots of code like this where I may have been tempted to use > a ternary operator for readability, so I was wondering is there a PG > convention to avoid such ternary operator

Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns

On Tue, Mar 16, 2021 at 1:35 AM Oh, Mike wrote: > > Sending this to pgsql-hackers list to create a CommitFest entry with the > attached patch proposal. > > > > Hello, > > We noticed that the logical replication could fail when the > Standby::RUNNING_XACT record is generated in the middle of a

Re: [PoC] Improve dead tuple storage for lazy vacuum

Masahiko Sawada писал 2021-07-29 12:11: On Thu, Jul 29, 2021 at 3:53 AM Andres Freund wrote: Hi, On 2021-07-27 13:06:56 +0900, Masahiko Sawada wrote: > Apart from performance and memory usage points of view, we also need > to consider the reusability of the code. When I started this thread,

Re: Out-of-memory error reports in libpq

Em qui., 29 de jul. de 2021 às 00:40, Tom Lane escreveu: > Ranier Vilela writes: > > IMO, I think that "char *msg" is unnecessary, isn't it? > > > + if (!PQExpBufferBroken(errorMessage)) > > + res->errMsg = pqResultStrdup(res, errorMessage->data); > > else > > - res->errMsg = NULL; > > +

Re: [Patch] ALTER SYSTEM READ ONLY

On Wed, Jul 28, 2021 at 5:03 PM Amul Sul wrote: > > I was too worried about how I could miss that & after thinking more > about that, I realized that the operation for ArchiveRecoveryRequested > is never going to be skipped in the startup process and that never > left for the checkpoint process

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

All, > between DECLARE and the past queries qualify as an open item.  I am > adding Michael Meskes in CC.  I got to wonder how much of a > compatibility break it would be for DEALLOCATE and DESCRIBE to handle > EXEC SQL AT in a way more consistent than DECLARE, even if these are > bounded to a

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, 29 Jul 2021 at 00:35, David G. Johnston wrote: > On Wed, Jul 28, 2021 at 6:52 PM Bruce Momjian wrote: > >> I came up with the attached patch. >> > > Thank you. It is an improvement but I think more could be done here (not > exactly sure what - though removing the "copy binaries for

Re: when the startup process doesn't (logging startup delays)

> The InitPostgres() case occurs when the server is started in bootstrap > mode (during initdb) or in single-user mode (postgres --single). I do > not see any reason why we shouldn't produce progress messages in at > least the latter case. I suspect that someone who is in the rather > desperate

Re: alter table set TABLE ACCESS METHOD

On Wed, Jul 28, 2021 at 01:05:10PM -0700, Jeff Davis wrote: > On Wed, 2021-07-28 at 14:02 +0900, Michael Paquier wrote: >> Right. Isn't that an older issue though? A rewrite involved after a >> change of relpersistence does not call the hook either. It looks to >> me that this should be after

Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

At Thu, 29 Jul 2021 09:52:08 +0900, Michael Paquier wrote in > On Wed, Jul 28, 2021 at 08:28:12PM +, Bossart, Nathan wrote: > > On 7/28/21, 11:32 AM, "Tom Lane" wrote: > >> I follow the idea of using WaitLatch to ensure that the delays are > >> interruptible by postmaster signals, but even

Re: Out-of-memory error reports in libpq

Em qui., 29 de jul. de 2021 às 04:02, Peter Smith escreveu: > (This is not a code review - this is just to satisfy my curiosity) > > I've seen lots of code like this where I may have been tempted to use > a ternary operator for readability, so I was wondering is there a PG > convention to avoid

Re: Fix around conn_duration in pgbench

On 2021/07/29 2:23, Fujii Masao wrote: On 2021/07/28 16:15, Yugo NAGATA wrote: I found another disconnect_all(). /* XXX should this be connection time? */ disconnect_all(state, nclients); The measurement is also not necessary here. So the above comment should be removed or

Re: pg_upgrade does not upgrade pg_stat_statements properly

> > > > I would simplify the first two sentences to just: > > If the old cluster used extensions those same extensions must be installed > in the new cluster via installation procedures specific to, and documented > by, each extension. For contrib extensions it is usually enough to install > the

Re: needless complexity in StartupXLOG

Hi, On 2021-07-29 12:49:19 +0800, Julien Rouhaud wrote: > On Thu, Jul 29, 2021 at 3:28 AM Andres Freund wrote: > > > > [1] I really wish somebody had the energy to just remove single user and > > bootstrap modes. The degree to which they increase complexity in the rest of > > the system is

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 7:56 AM Bruce Momjian wrote: > On Wed, Jul 28, 2021 at 09:35:28PM -0700, David G. Johnston wrote: > > On Wed, Jul 28, 2021 at 6:52 PM Bruce Momjian wrote: > > > > I came up with the attached patch. > > > > > > Thank you. It is an improvement but I think more could

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 12:22:59PM -0400, Dave Cramer wrote: > On Thu, 29 Jul 2021 at 12:16, Bruce Momjian wrote: > Can you review the text I just posted?  Thanks.   I think we are making > progress.  ;-) > > > I am OK with Everything except > > Do not load the schema definitions, >

Re: [PoC] Improve dead tuple storage for lazy vacuum

Yura Sokolov писал 2021-07-29 18:29: I've attached IntegerSet2 patch for pgtools repo and benchmark results. Branch https://github.com/funny-falcon/pgtools/tree/integerset2 Strange web-mail client... I never can be sure what it will attach... Reattach benchmark results regards, Yura

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 9:55 AM Jan Wieck wrote: > How exactly do you envision that we, the PostgreSQL project, make sure > that extension developers provide those mechanisms in the future? > > I have no suggestions here, and don't really plan to get deeply involved in this area of the project

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Fri, Jul 30, 2021 at 12:14 AM Bruce Momjian wrote: > > On Thu, Jul 29, 2021 at 11:46:12AM -0400, Jan Wieck wrote: > > > > This assumes that the scripts executed during CREATE EXTENSION have no > > conditional code in them that depends on the server version. Running the > > same SQL script on

Re: pg_upgrade does not upgrade pg_stat_statements properly

On 2021-Jul-29, Dave Cramer wrote: > > I suggest "can be upgraded" rather than "should be upgraded" because > > we're not making a recommendation, merely stating the fact that it is > > possible to do so. > > Why not recommend it? I was going to suggest that we actually run alter > extension

Re: [PoC] Improve dead tuple storage for lazy vacuum

Hi, On 2021-07-29 13:15:53 -0400, Robert Haas wrote: > I don't know if this is better, but I do kind of like the fact that > the basic representation is just an array. It makes it really easy to > predict how much memory will be needed for a given number of dead > TIDs, and it's very DSM-friendly

Re: pg_upgrade does not upgrade pg_stat_statements properly

On 7/29/21 12:00 PM, David G. Johnston wrote: Ok, looking at the flow again, where exactly would the user even be able to execute "CREATE EXTENSION" meaningfully?  The relevant databases do not exist (not totally sure what happens to the postgres database created during the initdb step...) so

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 10:00:12AM -0700, David G. Johnston wrote: > I'm warming up to "should" but maybe add a "why" such as "the old versions are > considered unsupported on the newer server". > > I dislike "usually via operating system commands", just offload this to the > extension, i.e.,

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 01:43:09PM -0400, Álvaro Herrera wrote: > On 2021-Jul-29, Bruce Momjian wrote: > > > + If the old cluster used extensions, whether from > > + contrib or some other source, it used > > + shared object files (or DLLs) to implement these extensions, e.g., > > +

Re: pg_upgrade does not upgrade pg_stat_statements properly

Dave Cramer On Thu, 29 Jul 2021 at 15:06, Bruce Momjian wrote: > On Thu, Jul 29, 2021 at 01:43:09PM -0400, Álvaro Herrera wrote: > > On 2021-Jul-29, Bruce Momjian wrote: > > > > > + If the old cluster used extensions, whether from > > > + contrib or some other source, it used > > > +

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 12:28 PM Dave Cramer wrote: > So back to the original motivation for bringing this up. Recall that a > cluster was upgraded. Everything appeared to work fine, except that the > definitions of the functions were slightly different enough to cause a > fatal issue on

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 9:34 AM Bruce Momjian wrote: > On Thu, Jul 29, 2021 at 12:22:59PM -0400, Dave Cramer wrote: > > On Thu, 29 Jul 2021 at 12:16, Bruce Momjian wrote: > > Can you review the text I just posted? Thanks. I think we are > making > > progress. ;-) > > > > > > I am OK

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, 29 Jul 2021 at 13:13, Alvaro Herrera wrote: > On 2021-Jul-29, Dave Cramer wrote: > > > > If the old cluster used extensions those same extensions must be > > > installed in the new cluster via installation procedures specific > > > to, and documented by, each extension. For contrib

Re: [PoC] Improve dead tuple storage for lazy vacuum

On Thu, Jul 29, 2021 at 5:11 AM Masahiko Sawada wrote: > Indeed. Given that the radix tree itself has other use cases, I have > no concern about using radix tree for vacuum's dead tuples storage. It > will be better to have one that can be generally used and has some > optimizations that are

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 11:28 AM Bruce Momjian wrote: > I am sorry but none of your suggestions are exciting me --- they seem to > get into too much detail for the context. > Fair, I still need to consider Alvaro's anyway, but given the amount of general angst surrounding performing a

Re: [PoC] Improve dead tuple storage for lazy vacuum

Robert Haas писал 2021-07-29 20:15: On Thu, Jul 29, 2021 at 5:11 AM Masahiko Sawada wrote: Indeed. Given that the radix tree itself has other use cases, I have no concern about using radix tree for vacuum's dead tuples storage. It will be better to have one that can be generally used and has

Re: needless complexity in StartupXLOG

On Thu, Jul 29, 2021 at 1:47 AM Amul Sul wrote: > Can we have an elog() fatal error or warning to make sure that the > last checkpoint is still readable? Since the case where the user > (knowingly or unknowingly) or some buggy code has removed the WAL file > containing the last checkpoint could

Re: pg_upgrade does not upgrade pg_stat_statements properly

Dave Cramer On Thu, 29 Jul 2021 at 12:16, Bruce Momjian wrote: > On Thu, Jul 29, 2021 at 09:00:36AM -0700, David G. Johnston wrote: > > On Thu, Jul 29, 2021 at 8:42 AM Bruce Momjian wrote: > > > > On Thu, Jul 29, 2021 at 11:36:19AM -0400, Dave Cramer wrote: > > > > > > > > >

Re: fixing pg_basebackup tests for modern Windows/msys2

On 7/28/21 9:31 AM, Andrew Dunstan wrote: > While looking into issues with fairywren and pg_basebackup tests, I > created a similar environment but with more modern Windows / msys2. > Before it even got to the test that failed on fairywren it failed the > first TAP test for a variety of reasons,

Re: pg_upgrade does not upgrade pg_stat_statements properly

On 7/29/21 12:44 PM, David G. Johnston wrote: ... - but at present pg_upgrade simply doesn't care and hopes that the extension author's documentation deals with these possibilities in a sane manner. pg_upgrade is not able to address this in a guaranteed, consistent fashion. At this point

Re: amcheck verification for GiST and GIN

Hello, First of all, thank you all -- Andrey, Peter, Heikki and others -- for this work, GIN support in amcheck is *really* needed, especially for OS upgrades such as from Ubuntu 16.04 (which is EOL now) to 18.04 or 20.04 I was trying to check a bunch of GINs on some production after switching

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 02:28:55PM -0400, Bruce Momjian wrote: > On Thu, Jul 29, 2021 at 10:00:12AM -0700, David G. Johnston wrote: > > I'm warming up to "should" but maybe add a "why" such as "the old versions > > are > > considered unsupported on the newer server". > > > > I dislike "usually

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 9:28 AM Jan Wieck wrote: > On 7/29/21 12:00 PM, David G. Johnston wrote: > > Ok, looking at the flow again, where exactly would the user even be able > > to execute "CREATE EXTENSION" meaningfully? The relevant databases do > > not exist (not totally sure what happens to

Re: pg_upgrade does not upgrade pg_stat_statements properly

On 2021-Jul-29, Dave Cramer wrote: > > If the old cluster used extensions those same extensions must be > > installed in the new cluster via installation procedures specific > > to, and documented by, each extension. For contrib extensions it is > > usually enough to install the -contrib package

Re: pg_upgrade does not upgrade pg_stat_statements properly

On 2021-Jul-29, Bruce Momjian wrote: > + If the old cluster used extensions, whether from > + contrib or some other source, it used > + shared object files (or DLLs) to implement these extensions, e.g., > + pgcrypto.so. Now, shared object files matching > + the new server

Re: pg_upgrade does not upgrade pg_stat_statements properly

Dave Cramer On Thu, 29 Jul 2021 at 13:43, Alvaro Herrera wrote: > On 2021-Jul-29, Bruce Momjian wrote: > > > + If the old cluster used extensions, whether from > > + contrib or some other source, it used > > + shared object files (or DLLs) to implement these extensions, e.g., > > +

Re: Numeric x^y for negative x

On Thu, 22 Jul 2021 at 16:19, Dean Rasheed wrote: > > On Thu, 22 Jul 2021 at 06:13, Yugo NAGATA wrote: > > > > Thank you for updating the patch. I am fine with the additional comments. > > I don't think there is any other problem left, so I marked it > > Ready-for-Committers. > > Thanks for

Re: pg_upgrade does not upgrade pg_stat_statements properly

On 7/29/21 2:04 PM, Julien Rouhaud wrote: On Thu, Jul 29, 2021 at 11:46:12AM -0400, Jan Wieck wrote: > I don't have a ready example of such an extension, but if we ever would > convert the backend parts of Slony into an extension, it would be one. FWIW I have an example of such an

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 11:35 AM Bruce Momjian wrote: > > Oh, and you can't use the same installation procedures as when you > installed the extension because that probably included CREATE EXTENSION. > This really highlights why this is tricky to explain --- we need the > binaries, but not the

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 02:19:17PM -0400, Álvaro Herrera wrote: > On 2021-Jul-29, Dave Cramer wrote: > > > > I suggest "can be upgraded" rather than "should be upgraded" because > > > we're not making a recommendation, merely stating the fact that it is > > > possible to do so. > > > > Why not

Re: [Proposal] Global temporary tables

> 2021年7月28日 23:09，Tony Zhu 写道： > > Hi Wenjing > > would you please rebase the code? Thank you for your attention. According to the test, the latest pgmaster code can merge the latest patch and pass the test. https://www.travis-ci.com/github/wjzeng/postgres/builds

Re: pg_upgrade does not upgrade pg_stat_statements properly

On 7/29/21 11:10 AM, Bruce Momjian wrote: On Thu, Jul 29, 2021 at 11:01:43AM -0400, Dave Cramer wrote: Much better, however I'm unclear on whether CREATE EXTENSION is actually executed on the upgraded server. From what I could gather it is not, otherwise the new function definitions should

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 8:42 AM Bruce Momjian wrote: > On Thu, Jul 29, 2021 at 11:36:19AM -0400, Dave Cramer wrote: > > > > > > I have an issue with the fragment "whether they are from contrib" - > my > > understanding at this point is that because of the way we package and > >

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 11:46:12AM -0400, Jan Wieck wrote: > On 7/29/21 11:10 AM, Bruce Momjian wrote: > > On Thu, Jul 29, 2021 at 11:01:43AM -0400, Dave Cramer wrote: > > > Much better, however I'm unclear on whether CREATE EXTENSION is actually > > > executed on the upgraded server. > > > > > >

Re: [PoC] Improve dead tuple storage for lazy vacuum

On Thu, Jul 29, 2021 at 8:03 PM Yura Sokolov wrote: > > Masahiko Sawada писал 2021-07-29 12:11: > > On Thu, Jul 29, 2021 at 3:53 AM Andres Freund > > wrote: > >> > >> Hi, > >> > >> On 2021-07-27 13:06:56 +0900, Masahiko Sawada wrote: > >> > Apart from performance and memory usage points of view,

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 11:01:43AM -0400, Dave Cramer wrote: > > > > > OK, I went with this new text.  There is confusion over install vs copy, > and whether this is happening at the operating system level or the SQL > level.  I tried to clarify that, but I am not sure I was

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 08:28:12AM -0700, David G. Johnston wrote: > On Thu, Jul 29, 2021 at 7:56 AM Bruce Momjian wrote: > > On Wed, Jul 28, 2021 at 09:35:28PM -0700, David G. Johnston wrote: > > On Wed, Jul 28, 2021 at 6:52 PM Bruce Momjian wrote: > > > >     I came up with

Re: Out-of-memory error reports in libpq

On Thu, Jul 29, 2021 at 9:57 AM Tom Lane wrote: > In the case at hand, I'd personally avoid a ternary op for the first > assignment because then the line would run over 80 characters, and > you'd have to make decisions about where to break it. (We don't have > a standardized convention about

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 08:39:32AM -0700, David G. Johnston wrote: > On Thu, Jul 29, 2021 at 8:36 AM Dave Cramer wrote: > > > > > I have an issue with the fragment "whether they are from contrib" - my > understanding at this point is that because of the way we package and >

Re: when the startup process doesn't (logging startup delays)

On Thu, Jul 29, 2021 at 4:56 AM Nitin Jadhav wrote: > Thanks for sharing the information. I have done the necessary changes > to show the logs during the latter case (postgres --single) and > verified the log messages. Thanks. Can you please have a look at what I suggested down toward the bottom

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

On Tue, Jul 27, 2021 at 11:41 AM Peter Smith wrote: > > Please find attached the latest patch set v99* > > v98-0001 --> split into v99-0001 + v99-0002 > Pushed the first refactoring patch after making few modifications as below. 1. - /* open the spool file for the committed transaction */ + /*

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Wed, Jul 28, 2021 at 09:35:28PM -0700, David G. Johnston wrote: > On Wed, Jul 28, 2021 at 6:52 PM Bruce Momjian wrote: > > I came up with the attached patch. > > > Thank you.  It is an improvement but I think more could be done here (not > exactly sure what - though removing the "copy

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, 29 Jul 2021 at 11:10, Bruce Momjian wrote: > On Thu, Jul 29, 2021 at 11:01:43AM -0400, Dave Cramer wrote: > > > > > > > > > > OK, I went with this new text. There is confusion over install vs > copy, > > and whether this is happening at the operating system level or the > SQL >

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 11:36:19AM -0400, Dave Cramer wrote: > > > I have an issue with the fragment "whether they are from contrib" - my > understanding at this point is that because of the way we package and > version contrib it should not be necessary to copy those shared object >

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 09:00:36AM -0700, David G. Johnston wrote: > On Thu, Jul 29, 2021 at 8:42 AM Bruce Momjian wrote: > > On Thu, Jul 29, 2021 at 11:36:19AM -0400, Dave Cramer wrote: > > > > > >     I have an issue with the fragment "whether they are from contrib" - > my

Re: [Patch] ALTER SYSTEM READ ONLY

On Wed, Jul 28, 2021 at 7:33 AM Amul Sul wrote: > I was too worried about how I could miss that & after thinking more > about that, I realized that the operation for ArchiveRecoveryRequested > is never going to be skipped in the startup process and that never > left for the checkpoint process to

Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR

Hi, Trying the v7a patch, here are a few comments: * SIGSEGV with ON HOLD cursors. Reproducer: declare c cursor with hold for select oid,relname from pg_class order by 1 limit 10; select * from rows_in('c') as x(f1 oid,f2 name); consumes a bit of time, then crashes and generates a 13 GB

Re: [postgres_fdw] add local pid to fallback_application_name

"kuroda.hay...@fujitsu.com" writes: > I propose adding trackable information in postgres_fdw, in order to track > remote query correctly. I don't think this is a great idea as-is. People who need to do this sort of thing will all have their own ideas of what they need to track --- most

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 11:17:52AM -0400, Dave Cramer wrote: > On Thu, 29 Jul 2021 at 11:10, Bruce Momjian wrote: > OK, I think we should be more clear as to what is happening.  Saying they will > be recreated is misleading. > The extension definitions are being copied from the old server to the

Re: [PoC] Improve dead tuple storage for lazy vacuum

Masahiko Sawada писал 2021-07-29 17:29: On Thu, Jul 29, 2021 at 8:03 PM Yura Sokolov wrote: Masahiko Sawada писал 2021-07-29 12:11: > On Thu, Jul 29, 2021 at 3:53 AM Andres Freund > wrote: >> >> Hi, >> >> On 2021-07-27 13:06:56 +0900, Masahiko Sawada wrote: >> > Apart from performance and

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 8:36 AM Dave Cramer wrote: > > > I have an issue with the fragment "whether they are from contrib" - my >> understanding at this point is that because of the way we package and >> version contrib it should not be necessary to copy those shared object >> files from the old

Re: alter table set TABLE ACCESS METHOD

On Thu, 2021-07-29 at 15:27 +0900, Michael Paquier wrote: > Doing any checks around the hooks of objectaccess.h is very annoying, > because we have no modules to check after them easily except sepgsql. > Anyway, I have been checking that, with the hack-ish module attached > and tracked down that

Re: Out-of-memory error reports in libpq

Andrew Dunstan writes: > On 7/29/21 3:01 AM, Peter Smith wrote: >> I've seen lots of code like this where I may have been tempted to use >> a ternary operator for readability, so I was wondering is there a PG >> convention to avoid such ternary operator assignments, or is it simply >> a personal

Re: Showing applied extended statistics in explain

> On Tue, Jul 27, 2021 at 10:20:34PM +0200, Tomas Vondra wrote: > > >> 1) The information is stashed in multiple lists added to a Plan. Maybe > >> there's a better place, and maybe we need to invent a better way to > >> track the info (a new node stashed in a single List). > >> > >> ... > >> > >>

Re: Replace l337sp34k in comments.

On 7/29/21 8:51 AM, Geoff Winkless wrote: > On Thu, 29 Jul 2021 at 11:22, Andrew Dunstan > wrote: > > Personally, I would have written this as just "up to date", I don't > think the hyphens are required. > >   > FWIW Mirriam-Webster and the CED suggest

Re: needless complexity in StartupXLOG

On Wed, Jul 28, 2021 at 3:28 PM Andres Freund wrote: > > Imagine if instead of > > all the hairy logic we have now we just replaced this whole if > > (IsInRecovery) stanza with this: > > > > if (InRecovery) > > CreateEndOfRecoveryRecord(); > > > > That would be WAY easier to reason about than

Re: Replace l337sp34k in comments.

On Thu, 29 Jul 2021 at 11:22, Andrew Dunstan wrote: > Personally, I would have written this as just "up to date", I don't > think the hyphens are required. > FWIW Mirriam-Webster and the CED suggest "up-to-date" when before a noun, so the changes should be "up-to-date answer" but "are up to

Re: pg_upgrade does not upgrade pg_stat_statements properly

I have an issue with the fragment "whether they are from contrib" - my > understanding at this point is that because of the way we package and > version contrib it should not be necessary to copy those shared object > files from the old to the new server (maybe, just maybe, with a > qualification

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, 29 Jul 2021 at 11:39, David G. Johnston wrote: > On Thu, Jul 29, 2021 at 8:36 AM Dave Cramer wrote: > >> >> >> I have an issue with the fragment "whether they are from contrib" - my >>> understanding at this point is that because of the way we package and >>> version contrib it should

Re: libpq compression

Hi! I made some noticeable changes to the patch and fixed the previously mentioned issues. On Fri, Mar 19, 2021 at 16:28 AM Justin Pryzby wrote: > Previously, I suggested that the server should have a "policy" GUC defining > which compression methods are allowed. Possibly including

Re: pg_upgrade does not upgrade pg_stat_statements properly

> > OK, I went with this new text. There is confusion over install vs copy, > and whether this is happening at the operating system level or the SQL > level. I tried to clarify that, but I am not sure I was successful. I > also used the word "extension" since this is more common than "custom".

Re: pg_upgrade does not upgrade pg_stat_statements properly

Dave Cramer writes: > So back to the original motivation for bringing this up. Recall that a > cluster was upgraded. Everything appeared to work fine, except that the > definitions of the functions were slightly different enough to cause a > fatal issue on restoring a dump from pg_dump. > Since

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 06:29:11PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Thu, Jul 29, 2021 at 06:19:56PM -0400, Tom Lane wrote: > >> I suggested awhile ago that pg_upgrade should look into > >> pg_available_extensions in the new cluster, and prepare > >> a script with ALTER

Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

On 7/29/21, 12:59 AM, "Kyotaro Horiguchi" wrote: > At Thu, 29 Jul 2021 09:52:08 +0900, Michael Paquier > wrote in >> On Wed, Jul 28, 2021 at 08:28:12PM +, Bossart, Nathan wrote: >> > On 7/28/21, 11:32 AM, "Tom Lane" wrote: >> >> I follow the idea of using WaitLatch to ensure that the

Re: pg_upgrade does not upgrade pg_stat_statements properly

On 2021-Jul-29, Bruce Momjian wrote: > On Thu, Jul 29, 2021 at 06:29:11PM -0400, Tom Lane wrote: > > No, because dump/restore does not have this issue. Regular pg_dump just > > issues "CREATE EXTENSION" commands, so you automatically get the target > > server's default version. > > Oh, so

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 02:14:56PM -0400, Jan Wieck wrote: > > I presume that pg_upgrade on a database with that extension installed would > silently succeed and have the pg_catalog as well as public (or wherever) > version of that function present. I'll have to run a pg_upgrade with it to be

Re: Doc: Fixed the result of the bit_count example

> On 29 Jul 2021, at 11:35, Daniel Gustafsson wrote: > I'll apply this shortly backpatched to 14 where bit_count was introduced. And done, thanks! -- Daniel Gustafsson https://vmware.com/

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 06:19:56PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > I think we need to first give clear instructions on how to find out if > > an extension update is available, and then how to update it. I am > > thinking we should supply a query which reports all extensions

Re: Replace l337sp34k in comments.

On Fri, Jul 30, 2021 at 09:46:59AM +1200, Gavin Flower wrote: > That 'feels' right to me. > > Though in code, possibly it would be better to just use 'up-to-date' in code > for consistency and to make the it easier to grep? The change in llvmjit_expr.c may not look like an adjective though,

Re: Autovacuum on partitioned table (autoanalyze)

Hi, CCing RMT because I think we need to do something about this for v14. On 2021-07-27 19:23:42 -0700, Andres Freund wrote: > On 2021-07-22 13:54:58 -0700, Andres Freund wrote: > > On 2021-04-08 01:20:14 -0400, Alvaro Herrera wrote: > > > On 2021-Apr-07, Alvaro Herrera wrote: > > > > > > > OK,

Re: Case expression pushdown

Alexander Pyhalov writes: > [ 0001-Allow-pushing-CASE-expression-to-foreign-server-v7.patch ] I looked this over. It's better than before, but the collation handling is still not at all correct. We have to consider that a CASE's arg expression supplies the collation for a contained

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 29, 2021 at 05:01:24PM -0400, Tom Lane wrote: > Dave Cramer writes: > > So back to the original motivation for bringing this up. Recall that a > > cluster was upgraded. Everything appeared to work fine, except that the > > definitions of the functions were slightly different enough

Re: pg_upgrade does not upgrade pg_stat_statements properly

Bruce Momjian writes: > I think we need to first give clear instructions on how to find out if > an extension update is available, and then how to update it. I am > thinking we should supply a query which reports all extensions that can > be upgraded, at least for contrib. I suggested awhile

Re: Replace l337sp34k in comments.

On 30/07/21 12:51 am, Geoff Winkless wrote: On Thu, 29 Jul 2021 at 11:22, Andrew Dunstan > wrote: Personally, I would have written this as just "up to date", I don't think the hyphens are required. FWIW Mirriam-Webster and the CED suggest "up-to-date" when

Re: pg_upgrade does not upgrade pg_stat_statements properly

Bruce Momjian writes: > On Thu, Jul 29, 2021 at 06:19:56PM -0400, Tom Lane wrote: >> I suggested awhile ago that pg_upgrade should look into >> pg_available_extensions in the new cluster, and prepare >> a script with ALTER EXTENSION UPDATE commands for >> anything that's installed but is not the

Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, 29 Jul 2021 at 18:39, Bruce Momjian wrote: > On Thu, Jul 29, 2021 at 06:29:11PM -0400, Tom Lane wrote: > > Bruce Momjian writes: > > > On Thu, Jul 29, 2021 at 06:19:56PM -0400, Tom Lane wrote: > > >> I suggested awhile ago that pg_upgrade should look into > > >> pg_available_extensions

  1   2   >