Re: Prevent writes on large objects in read-only transactions

On Tue, May 31, 2022 at 05:17:42PM -0400, Robert Haas wrote: > On Tue, May 31, 2022 at 3:49 PM Tom Lane wrote: >> What I'm wondering about is how far the principle of read-only-ness >> ought to be expected to go. Should a read-only transaction fail >> to execute adminpack's pg_file_write(), for

Re: Unicode Variation Selector and Combining character

On 30.05.22 02:27, 荒井元成 wrote: I tried it on PostgreSQL 13. If you use the Unicode Variation Selector and Combining Character , the base character and the Variation selector will be 2 in length. Since it will be one character on the display, we expect it to be one in length. Please provide a

Re: Perform streaming logical transactions by background workers and parallel apply

On Wed, Jun 1, 2022 at 7:30 AM Masahiko Sawada wrote: > > On Tue, May 31, 2022 at 5:53 PM Amit Kapila wrote: > > > > On Mon, May 30, 2022 at 5:08 PM Amit Kapila wrote: > > > > > > On Mon, May 30, 2022 at 2:22 PM wangw.f...@fujitsu.com > > > wrote: > > > > > > > > Attach the new patches(only

Re: Ignore heap rewrites for materialized views in logical replication

On Tue, May 31, 2022 at 8:28 PM Euler Taveira wrote: > > On Tue, May 31, 2022, at 11:13 AM, Amit Kapila wrote: > > I think we don't need the retry logical to check error, a simple > wait_for_caught_up should be sufficient as we are doing in other > tests. See attached. I have slightly modified

Re: convert libpq uri-regress tests to tap test

On Tue, May 31, 2022 at 01:58:25PM +0900, Michael Paquier wrote: > Why don't you just use src/interfaces/ instead of adding a direct > path to libpq? So, this leads to something like the attached. Does that sound fine to you? -- Michael From 893ef90ce07084c4e4837205a805c590798ac115 Mon Sep 17

Re: Multi-Master Logical Replication

On Tue, May 31, 2022 at 7:36 PM Bruce Momjian wrote: > > On Wed, May 25, 2022 at 10:32:50PM -0400, Bruce Momjian wrote: > > On Wed, May 25, 2022 at 12:13:17PM +0530, Amit Kapila wrote: > > > > > > It helps with setting up logical replication among two or more nodes > > > (data flows both ways)

Re: [RFC] building postgres with meson -v8

On 06.05.22 23:27, Andres Freund wrote: I added pkgconfig since then. They're not exactly the same, but pretty close, except for one thing: Looks like some of the ecpg libraries really should link to some other ecpg libs? I think we're missing something there... That then leads to missing

Re: ParseTzFile doesn't FreeFile on error

At Tue, 31 May 2022 14:21:28 -0400, Tom Lane wrote in > Actually the problem *is* reachable, if you intentionally break the > already-active timezone abbreviation file: newly started sessions > produce file-leak warnings after failing to apply the setting. > I concede that's not a likely

Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)

At Wed, 01 Jun 2022 11:42:01 +0900 (JST), Kyotaro Horiguchi wrote in me> At Tue, 31 May 2022 16:10:05 -0400, Tom Lane wrote in me> tgl> Robert Haas writes: me> tgl> > Yeah, so when I created this stuff in the first place, I figured that me> tgl> > it wasn't a problem if we reserved relptr ==

Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)

At Tue, 31 May 2022 15:57:14 -0400, Robert Haas wrote in > 1. Using a relative pointer value other than 0 to represent a null > pointer. Andres suggested (Size) -1. I thought that relptr as a part of DSM so the use of offset=0 is somewhat illegal. But I like this. We can fix this by this

Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)

At Tue, 31 May 2022 16:10:05 -0400, Tom Lane wrote in tgl> Robert Haas writes: tgl> > Yeah, so when I created this stuff in the first place, I figured that tgl> > it wasn't a problem if we reserved relptr == 0 to mean a NULL pointer, tgl> > because you would never have a relative pointer

RE: Build-farm - intermittent error in 031_column_list.pl

