Re: psql - add SHOW_ALL_RESULTS option

[...] I agree that these two behaviors in libpq are dubious, especially the second one. I want to spend some time analyzing this more and see if fixes in libpq might be appropriate. Ok. My analysis is that fixing libpq behavior is not in the scope of a psql patch, and that if I was to

Re: [PROPOSAL] new diagnostic items for the dynamic sql

Hi Everyone, Let me know if anything else is needed on my end On Fri, 17 Dec 2021 at 10:54, Dinesh Chemuduru wrote: > > > On Fri, 3 Dec 2021 at 22:04, Zhihong Yu wrote: > >> >> >> On Fri, Dec 3, 2021 at 3:15 AM Dinesh Chemuduru >> wrote: >> >>> Hi Michael, >>> >>> Attaching the latest patch

Converting WAL to SQL

Hi Hackers, I am wondering if we have a mechanism to convert WAL records to SQL statements. I am able to use logical decoders like wal2json or test_decoding for converting WAL to readable format, but I am looking for a way to convert WAL to sql statements. Thanks Rajesh

Re: WIP: WAL prefetch (another approach)

Thomas Munro writes: >> FWIW I don't think we include updates to typedefs.list in patches. > Seems pretty harmless? And useful to keep around in development > branches because I like to pgindent stuff... As far as that goes, my habit is to pull down

Re: PublicationActions - use bit flags.

On Tue, Dec 21, 2021 at 11:56 AM Tom Lane wrote: > > Greg Nancarrow writes: > > I've attached a patch which addresses that and replaces a couple of > > memcpy()s with struct assignment, as suggested. > > Removing this is not good: > > if (relation->rd_pubactions) > - { >

Re: Documenting when to retry on serialization failure

On Fri, Dec 10, 2021 at 1:43 AM Simon Riggs wrote: > "Applications using this level must be prepared to retry transactions > due to serialization failures." > ... > "When an application receives this error message, it should abort the > current transaction and retry the whole transaction from the

Re: Look at all paths?

On 12/29/21 5:07 AM, Chris Cleveland wrote: I'm developing a new index access method. Sometimes the planner uses it and sometimes it doesn't. I'm trying to debug the process to understand why the index does or doesn't get picked up. Is there a way to dump all of the query plans that the

RE: row filtering for logical replication

On Mon, Dec 27, 2021 9:16 PM houzj.f...@fujitsu.com wrote: > > On Thur, Dec 23, 2021 4:28 PM Peter Smith wrote: > > Here is the v54* patch set: > > Attach the v55 patch set which add the following testcases in 0003 patch. > 1. Added a test to cover the case where TOASTed values are not

Re: GUC flags

On Thu, Dec 09, 2021 at 09:53:23AM -0600, Justin Pryzby wrote: > On Thu, Dec 09, 2021 at 05:17:54PM +0900, Michael Paquier wrote: > > On Wed, Dec 08, 2021 at 01:23:51PM +0100, Peter Eisentraut wrote: > > > I wasn't really aware of this script either. But I think it's a good idea > > > to have it.

Re: Allow escape in application_name

On Tue, Dec 28, 2021 at 3:29 PM Fujii Masao wrote: > > > > On 2021/12/28 9:32, Masahiko Sawada wrote: > > Doesn't this query return 64? So the expression "substring(str for > > (SELECT max_identifier_length FROM pg_control_init()))" returns the > > first 64 characters of the given string while

Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display

On Thu, Dec 9, 2021 at 9:28 PM Alvaro Herrera wrote: > > Maybe some tunable like > log_wal_traffic = { none, medium, high } > where "none" is current behavior of no noise, "medium" gets (say) once > every 256 segments (e.g., when going from XFF to (X+1)00), "high" gets > you one message per

Re: Look at all paths?

Chris Cleveland writes: > I'm developing a new index access method. Sometimes the planner uses it and > sometimes it doesn't. I'm trying to debug the process to understand why the > index does or doesn't get picked up. > Is there a way to dump all of the query plans that the planner considered,

Look at all paths?

I'm developing a new index access method. Sometimes the planner uses it and sometimes it doesn't. I'm trying to debug the process to understand why the index does or doesn't get picked up. Is there a way to dump all of the query plans that the planner considered, along with information on why

Re: [EXTERNAL] Re: Add ETIMEDOUT to ALL_CONNECTION_FAILURE_ERRNOS

I would still love to get a version of this patch backported. And I just thought of an idea to do so without breaking the Windows ABI, by slightly modifying my previous idea. See the attached patch. 0001-Treat-ETIMEDOUT-as-indicating-a-non-recoverable-conn.patch Description:

Re: [PROPOSAL] Make PSQLVAR on \getenv opitional

## Pavel Stehule (pavel.steh...@gmail.com): > it is not consistent with other \g* commands. Maybe a new statement \senv > ? But what is the use case? You can just press ^z and inside shell write > echo $xxx, and then fg That does not work: backgrounding psql will put you into your original

