Hi
út 31. 10. 2023 v 22:12 odesílatel Matthias van de Meent <
boekewurm+postg...@gmail.com> napsal:
> Hi,
>
> Currently, nbtree code compares each and every column of an index
> tuple during the binary search on the index page. With large indexes
> that have many duplicate prefix column values (e
I didn't see any recent mentions in the archives, so I'll volunteer to
be CF manager for 2023-11.
On Tue, Oct 31, 2023 at 10:33:25AM +0900, Michael Paquier wrote:
> Sounds pretty much OK to me. Thanks!
The main thing I have found annoying in the patch was the term
"tranche ID", so I have reworded that to use tranche_id to match with
the surroundings and the routines of lwlock.h. LWLockInitia
On Thu, Aug 10, 2023 at 3:24 PM Richard Guo wrote:
> The cfbot reminds that this patch does not apply any more, so rebase it
> to v2.
>
Attached is another rebase over the latest master. Any feedback is
appreciated.
Thanks
Richard
v3-0001-Support-Right-Semi-Join-plan-shapes.patch
Description
On Mon, Oct 30, 2023 at 03:05:09PM +0530, vignesh C wrote:
> The patch was not applying because of recent commits. Here is a
> rebased version of the patches.
+ * We don't want the launcher to run while upgrading because it may start
+ * apply workers which could start receiving changes fr
On Fri, Oct 27, 2023 at 05:05:39PM +0530, Amit Kapila wrote:
> I was analyzing this part and it seems it could be tricky to upgrade
> in FINISHEDCOPY state. Because the system would expect that subscriber
> would know the old slotname from oldcluster which it can drop at
> SYNCDONE state. Now, as s
On Mon, Mar 27, 2023 at 11:08 AM Bharath Rupireddy
wrote:
>
> The v9 patch was failing because I was using MyReplicationSlot after
> it got reset by slot release, attached v10 patch fixes it.
>
+ *
+ * Note: use LogReplicationSlotAcquire() if needed, to log a message after
+ * acquiring the repli
I think this is duplicate with https://commitfest.postgresql.org/45/4637/
The new status of this patch is: Waiting on Author
On Tue, Oct 31, 2023 at 9:07 PM Tom Lane wrote:
> shihao zhong writes:
> > I noticed that the CREATE/ALTER TABLE document does not mention that
> > EXCLUDE can accept a collation. I created a documentation fix for this
> > issue, and I have attached it to this email.
>
> > Hmm ... is this actual
Adding this comment via the CF app so it isn't lost, while an
improperly-interpreted-DKIM-headers issue is still preventing me from mailing
directly to -hackers.
It was my view that the patch was getting close by the end of the last
commitfest, but still contained a bit of a logic wart made nec
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
>> called again". That provides a hint that retry is the appropriate
>> response to a failure. Admittedly, it's not 100% clear, but your
>> v
On Tue, Oct 31, 2023 at 09:11:06PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Okay, I added "_successful_ calls", attached. I am not sure what else
> > to add.
>
> What I'm objecting to is removal of the bit about "if they need to be
> called again". That provides a hint that retry is t
Bruce Momjian writes:
> Okay, I added "_successful_ calls", attached. I am not sure what else
> to add.
What I'm objecting to is removal of the bit about "if they need to be
called again". That provides a hint that retry is the appropriate
response to a failure. Admittedly, it's not 100% clear
shihao zhong writes:
> I noticed that the CREATE/ALTER TABLE document does not mention that
> EXCLUDE can accept a collation. I created a documentation fix for this
> issue, and I have attached it to this email.
Hmm ... is this actually correct? I think that the collate
option has to come before
Dear Nisha,
>
> The failure cause is -
> no data was returned by command
> ""D:/Project/pg1/postgres/tmp_install/bin/pg_resetwal" -V"
> check for "D:/Project/pg1/postgres/tmp_install/bin/pg_resetwal"
> failed: cannot execute
>
> Failure, exiting
> [16:24:21.144](6.275s) not ok 10 - run of pg_up
On Tue, Oct 31, 2023 at 11:51 PM Bruce Momjian wrote:
>
...
> Patch applied to master. Perhaps someday we will adjust tabs, but for
> now, this is an improvements. I made a few small adjustments myself.
>
I had long forgotten this old patch. Thanks for resurrecting it and pushing!
==
Kind
Hi hackers,
I hope this email finds you well.
I noticed that the CREATE/ALTER TABLE document does not mention that
EXCLUDE can accept a collation. I created a documentation fix for this
issue, and I have attached it to this email.
Please let me know if you have any questions or concerns.
Thanks
On Tue, Oct 31, 2023 at 08:28:07AM -0400, Robert Haas wrote:
> On Mon, Oct 30, 2023 at 8:40 PM Michael Paquier wrote:
>> As far as I know, there's one paragraph in the docs that implies this
>> mode without giving an actual hint that this may be OK or not, so
>> shrug:
>> https://www.postgresql.or
On 10/31/23 19:28, Jeff Davis wrote:
On Tue, 2023-10-31 at 12:45 +0100, Vik Fearing wrote:
On 10/24/23 21:10, Jeff Davis wrote:
Can we revisit the idea of a per-WHEN RETURNING clause?
For the record, I dislike this idea.
I agree that it makes things awkward, and if it creates grammatical
pr
On Tue, Oct 31, 2023 at 04:26:18PM +0900, torikoshia wrote:
> Yes, calling pg_stat_reset_shared() for all stats types can do what I wanted
> to do.
> But calling it with 6 different parameters seems tiresome and I thought it
> would be convenient to have a parameter to delete all cluster-wide
> sta
Looking at the Assert inside tts_virtual_copyslot(), it does:
Assert(srcdesc->natts <= dstslot->tts_tupleDescriptor->natts);
So, that seems to indicate that it's ok for the src slot to have fewer
attributes than the destination. The code then calls
tts_virtual_clear(dstslot), then slot_getallatt
(now really to -hackers)
Hi,
Over at [0] I'd implemented an optimization that allows us to skip
calling _bt_compare in _bt_moveright in many common cases. This patch,
when stacked on top of the prefix truncation patch, improves INSERT
performance by an additional 2-9%pt, with an extreme case of 45
On Tue, Oct 31, 2023 at 04:32:38PM -0500, David Christensen wrote:
> On Tue, Oct 31, 2023 at 4:30 PM Bruce Momjian wrote:
> Temporary /files/ are handled in a different patch set and are not included
> here (not sure of the status of integrating at this point). I believe that
> this patch should
On Tue, Oct 31, 2023 at 4:30 PM Bruce Momjian wrote:
> On Tue, Oct 31, 2023 at 04:23:17PM -0500, David Christensen wrote:
> > Greetings,
> >
> > I am including an updated version of this patch series; it has been
> rebased
> > onto 6ec62b7799 and reworked somewhat.
> >
> > The patches are as foll
On Tue, Oct 31, 2023 at 04:23:17PM -0500, David Christensen wrote:
> Greetings,
>
> I am including an updated version of this patch series; it has been rebased
> onto 6ec62b7799 and reworked somewhat.
>
> The patches are as follows:
>
> 0001 - doc updates
> 0002 - Basic key management and cipher
On Tue, Oct 31, 2023 at 01:58:34PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I modified your patch, attached, that I would like to apply to all
> > supported versions.
>
> This seems to have lost the information about what to do if these
> functions fail. I think probably the only possi
Hi,
Currently, nbtree code compares each and every column of an index
tuple during the binary search on the index page. With large indexes
that have many duplicate prefix column values (e.g. an index on (bool,
bool, uuid) ) that means a lot of wasted time getting to the right
column.
The attached
On Tue, Oct 31, 2023, at 3:21 PM, Hannu Krosing wrote:
> One thing though re:
> > The former is true but the latter is not. Logical replication requires
> > wal_level = logical. That's also true for skipping FSM.
>
> wal_level=logical is only needed *at provider* side, at least when
> running pg
On Mon, Oct 30, 2023 at 11:21:43AM -0500, Nathan Bossart wrote:
> On Fri, Oct 27, 2023 at 07:01:10AM +, Xiang Gao wrote:
>> On Thu, 26 Oct, 2023 11:37:52AM -0500, Nathan Bossart wrote:
We consider that a runtime check needs to be done in any scenario.
Here we only confirm that the com
On Tue, Oct 31, 2023 at 03:38:17PM -0500, Nathan Bossart wrote:
> On Tue, Oct 31, 2023 at 04:12:40PM -0400, Tom Lane wrote:
>> This seems like a reasonable proposal.
>
> Great. I think that leaves us with nothing left to do for this thread, so
> I'll withdraw it from the commitfest and move the d
On Tue, Oct 31, 2023 at 04:12:40PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> Okay. With that in mind, I think the path forward for new instructions is
>> as follows:
>
>> * If the special CRC instructions can be used with the default compiler
>> flags, we can only use newer instructio
Nathan Bossart writes:
> Okay. With that in mind, I think the path forward for new instructions is
> as follows:
> * If the special CRC instructions can be used with the default compiler
> flags, we can only use newer instructions if they can also be used with
> the default compiler flags.
Please discard this second thread. My mail client seems to have done
something very wrong.
--
Tristan Partin
Neon (https://neon.tech)
Postgres has been bitten by a few locale-related bugs, most recently via
libperl[0]. I had previously submitted this patchset in the bug thread
for the aforementioned bug, but here is a standalone submission for the
purposes of an eventual commitfest submission, and to get discussion
going. I w
On Tue, Oct 31, 2023 at 03:42:33PM -0400, Tom Lane wrote:
> The one machine using slicing-by-8 where there might be a better
> alternative is arowana, which is CentOS 7 with a pretty ancient gcc
> version. So I reject the idea that slicing-by-8 is an appropriate
> baseline for comparisons. There
On Tue, Oct 31, 2023 at 03:16:16PM -0400, Tom Lane wrote:
> Really this just reinforces my concern that doing a runtime check
> all the time is on the wrong side of history. I grant that we've
> got to do that for anything where the availability of the instruction
> is really in serious question,
I wrote:
> I did a more thorough scrape of the buildfarm results. Of 161 animals
> currently reporting configure output on HEAD, we have
Oh ... take "current" with a grain of salt there, because I just noticed
that I typo'd my search condition so that it collected results from all
systems that re
Nathan Bossart writes:
> On Mon, Oct 30, 2023 at 10:36:01PM -0500, Nathan Bossart wrote:
>> I tested pg_waldump -z with 50M 65-byte records for the following
>> implementations on an ARM system:
>>
>> * slicing-by-8: ~3.08s
>> * proposed patches applied (runtime ch
Hi,
On Tue, Oct 31, 2023 at 04:59:24PM +0530, Shlok Kyal wrote:
> I went through the Cfbot for this patch and found out that the build
> is failing with the following error (Link:
> https://cirrus-ci.com/task/4648506929971200?logs=build#L1217):
Oops, sorry. Attached is a working third version of
On Tue, 2023-10-31 at 12:45 +0100, Vik Fearing wrote:
> On 10/24/23 21:10, Jeff Davis wrote:
> > Can we revisit the idea of a per-WHEN RETURNING clause?
>
> For the record, I dislike this idea.
I agree that it makes things awkward, and if it creates grammatical
problems as well, then it's not ver
Thanks for the pointers.
One thing though re:
> The former is true but the latter is not. Logical replication requires
> wal_level = logical. That's also true for skipping FSM.
wal_level=logical is only needed *at provider* side, at least when
running pglogical.
Also, even for native logical rep
* This patch looks a little different than the last version I see posted
[0].
That last version of the patch (which appears to be just about committable)
My oops – I was looking at the wrong commit. The newer patch has already been
committed, so pretend that last message didn’t happen. Than
>
>
> I think the SQL statements should end with semicolons. Our SQL examples
> are usually written like that.
>
ok
>
> Our general style with CTEs seems to be (according to
> https://www.postgresql.org/docs/current/queries-with.html):
>
> WITH quaxi AS (
> SELECT ...
> )
> SELECT ...;
Bruce Momjian writes:
> I modified your patch, attached, that I would like to apply to all
> supported versions.
This seems to have lost the information about what to do if these
functions fail. I think probably the only possible failure cause
in nonblock mode is "unable to enlarge the buffer be
On Fri, 27 Oct 2023 at 19:04, Jeff Davis wrote:
The approach of locking down search_path during maintenance commands
> would solve the problem, but it means that we are enforcing search_path
> in some contexts and not others. That's not great, but it's similar to
> what we are doing when we ignor
On Wed, Jul 21, 2021 at 10:15:09AM +0900, Yugo NAGATA wrote:
> I understood that, although PQgetResult() also flushes the buffer, we still
> should call PQflush() beforehand because we would not like get blocked after
> calling PQgetResult(). Thanks.
I modified your patch, attached, that I would l
On Fri, Oct 27, 2023 at 04:04:26PM -0700, Jeff Davis wrote:
> Do we still want to do this?
>
> Right now, the MAINTAIN privilege is blocking on some way to prevent
> malicious users from abusing the MAINTAIN privilege and search_path to
> acquire the table owner's privileges.
I vote +1 for procee
On Tue, Oct 31, 2023, at 5:09 AM, Hannu Krosing wrote:
> Currently we do not allow TRUNCATE of a table when any Foreign Keys
> point to that table.
It is allowed iif you *also* truncate all tables referencing it.
> At the same time we do allow one to delete all rows when
> session_replication_rol
On Fri, Oct 27, 2023 at 12:58:47PM -0700, Jeff Davis wrote:
> Do you, overall, find this feature useful?
>
> Most functions don't need pg_temp, so it feels cleaner to exclude it.
> But pg_temp is ignored for function/op lookup anyway, so functions
> won't be exposed to search_path risks related to
Re: Tom Lane
> Well, the idea was exactly to forbid that sort of setup.
Fwiw, pgsphere has remove the problematic operators now:
https://github.com/postgrespro/pgsphere/commit/e810f5ddd827881b06a92a303c5c9fbf997b892e
> However, if we get sufficient pushback maybe we should
> reconsider --- for e
On Fri, Oct 20, 2023 at 5:33 PM Tom Lane wrote:
> Pushed after a round of editorialization -- mostly cosmetic
> stuff, except for tweaking some error messages. I shortened the
> test cases a bit too, as I thought they were somewhat excessive
> to have as a permanent thing.
Thanks Tom.
On Tue, O
Hi Peter,
You may find value in this Meson PR[0] adding a skip keyword argument to
Meson's test() function. From what I understand of the PR and your
issue, they seem related. If you could provide a comment describing why
this is valuable to you, it would be good to help the Meson
maintainers
On Sat, Aug 13, 2022 at 02:46:24PM +0530, Bharath Rupireddy wrote:
> On Sat, Aug 13, 2022 at 4:34 AM Bruce Momjian wrote:
> >
> > On Fri, Aug 12, 2022 at 06:22:01PM -0400, Bruce Momjian wrote:
> > > On Mon, Jan 10, 2022 at 12:19:28AM +0800, Wei Sun wrote:
> > > > Hi,
> > > >
> > > > Some time ago,
On Mon, Oct 30, 2023 at 10:36:01PM -0500, Nathan Bossart wrote:
> I tested pg_waldump -z with 50M 65-byte records for the following
> implementations on an ARM system:
>
> * slicing-by-8: ~3.08s
> * proposed patches applied (runtime check): ~2.44s
> * only CR
On Sun, Jul 17, 2022 at 07:07:15PM -0400, Dian M Fay wrote:
> On Sat Jul 16, 2022 at 11:23 PM EDT, David G. Johnston wrote:
> > Thanks for the review. I generally like everything you said but it made me
> > realize that I still didn't really understand the intent behind the
> > formula. I spent w
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 isn't adequately filling in the documentation for the behavior
> > > of
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 isn't adequately filling in the documentation for the behavior
> > of their packaging, that's on them.
>
> Having now looked more closely a
On Mon, Aug 1, 2022 at 09:05:45PM +0900, torikoshia wrote:
> On 2022-07-30 02:53, Alvaro Herrera wrote:
>
> > I don't think this refers to the statistics collector process; I
> > understand it to refer to ANALYZE that captures the data being stored.
>
> Thanks for the explanation!
>
> > Maybe i
On Tue, Oct 31, 2023 at 08:17:52AM +0900, Michael Paquier wrote:
> Thanks for the input. I was looking yesterday if this code was
> available somewhere, but couldn't find it.. Until this morning:
> https://gitlab.com/depesz/explain.depesz.com.git
Well, the parser itself is https://gitlab.com/dep
Hi,
Thank you for the feedback!
On Thu, 26 Oct 2023 at 09:28, Michael Paquier wrote:
>
> On Wed, Sep 20, 2023 at 10:57:48AM +0300, Nazir Bilal Yavuz wrote:
> > Any kind of feedback would be appreciated.
>
> This was registered in the CF, so I have given it a look. Note that
> 0001 has a conflic
Dear Horiguchi-san,
Thanks for making the patch!
> > 4. I think a test case to hit the error in the check hook in
> > 003_logical_slots.pl will help a lot here - not only covers the code
> > but also helps demonstrate how one can reach the error.
>
> Yeah, of course. I was planning to add tests
On Thu, Oct 26, 2023 at 11:04:47PM -0400, Bruce Momjian wrote:
> On Thu, Oct 26, 2023 at 04:17:19PM -0700, David G. Johnston wrote:
> > On Thu, Oct 26, 2023 at 4:13 PM David G. Johnston
> >
> > wrote:
> >
> > On Thu, Oct 26, 2023 at 4:08 PM Tom Lane wrote:
> >
> > Bruce Momjian wr
On Sat, Oct 21, 2023 at 09:59:04PM -0400, Bruce Momjian wrote:
> On Sat, Oct 21, 2023 at 09:56:13PM -0400, Bruce Momjian wrote:
> > I did some more research. It turns out that the source slot/planSlot is
> > populating its pg_attribute information via makeTargetEntry() and it
> > has no concept of
On Thu, Aug 4, 2022 at 12:42:38PM +1000, Peter Smith wrote:
> On Thu, Aug 4, 2022 at 11:09 AM Michael Paquier wrote:
> >
> > On Wed, Aug 03, 2022 at 12:58:04PM +0200, Alvaro Herrera wrote:
> > > On 2022-Aug-01, Tom Lane wrote:
> > >> One idea for avoiding confusion is to legislate that we won't
>
On Tue, 31 Oct 2023 at 17:51, Amit Kapila wrote:
>
> On Tue, Oct 31, 2023 at 4:53 PM Nisha Moond wrote:
> >
> > There is a failure with 't/003_logical_slots.pl' test during the
> > upgrade. The failure is intermittent and observed in the Windows
> > environment.
> >
>
> How did you reach the conc
On Mon, Oct 30, 2023 at 11:15 PM Amit Kapila wrote:
> My understanding is the same. It is possible that my wording is not
> clear. Let me try to clarify again, Michael asked: "do we need the
> cleanup lock on the write buffer even if there are no tuples, and even
> if primary bucket and the write
On Mon, Oct 30, 2023 at 8:40 PM Michael Paquier wrote:
> As far as I know, there's one paragraph in the docs that implies this
> mode without giving an actual hint that this may be OK or not, so
> shrug:
> https://www.postgresql.org/docs/devel/continuous-archiving.html#BACKUP-TIPS
> "As with base
On Tue, Oct 31, 2023 at 4:53 PM Nisha Moond wrote:
>
> There is a failure with 't/003_logical_slots.pl' test during the
> upgrade. The failure is intermittent and observed in the Windows
> environment.
>
How did you reach the conclusion that it is only for
't/003_logical_slots.pl'? I see that the
On 30.10.23 12:55, Aleksander Alekseev wrote:
The patch LGTM. However, postgresql:pg_resetwal test suite doesn't
pass on Windows according to cfbot. Seems to be a matter of picking a
more generic regular expression:
```
at C:/cirrus/src/bin/pg_resetwal/t/001_basic.pl line 54.
'p
On 10/24/23 21:10, Jeff Davis wrote:
Can we revisit the idea of a per-WHEN RETURNING clause?
For the record, I dislike this idea.
--
Vik Fearing
Hi,
On Thu, 26 Oct 2023 at 13:58, Michael Banck wrote:
>
> Hi,
>
> On Wed, Oct 25, 2023 at 04:36:41PM +0200, Peter Eisentraut wrote:
> > On 19.10.23 11:39, Michael Banck wrote:
> > > Hi,
> > >
> > > I believed that spread (not fast) checkpoints are the default in
> > > pg_basebackup, but noticed
Hi hackers,
There is a failure with 't/003_logical_slots.pl' test during the
upgrade. The failure is intermittent and observed in the Windows
environment.
Details-
Test - pg_upgrade/t/003_logical_slots.pl
Result -
t/003_logical_slots.pl .. 5/?
# Failed test 'run of pg_upgrade of old cluster'
#
On Tuesday, October 31, 2023 6:45 PM Amit Kapila
wrote:
> > b) Currently I have restricted 'alter subscription.. refresh
> > publication with copy=true' when failover=true (on a similar line of
> > two-phase). The reason being, refresh with copy=true will go for
> > table-sync again and since fa
On Tue, Oct 31, 2023 at 4:00 PM Bharath Rupireddy
wrote:
>
> > > 5. A possible problem with this check_hook approach is that it doesn't
> > > let anyone setting max_slot_wal_keep_size to a value other than -1
> > > during pg_ugprade even if someone doesn't have logical slots or
> > > doesn't want
Alexander Korotkov писал 2023-10-30 19:05:
Hi, Alexander!
Thank you for working on this. I believe this is a very interesting
patch, which significantly improves our FDW-based distributed
facilities. This is why I decided to review this.
Hi. Thanks for reviewing.
+ /*
+* We can't pu
On Fri, Oct 27, 2023 at 4:04 PM shveta malik wrote:
>
> On Fri, Oct 27, 2023 at 3:26 PM shveta malik wrote:
> ==
>
> Open questions regarding change for pt 1 above:
> a) I think we should restrict the 'alter-sub set failover' when
> failover-state is currently in 'p' (pending) state i.e.
> @@ -2036,8 +2035,8 @@ RestoreBlockImage(XLogReaderState *record, uint8
> block_id, char *page)
> char*ptr;
> PGAlignedBlock tmp;
>
> - if (block_id > record->record->max_block_id ||
> - !record->record->blocks[block_id].in_use)
> + if (block_id > XLogRecMaxBlockId(record) ||
> + !XLogRecG
Thanks for having a look at my patch!
On Mon, 2023-10-30 at 15:03 -0700, David G. Johnston wrote:
> On Mon, Oct 30, 2023 at 2:50 PM David G. Johnston
> wrote:
> > On Tue, Oct 3, 2023 at 12:52 AM Laurenz Albe
> > wrote:
> > > On Mon, 2023-10-02 at 09:49 -0400, Tom Lane wrote:
> > > > This is by
On Tue, Oct 31, 2023 at 2:19 PM Kyotaro Horiguchi
wrote:
>
> > GUC_check_errcode(ERRCODE_INVALID_PARAMETER_VALUE);
> > GUC_check_errmsg(""\"max_slot_wal_keep_size\" must be set
> > to -1 when in binary upgrade mode");
> > GUC_check_errdetail("A value of -1 preve
On Tue, Oct 31, 2023 at 5:23 PM 邱宇航 wrote:
>
> Hello hackers,
>
> Commit 3f1ce97 refactored XLog record access macros, but missed in a few
> places. I fixed this, and patch is attached.
>
> --
> Yuhang Qiu
>
>
>
@@ -2036,8 +2035,8 @@ RestoreBlockImage(XLogReaderState *record, uint8
block_id, cha
As this change showed a really good improvement in my micro-benchmark, I
decided to give it a try on something that's a bit more of a real world
benchmark: PostgreSQL.
Hence, I'm also Cc'ing the postgres maintainers in case they are interested.
To bring them up to speed, here's what's been going o
On Fri, Oct 27, 2023 at 8:43 PM Drouvot, Bertrand
wrote:
>
> Hi,
>
> On 10/27/23 11:56 AM, shveta malik wrote:
> > On Wed, Oct 25, 2023 at 3:15 PM Drouvot, Bertrand
> > wrote:
> >>
> >> Hi,
> >>
> >> On 10/25/23 5:00 AM, shveta malik wrote:
> >>> On Tue, Oct 24, 2023 at 11:54 AM Drouvot, Bertrand
On Thu, Oct 26, 2023 at 5:43 PM Amit Kapila wrote:
>
> On Thu, Oct 26, 2023 at 5:38 PM Drouvot, Bertrand
> wrote:
> >
> > On 10/26/23 10:40 AM, Amit Kapila wrote:
> > > On Wed, Oct 25, 2023 at 8:49 PM Drouvot, Bertrand
> > > wrote:
> > >>
> > >
> > > Good point, I think we should enhance the Wal
Hello hackers,
Commit 3f1ce97 refactored XLog record access macros, but missed in a few
places. I fixed this, and patch is attached.
--
Yuhang Qiu
0001-Simplify-xlogreader.c-with-XLogRec-macros.patch
Description: Binary data
> On Fri, Oct 27, 2023 at 05:02:44PM +0200, Dmitry Dolgov wrote:
> > On Thu, Oct 26, 2023 at 09:08:42AM +0900, Michael Paquier wrote:
> > typedef struct ArrayExpr
> > {
> > + pg_node_attr(custom_query_jumble)
> > +
> >
> > Hmm. I am not sure that this is the best approach
> > implementation-wi
At Mon, 30 Oct 2023 14:55:01 +0530, Bharath Rupireddy
wrote in
> > I get it. I agree to go with just the assert because the GUC
> > check_hook kinda tightens the screws against setting
> > max_slot_wal_keep_size to a value other than -1 during the binary
> > upgrade,
Thanks for being on the sam
Hi
Currently we do not allow TRUNCATE of a table when any Foreign Keys
point to that table.
At the same time we do allow one to delete all rows when
session_replication_role=replica
This causes all kinds of pain when trying to copy in large amounts of
data, especially at the start of logical rep
On Mon, Oct 30, 2023 at 5:46 PM Bharath Rupireddy
wrote:
Thanks for the comments!
Isn't calling pg_stat_reset_shared() for all stats types helping you
out? Is there any problem with it? Can you be more specific about the
use-case?
Yes, calling pg_stat_reset_shared() for all stats types can
88 matches
Mail list logo