On Thursday, May 26, 2022 11:37 AM Amit Kapila wrote: > On Wed, May 25, 2022 at 6:54 PM Tomas Vondra > wrote: > > > > On 5/25/22 13:26, Amit Kapila wrote: > > > On Wed, May 25, 2022 at 8:16 AM Kyotaro Horiguchi > > > wrote: > > >> > > >> It does "fix" the case of [1]. But AFAIS > > >>

Re: Perform streaming logical transactions by background workers and parallel apply

On Tue, May 31, 2022 at 5:53 PM Amit Kapila wrote: > > On Mon, May 30, 2022 at 5:08 PM Amit Kapila wrote: > > > > On Mon, May 30, 2022 at 2:22 PM wangw.f...@fujitsu.com > > wrote: > > > > > > Attach the new patches(only changed 0001 and 0002) > > > > > > > This patch allows the same replication

Re: PostgreSQL Limits: maximum number of columns in SELECT result

David Rowley writes: > Maybe "columns per result set" would have been a better title for consistency. I can't quite put my finger on why, but that wording seems odd to me, even though "columns per table" is natural enough. "In a" reads much better here IMO. Anyway, I see you committed it that

Re: PostgreSQL Limits: maximum number of columns in SELECT result

On Wed, 1 Jun 2022 at 12:42, Tom Lane wrote: > > David Rowley writes: > > I've adjusted the patch to use the wording proposed by Alvaro. See attached. > > Should we also change the adjacent item to "columns in a table", > for consistency of wording? Not sure though, because s/per/in a/ >

Re: PostgreSQL Limits: maximum number of columns in SELECT result

On 1/06/22 12:42, Tom Lane wrote: David Rowley writes: I've adjusted the patch to use the wording proposed by Alvaro. See attached. Should we also change the adjacent item to "columns in a table", for consistency of wording? Not sure though, because s/per/in a/ throughout the list doesn't

Re: PostgreSQL Limits: maximum number of columns in SELECT result

David Rowley writes: > I've adjusted the patch to use the wording proposed by Alvaro. See attached. Should we also change the adjacent item to "columns in a table", for consistency of wording? Not sure though, because s/per/in a/ throughout the list doesn't seem like it'd be an improvement.

Re: PostgreSQL Limits: maximum number of columns in SELECT result

On Tue, 31 May 2022 at 20:33, David Rowley wrote: > On Wed, 1 Jun 2022 at 07:08, Dave Cramer > wrote: > > > > On Tue, 31 May 2022 at 14:51, Tom Lane wrote: > >> > >> Alvaro Herrera writes: > >> > I think it's reasonable to have two adjacent rows in the table for > these > >> > two closely

Re: PostgreSQL Limits: maximum number of columns in SELECT result

On Wed, 1 Jun 2022 at 07:08, Dave Cramer wrote: > > On Tue, 31 May 2022 at 14:51, Tom Lane wrote: >> >> Alvaro Herrera writes: >> > I think it's reasonable to have two adjacent rows in the table for these >> > two closely related things, but rather than "columns per tuple" I would >> > label

Re: PostgreSQL Limits: maximum number of columns in SELECT result

On Tue, May 31, 2022 at 01:22:44PM -0400, Dave Cramer wrote: > > > On Tue, 31 May 2022 at 10:49, Tom Lane wrote: > > Dave Cramer writes: > > On Tue, 31 May 2022 at 10:16, Tom Lane wrote: > >> We've generally felt that the existing "columns per table" limit is > >> sufficient

Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)

Robert Haas writes: > On Tue, May 31, 2022 at 6:14 PM Tom Lane wrote: >> However, now that I've corrected that mistaken image ... I wonder if >> it could make sense to redefine relptr as self-relative? That ought >> to provide some notational savings since you'd only need to carry >> around the

Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)

On Tue, May 31, 2022 at 6:14 PM Tom Lane wrote: > However, now that I've corrected that mistaken image ... I wonder if > it could make sense to redefine relptr as self-relative? That ought > to provide some notational savings since you'd only need to carry > around the relptr's own address not

Re: [PATCH] Expose port->authn_id to extensions and triggers