Re: Column Filtering in Logical Replication

OK, getting closer now. I've fixed the code to filter them column list during the initial sync, and added some more tests for code that wasn't covered. There are still some XXX comments. The one that bothers me most is the lack of an implementation that allows changing the column list in a

Re: [PROPOSAL] Make PSQLVAR on \getenv opitional

On 12/28/21 14:53, Tom Lane wrote: > Matheus Alcantara writes: >>> it is not consistent with other \g* commands. Maybe a new statement \senv ? >>> But what is the use case? You can just press ^z and inside shell write echo >>> $xxx, and then fg >> I think that the basic use case would be just

Re: [PROPOSAL] Make PSQLVAR on \getenv opitional

On Tuesday, December 28th, 2021 at 16:53, Tom lane...@sss.pgh.pa.us wrote: > Matheus Alcantara msalcantara@pm.me writes: > >>> it is not consistent with other \g* commands. Maybe a new statement \senv ? >>> But what is the use case? You can just press ^z and inside shell write echo >>>

Re: Foreign key joins revisited

Vik Fearing writes: > On 12/28/21 8:26 PM, Joel Jacobson wrote: >> Can with think of some other suitable reserved keyword? > I don't particularly like this whole idea anyway, but if we're going to > have it, I would suggest > JOIN ... USING KEY ... That would read well, which is nice, but

Re: Foreign key joins revisited

On 2021-Dec-27, Joel Jacobson wrote: > >On Mon, Dec 27, 2021, at 15:48, Isaac Morland wrote: > >I thought the proposal was to give the FK constraint name. > >However, if the idea now is to allow leaving that out also if there > >is only one FK, then that's also OK as long as people understand it

Re: [PROPOSAL] Make PSQLVAR on \getenv opitional

Matheus Alcantara writes: >> it is not consistent with other \g* commands. Maybe a new statement \senv ? >> But what is the use case? You can just press ^z and inside shell write echo >> $xxx, and then fg > I think that the basic use case would be just for debugging, instead call > \getenv

Re: Foreign key joins revisited

> How about JOIN WITH? I'm -1 on this, reusing WITH is just likely to cause confusion because WITH can appear other places in a query having an entirely different meaning. I'd just avoid that from the start. >> Can with think of some other suitable reserved keyword? >FOREIGN? Or even spell out

Re: Foreign key joins revisited

