On Sun, Mar 24, 2024 at 3:05 PM Bharath Rupireddy
wrote:
>
> I've attached the v18 patch set here. I've also addressed earlier
> review comments from Amit, Ajin Cherian. Note that I've added new
> invalidation mechanism tests in a separate TAP test file just because
> I don't want to clutter or
Hi,
On Tue, Mar 26, 2024 at 09:30:32AM +0530, shveta malik wrote:
> On Mon, Mar 25, 2024 at 12:43 PM shveta malik wrote:
> >
> > I have one concern, for synced slots on standby, how do we disallow
> > invalidation due to inactive-timeout immediately after promotion?
> >
> > For synced slots,
On Tue, Mar 26, 2024 at 9:38 AM shveta malik wrote:
>
> On Mon, Mar 25, 2024 at 9:54 PM Bertrand Drouvot
> wrote:
> >
> > Hi,
> >
> > On Mon, Mar 25, 2024 at 07:32:11PM +0530, Amit Kapila wrote:
> > > On Mon, Mar 25, 2024 at 6:57 PM Robert Haas wrote:
> > > > And I'm suspicious that having an
On Tue, Mar 26, 2024 at 9:30 AM shveta malik wrote:
>
> On Mon, Mar 25, 2024 at 12:43 PM shveta malik wrote:
> >
> > I have one concern, for synced slots on standby, how do we disallow
> > invalidation due to inactive-timeout immediately after promotion?
> >
> > For synced slots,
On Mon, Mar 25, 2024 at 2:47 PM Paul Jungwirth
wrote:
>
> On 3/23/24 10:04, Paul Jungwirth wrote:
> > Perhaps if the previous collation was nondeterministic we should force a
> > re-check.
>
> Here is a patch implementing this. It was a bit more fuss than I expected, so
> maybe someone has a
>
Andres Freund writes:
> On 2024-03-26 00:00:38 -0400, Tom Lane wrote:
>> Are you sure it's not just that the total time to run the core
>> regression tests has grown to a bit more than what the test timeout
>> allows for?
> You're right, that could be it - in a way at least, the issue is replay
On Tue, Mar 26, 2024 at 1:24 AM Nathan Bossart wrote:
>
>
> On Sun, Mar 24, 2024 at 03:05:44PM +0530, Bharath Rupireddy wrote:
> > This commit particularly lets one specify the inactive_timeout for
> > a slot via SQL functions pg_create_physical_replication_slot and
> >
On Thu, Mar 14, 2024 at 12:02 PM Masahiko Sawada wrote:
>
>
> I've attached new version patches.
Since the previous patch conflicts with the current HEAD, I've
attached the rebased patches.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
Hi,
On 2024-03-26 00:00:38 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I think there must be some actual regression involved. The frequency of
> > failures on HEAD vs failures on 16 - both of which run the tests
> > concurrently
> > via meson - is just vastly different.
>
> Are you sure
Dear Amit, Euler,
>
> This only drops the publications created by this tool, not the
> pre-existing ones that we discussed in the link provided.
Another concern around here is the case which primary subscribes changes from
others.
After the conversion, new subscriber also tries to connect to
On Tue, Mar 26, 2024 at 12:23 PM Bharath Rupireddy
wrote:
>
> On Tue, Mar 26, 2024 at 7:16 AM Masahiko Sawada wrote:
> >
> > > Please see the attached v9 patch set.
> >
> > Thank you for updating the patch! The patch mostly looks good to me.
> > Here are some minor comments:
>
> Thanks for
On Tue, Mar 26, 2024 at 1:50 AM Bharath Rupireddy
wrote:
>
> On Tue, Mar 26, 2024 at 1:30 AM Nathan Bossart
> wrote:
> >
> > On Mon, Mar 25, 2024 at 04:49:12PM +, Bertrand Drouvot wrote:
> > > On Mon, Mar 25, 2024 at 12:25:37PM -0400, Robert Haas wrote:
> > >> In the same vein, I think
On Mon, Mar 25, 2024 at 9:54 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Mon, Mar 25, 2024 at 07:32:11PM +0530, Amit Kapila wrote:
> > On Mon, Mar 25, 2024 at 6:57 PM Robert Haas wrote:
> > > And I'm suspicious that having an exception for slots being synced is
> > > a bad idea. That makes too
On Tue, Mar 26, 2024 at 8:27 AM Euler Taveira wrote:
>
> On Mon, Mar 25, 2024, at 11:33 PM, Amit Kapila wrote:
>
> On Mon, Mar 25, 2024 at 5:25 PM Peter Eisentraut wrote:
> >
> > I have committed your version v33. I did another pass over the
> > identifier and literal quoting. I added quoting
On Mon, Mar 25, 2024 at 12:43 PM shveta malik wrote:
>
> I have one concern, for synced slots on standby, how do we disallow
> invalidation due to inactive-timeout immediately after promotion?
>
> For synced slots, last_inactive_time and inactive_timeout are both
> set. Let's say I bring down
Andres Freund writes:
> I think there must be some actual regression involved. The frequency of
> failures on HEAD vs failures on 16 - both of which run the tests concurrently
> via meson - is just vastly different.
Are you sure it's not just that the total time to run the core
regression tests
Hi,
On 2024-03-20 17:41:45 -0700, Andres Freund wrote:
> On 2024-03-14 16:56:39 -0400, Tom Lane wrote:
> > Also, this is probably not
> > helping anything:
> >
> >'extra_config' => {
> > ...
> >
I wrote:
> I went ahead and committed 0001 after one more round of review
>
> statements; my bad). I also added the changes in test_predtest.c from
> 0002. I attach a rebased version of 0002, as well as 0003 which isn't
> changed, mainly to keep the cfbot happy.
[ squint.. ] Apparently I
Hi,
On 2024-03-24 11:28:12 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 19/09/2023 01:57, Andres Freund wrote:
> >> On 2023-09-18 13:49:24 +0300, Heikki Linnakangas wrote:
> >>> d) Copy fewer rows to the table in the test. If we copy only 6 rows, for
> >>> example, the table will
On Tue, Mar 26, 2024 at 7:16 AM Masahiko Sawada wrote:
>
> > Please see the attached v9 patch set.
>
> Thank you for updating the patch! The patch mostly looks good to me.
> Here are some minor comments:
Thanks for looking into this.
> ---
> /* non-export function prototypes */
> -static char
On Mon, Mar 25, 2024, at 11:33 PM, Amit Kapila wrote:
> On Mon, Mar 25, 2024 at 5:25 PM Peter Eisentraut wrote:
> >
> > I have committed your version v33. I did another pass over the
> > identifier and literal quoting. I added quoting for replication slot
> > names, for example, even though
On Mon, Mar 25, 2024, at 1:06 PM, Hayato Kuroda (Fujitsu) wrote:
> ## Analysis for failure 1
>
> The failure caused by a time lag between walreceiver finishes and
> pg_is_in_recovery()
> returns true.
>
> According to the output [1], it seems that the tool failed at
> wait_for_end_recovery()
>
Hi,
On 2024-03-13 15:33:02 -0400, Robert Haas wrote:
> But also ... having to wrap the entire plan tree like this seems
> pretty awful. I don't really like the idea of a large-scan plan
> modification like this in the middle of the query.
It's not great. But I also don't really see an
On Mon, Mar 25, 2024 at 5:25 PM Peter Eisentraut wrote:
>
> I have committed your version v33. I did another pass over the
> identifier and literal quoting. I added quoting for replication slot
> names, for example, even though they can only contain a restricted set
> of characters, but it felt
On Mon, Mar 25, 2024 at 8:21 PM Bharath Rupireddy
wrote:
>
> On Mon, Mar 25, 2024 at 10:42 AM Masahiko Sawada
> wrote:
> >
> > The current approach, eliminating the duplicated information in
> > CONTEXT, seems good to me.
>
> Thanks for looking into it.
>
> > One question about the latest (v8)
On Mon, 25 Mar 2024 at 21:36, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Bharath, Peter,
>
> > Looks like BF animals aren't happy, please check -
> > > https://buildfarm.postgresql.org/cgi-bin/show_failures.pl.
> >
> > Looks like sanitizer failures. There were a few messages about that
> >
On Mon, Mar 25, 2024 at 9:55 PM Robert Haas wrote:
>
> On Mon, Mar 25, 2024 at 12:12 PM Bertrand Drouvot
> wrote:
>
> > Would "released_time" sounds better? (at the end this is exactly what it
> > does
> > represent unless for the case where it is restored from disk for which the
> > meaning
>
Thanks for committing the new WAL format!
On Mon, Mar 25, 2024 at 3:33 PM Heikki Linnakangas wrote:
>
> On 24/03/2024 18:32, Melanie Plageman wrote:
> > On Thu, Mar 21, 2024 at 9:28 AM Heikki Linnakangas wrote:
> >>
> >> In heap_page_prune_and_freeze(), we now do some extra work on each live
>
Hi,
On 2024-03-25 06:44:33 +0100, Peter Eisentraut wrote:
> Done and committed.
This triggered a new warning for me:
../../../../../home/andres/src/postgresql/meson.build:3422: WARNING: Project
targets '>=0.54' but uses feature introduced in '0.55.0': Passing
executable/found program object
On Sun, Mar 24, 2024 at 1:42 AM Paul Jungwirth
wrote:
>
> v33 attached with minor changes.
>
> Okay, added those tests too. Thanks!
>
> Rebased to 697f8d266c.
>
hi.
minor issues I found in v33-0003.
there are 29 of {check_amproc_signature?.*false}
only one
On Mon, Mar 25, 2024 at 4:24 PM Andrew Dunstan wrote:
> OK, so we invent a new error code and have the parser return that if the
> stack depth gets too big?
Yeah, that seems reasonable. I'd potentially be able to build on that
via OAuth for next cycle, too, since that client needs to limit its
On Mon, Mar 25, 2024 at 7:12 PM Jacob Champion <
jacob.champ...@enterprisedb.com> wrote:
> On Mon, Mar 25, 2024 at 4:02 PM Andrew Dunstan
> wrote:
> > Well, what's the alternative? The current parser doesn't check stack
> depth in frontend code. Presumably it too will eventually just run out of
On Mon, Mar 25, 2024 at 4:12 PM Jacob Champion
wrote:
> Stack size should be pretty limited, at least on the platforms I'm
> familiar with. So yeah, the recursive descent will segfault pretty
> quickly, but it won't repalloc() an unbounded amount of heap space.
> The alternative would just be to
On Mon, Mar 25, 2024 at 9:14 AM Jelte Fennema-Nio
wrote:
> On Mon, 25 Mar 2024 at 14:06, Robert Haas wrote:
> > On Mon, Mar 25, 2024 at 4:30 AM Jelte Fennema-Nio
> wrote:
> > > That problem seems easy to address by adding a newline into the
> > > default prompt.
> >
> > Ugh. Please, no!
>
> I
On Mon, Mar 25, 2024 at 4:02 PM Andrew Dunstan wrote:
> Well, what's the alternative? The current parser doesn't check stack depth in
> frontend code. Presumably it too will eventually just run out of memory,
> possibly rather sooner as the stack frames could be more expensive than the
>
On Mon, Mar 25, 2024 at 6:15 PM Jacob Champion <
jacob.champ...@enterprisedb.com> wrote:
> On Wed, Mar 20, 2024 at 11:56 PM Andrew Dunstan
> wrote:
> > Thanks, included that and attended to the other issues we discussed. I
> think this is pretty close now.
>
> Okay, looking over the thread,
On Wed, Mar 20, 2024 at 11:56 PM Andrew Dunstan wrote:
> Thanks, included that and attended to the other issues we discussed. I think
> this is pretty close now.
Okay, looking over the thread, there are the following open items:
- extend the incremental test in order to exercise the semantic
James Coleman writes:
> [ v6 patchset ]
I went ahead and committed 0001 after one more round of review
statements; my bad). I also added the changes in test_predtest.c from
0002. I attach a rebased version of 0002, as well as 0003 which isn't
changed, mainly to keep the cfbot happy.
I'm
David Rowley writes:
> On Tue, 26 Mar 2024 at 03:53, Tom Lane wrote:
>> Could we move the knowledge of exactly which context type it is out
>> of the per-chunk header and keep it in the block header?
> I wasn't 100% clear on your opinion about using 010 vs expanding the
> bit-space. Based on
Here is what I have staged for commit. One notable difference in this
version of the patch is that I've changed
+ if (nelem <= nelem_per_iteration)
+ goto one_by_one;
to
+ if (nelem < nelem_per_iteration)
+ goto one_by_one;
I realized that there's no
On Mon, Mar 25, 2024 at 2:29 AM Donghang Lin wrote:
>
>
> > On Sat, Feb 17, 2024 at 2:31 PM Tomas Vondra
> > wrote:
> > 2) Leader vs. worker counters
> >
> > It seems to me this does nothing to add the per-worker values from "Heap
> > Blocks" into the leader, which means we get stuff like this:
On Mon, Mar 25, 2024 at 09:40:55PM +0100, Jelte Fennema-Nio wrote:
> On Mon, 25 Mar 2024 at 20:16, Bruce Momjian wrote:
> > I am wondering if the fact that you would be able to do:
> >
> > ALTER SYSTEM SET externally_managed_configuration = false
> >
> > and then be unable to use ALTER
On Tue, 26 Mar 2024 at 03:53, Tom Lane wrote:
> I agree with this completely. However, the current design for chunk
> headers is mighty restrictive about how many kinds of contexts we can
> have. We need to open that back up.
Andres mentioned how we could do this in [1]. One possible issue
On Mon, 25 Mar 2024 at 20:16, Bruce Momjian wrote:
> I am wondering if the fact that you would be able to do:
>
> ALTER SYSTEM SET externally_managed_configuration = false
>
> and then be unable to use ALTER SYSTEM to revert the change is
> significant.
This is not possible, due to the
On Thu, 21 Mar 2024 at 14:19, Tom Lane wrote:
>
> David Rowley writes:
> > We could also do something like the attached just in case we're
> > barking up the wrong tree.
>
> Yeah, checking indisvalid isn't a bad idea. I'd put another
> one further down, just before the DROP of table ab, so we
>
On Tue, Mar 26, 2024 at 3:34 AM Pankaj Raghav wrote:
> One question: Does ZFS do something like FUA request to force the device
> to clear the cache before it can update the node to point to the new page?
>
> If it doesn't do it, there is no guarantee from device to update the data
> atomically
On Tue, Mar 26, 2024 at 1:30 AM Nathan Bossart wrote:
>
> On Mon, Mar 25, 2024 at 04:49:12PM +, Bertrand Drouvot wrote:
> > On Mon, Mar 25, 2024 at 12:25:37PM -0400, Robert Haas wrote:
> >> In the same vein, I think deactivated_at or inactive_since might be
> >> good names to consider. I
On Mon, Mar 25, 2024 at 02:53:56PM +0100, Pankaj Raghav wrote:
> This is an excellent question that needs a bit of community discussion to
> expose a device agnostic value that userspace can trust.
>
> There might be a talk this year at LSFMM about untorn writes[1] in buffered IO
> path. I will
On Mon, Mar 25, 2024 at 06:42:36PM +, Amonson, Paul D wrote:
> Ok, CI turned green after my re-post of the patches. Can this please get
> merged?
Thanks for the new patches. I intend to take another look soon.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Mar 25, 2024 at 04:49:12PM +, Bertrand Drouvot wrote:
> On Mon, Mar 25, 2024 at 12:25:37PM -0400, Robert Haas wrote:
>> In the same vein, I think deactivated_at or inactive_since might be
>> good names to consider. I think they get at the same thing as
>> released_time, but they avoid
On Sat, Mar 23, 2024 at 5:47 AM Jeff Davis wrote:
>
> Comments:
Thanks for looking into it.
> * Do I understand correctly that CMV, RMV, and CTAS experience a
> performance benefit, but COPY FROM does not? And is that because COPY
> already used table_multi_insert, whereas CMV and RMV did not?
I apologize that I haven't been able to keep up with this thread for a
while, but I'm happy to see the continued interest in $SUBJECT.
On Sun, Mar 24, 2024 at 03:05:44PM +0530, Bharath Rupireddy wrote:
> This commit particularly lets one specify the inactive_timeout for
> a slot via SQL functions
On 24/03/2024 18:32, Melanie Plageman wrote:
On Thu, Mar 21, 2024 at 9:28 AM Heikki Linnakangas wrote:
In heap_page_prune_and_freeze(), we now do some extra work on each live
tuple, to set the all_visible_except_removable correctly. And also to
update live_tuples, recently_dead_tuples and
On Mon, Mar 25, 2024 at 01:29:46PM -0400, Robert Haas wrote:
> What is less clear is whether there is a consensus in favor of this
> particular method of disabling ALTER SYSTEM, namely, via a GUC. The
> two alternate approaches that seem to enjoy some level of support are
> (a) an extension or (b)
Hi,
On 2024-01-19 15:40:21 +0100, Peter Eisentraut wrote:
> On 19.01.24 15:26, Daniel Gustafsson wrote:
> > > On 18 Jan 2024, at 01:57, vignesh C wrote:
> >
> > > There are a lot of failures in CFBot at [1] with:
> >
> > > More details of the same are available at [2].
> > > Do we need to
On Mon, Mar 25, 2024 at 2:26 PM Tom Lane wrote:
> I wonder whether this feature should include teaching the server
> to ignore postgresql.auto.conf altogether, which would make it
> relatively easy to get to a bulletproof configuration.
This has been debated a few times on the thread already,
On Fri, Mar 22, 2024 at 4:58 PM Tristan Partin wrote:
> I had a question about parameter naming. Right now I have a mix of
> camel-case and snake-case in the function signature since that is what
> I inherited. Should I change that to be consistent? If so, which case
> would you like?
Uh...
> -Original Message-
> From: Amonson, Paul D
> Sent: Monday, March 25, 2024 8:20 AM
> To: Tom Lane
> Cc: David Rowley ; Nathan Bossart
> ; Andres Freund ; Alvaro
> Herrera ; Shankaran, Akash
> ; Noah Misch ; Matthias
> van de Meent ; pgsql-
> hack...@lists.postgresql.org
> Subject: RE:
On 23/03/2024 03:41, Bruce Momjian wrote:
> On Fri, Mar 22, 2024 at 10:31:11PM +0100, Tomas Vondra wrote:
>> Right, but things change over time - current storage devices support
>> much larger sectors (LBA format), usually 4K. And if you do I/O with
>> this size, it's usually atomic.
>>
>> AFAIK
Hi Thomas,
On 23/03/2024 05:53, Thomas Munro wrote:
> On Fri, Mar 22, 2024 at 10:56 PM Pankaj Raghav (Samsung)
> wrote:
>> My team and I have been working on adding Large block size(LBS)
>> support to XFS in Linux[1]. Once this feature lands upstream, we will be
>> able to create XFS with FS
Hi Tomas and Bruce,
>>> My knowledge of Postgres internals is limited, so I'm wondering if there
>>> are any optimizations or potential optimizations that Postgres could
>>> leverage once we have LBS support on Linux?
>>
>> We have discussed this in the past, and in fact in the early years we
>>
On Mon, Mar 25, 2024 at 7:27 PM Tom Lane wrote:
> Robert Haas writes:
> > OK, great. The latest patch doesn't specifically talk about backing it
> > up with filesystem-level controls, but it does clearly say that this
> > feature is not going to stop a determined superuser from bypassing the
>
On Fri, 22 Mar 2024 at 08:28, jian he wrote:
>
> On Thu, Mar 21, 2024 at 7:23 PM Peter Eisentraut wrote:
> >
> > Hmm. CREATE DOMAIN uses column constraint syntax, but ALTER DOMAIN uses
> > table constraint syntax. Attached is a patch to try to sort this out.
>
> also you should also change
Robert Haas writes:
> OK, great. The latest patch doesn't specifically talk about backing it
> up with filesystem-level controls, but it does clearly say that this
> feature is not going to stop a determined superuser from bypassing the
> feature, which I think is the appropriate level of detail.
On Mon, Mar 25, 2024 at 12:03:10PM -0400, Peter Geoghegan wrote:
> On Sun, Mar 24, 2024 at 10:03 PM Noah Misch wrote:
> Separately, I now see that the committed patch just reuses the code
> that has long been used to check that things are in the correct order
> across page boundaries: this is
On Mon, Mar 25, 2024 at 1:47 PM Tom Lane wrote:
> FWIW, I never objected to the idea of being able to disable ALTER
> SYSTEM. I felt that it ought to be part of a larger feature that
> would provide a more bulletproof guarantee that a superuser can't
> alter the system configuration; but I'm
On Mon, 2024-03-25 at 08:29 +0100, Peter Eisentraut wrote:
> Right. I thought when you said there is an ICU configuration for it,
> that it might be like collation options that you specify in the
> locale
> string. But it appears it is only an internal API setting. So that,
> in
> my mind,
Robert Haas writes:
> Since those are just minor points, that brings us to the question of
> whether there is consensus to proceed with this. I believe that there
> is a clear consensus that there should be some way to disable ALTER
> SYSTEM. Sure, some people, particularly Tom, disagree, but I
Richard Guo writes:
> This patch was initially posted in that same thread and has received
> some comments from Tom in [2]. Due to the presence of multiple patches
> in that thread, it has led to confusion. So fork a new thread here
> specifically dedicated to discussing the patch about
On Tue, Mar 19, 2024 at 9:13 AM Jelte Fennema-Nio wrote:
> On Mon, 18 Mar 2024 at 18:27, Robert Haas wrote:
> > I think for now we
> > should just file this under "Other platforms and clients," which only
> > has one existing setting. If the number of settings of this type
> > grows, we can
Hi,
On Mon, Mar 25, 2024 at 12:25:37PM -0400, Robert Haas wrote:
> On Mon, Mar 25, 2024 at 12:12 PM Bertrand Drouvot
> wrote:
> > Would "released_time" sounds better? (at the end this is exactly what it
> > does
> > represent unless for the case where it is restored from disk for which the
> >
> On Sun, Mar 24, 2024 at 11:36:38PM +0900, Yasuo Honda wrote:
> Thanks for the information. I can apply these 4 patches from
> 0eb23285a2 . I tested this branch from Ruby on Rails and it gets some
> unexpected behavior from my point of view.
> Setting
On Mon, Mar 25, 2024 at 12:12 PM Bertrand Drouvot
wrote:
> Now that I read your arguments I think that last__time could
> be
> both missleading because at the end they rely on users "expectation".
Well, the user is always going to expect *something* -- that's just
how language works.
> Would
Hi,
On Mon, Mar 25, 2024 at 07:32:11PM +0530, Amit Kapila wrote:
> On Mon, Mar 25, 2024 at 6:57 PM Robert Haas wrote:
> > And I'm suspicious that having an exception for slots being synced is
> > a bad idea. That makes too much of a judgement about how the user will
> > use this field. It's
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Hi,
On Mon, Mar 25, 2024 at 11:49:00AM -0400, Robert Haas wrote:
> On Mon, Mar 25, 2024 at 11:16 AM Bertrand Drouvot
> wrote:
> > > IIUC, Bertrand's point was that users can interpret last_active_time
> > > as a value that gets updated each time they decode a change which is
> > > not what we
Dear Bharath, Peter,
> Looks like BF animals aren't happy, please check -
> > https://buildfarm.postgresql.org/cgi-bin/show_failures.pl.
>
> Looks like sanitizer failures. There were a few messages about that
> recently, but those were all just about freeing memory after use, which
> we don't
On Sun, Mar 24, 2024 at 10:03 PM Noah Misch wrote:
> > You're going to have to "couple" buffer locks in the style of
> > _bt_check_unique() (as well as keeping a buffer lock on "the first
> > leaf page a duplicate might be on" throughout) if you need the test to
> > work reliably.
>
> The amcheck
On Mon, Mar 25, 2024 at 11:40 AM Peter Eisentraut wrote:
> I think a possible problem we need to consider with these proposals to
> combine chapters is that they could make the chapters themselves too
> deep and harder to navigate. For example, if we combined the
> installation from source and
On Mon, Mar 25, 2024 at 11:36 AM Tom Lane wrote:
> By that logic, we should rip out every Assert in the system, as well
> as all of the (extensive) resource leak checking that already happens
> during CommitTransaction. We've always felt that those leak checks
> were worth the cost to help us
On Mon, Mar 25, 2024 at 11:16 AM Bertrand Drouvot
wrote:
> > IIUC, Bertrand's point was that users can interpret last_active_time
> > as a value that gets updated each time they decode a change which is
> > not what we are doing. So, this can confuse users. Your expectation of
> > answer (NULL)
On 3/25/24 11:12, Tom Lane wrote:
"Amonson, Paul D" writes:
I am re-posting the patches as CI for Mac failed (CI error not code/test
error). The patches are the same as last time.
Just for a note --- the cfbot will re-test existing patches every
so often without needing a bump. The current
On 22.03.24 15:10, Robert Haas wrote:
Sorry. I didn't mean to dispute the point that the section was added a
few years ago, nor the point that most people just want to read about
the binaries. I am confident that both of those things are true. What
I do want to dispute is that having a
Hi,
On Mon, Mar 25, 2024 at 08:59:55PM +0530, Amit Kapila wrote:
> On Mon, Mar 25, 2024 at 8:46 PM Bertrand Drouvot
> wrote:
> >
> > On Mon, Mar 25, 2024 at 08:38:16PM +0530, Amit Kapila wrote:
> > > On Mon, Mar 25, 2024 at 7:51 PM Robert Haas wrote:
> > > >
> > > > On Mon, Mar 25, 2024 at
Robert Haas writes:
> On Sat, Mar 23, 2024 at 12:31 PM Tom Lane wrote:
>> However, the calling logic seems a bit shy of a load, in that it
>> trusts IsInParallelMode() completely to decide whether to check for
>> leaked parallel contexts. So we'd miss the case where somebody did
>>
On Mon, Mar 25, 2024 at 8:46 PM Bertrand Drouvot
wrote:
>
> On Mon, Mar 25, 2024 at 08:38:16PM +0530, Amit Kapila wrote:
> > On Mon, Mar 25, 2024 at 7:51 PM Robert Haas wrote:
> > >
> > > On Mon, Mar 25, 2024 at 10:02 AM Amit Kapila
> > > wrote:
> > > > We considered the other two names as
On 22.03.24 14:59, Robert Haas wrote:
And I don't believe that if someone were writing a physical book about
PostgreSQL from scratch, they'd ever end up with a top-level chapter
that looks anything like our GiST chapter. All of the index AM
chapters are quite obviously clones of each other, and
On Mon, Mar 25, 2024 at 10:03:27AM +0700, John Naylor wrote:
> Seems pretty good. It'd be good to see the results of 2- vs.
> 4-register before committing, because that might lead to some
> restructuring, but maybe it won't, and v8 is already an improvement
> over HEAD.
I tested this the other
> -Original Message-
> From: Tom Lane
> Sent: Monday, March 25, 2024 8:12 AM
> To: Amonson, Paul D
> Cc: David Rowley ; Nathan Bossart
> Subject: Re: Popcount optimization using AVX512
>...
> Just for a note --- the cfbot will re-test existing patches every so often
> without
> needing
Hi,
On Mon, Mar 25, 2024 at 08:38:16PM +0530, Amit Kapila wrote:
> On Mon, Mar 25, 2024 at 7:51 PM Robert Haas wrote:
> >
> > On Mon, Mar 25, 2024 at 10:02 AM Amit Kapila
> > wrote:
> > > We considered the other two names as last_inactive_at and
> > > last_active_time. For the first
On Mon, Mar 25, 2024 at 11:08:39AM -0400, Tom Lane wrote:
> * The magic constants (crossover list length and bloom filter size)
> need some testing to see if there are better values. They should
> probably be made into named #defines, too. I suspect, with little
> proof, that the bloom filter
On Sat, Mar 23, 2024 at 12:31 PM Tom Lane wrote:
> However, the calling logic seems a bit shy of a load, in that it
> trusts IsInParallelMode() completely to decide whether to check for
> leaked parallel contexts. So we'd miss the case where somebody did
> ExitParallelMode without having cleaned
"Amonson, Paul D" writes:
> I am re-posting the patches as CI for Mac failed (CI error not code/test
> error). The patches are the same as last time.
Just for a note --- the cfbot will re-test existing patches every
so often without needing a bump. The current cycle period seems to
be about
Nathan Bossart writes:
> Are there any changes you'd like to see for the Bloom patch [0]? I'd like
> to see about getting that committed for v17. One thing that crossed my
> mind is creating a combined list/filter that transparently created a filter
> when necessary (for reuse elsewhere), but
On Mon, Mar 25, 2024 at 7:51 PM Robert Haas wrote:
>
> On Mon, Mar 25, 2024 at 10:02 AM Amit Kapila wrote:
> > We considered the other two names as last_inactive_at and
> > last_active_time. For the first (last_inactive_at), there was an
> > argument that most other fields that display time ends
> -Original Message-
> From: Amonson, Paul D
> Sent: Thursday, March 21, 2024 12:18 PM
> To: David Rowley
> Cc: Nathan Bossart ; Andres Freund
I am re-posting the patches as CI for Mac failed (CI error not code/test
error). The patches are the same as last time.
Thanks,
Paul
Tomas Vondra writes:
> IMHO the idea of having a general purpose memory context and then also
> specialized memory contexts for particular allocation patterns is great,
> and we should embrace it. Adding more and more special cases into
> AllocSet seems to go directly against that idea, makes the
On Fri, Mar 22, 2024 at 04:41:49PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> LGTM
>
> Thanks for looking, I'll push that shortly.
Are there any changes you'd like to see for the Bloom patch [0]? I'd like
to see about getting that committed for v17. One thing that crossed my
mind is
On 3/25/24 12:41, David Rowley wrote:
> On Tue, 5 Mar 2024 at 15:42, David Rowley wrote:
>> The query I ran was:
>>
>> select chksz,mtype,pg_allocate_memory_test_reset(chksz,
>> 1024*1024,1024*1024*1024, mtype) from (values(8),(16),(32),(64))
>>
On Sat, Mar 23, 2024 at 9:47 AM Tomas Vondra
wrote:
> BTW is there a reason why the code calls "write" and not "pg_pwrite"?
I think it's mostly because I learned to code a really long time ago.
--
Robert Haas
EDB: http://www.enterprisedb.com
1 - 100 of 158 matches
Mail list logo