v10 is rebased over latest; I've also added a PGDLLIMPORT to the new global. --Jacob From c8b3d2df4ce461fc65a27699419a54a5b7bb2001 Mon Sep 17 00:00:00 2001 From: Jacob Champion Date: Mon, 14 Feb 2022 08:10:53 -0800 Subject: [PATCH v10 1/2] Add API to retrieve authn_id from SQL The authn_id

Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)

Robert Haas writes: > Seems backwards to me. A relative pointer is supposed to point to > something inside some range of memory, like a DSM gment -- it can > never be legally used to point to anything outside that segment. So it > seems to me that you could perfectly legally point to the second

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Tue, May 31, 2022 at 1:43 PM Zhihong Yu wrote: > > > On Tue, May 31, 2022 at 12:43 PM Dmitry Koval > wrote: > >> >Just out of curiosity, why is SPLIT / MERGE support not included for >> >HASH partitions? Because sibling partitions can have a different >> >modulus, you should be able to

Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)

On Tue, May 31, 2022 at 5:52 PM Tom Lane wrote: > Thomas Munro writes: > > Count we make the relptrs 1-based, so that 0 is reserved as a sentinel > > that has the nice memset(0) property? > > Hm ... almost. A +1 offset would mean that zero is ambiguous with a > pointer to the byte just before

Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)

Thomas Munro writes: > Count we make the relptrs 1-based, so that 0 is reserved as a sentinel > that has the nice memset(0) property? Hm ... almost. A +1 offset would mean that zero is ambiguous with a pointer to the byte just before the relptr. Maybe that case never arises in practice, but

Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)

On Wed, Jun 1, 2022 at 9:09 AM Tom Lane wrote: > Robert Haas writes: > > Could it use something other than its own address as the base address? > > Hmm, maybe we could make something of that idea ... > > > One way to do this would be to put it at the *end* of the > > "Preallocated DSM" space,

Re: Prevent writes on large objects in read-only transactions

On Tue, May 31, 2022 at 3:49 PM Tom Lane wrote: > Yeah. Certainly we'd not want to back-patch this change, in case > anyone is relying on the current behavior ... but it's hard to argue > that it's not wrong. Agreed. > What I'm wondering about is how far the principle of read-only-ness > ought

Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)

Robert Haas writes: > Could it use something other than its own address as the base address? Hmm, maybe we could make something of that idea ... > One way to do this would be to put it at the *end* of the > "Preallocated DSM" space, rather than the beginning. ... but that way doesn't sound

Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)

On Tue, May 31, 2022 at 4:32 PM Thomas Munro wrote: > This FPM isn't in a DSM. (It happens to have DSMs *inside it*, > because I'm using it as a separate DSM allocator: instead of making > them with dsm_impl.c mechanisms, this one recycles space from the main > shmem area). I view FPM as a

Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)

On Tue, May 31, 2022 at 4:10 PM Tom Lane wrote: > Seems like that in itself is a a lousy idea. Either the code should > respect the abstraction, or it shouldn't be declaring the variable > as a relptr in the first place. Yep. I think it should be respecting the abstraction, but the 2016 version

Re: generate_series for timestamptz and time zone problem

=?UTF-8?Q?Przemys=c5=82aw_Sztoch?= writes: > |generate_series| ( /|start|/ |timestamp with time zone|, /|stop|/ > |timestamp with time zone|, /|step|/ |interval| ) > produces results depending on the timezone value set: That's intentional. If you don't want it, maybe you should be using

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Tue, May 31, 2022 at 12:43 PM Dmitry Koval wrote: > >Just out of curiosity, why is SPLIT / MERGE support not included for > >HASH partitions? Because sibling partitions can have a different > >modulus, you should be able to e.g. split a partition with (modulus, > >remainder) of (3, 1)

Logging query parmeters in auto_explain

Hi hackers, Inspired by a question on IRC, I noticed that while the core statement logging system gained the option to log statement parameters in PG 13, auto_explain was left out. Here's a patch that adds a corresponding auto_explain.log_parameter_max_length config setting, which controls the

Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)

On Wed, Jun 1, 2022 at 8:10 AM Tom Lane wrote: > Robert Haas writes: > > So we can fix this by: > > 1. Using a relative pointer value other than 0 to represent a null > > pointer. Andres suggested (Size) -1. > > 2. Not storing the free page manager for the DSM in the main shared > > memory

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