On 12/28/21 8:26 PM, Joel Jacobson wrote: > On Mon, Dec 27, 2021, at 19:15, Tom Lane wrote: >> NATURAL JOIN is widely regarded as a foot-gun that the SQL committee >> should never have invented. Why would we want to create another one? >> >> (I suspect that making the constraint name optional

Re: Foreign key joins revisited

"Joel Jacobson" writes: > Since my last email in this thread, I've learned KEY is unfortunately not a > reserved keyword. > This probably means the proposed "JOIN KEY" would be problematic, since a > relation could be named KEY. > Can with think of some other suitable reserved keyword?

Re: Foreign key joins revisited

On Mon, Dec 27, 2021, at 19:15, Tom Lane wrote: > NATURAL JOIN is widely regarded as a foot-gun that the SQL committee > should never have invented. Why would we want to create another one? > > (I suspect that making the constraint name optional would be problematic > for reasons of syntax

Re: [PROPOSAL] Make PSQLVAR on \getenv opitional

> út 28. 12. 2021 v 19:51 odesílatel Matheus Alcantara > napsal: > >> Hi pgsql hackers, I was testing the new psql command \getenv introduced on >> commit 33d3eeadb2 and from a user perspective, I think that would be nice if >> the PSQLVAR parameter were optional, therefore when it is only

Re: [PROPOSAL] Make PSQLVAR on \getenv opitional

út 28. 12. 2021 v 19:51 odesílatel Matheus Alcantara napsal: > Hi pgsql hackers, I was testing the new psql command \getenv introduced on > commit 33d3eeadb2 and from a user perspective, I think that would be nice > if the PSQLVAR parameter were optional, therefore when it is only necessary > to

[PROPOSAL] Make PSQLVAR on \getenv opitional

Hi pgsql hackers, I was testing the new psql command \getenv introduced on commit 33d3eeadb2 and from a user perspective, I think that would be nice if the PSQLVAR parameter were optional, therefore when it is only necessary to view the value of the environment variable, the user just run

warn if GUC set to an invalid shared library

forking On Mon, Dec 13, 2021 at 09:01:57AM -0500, Robert Haas wrote: > On Thu, Dec 9, 2021 at 2:32 AM Maciek Sakrejda wrote: > > > Considering the vanishingly small number of actual complaints we've > > > seen about this, that sounds ridiculously over-engineered. > > > A documentation example

Re: refactoring basebackup.c

On 12/28/21 1:11 PM, Jeevan Ladhe wrote: You need to apply Robert's v10 version patches 0002, 0003 and 0004, before applying the lz4 patch(v8 version). Thanks, able to apply now. -- regards,tushar EnterpriseDB https://www.enterprisedb.com/ The Enterprise PostgreSQL Company

Re: Emit a warning if the extension's GUC is set incorrectly

I wrote: > As a stopgap to turn the farm green again, I am going to revert > 75d22069e as well as my followup patches. If we don't want to > give up on that idea altogether, we have to find some way to > suppress the chatter from parallel workers. I wonder whether > it would be appropriate to go

Re: Extend compatibility of PostgreSQL::Test::Cluster

On 12/28/21 09:30, Andrew Dunstan wrote: > PFA a patch to extend the compatibility of PostgreSQL::Test::Cluster to > all live branches. It does this by introducing a couple of subclasses > which override a few things. The required class is automatically > detected and used, so users don't need to

parse/analyze API refactoring

I have found some of the parse/analyze API calls confusing one too many times, so here I'm proposing some renaming and refactoring. Notionally, there are three parallel ways to call the parse/analyze phase: with fixed parameters (for example, used by SPI), with variable parameters (for

Re: Add Boolean node

=?UTF-8?B?Sm9zZWYgxaBpbcOhbmVr?= writes: > po 27. 12. 2021 v 16:10 odesílatel Alvaro Herrera > napsal: >> Hmm, interesting side-effect: we no longer assign a column name in this >> case so it remains "?column?", just like it happens for other datatypes. >> This seems okay to me. (This is also

Re: [EXTERNAL] Re: PQcancel does not use tcp_user_timeout, connect_timeout and keepalive settings

I was able to spend some time on this again. I attached two patches to this email: The first patch is a cleaned up version of my previous patch. I think I addressed all feedback on the previous version in that patch (e.g. removed windows code, fixed formatting). The second patch is a new one,

Extend compatibility of PostgreSQL::Test::Cluster

PFA a patch to extend the compatibility of PostgreSQL::Test::Cluster to all live branches. It does this by introducing a couple of subclasses which override a few things. The required class is automatically detected and used, so users don't need to specify a subclass. Although this is my work it

Re: generic plans and "initial" pruning

On Sat, Dec 25, 2021 at 9:06 AM Amit Langote wrote: > > Executing generic plans involving partitions is known to become slower > as partition count grows due to a number of bottlenecks, with > AcquireExecutorLocks() showing at the top in profiles. > > Previous attempt at solving that problem was

toast tables and toast indexes

Folks, While experimenting with toast tables I noticed that the toast index lands in the same tablespace as the toast table itself. Is there a way to make the toast indexes create in a different tablespace? Phil Godfrin | Database Administration NOV NOV US | Engineering Data 9720 Beechnut St |

Re: sequences vs. synchronous replication

út 28. 12. 2021 v 9:53 odesílatel Sascha Kuhl napsal: > > > Pavel Stehule schrieb am Di., 28. Dez. 2021, > 09:51: > >> Hi >> >> út 28. 12. 2021 v 9:28 odesílatel Sascha Kuhl >> napsal: >> >>> Sequence validation by step, in total is great. If the sequence is >>> Familie or professional, does

Re: sequences vs. synchronous replication

Pavel Stehule schrieb am Di., 28. Dez. 2021, 09:51: > Hi > > út 28. 12. 2021 v 9:28 odesílatel Sascha Kuhl > napsal: > >> Sequence validation by step, in total is great. If the sequence is >> Familie or professional, does it make sense to a have a total validation by >> an expert. I can only

Re: Add Boolean node

po 27. 12. 2021 v 16:10 odesílatel Alvaro Herrera napsal: > > On 2021-Dec-27, Peter Eisentraut wrote: > > > This patch adds a new node type Boolean, to go alongside the "value" nodes > > Integer, Float, String, etc. This seems appropriate given that Boolean > > values are a fundamental part of

Re: sequences vs. synchronous replication

Hi út 28. 12. 2021 v 9:28 odesílatel Sascha Kuhl napsal: > Sequence validation by step, in total is great. If the sequence is Familie > or professional, does it make sense to a have a total validation by an > expert. I can only say true by chi square Networks, but would a medical > opinion be

Re: POC: GROUP BY optimization

On 9/2/20 9:12 PM, Tomas Vondra wrote: > We could simply use the input "tuples" value here, and then divide the > current and previous estimate to calculate the number of new groups. Performing a review of this patch I made a number of changes (see cleanup.txt). Maybe it will be useful. As I

Re: sequences vs. synchronous replication

Sequence validation by step, in total is great. If the sequence is Familie or professional, does it make sense to a have a total validation by an expert. I can only say true by chi square Networks, but would a medical opinion be an improvement? Fujii Masao schrieb am Di., 28. Dez. 2021, 07:56: