Re: add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?)

On Tue, Nov 14, 2023 at 4:50 AM Peter Smith wrote: > > Here are some review comments for patch v13-0001. Thanks. > == > doc/src/sgml/config.sgml > > 1. > > Should that also mention about walsender? > > e.g. > "and slot acquisition/release" ==> "and walsender > slot acquisition/release"

Re: Why do indexes and sorts use the database collation?

On Mon, 2023-11-13 at 22:36 +0100, Tomas Vondra wrote: > Perhaps we could allow the PK index to have a different collation, say > by supporting something like this: > >   ALTER TABLE distributors ADD PRIMARY KEY (dist_id COLLATE "C"); An appealing idea! While at it, we could add an INCLUDE

Re: Fix output of zero privileges in psql

On Mon, 2023-11-13 at 15:49 -0500, Tom Lane wrote: > Patch pushed with minor adjustments, mainly rewriting some comments. Thank you! Yours, Laurenz Albe

Re: Array initialisation notation in syscache.c

On Thu, Sep 21, 2023 at 8:19 PM Peter Eisentraut wrote: > On 31.03.23 04:16, Thomas Munro wrote: > > From the light relief department, here is some more variadic macrology: > > > > - tp = SearchSysCache1(TSPARSEROID, ObjectIdGetDatum(prsId)); > > + tp = SearchSysCache(TSPARSEROID,

Re: trying again to get incremental backup

On Tue, Nov 14, 2023 at 12:52 AM Robert Haas wrote: > > On Fri, Nov 10, 2023 at 6:27 AM Dilip Kumar wrote: > > - I think 0001 looks good improvement irrespective of the patch series. > > OK, perhaps that can be independently committed, then, if nobody objects. > > Thanks for the review; I've

typo in fallback implementation for pg_atomic_test_set_flag()

I noticed that the fallback pg_atomic_test_set_flag_impl() implementation that uses atomic-exchange is giving pg_atomic_exchange_u32_impl() an extra argument. This appears to be copy/pasted from the atomic-compare-exchange version a few lines down. It looks like it's been this way since this

Re: pg_upgrade and logical replication[

On Tue, Nov 14, 2023 at 5:52 AM Michael Paquier wrote: > > On Mon, Nov 13, 2023 at 04:02:27PM +0530, Amit Kapila wrote: > > On Mon, Nov 13, 2023 at 1:52 PM Michael Paquier wrote: > >> It seems to me that INIT cannot be relied on for a similar reason. > >> This state would be set for a new

Re: Is this a problem in GenericXLogFinish()?

On Mon, Nov 13, 2023 at 10:51 PM Robert Haas wrote: > > On Mon, Nov 13, 2023 at 12:47 AM Hayato Kuroda (Fujitsu) > wrote: > > Moved. > > I see that this patch was committed, but I'm not very convinced that > the approach is correct. The comment says this: > > + /* > +* A

Re: Re: How to solve the problem of one backend process crashing and causing other processes to restart?

On Mon, Nov 13, 2023 at 3:14 AM yuansong wrote: > Enhancing the overall fault tolerance of the entire system for this > feature is quite important. No one can avoid bugs, and I don't believe that > this approach is a more advanced one. It might be worth considering adding > it to the roadmap so

Re: Why do indexes and sorts use the database collation?

On Mon, 2023-11-13 at 22:36 +0100, Tomas Vondra wrote: > Yeah. I don't quite agree with the initial argument that not > specifying > the collation explicitly in CREATE TABLE or a query means the user > does > not care about the collation. I didn't argue that the user doesn't care about collation

Re: building with meson on windows with ssl

Hi, On 2023-11-12 11:41:15 -0500, Dave Cramer wrote: > On Sun, 12 Nov 2023 at 07:57, Dave Cramer wrote: > > I am getting the following error > > building on HEAD > > > > Library crypto found: YES > > Checking for function "CRYPTO_new_ex_data" with dependencies -lssl, > > -lcrypto: NO > > > > So

Re: pg_upgrade and logical replication

On Mon, 13 Nov 2023 at 13:52, Michael Paquier wrote: > > On Fri, Nov 10, 2023 at 07:26:18PM +0530, vignesh C wrote: > > I did testing in the same lines that you mentioned. Apart from that I > > also reviewed the design where it was using the old subscription id > > like in case of table sync

回复: Re:Re: How to solve the problem of one backend process crashing and causing other processes to restart?

Hi yuansong there is connnection pool path (https://commitfest.postgresql.org/34/3043/) ,but it has been dormant for few years,You can check this patch to get what you want to need 发件人: yuansong 发送时间: 2023年11月13日 17:13 收件人: Laurenz Albe 抄送:

Re: mxid_age() and age(xid) appear undocumented

Hi, On 2023-11-13 17:00:43 -0800, Peter Geoghegan wrote: > On Mon, Nov 13, 2023 at 4:43 PM Bruce Momjian wrote: > > I looked into this and all the 4-byte xid functions are marked as > > deprecated for the 8-byte variants. I don't think documenting 4-byte > > mxid_age() and age(xid) makes sense

Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM

Hi, On 2023-11-13 17:13:32 -0500, Melanie Plageman wrote: > I noticed that in lazy_scan_heap(), when there are no indexes on the > table being vacuumed, we don't release the lock on the heap page buffer > before vacuuming the freespace map. Other call sites of > FreeSpaceMapVacuumRange() hold no

Re: mxid_age() and age(xid) appear undocumented

On Mon, Nov 13, 2023 at 5:01 PM Peter Geoghegan wrote: > > On Mon, Nov 13, 2023 at 4:43 PM Bruce Momjian wrote: > > I looked into this and all the 4-byte xid functions are marked as > > deprecated for the 8-byte variants. I don't think documenting 4-byte > > mxid_age() and age(xid) makes sense

Re: mxid_age() and age(xid) appear undocumented

On Mon, Nov 13, 2023 at 4:43 PM Bruce Momjian wrote: > I looked into this and all the 4-byte xid functions are marked as > deprecated for the 8-byte variants. I don't think documenting 4-byte > mxid_age() and age(xid) makes sense anymore, and I don't see their value > enough to create 8-byte

Re: Add new option 'all' to pg_stat_reset_shared()

On Mon, Nov 13, 2023 at 07:31:41PM +0900, Michael Paquier wrote: > On Mon, Nov 13, 2023 at 02:07:21PM +0530, Bharath Rupireddy wrote: >> Modified the docs for pg_stat_reset_slru to match with that of >> pg_stat_reset_shared. PSA v2 patch. > > That feels consistent. Thanks. And applied this one.

Re: Lifetime of commit timestamps

On Fri, Jun 22, 2018 at 05:21:32PM +0900, Kyotaro HORIGUCHI wrote: > Hello. > > I don't find any description in the documentation about the > guaranteed lifetime of commit timestamps. I think they are > preserved until corresponding xid goes beyond the freeze horizen, > even though they are

Re: mxid_age() and age(xid) appear undocumented

On Thu, Jul 5, 2018 at 01:30:22PM -0700, Peter Geoghegan wrote: > On Thu, Jul 5, 2018 at 12:36 PM, Robert Haas wrote: > > On Sun, Jul 1, 2018 at 11:18 PM, David Rowley > > wrote: > >> I see d692308cf494f6126 mentions mxid_age() in passing, but there > >> appears to be no formal definition of

Re: pgsql: doc: fix wording describing the checkpoint_flush_after GUC

Hi, On 2023-11-13 12:31:42 +0100, Alvaro Herrera wrote: > On 2023-Nov-09, Bruce Momjian wrote: > > > doc: fix wording describing the checkpoint_flush_after GUC > > Hmm. Is this new wording really more clear than the original wording? > I agree the original may not have been the most simple, but

Re: pg_upgrade and logical replication[

On Mon, Nov 13, 2023 at 04:02:27PM +0530, Amit Kapila wrote: > On Mon, Nov 13, 2023 at 1:52 PM Michael Paquier wrote: >> It seems to me that INIT cannot be relied on for a similar reason. >> This state would be set for a new relation in >> LogicalRepSyncTableStart(), and the relation would still

Re: Requiring recovery.signal or standby.signal when recovering with a backup_label

Hi, On 2023-11-14 09:13:44 +0900, Michael Paquier wrote: > On Mon, Nov 13, 2023 at 03:41:44PM -0800, Andres Freund wrote: > > On 2023-11-09 12:16:52 +0900, Michael Paquier wrote: > >> On Thu, Nov 09, 2023 at 12:04:19PM +0900, Michael Paquier wrote: > >> > Sure, sorry for the confusion. By "we'd

Re: Requiring recovery.signal or standby.signal when recovering with a backup_label

On Mon, Nov 13, 2023 at 03:41:44PM -0800, Andres Freund wrote: > On 2023-11-09 12:16:52 +0900, Michael Paquier wrote: >> On Thu, Nov 09, 2023 at 12:04:19PM +0900, Michael Paquier wrote: >> > Sure, sorry for the confusion. By "we'd do nothing", I mean precirely >> > "to take no specific action

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Mon, Nov 13, 2023 at 5:59 PM Peter Geoghegan wrote: > > On Mon, Nov 13, 2023 at 2:29 PM Melanie Plageman > wrote: > > I think it also makes it clear that we should update the VM in > > lazy_scan_prune(). All callers of lazy_scan_prune() will now consider > > updating the VM after returning.

Re: [PATCH] pgbench log file headers

Hi, On 2023-11-13 11:55:07 -0600, Adam Hendel wrote: > Currently, pgbench will log individual transactions to a logfile when the > `--log` parameter flag is provided. The logfile, however, does not include > column header. It has become a fairly standard expectation of users to have > column

Re: Why do indexes and sorts use the database collation?

On Mon, 2023-11-13 at 10:02 -0800, Andres Freund wrote: > > Inequalities and ORDER BYs can't benefit from an index with a > > different > > collation, but lots of indexes don't need that. > > But we don't know whether the index is used for that. That will be hard to quantify, but perhaps we can

Re: Requiring recovery.signal or standby.signal when recovering with a backup_label

Hi, On 2023-11-09 12:16:52 +0900, Michael Paquier wrote: > On Thu, Nov 09, 2023 at 12:04:19PM +0900, Michael Paquier wrote: > > Sure, sorry for the confusion. By "we'd do nothing", I mean precirely > > "to take no specific action related to archive recovery and recovery > > parameters at the end

Re: Why do indexes and sorts use the database collation?

Hi, On 2023-11-14 00:02:13 +0100, Tomas Vondra wrote: > On 11/13/23 23:12, Andres Freund wrote: > > On 2023-11-13 22:36:24 +0100, Tomas Vondra wrote: > >> ISTM it's about how complex the rules implemented by the collation are, > >> so I agree the cost should be a feature of collations not

Re: archive modules loose ends

Hi, On 2023-11-13 16:42:31 -0600, Nathan Bossart wrote: > There seems to be no interest in this patch, so I plan to withdraw it from > the commitfest system by the end of the month unless such interest > materializes. I think it might just have arrived too shortly before the feature freeze to be

Re: Some deleted GUCs are still referred to

On Thu, Nov 9, 2023 at 8:12 PM Daniel Gustafsson wrote: > > > On 9 Nov 2023, at 00:51, Peter Smith wrote: > > > > Hi, > > > > I happened to notice that some GUC names "max_fsm_pages" and > > "max_fsm_relations" are still mentioned in these translation files > > (from the REL_16_1 source zip) > >

Re: add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?)

Here are some review comments for patch v13-0001. == doc/src/sgml/config.sgml 1. -Causes each replication command to be logged in the server log. -See for more information about -replication command. The default value is off. -Only superusers and

Re: Why do indexes and sorts use the database collation?

On 11/13/23 23:12, Andres Freund wrote: > Hi, > > On 2023-11-13 22:36:24 +0100, Tomas Vondra wrote: >> I don't think we can just arbitrarily override the default because we >> happen to think "C" is going to be faster. If we could prove that using >> "C" is going to produce exactly the same

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Mon, Nov 13, 2023 at 2:29 PM Melanie Plageman wrote: > I think it also makes it clear that we should update the VM in > lazy_scan_prune(). All callers of lazy_scan_prune() will now consider > updating the VM after returning. And most of the state communicated back > to lazy_scan_heap() from

Re: archive modules loose ends

There seems to be no interest in this patch, so I plan to withdraw it from the commitfest system by the end of the month unless such interest materializes. On Fri, Feb 17, 2023 at 01:56:24PM -0800, Nathan Bossart wrote: > The first one is the requirement that archive module authors create their >

Emit fewer vacuum records by reaping removable tuples during pruning

Hi, When there are no indexes on the relation, we can set would-be dead items LP_UNUSED and remove them during pruning. This saves us a vacuum WAL record, reducing WAL volume (and time spent writing and syncing WAL). See this example: drop table if exists foo; create table foo(a int) with

lazy_scan_heap() should release lock on buffer before vacuuming FSM

Hi, I noticed that in lazy_scan_heap(), when there are no indexes on the table being vacuumed, we don't release the lock on the heap page buffer before vacuuming the freespace map. Other call sites of FreeSpaceMapVacuumRange() hold no such lock. It seems like a waste to hold a lock we don't need.

Re: Why do indexes and sorts use the database collation?

Hi, On 2023-11-13 22:36:24 +0100, Tomas Vondra wrote: > I don't think we can just arbitrarily override the default because we > happen to think "C" is going to be faster. If we could prove that using > "C" is going to produce exactly the same results as for the implicit > collation (for a given

Re: [PATCHES] Post-special page storage TDE support

Greetings, On Mon, Nov 13, 2023 at 16:53 David Christensen < david.christen...@crunchydata.com> wrote: > On Mon, Nov 13, 2023 at 2:52 PM Andres Freund wrote: > >> >> > This scheme would open up space per page that would now be available for >> > plenty of other things; the encoding in the

Re: [PATCHES] Post-special page storage TDE support

On Mon, Nov 13, 2023 at 2:52 PM Andres Freund wrote: > > > This scheme would open up space per page that would now be available for > > plenty of other things; the encoding in the header and the corresponding > > available space in the footer would seem to open up quite a few options > > now,

[DOC] Add detail regarding resource consumption wrt max_connections

The documentation for max_connections does not mention that just by having a higher value for max_connections, PostgreSQL will use more resources. While working with different customers, I noticed that several of them set max_connections to very high numbers, even though they never expected to

Re: Why do indexes and sorts use the database collation?

On 11/13/23 19:02, Andres Freund wrote: > Hi, > > On 2023-11-11 23:19:55 -0800, Jeff Davis wrote: >> On Fri, 2023-11-10 at 17:19 -0800, Andres Freund wrote: >>> I guess you are arguing that the user didn't intend to create an >>> index here? >> >> No, obviously the user should expect an index

Re: "box" type description

On Thu, Nov 2, 2023 at 04:12:57PM -0400, Bruce Momjian wrote: > > pg_brin_bloom_summary, pg_brin_minmax_multi_summary, pg_mcv_list and many: > > > > I'm uncertain whether these types, which lack an input syntax (but > > have an output format), qualify as pseudo-types. Nevertheless, I > >

Re: [PATCHES] Post-special page storage TDE support

Hi, On 2023-11-13 14:37:47 -0600, David Christensen wrote: > On Mon, Nov 13, 2023 at 2:27 PM Andres Freund wrote: > > On 2023-11-08 18:47:56 -0800, Peter Geoghegan wrote: > > > On Wed, Nov 8, 2023 at 6:04 AM Stephen Frost wrote: > > > > In conversations with folks (my memory specifically is a

Re: Fix output of zero privileges in psql

"David G. Johnston" writes: > On Mon, Nov 13, 2023 at 12:36 PM Laurenz Albe > wrote: >> On Mon, 2023-11-13 at 11:27 +0100, Erik Wienhold wrote: >>> On 2023-11-09 20:19 +0100, Tom Lane wrote: So, just to clarify, we're settling on your v4 from [1]? >>> Yes from my side. >> +1 > +0.5 for

Re: Split index and table statistics into different types of stats

Hi, On 2023-11-13 09:26:56 +0100, Drouvot, Bertrand wrote: > --- a/src/backend/storage/buffer/bufmgr.c > +++ b/src/backend/storage/buffer/bufmgr.c > @@ -799,11 +799,19 @@ ReadBufferExtended(Relation reln, ForkNumber forkNum, > BlockNumber blockNum, >* Read the buffer, and update pgstat

Re: [PATCHES] Post-special page storage TDE support

On Mon, Nov 13, 2023 at 2:27 PM Andres Freund wrote: > Hi, > > On 2023-11-08 18:47:56 -0800, Peter Geoghegan wrote: > > On Wed, Nov 8, 2023 at 6:04 AM Stephen Frost wrote: > > > In conversations with folks (my memory specifically is a discussion > with > > > Peter G, added to CC, and my

Re: [PATCHES] Post-special page storage TDE support

Hi, On 2023-11-08 18:47:56 -0800, Peter Geoghegan wrote: > On Wed, Nov 8, 2023 at 6:04 AM Stephen Frost wrote: > > In conversations with folks (my memory specifically is a discussion with > > Peter G, added to CC, and my apologies to Peter if I'm misremembering) > > there was a pretty strong

Re: should check collations when creating partitioned index

On Mon, 2023-11-13 at 10:24 +0100, Peter Eisentraut wrote: > * If this table is partitioned and we're creating a unique index, > primary > * key, or exclusion constraint, make sure that the partition key is a > * subset of the index's columns. Otherwise it would be possible to

Re: [PATCHES] Post-special page storage TDE support

On Tue, Nov 7, 2023 at 6:20 PM Andres Freund wrote: > Hi, > > On 2023-05-09 17:08:26 -0500, David Christensen wrote: > > From 965309ea3517fa734c4bc89c144e2031cdf6c0c3 Mon Sep 17 00:00:00 2001 > > From: David Christensen > > Date: Tue, 9 May 2023 16:56:15 -0500 > > Subject: [PATCH v4 1/3] Add

Re: POC, WIP: OR-clause support for indexes

Hi, all! These days I was porting a patch for converting or expressions to ANY to the choose_bitmap_and function. Unfortunately, it is not possible to transfer the conversion there, since expressions are processed one by one, as far as I saw. Therefore, I tried to make the conversion earlier

Re: Version 14/15 documentation Section "Alter Default Privileges"

On Mon, Nov 13, 2023 at 08:33:33PM +0100, Laurenz Albe wrote: > On Mon, 2023-11-13 at 14:28 -0500, Bruce Momjian wrote: > > Patch applied back to PG 16. > > Great thanks! > > I am hopeful that that will reduce people's confusion about this feature. Agreed! -- Bruce Momjian

Re: COPY TO (FREEZE)?

On Mon, Nov 13, 2023 at 01:17:32PM -0500, Tom Lane wrote: > Bruce Momjian writes: > > Patch applied to master. > > The buildfarm is quite unhappy with you. Wow, I never suspeced that, fixed. -- Bruce Momjian https://momjian.us EDB

Re: Fix output of zero privileges in psql

On Mon, Nov 13, 2023 at 12:36 PM Laurenz Albe wrote: > On Mon, 2023-11-13 at 11:27 +0100, Erik Wienhold wrote: > > On 2023-11-09 20:19 +0100, Tom Lane wrote: > > > Laurenz Albe writes: > > > > Thanks for the feedback. I'll set the patch to "ready for > committer" then. > > > > > > So, just to

Re: Fix output of zero privileges in psql

On Mon, 2023-11-13 at 11:27 +0100, Erik Wienhold wrote: > On 2023-11-09 20:19 +0100, Tom Lane wrote: > > Laurenz Albe writes: > > > Thanks for the feedback. I'll set the patch to "ready for committer" > > > then. > > > > So, just to clarify, we're settling on your v4 from [1]? > > > > [1] >

Re: Version 14/15 documentation Section "Alter Default Privileges"

On Mon, 2023-11-13 at 14:28 -0500, Bruce Momjian wrote: > Patch applied back to PG 16. Great thanks! I am hopeful that that will reduce people's confusion about this feature. Yours, Laurenz Albe

Re: Bug: RLS policy FOR SELECT is used to check new rows

On Mon, 2023-11-13 at 12:57 -0500, Robert Haas wrote: > On Fri, Nov 10, 2023 at 7:43 AM Laurenz Albe wrote: > > So, from my perspective, we should never have let FOR SELECT policies > > mess with an UPDATE. But I am too late for that; such a change would > > be way too invasive now. So I'd like

Re: Version 14/15 documentation Section "Alter Default Privileges"

On Wed, Nov 8, 2023 at 01:12:24PM +0100, Laurenz Albe wrote: > > I find the above sentence odd. What is its purpose? > > I cannot count how many times I have seen the complaint "I have run ALTER > DEFAULT > PRIVILEGES, and now when some other user creates a table, the permissions are >

Re: trying again to get incremental backup

On Fri, Nov 10, 2023 at 6:27 AM Dilip Kumar wrote: > - I think 0001 looks good improvement irrespective of the patch series. OK, perhaps that can be independently committed, then, if nobody objects. Thanks for the review; I've fixed a bunch of things that you mentioned. I'll just comment on the

Re: [PATCH] pgbench log file headers

Hi Adam. Column headers in pgbench log files seem helpful. Besides programs, it seems helpful for humans to understand the column data as well. I was able to apply your patch and verify that the headers are added to the log file: andy@MacBook-Air-4 ~/P/postgres (master)> rm pgbench_log.*

Re: pg_walfile_name_offset can return inconsistent values

On Mon, Nov 13, 2023 at 09:49:53AM -0800, Andres Freund wrote: > Hi, > > On 2023-11-13 12:14:57 -0500, Bruce Momjian wrote: > > +SELECT * > > +FROM (values ('0/16ff'), ('0/1700'), ('0/1701')) as t(lsn), > > + LATERAL pg_walfile_name_offset(lsn::pg_lsn), > > + LATERAL

Re: Question about non-blocking mode in libpq

On Mon, Nov 13, 2023 at 01:01:32PM -0500, Bruce Momjian wrote: > On Wed, Nov 1, 2023 at 08:47:33AM -0400, Bruce Momjian wrote: > > On Tue, Oct 31, 2023 at 10:16:07PM -0400, Tom Lane wrote: > > > Bruce Momjian writes: > > > > On Tue, Oct 31, 2023 at 09:11:06PM -0400, Tom Lane wrote: > > > >> What

retire MemoryContextResetAndDeleteChildren backwards compatibility macro

I just found myself researching the difference between MemoryContextReset() and MemoryContextResetAndDeleteChildren(), and it turns out that as of commit eaa5808 (2015), there is none. MemoryContextResetAndDeleteChildren() is just a backwards compatibility macro for MemoryContextReset(). I found

Re: Cleaning up array_in()

I wrote: > Heikki Linnakangas writes: >> 2. This was the same before this patch, but: >> postgres=# select '{{1}}'::int[]; >> ERROR: number of array dimensions (7) exceeds the maximum allowed (6) >> LINE 1: select '{{1}}'::int[]; >> ^ >> The error message isn't

Re: COPY TO (FREEZE)?

Bruce Momjian writes: > Patch applied to master. The buildfarm is quite unhappy with you. regards, tom lane

Re: Why do indexes and sorts use the database collation?

Hi, On 2023-11-11 23:19:55 -0800, Jeff Davis wrote: > On Fri, 2023-11-10 at 17:19 -0800, Andres Freund wrote: > > I guess you are arguing that the user didn't intend to create an > > index here? > > No, obviously the user should expect an index when a primary key is > created. But that doesn't

Re: Question about non-blocking mode in libpq

On Wed, Nov 1, 2023 at 08:47:33AM -0400, Bruce Momjian wrote: > On Tue, Oct 31, 2023 at 10:16:07PM -0400, Tom Lane wrote: > > Bruce Momjian writes: > > > On Tue, Oct 31, 2023 at 09:11:06PM -0400, Tom Lane wrote: > > >> What I'm objecting to is removal of the bit about "if they need to be > > >>

Re: Bug: RLS policy FOR SELECT is used to check new rows

On Fri, Nov 10, 2023 at 7:43 AM Laurenz Albe wrote: > So, from my perspective, we should never have let FOR SELECT policies > mess with an UPDATE. But I am too late for that; such a change would > be way too invasive now. So I'd like to introduce a "back door" by > creating a FOR SELECT policy

[PATCH] pgbench log file headers

Hello Hackers! Currently, pgbench will log individual transactions to a logfile when the `--log` parameter flag is provided. The logfile, however, does not include column header. It has become a fairly standard expectation of users to have column headers present in flat files. Without the header

Re: COPY TO (FREEZE)?

On Mon, Oct 30, 2023 at 03:55:21PM -0400, Bruce Momjian wrote: > On Mon, Oct 30, 2023 at 02:29:05PM -0400, Tom Lane wrote: > > Bruce Momjian writes: > > > That is a good point. I reviewed more of the messages and added > > > capitalization where appropriate, patch attached. > > > > This is

Re: pg_walfile_name_offset can return inconsistent values

Hi, On 2023-11-13 12:14:57 -0500, Bruce Momjian wrote: > +SELECT * > +FROM (values ('0/16ff'), ('0/1700'), ('0/1701')) as t(lsn), > + LATERAL pg_walfile_name_offset(lsn::pg_lsn), > + LATERAL pg_walfile_name(lsn::pg_lsn); > +lsn |file_name | file_offset

Re: Official Windows Installer and Documentation

On Tue, Oct 31, 2023 at 11:24:24AM -0400, Bruce Momjian wrote: > On Tue, Oct 31, 2023 at 11:16:29AM -0400, Bruce Momjian wrote: > > On Wed, Jul 27, 2022 at 09:28:51PM -0700, David G. Johnston wrote: > > > On Wed, Jul 27, 2022 at 8:22 PM Tom Lane wrote: > > > > > > I wrote: > > > > If EDB

Re: Is this a problem in GenericXLogFinish()?

On Mon, Nov 13, 2023 at 12:47 AM Hayato Kuroda (Fujitsu) wrote: > Moved. I see that this patch was committed, but I'm not very convinced that the approach is correct. The comment says this: + /* +* A write buffer needs to be registered even if no tuples are +*

Re: pg_walfile_name_offset can return inconsistent values

On Fri, Nov 10, 2023 at 07:59:43PM -0800, Andres Freund wrote: > Hi, > > On 2023-11-09 16:14:07 -0500, Bruce Momjian wrote: > > On Thu, Nov 9, 2023 at 09:49:48PM +0100, Matthias van de Meent wrote: > > > Either way, I think fix #1 is most correct (as was attached in > > > offset2.diff, and

Re: How to solve the problem of one backend process crashing and causing other processes to restart?

On 11/13/23 00:53, Laurenz Albe wrote: On Sun, 2023-11-12 at 21:55 -0500, Tom Lane wrote: yuansong writes: > In PostgreSQL, when a backend process crashes, it can cause other backend > processes to also require a restart, primarily to ensure data consistency. > I understand that the correct

Re: Why do indexes and sorts use the database collation?

On Mon, 2023-11-13 at 13:43 +0100, Peter Eisentraut wrote: > On 11.11.23 01:03, Jeff Davis wrote: > > But the database collation is always deterministic, > > So far! Yeah, if we did that, clearly the index collation would need to match that of the database to be useful. What are the main

Re: trying again to get incremental backup

Great stuff you got here. I'm doing a first pass trying to grok the whole thing for more substantive comments, but in the meantime here are some cosmetic ones. I got the following warnings, both valid: ../../../../pgsql/source/master/src/common/blkreftable.c: In function 'WriteBlockRefTable':

Re: proposal: possibility to read dumped table's name from file

po 13. 11. 2023 v 14:39 odesílatel Daniel Gustafsson napsal: > > On 13 Nov 2023, at 14:15, Pavel Stehule wrote: > > > > Hi > > > > ne 12. 11. 2023 v 14:17 odesílatel Pavel Stehule < > pavel.steh...@gmail.com > napsal: > > Hi > > > > > > What are your thoughts on

Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression

On 13.11.23 14:07, Amul Sul wrote: Also, it seems to me that the SET EXPRESSION variant should just do an update of the catalog table instead of a drop and re-insert. I am not sure if that is sufficient; we need to get rid of the dependencies of existing expressions on other columns

Re: pg_upgrade failing for 200+ million Large Objects

> On 09/11/2023, 18:41, "Tom Lane" > wrote: > Um ... you didn't attach the patch? Sorry , patch attached Regards Sachin pg_upgrade_improvements_v6.diff Description: pg_upgrade_improvements_v6.diff

Re: add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?)

On Mon, Nov 13, 2023 at 5:43 PM Bharath Rupireddy wrote: > > On Mon, Nov 6, 2023 at 9:09 AM Amit Kapila wrote: > > > > On Sun, Nov 5, 2023 at 4:01 AM Bharath Rupireddy > > wrote: > > > > > > On Thu, Nov 2, 2023 at 7:19 AM Peter Smith wrote: > > > > > > > > But that's not quite compatible with

Re: proposal: possibility to read dumped table's name from file

> On 13 Nov 2023, at 14:15, Pavel Stehule wrote: > > Hi > > ne 12. 11. 2023 v 14:17 odesílatel Pavel Stehule > napsal: > Hi > > > What are your thoughts on this version? It's not in a committable state as it > needs a bit more comments here and there and a

Re: Improve WALRead() to suck data directly from WAL buffers when possible

On Fri, Nov 10, 2023 at 2:28 AM Andres Freund wrote: > > On 2023-11-08 13:10:34 +0530, Bharath Rupireddy wrote: > > > > + /* > > > > + * The fact that we acquire WALBufMappingLock while > > > > reading the WAL > > > > + * buffer page itself guarantees that

Re: pg_basebackup check vs Windows file path limits

On 2023-11-11 Sa 11:31, Alvaro Herrera wrote: On 2023-Jul-08, Andrew Dunstan wrote: # Running: pg_basebackup -D C:\\tools\\nmsys64\\home\\pgrunner\\bf\\root\\REL_16_STABLE\\pgsql.build/testrun/pg_basebackup/010_pg_basebackup/data/t_010_pg_basebackup_main_data/backup/tarbackup2 -h

Re: proposal: possibility to read dumped table's name from file

Hi ne 12. 11. 2023 v 14:17 odesílatel Pavel Stehule napsal: > Hi > > >> What are your thoughts on this version? It's not in a committable state >> as it >> needs a bit more comments here and there and a triplecheck that nothing >> was >> missed in changing this, but I prefer to get your

Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression

On Mon, Nov 13, 2023 at 1:40 PM Peter Eisentraut wrote: > On 09.11.23 13:00, Amul Sul wrote: > > On Tue, Nov 7, 2023 at 8:21 PM Peter Eisentraut > > wrote: > > > > On 25.10.23 08:12, Amul Sul wrote: > > > Here is the rebase version for the latest master >

Re: Why do indexes and sorts use the database collation?

On 11.11.23 01:03, Jeff Davis wrote: But the database collation is always deterministic, So far!

Re: pg_upgrade and logical replication

On Mon, Nov 13, 2023 at 5:01 PM Amit Kapila wrote: > > On Fri, Nov 10, 2023 at 7:26 PM vignesh C wrote: > > > > Thanks for the comments, the attached v13 version patch has the > > changes for the same. > > > > + > + ReplicationOriginNameForLogicalRep(subid, InvalidOid, originname, >

Re: add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?)

On Mon, Nov 6, 2023 at 9:09 AM Amit Kapila wrote: > > On Sun, Nov 5, 2023 at 4:01 AM Bharath Rupireddy > wrote: > > > > On Thu, Nov 2, 2023 at 7:19 AM Peter Smith wrote: > > > > > > But that's not quite compatible with what Alvaro [2] had written long > > > back ("... the only acquisitions that

Re: pg_upgrade and logical replication

On Fri, Nov 10, 2023 at 7:26 PM vignesh C wrote: > > Thanks for the comments, the attached v13 version patch has the > changes for the same. > + + ReplicationOriginNameForLogicalRep(subid, InvalidOid, originname, sizeof(originname)); + originid = replorigin_by_name(originname, false); +

Re: pgsql: doc: fix wording describing the checkpoint_flush_after GUC

On 2023-Nov-09, Bruce Momjian wrote: > doc: fix wording describing the checkpoint_flush_after GUC Hmm. Is this new wording really more clear than the original wording? I agree the original may not have been the most simple, but I don't think it was wrong English. I'm not suggesting to revert

Re: Re: How to solve the problem of one backend process crashing and causing other processes to restart?

On Mon, Nov 13, 2023 at 5:14 PM yuansong wrote: > > Enhancing the overall fault tolerance of the entire system for this feature > is quite important. No one can avoid bugs, and I don't believe that this > approach is a more advanced one. It might be worth considering adding it to > the roadmap

Re: pg_upgrade and logical replication

On Mon, Nov 13, 2023 at 1:52 PM Michael Paquier wrote: > > It seems to me that INIT cannot be relied on for a similar reason. > This state would be set for a new relation in > LogicalRepSyncTableStart(), and the relation would still be in INIT > state when creating the slot via

Re: Add new option 'all' to pg_stat_reset_shared()

On Mon, Nov 13, 2023 at 02:07:21PM +0530, Bharath Rupireddy wrote: > Modified the docs for pg_stat_reset_slru to match with that of > pg_stat_reset_shared. PSA v2 patch. That feels consistent. Thanks. > I noticed that the commit 23c8c0c8 missed to add proargnames => > '{target}' in .dat file

Re: Fix output of zero privileges in psql

On 2023-11-09 20:19 +0100, Tom Lane wrote: > Laurenz Albe writes: > > Thanks for the feedback. I'll set the patch to "ready for committer" then. > > So, just to clarify, we're settling on your v4 from [1]? > > [1] >

Re: partitioning and identity column

On 27.10.23 13:32, Ashutosh Bapat wrote: I think we should fix these anomalies as follows 1. Allow identity columns to be added to the partitioned table irrespective of whether they have partitions of not. 2. Propagate identity property to partitions. 3. Use the same underlying sequence for

Re: Incorrect file reference in comment in procarray.c

On Fri, Nov 3, 2023 at 6:53 PM Etsuro Fujita wrote: > On Thu, Nov 2, 2023 at 10:20 PM Daniel Gustafsson wrote: > > > On 2 Nov 2023, at 13:40, Etsuro Fujita wrote: > > > Attached is a small patch for that: s/heapam_visibility.c/snapmgr.c/. > > > > No objections to the patch, the change is

Re: serial and partitioned table

On 17.10.23 09:25, Ashutosh Bapat wrote: #create table tpart (a serial primary key, src varchar) partition by range(a); CREATE TABLE #create table t_p4 (a int primary key, src varchar); CREATE TABLE To appease the gods of surprises I need to add a NOT NULL constraint. See [1]. #alter table t_p4

Re: Synchronizing slots from primary to standby

Hi, On 11/13/23 5:24 AM, shveta malik wrote: On Thu, Nov 9, 2023 at 8:56 AM Amit Kapila wrote: Apart from the above, I would like to discuss the slot sync work distribution strategy of this patch. The current implementation as explained in the commit message [1] works well if the slots

should check collations when creating partitioned index

When creating a partitioned index, the partition key must be a subset of the index's columns. DefineIndex() explains: * If this table is partitioned and we're creating a unique index, primary * key, or exclusion constraint, make sure that the partition key is a * subset of the

  1   2   >