I didn't read the patch, but what lock level does that place on the partitioned table? Anything more than ACCESS SHARE? Current patch locks a partitioned table with ACCESS EXCLUSIVE lock. Unfortunately only this lock guarantees that other session can not work with partitions that are

Re: Assorted small doc patches

Anything I should be doing differently here to get a bit of reviewer/committer time on these? I'll add them to the commitfest for next month if needed but I'm seeing quick patches going in every week and the batch format done at the beginning of the month got processed through without issue.

Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)

Robert Haas writes: > Yeah, so when I created this stuff in the first place, I figured that > it wasn't a problem if we reserved relptr == 0 to mean a NULL pointer, > because you would never have a relative pointer pointing to the > beginning of a DSM, because it would probably always start with

Re: support for MERGE

On Wed, May 18, 2022 at 11:57:15AM -0500, Justin Pryzby wrote: > I prefer my original, but the most important thing is to include the link at > *somewhere*. Any other opinions ?

Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)

On Thu, May 19, 2022 at 11:00 PM Kyotaro Horiguchi wrote: > The path is taken only when a valid value is given to the > parameter. If we don't use preallocated dsm, it is initialized > elsewhere. In those cases the first bytes of the base address (the > second parameter of

generate_series for timestamptz and time zone problem

|generate_series| ( /|start|/ |timestamp with time zone|, /|stop|/ |timestamp with time zone|, /|step|/ |interval| ) produces results depending on the timezone value set: SET timezone = 'UTC'; SELECT ts, ts AT TIME ZONE 'UTC' FROM generate_series('2022-03-26 00:00:00+01'::timestamptz,

Re: Prevent writes on large objects in read-only transactions

Robert Haas writes: > On Sat, May 28, 2022 at 5:01 AM Michael Paquier wrote: >> Well, there is an actual risk to break applications that have worked >> until now for a behavior that has existed for years with zero >> complaints on the matter, so I would leave that alone. Saying that, I >> don't

Re: [RFC] building postgres with meson

Hi, On 2022-05-31 16:49:17 +0300, Aleksander Alekseev wrote: > I tried the branch on GitHub on MacOS Monterey 12.3.1 and Ubuntu 20.04 LTS. > I was going to test it against several third party extensions, but it looks > like > it is a bit early for this. On Ubuntu I got the following error: What

Re: PostgreSQL Limits: maximum number of columns in SELECT result

On Tue, 31 May 2022 at 14:51, Tom Lane wrote: > Alvaro Herrera writes: > > I think it's reasonable to have two adjacent rows in the table for these > > two closely related things, but rather than "columns per tuple" I would > > label the second one "columns in a result set". This is easy

Re: PostgreSQL Limits: maximum number of columns in SELECT result

Alvaro Herrera writes: > I think it's reasonable to have two adjacent rows in the table for these > two closely related things, but rather than "columns per tuple" I would > label the second one "columns in a result set". This is easy enough to > understand and to differentiate from the other

Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

On 5/31/22 16:36, Ranier Vilela wrote: > Em dom., 29 de mai. de 2022 às 17:10, Ranier Vilela > escreveu: > > Em dom., 29 de mai. de 2022 às 15:21, Andres Freund > mailto:and...@anarazel.de>> escreveu: > > On 2022-05-29 18:00:14 +0200, Tomas Vondra

Re: Prevent writes on large objects in read-only transactions

On Sat, May 28, 2022 at 5:01 AM Michael Paquier wrote: > Well, there is an actual risk to break applications that have worked > until now for a behavior that has existed for years with zero > complaints on the matter, so I would leave that alone. Saying that, I > don't really disagree with

Re: ParseTzFile doesn't FreeFile on error

Kyotaro Horiguchi writes: > At Mon, 30 May 2022 13:11:04 -0400, Tom Lane wrote in >> BTW, my first thought about it was "what if one of the callees throws >> elog(ERROR), eg palloc out-of-memory"? But I think that's all right >> since then we'll reach transaction abort cleanup, which won't

Re: PostgreSQL Limits: maximum number of columns in SELECT result

On 2022-May-31, Tom Lane wrote: > Detail is far from "free". Most readers are going to spend more time > wondering what the difference is between "columns per table" and "columns > per tuple", and which limit applies when, than they are going to save by > having the docs present them with two

Re: PostgreSQL Limits: maximum number of columns in SELECT result

On Tue, 31 May 2022 at 10:49, Tom Lane wrote: > Dave Cramer writes: > > On Tue, 31 May 2022 at 10:16, Tom Lane wrote: > >> We've generally felt that the existing "columns per table" limit is > >> sufficient detail here. > > > ISTM that adding detail is free whereas the readers time to figure

Re: PG15 beta1 sort performance regression due to Generation context change

On Tue, May 31, 2022 at 11:09 AM Tom Lane wrote: > Yeah, we don't have any hard data here. It could be that it's a win to > switch to a rule that chunks must present an offset (instead of a pointer) > back to a block header, which'd then be required to contain a link to the > actual context,

Re: PostgreSQL Limits: maximum number of columns in SELECT result

>ost readers are going to spend more time >wondering what the difference is between "columns per table" and "columns >per tuple" "tuple" is already mentioned 10 times on "limits" page, so adding "columns per tuple" is not really obscure. The comment could be like "for instance, max number of

Re: PG15 beta1 sort performance regression due to Generation context change

Robert Haas writes: > I don't want to take the position that we ought necessarily to commit > your patch, because I don't really have a clear sense of what the wins > and losses actually are. Yeah, we don't have any hard data here. It could be that it's a win to switch to a rule that chunks

Re: SQL/JSON functions vs. ECPG vs. STRING as a reserved word

On 2022-05-29 Su 16:19, Tom Lane wrote: > More generally, I feel like we have a process problem: there needs to > be a higher bar to adding new fully- or even partially-reserved words. > I might've missed it, but I don't recall that there was any discussion > of the compatibility implications of

Re: Ignore heap rewrites for materialized views in logical replication

On Tue, May 31, 2022, at 11:13 AM, Amit Kapila wrote: > I think we don't need the retry logical to check error, a simple > wait_for_caught_up should be sufficient as we are doing in other > tests. See attached. I have slightly modified the commit message as > well. Kindly let me know what you

Re: PG15 beta1 sort performance regression due to Generation context change

On Fri, May 27, 2022 at 10:52 AM Tom Lane wrote: > Given David's results in the preceding message, I don't think I am. > A scheme like this would add more arithmetic and at least one more > indirection to GetMemoryChunkContext(), and we already know that > adding even a test-and-branch there has

Re: PostgreSQL Limits: maximum number of columns in SELECT result

Dave Cramer writes: > On Tue, 31 May 2022 at 10:16, Tom Lane wrote: >> We've generally felt that the existing "columns per table" limit is >> sufficient detail here. > ISTM that adding detail is free whereas the readers time to figure out why > and where this number came from is not. Detail is

Re: PostgreSQL Limits: maximum number of columns in SELECT result

On Tue, 31 May 2022 at 10:16, Tom Lane wrote: > Amul Sul writes: > > On Tue, May 31, 2022 at 12:46 PM Vladimir Sitnikov > > wrote: > >> I suggest that the limit of "1664 columns per tuple" (or whatever is > the right term) should be added > >> to the list at

Re: adding status for COPY progress report

On Tue, May 31, 2022 at 1:20 AM Amit Langote wrote: > Hi, > > On Thu, May 26, 2022 at 11:35 AM Zhihong Yu wrote: > >> The changes in pgstat_progress_end_command() and > >> pg_stat_get_progress_info() update st_progress_command_target > >> depending on the command type involved, breaking the

Re: PostgreSQL Limits: maximum number of columns in SELECT result

Amul Sul writes: > On Tue, May 31, 2022 at 12:46 PM Vladimir Sitnikov > wrote: >> I suggest that the limit of "1664 columns per tuple" (or whatever is the >> right term) should be added >> to the list at https://www.postgresql.org/docs/current/limits.html e.g. >> after "columns per table".

Re: Ignore heap rewrites for materialized views in logical replication

On Tue, May 31, 2022 at 6:27 AM Euler Taveira wrote: > > On Sat, May 28, 2022, at 7:07 AM, Amit Kapila wrote: > > I agree with your analysis and the fix looks correct to me. > > Thanks for checking. > > Instead of waiting for an error, we can try to insert into a new table > created by the test

Re: PostgreSQL Limits: maximum number of columns in SELECT result

> > > > > On Tue, 31 May 2022 at 09:56, Amul Sul wrote: > >> On Tue, May 31, 2022 at 12:46 PM Vladimir Sitnikov >> wrote: >> > >> > Hi, >> > >> > Today I hit "ERROR: target lists can have at most 1664 entries", and I >> was surprised the limit was not documented. >> > >> > I suggest that the

Re: Multi-Master Logical Replication

On Wed, May 25, 2022 at 10:32:50PM -0400, Bruce Momjian wrote: > On Wed, May 25, 2022 at 12:13:17PM +0530, Amit Kapila wrote: > > > You still have not answered my question above. "Without these features, > > > what workload would this help with?" You have only explained how the > > > patch would

Re: PostgreSQL Limits: maximum number of columns in SELECT result

On Tue, 31 May 2022 at 09:56, Amul Sul wrote: > On Tue, May 31, 2022 at 12:46 PM Vladimir Sitnikov > wrote: > > > > Hi, > > > > Today I hit "ERROR: target lists can have at most 1664 entries", and I > was surprised the limit was not documented. > > > > I suggest that the limit of "1664 columns

Re: PostgreSQL Limits: maximum number of columns in SELECT result

On Tue, May 31, 2022 at 12:46 PM Vladimir Sitnikov wrote: > > Hi, > > Today I hit "ERROR: target lists can have at most 1664 entries", and I was > surprised the limit was not documented. > > I suggest that the limit of "1664 columns per tuple" (or whatever is the > right term) should be added >

Re: [RFC] building postgres with meson

Hi Andres, > Not having a ninja backend etc didn't strike me as great either - the builds > with scons I've done weren't fast at all. I must admit, personally I never used Scons, I just know that it was considered (an / the only?) alternative to CMake for many years. The Scons 4.3.0 release

Re: Shmem queue is not flushed if receiver is not yet attached

On Mon, May 30, 2022 at 3:06 AM Pavan Deolasee wrote: >> I think that this patch is basically correct, except that it's not >> correct to set mqh_counterparty_attached when receiver is still NULL. >> Here's a v2 where I've attempted to correct that while preserving the >> essence of your proposed

Re: "ERROR: latch already owned" on gharial

On Tue, May 31, 2022 at 8:20 AM Robert Haas wrote: > On Mon, May 30, 2022 at 8:31 PM Thomas Munro wrote: > > On Sat, May 28, 2022 at 1:56 AM Robert Haas wrote: > > > What I'm inclined to do is get gharial and anole removed from the > > > buildfarm. anole was set up by Heikki in 2011. I don't

Re: doc: CREATE FOREIGN TABLE .. PARTITION OF .. DEFAULT

On Mon, May 30, 2022 at 2:27 AM Etsuro Fujita wrote: > On Fri, May 27, 2022 at 9:22 PM Amit Langote wrote: > > On Fri, May 27, 2022 at 7:15 PM Etsuro Fujita > > wrote: > > > Attached is a patch for that. > > > I think we should also rewrite the description to match the CREATE > > TABLE's

Re: Allowing REINDEX to have an optional name

On 2022-May-31, Michael Paquier wrote: > The case with CONCURRENTLY is different though: the option will never > work on system catalogs so we have to skip them. Echoing with others > on this thread, I don't think that we should introduce a different > behavior on what's basically the same

Re: "ERROR: latch already owned" on gharial

On Mon, May 30, 2022 at 8:31 PM Thomas Munro wrote: > On Sat, May 28, 2022 at 1:56 AM Robert Haas wrote: > > What I'm inclined to do is get gharial and anole removed from the > > buildfarm. anole was set up by Heikki in 2011. I don't know when > > gharial was set up, or by whom. I don't think

Re: Allowing REINDEX to have an optional name

On Tue, May 31, 2022 at 11:04:58AM +0200, Bernd Helmle wrote: > And we already have a situation where this already happens with REINDEX > DATABASE: if you use CONCURRENTLY, it skips system catalogs already and > prints a warning. In both cases there are good technical reasons to > skip catalog

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Tue, 2022-05-31 at 12:32 +0300, Dmitry Koval wrote: > There are not many commands in PostgreSQL for working with partitioned > tables. This is an obstacle to their widespread use. > Adding SPLIT PARTITION/MERGE PARTITIONS operations can make easier to > use partitioned tables in PostgreSQL. >

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Tue, 31 May 2022 at 11:33, Dmitry Koval wrote: > > Hi, hackers! > > There are not many commands in PostgreSQL for working with partitioned > tables. This is an obstacle to their widespread use. > Adding SPLIT PARTITION/MERGE PARTITIONS operations can make easier to > use partitioned tables in

Re: Remove useless tests about TRUNCATE on foreign table

On Tue, 31 May 2022 09:49:40 +0900 Michael Paquier wrote: > On Mon, May 30, 2022 at 05:08:10PM +0900, Michael Paquier wrote: > > Partitions have also some coverage as far as I can see, so I agree > > that it makes little sense to keep the tests you are removing here. > > And done as of 0efa513.

Re: Allowing REINDEX to have an optional name

Am Dienstag, dem 10.05.2022 um 15:00 +0100 schrieb Simon Riggs: [...] > > > I think REINDEX DATABASE reindexing the current database is a good > > usability improvement in itself. But skipping the shared catalogs > > needs an explicity syntax. Not sure how feasible it is but > > something > >

Re: Perform streaming logical transactions by background workers and parallel apply

On Mon, May 30, 2022 at 5:08 PM Amit Kapila wrote: > > On Mon, May 30, 2022 at 2:22 PM wangw.f...@fujitsu.com > wrote: > > > > Attach the new patches(only changed 0001 and 0002) > > > This patch allows the same replication origin to be used by the main apply worker and the bgworker that uses it

Re: Allowing REINDEX to have an optional name

Am Freitag, dem 27.05.2022 um 19:08 + schrieb Cary Huang: [...] > The patch applies and tests fine and I think this patch has good > intentions to prevent the default behavior of REINDEX DATABASE to > cause a deadlock. However, I am not in favor of simply omitting the > database name after

Re: Fix spelling mistake in README file

On Tue, May 31, 2022 at 1:58 PM Peter Smith wrote: > > PSA a patch to fix a spelling mistake that I happened upon... > LGTM. I'll push this in some time. Thanks! -- With Regards, Amit Kapila.

Fix spelling mistake in README file

PSA a patch to fix a spelling mistake that I happened upon... -- Kind Regards, Peter Smith. Fujitsu Australia v1-0001-Fix-typo.patch Description: Binary data

Re: adding status for COPY progress report

Hi, On Thu, May 26, 2022 at 11:35 AM Zhihong Yu wrote: >> The changes in pgstat_progress_end_command() and >> pg_stat_get_progress_info() update st_progress_command_target >> depending on the command type involved, breaking the existing contract >> of those routines, particularly the fact that

Re: pg_upgrade test writes to source directory

On Sat, May 28, 2022 at 04:14:01PM -0400, Tom Lane wrote: > Yeah, I'd noticed the obsoleted comments too, but not bothered to complain > since that was just WIP and not an officially proposed patch. I'll be > happy to review if you want to put up a full patch. Well, here is a formal patch set,

PostgreSQL Limits: maximum number of columns in SELECT result

Hi, Today I hit "ERROR: target lists can have at most 1664 entries", and I was surprised the limit was not documented. I suggest that the limit of "1664 columns per tuple" (or whatever is the right term) should be added to the list at https://www.postgresql.org/docs/current/limits.html e.g.

Re: Skipping schema changes in publication

Here are my review comments for patch v7-0002. == 1. doc/src/sgml/logical-replication.sgml @@ -1167,8 +1167,9 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER To add tables to a publication, the user must have ownership rights on the table. To