On 19.08.24 11:43, Peter Eisentraut wrote:
On 16.08.24 23:01, Thomas Munro wrote:
On Sat, Aug 17, 2024 at 3:43 AM Peter
Eisentraut wrote:
I moved the _POSIX_C_SOURCE definition for MinGW from the header file to
a command-line option (-D_POSIX_C_SOURCE). This matches the treatment
of _GNU_SOUR
On Thu, Aug 22, 2024 at 3:44 PM shveta malik wrote:
>
>
> For clock-skew and timestamp based resolution, if needed, I will post
> another email for the design items where suggestions are needed.
>
Please find issues which need some thoughts and approval for
time-based resolution and clock-skew.
Richard Guo writes:
> On Fri, Aug 23, 2024 at 11:19 AM Tom Lane wrote:
>> I'm not sure you're considering "efficiency" in the right light.
> I agree that it’s always desirable to postpone work from path-creation
> time to plan-creation time. In this case, however, it’s a little
> different. Th
On Fri, Aug 23, 2024 at 11:19 AM Tom Lane wrote:
> Richard Guo writes:
> > ... we'll always make a separate ProjectionPath on top of the SortPath
> > in create_ordered_paths. It’s only when we create the plan node for
> > the projection step in createplan.c that we realize a separate Result
> >
On Tue, Aug 20, 2024 at 12:30:35PM -0400, Alvaro Herrera wrote:
> Yeah, I like this option. Injection points require to be explicitly
> enabled in configure, so skipping that test when injection_points can't
> be found seems reasonable.
My apologies for the delay in doing something here.
The sim
On Fri, Aug 23, 2024 at 11:26:30AM +0800, jian he wrote:
> do you mean this thread [1]? but the output is the attached image.png,
> which looks more invasive.
> also that does not link to git commit url.
>
> or do you mean automate the process, like add
> commit
> automatically? using perl script,
Richard Guo writes:
> ... we'll always make a separate ProjectionPath on top of the SortPath
> in create_ordered_paths. It’s only when we create the plan node for
> the projection step in createplan.c that we realize a separate Result
> is unnecessary. This is not efficient.
I'm not sure you're
On Thu, Aug 22, 2024 at 3:34 PM Richard Guo wrote:
> /* Add projection step if needed */
> if (sorted_path->pathtarget != target)
> sorted_path = apply_projection_to_path(root, ordered_rel,
>sorted_path, target);
>
> This does not see
Alvaro Herrera 于2024年8月23日周五 02:41写道：
> On 2024-Aug-22, Tender Wang wrote:
>
> > I apply the v14 patch on branch REL_14_STABLE. I run this thread issue
> and I
> > find below error.
> > [...]
> > ERROR: cache lookup failed for constraint 16400
> >
> > I haven't look into details to find out wher
On Thu, Aug 22, 2024 at 7:27 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > On Thu, Aug 22, 2024 at 7:07 PM 席冲(宜穆)
> wrote:
> >> In SlruSelectLRUPage(), Why do we need to traverse all slots to find
> that
> >> a page already has a buffer assigned? Why not find it
> >> from the [bankstart
On Thu, Aug 22, 2024 at 8:03 PM David Rowley wrote:
> On Thu, 22 Aug 2024 at 23:33, Peter Eisentraut wrote:
> > > I wonder if we need to invent a function to compare two PathTargets.
> >
> > Wouldn't the normal node equal() work?
>
> It might. I think has_volatile_expr might be missing a
> pg_nod
"David G. Johnston" writes:
> On Thu, Aug 22, 2024 at 7:07 PM 席冲(宜穆) wrote:
>> In SlruSelectLRUPage(), Why do we need to traverse all slots to find that
>> a page already has a buffer assigned? Why not find it
>> from the [bankstart,bankend]?
> Only the bank is searched, both of the logic loops
On Thu, Aug 22, 2024 at 7:07 PM 席冲(宜穆) wrote:
> In SlruSelectLRUPage(), Why do we need to traverse all slots to find that
> a page already has a buffer assigned? Why not find it
> from the [bankstart,bankend]?
>
>
Only the bank is searched, both of the logic loops are bounded by:
for (int slotn
Hello all,
This PostgreSQL version is 17beta2.
In SlruSelectLRUPage(), Why do we need to traverse all slots to find that a
page already has a buffer assigned? Why not find it
from the [bankstart,bankend]?
Best regards
Michael Paquier writes:
> The patch does not apply on HEAD due to the dependency with the other
> things you are proposing, and I would have hardcoded failures to check
> that the reports are correct, but that looks neat on read.
I did test it by injecting errors, but I don't see why we'd leave
t
On Wed, Aug 21, 2024 at 1:39 AM Alena Rybakina
wrote:
>
> I think you've counted the above system tables from the database, but
> I'll double-check it. Thank you for your review!
>
> On 19.08.2024 19:28, Ilia Evdokimov wrote:
> > Are you certain that all tables are included in
> > `pg_stat_vacuum_
On Thu, Aug 22, 2024 at 8:25 PM Robert Haas wrote:
>
> On Thu, Aug 22, 2024 at 12:43 PM Alexander Korotkov
> wrote:
> > Thank you for your feedback. Yes, it seems that there is not enough
> > time to even carefully analyze all the issues in these features. The
> > rule of thumb I can get from t
On Thu, Aug 22, 2024 at 10:36:38AM -0400, Alvaro Herrera wrote:
> On 2024-Aug-22, Michael Paquier wrote:
>> I'm not sure that we need to get down to that until somebody has a
>> case where they want to rely on stats of injection points for their
>> stuff. At this stage, I only want the stats to be
On Tue, Aug 20, 2024 at 02:33:23PM -0400, Tom Lane wrote:
> I wrote:
>> Yeah, I was wondering about that. I wouldn't do it exactly like
>> that, but with a check that the entry gets matched somewhere.
>
> Here's a patch for that (again based on the other patch series).
> This did not turn up anyt
On Thu, Aug 22, 2024 at 01:16:37PM -0400, Yogesh Sharma wrote:
> On 8/18/24 20:09, Michael Paquier wrote:
>> I'm tempted to propose a separate improvement for the template of the
>> fixed-numbered stats. We could do like pgstatfuncs.c where we use a
>> macro to define the routines of the counters,
On 8/22/24 22:07, Bruce Momjian wrote:
> On Thu, Aug 22, 2024 at 09:54:02PM +0200, Tomas Vondra wrote:
>> On 8/22/24 20:56, Bruce Momjian wrote:
>>> You make a very good point above. Would there ever be cases where a
>>> targetlist would have multiple aggregates, and some can be pushed down,
>>>
On Thu, Aug 22, 2024 at 11:13:15PM +0200, Daniel Gustafsson wrote:
> On 22 Aug 2024, at 02:31, Michael Paquier wrote:
>> Just do it :)
>
> That's my plan, I wanted to wait a bit to see if anyone else chimed in with
> concerns.
Cool, thanks!
--
Michael
signature.asc
Description: PGP signature
Hi,
I took a brief look at the patch.
For a motivation aspect I can see this being useful
synchronous_replicas if you have commit set to flush mode.
So +1 on feature, easier configurability, although thinking about it
more you could probably have the restore script be smarter and provide
non-zero
On Fri, 23 Aug 2024 at 10:14, Craig Ringer
wrote:
> On Thu, 22 Aug 2024 at 21:00, Gabriele Bartolini
> wrote:
> > On Thu, 22 Aug 2024 at 09:32, Jelte Fennema-Nio wrote:
> >> SET extension_search_path = /mnt/extensions/pg16/*
> >
> > That'd be great. +1.
>
> Agreed, that'd be handy, but not worth
On Thu, 22 Aug 2024 at 21:00, Gabriele Bartolini
wrote:
> On Thu, 22 Aug 2024 at 09:32, Jelte Fennema-Nio wrote:
>> SET extension_search_path = /mnt/extensions/pg16/*
>
> That'd be great. +1.
Agreed, that'd be handy, but not worth blocking the underlying capability for.
Except possibly to the d
> On 22 Aug 2024, at 02:31, Michael Paquier wrote:
>
> On Wed, Aug 21, 2024 at 10:48:38AM -0400, Joe Conway wrote:
>> On 8/21/24 09:01, Peter Eisentraut wrote:
>>> Is anything -- other than this inquiry -- preventing this patch set from
>>> getting committed?
That, and available time.
>> The ov
On Thu, 22 Aug 2024 at 15:02, Ranier Vilela wrote:
> Hi.
>
> Em qui., 22 de ago. de 2024 às 04:34, Richard Guo
> escreveu:
>
>> I ran into a query plan where the Result node seems redundant to me:
>>
>> create table t (a int, b int, c int);
>> insert into t select i%10, i%10, i%10 from generate_
On Thu, Aug 22, 2024 at 09:54:02PM +0200, Tomas Vondra wrote:
> On 8/22/24 20:56, Bruce Momjian wrote:
> > You make a very good point above. Would there ever be cases where a
> > targetlist would have multiple aggregates, and some can be pushed down,
> > and some have to return all matching rows s
On Thu, 22 Aug 2024 at 10:11, Frédéric Yhuel
wrote:
> Hello,
>
> I think that pgstattuple should use PageGetExactFreeSpace() instead of
> PageGetHeapFreeSpace() or PageGetFreeSpace(). The latter two compute the
> free space minus the space of a line pointer. They are used like this in
> the rest
On 8/22/24 20:56, Bruce Momjian wrote:
> On Wed, Aug 21, 2024 at 05:41:02PM +0200, Tomas Vondra wrote:
>> On 8/8/24 13:48, Jelte Fennema-Nio wrote:
>>> SUMMARY OF THREAD
>>>
>>> The design of patch 0001 is agreed upon by everyone on the thread (so
>>> far). This adds the PARTIAL_AGGREGATE label for
Em qui., 22 de ago. de 2024 às 14:27, Tom Lane escreveu:
>
> I'd prefer to see this implemented in the website based on our
> existing markup practices. That way it would work for quite a
> few years' worth of existing release notes, not only future ones.
>
> I understand your point, and agree w
On Thu, Aug 22, 2024 at 08:31:11PM +0200, Tomas Vondra wrote:
> > My question is related to #3 and #4. For #3, if we are going to be
> > building infrastructure to handle passing int128 for AVG, wouldn't it be
> > wiser to create an int128 type and an int128 array type, and then use
> > method #2
Hi,
It seems you responded by writing a new message and just copying the
subject, which unfortunately doesn't set the headers used for threading
(e.g. in archives). Please just respond to the message.
Or maybe your client does not set the References/In-Reply-To headers
correctly. Not sure which m
On Wed, Aug 21, 2024 at 05:41:02PM +0200, Tomas Vondra wrote:
> On 8/8/24 13:48, Jelte Fennema-Nio wrote:
> > SUMMARY OF THREAD
> >
> > The design of patch 0001 is agreed upon by everyone on the thread (so
> > far). This adds the PARTIAL_AGGREGATE label for aggregates, which will
> > cause the fin
Hi,
I would like to propose a slight elaboration of the sort cost model.
In practice, we frequently see the choice of suboptimal sortings, which
slump performance by 10-50%.
The key reason here is the optimiser's blindness to the fact that
sorting calls a comparison operator for each pair of
On 2024-Aug-22, Tender Wang wrote:
> I apply the v14 patch on branch REL_14_STABLE. I run this thread issue and I
> find below error.
> [...]
> ERROR: cache lookup failed for constraint 16400
>
> I haven't look into details to find out where cause above error.
Right, we try to drop the constrai
On 8/22/24 19:22, Bruce Momjian wrote:
> On Wed, Aug 21, 2024 at 04:59:12PM +0200, Tomas Vondra wrote:
>> On 8/20/24 20:41, Bruce Momjian wrote:
>>> SELECT (oid, relname) FROM pg_class LIMIT 1;
>>> row
>>> -
>>> (2619,pg_statistic)
>>>
>>> SELECT pg
Like ICU, allow -1 length to mean that the input string is NUL-
terminated for pg_strncoll(), pg_strnxfrm(), and pg_strnxfrm_prefix().
This simplifies the API and code a bit.
Along with some other refactoring in this area, we are getting close to
the point where the collation provider can just be
Marcos Pegoraro writes:
> Well, a process which does this automatically would be cool, but a
> modified version of release notes for version 17 was done manually and
> seems fine.
> So, why not commit this version and later for version 18 then create this
> process ?
I'd prefer to see this implem
On Thu, Aug 22, 2024 at 12:43 PM Alexander Korotkov
wrote:
> Thank you for your feedback. Yes, it seems that there is not enough
> time to even carefully analyze all the issues in these features. The
> rule of thumb I can get from this experience is "think multiple times
> before accessing somet
On Thu, Aug 22, 2024 at 10:16 AM Tom Lane wrote:
>
> In connection with that last point, I wonder if we should include
> commentary about when things came in. I'd originally thought of
> just inserting the above names in alphabetical order, but now I
> wonder if the patch ought to look more like
On Wed, Aug 21, 2024 at 04:59:12PM +0200, Tomas Vondra wrote:
> On 8/20/24 20:41, Bruce Momjian wrote:
> > SELECT (oid, relname) FROM pg_class LIMIT 1;
> > row
> > -
> > (2619,pg_statistic)
> >
> > SELECT pg_typeof((oid, relname)) FROM pg_class LIM
Em seg., 19 de ago. de 2024 às 19:10, Bruce Momjian
escreveu:
> Should I work on this?
>
> Well, a process which does this automatically would be cool, but a
modified version of release notes for version 17 was done manually and
seems fine.
So, why not commit this version and later for version 18
On 8/18/24 20:09, Michael Paquier wrote:
f68cd847fa40 but I've just lacked a combination of time and energy
while the original commit was already enough.
The code indentation was a bit incorrect, and I think that we should
also have tests to stress that the insertion of the new stats is
correct.
Back in commit 6991e774e we established a policy that, well,
I'll just quote the commit message:
Provide feature-test macros for libpq features added in v14.
We had a request to provide a way to test at compile time for the
availability of the new pipeline features. More generall
Hi!
On Thu, Aug 22, 2024 at 1:02 PM Pavel Borisov wrote:
Looked at v9:
> Patch looks good to me. I'd only suggest comments changes:
>
> "The map from relation's OID to the corresponding composite type OID" -> "The
> mapping of relation's OID to the corresponding composite type OID"
> "We're keep
Lakshmi Narayana Velayudam writes:
> Just as an info for future readers, it is indeed a bug for two reasons
No, it isn't. There's twenty years' worth of successful usage of
the old coding pattern that says you're wrong.
regards, tom lane
Hi!
On Thu, Aug 22, 2024 at 7:33 PM Robert Haas wrote:
> In response to some concerns raised about this fix on the
> pgsql-release list today, I spent some time investigating this patch.
> Unfortunately, I think there are too many problems here to be
> reasonably fixed before release, and I think
On 8/22/24 12:33 PM, Robert Haas wrote:
I think it is very unlikely that the problems mentioned above are the
only ones. They're just what I found in an hour or two of testing.
Even if they were, we're probably too close to release to be rushing
out last minute fixes to multiple unanticipated se
On Thu, Aug 22, 2024 at 9:50 PM Tom Lane wrote:
>
> > The previous postmaster coding blocked signals
> > everywhere except immediately around the main loop's select() call,
> > so there wasn't any real hazard of signal handlers interrupting
> > anything of concern. We redid it for cleanliness, n
Hi,
In response to some concerns raised about this fix on the
pgsql-release list today, I spent some time investigating this patch.
Unfortunately, I think there are too many problems here to be
reasonably fixed before release, and I think all of SPLIT/MERGE
PARTITION needs to be reverted.
I focus
Lakshmi Narayana Velayudam writes:
> My Bad Nathan, was looking at PG 11, 14 codes. Just to be sure, calling
> *ProcessConfigFile *is a bug from a signal handler is a bug, right?
No, it was not. The previous postmaster coding blocked signals
everywhere except immediately around the main loop's s
> Upthread [0], Andres suggested dispatching to a different implementation for
> compile-time-known small lengths. Have you looked into that? In your
> original post, you noted a 14% regression for records smaller than 256 bytes,
> which is not an uncommon case for Postgres. IMO we should try to
On Thu, Aug 22, 2024 at 8:46 PM Nathan Bossart
wrote:
>
> > I think this is no longer true as of v16, thanks to commit 7389aad [0].
>
My Bad Nathan, was looking at PG 11, 14 codes. Just to be sure, calling
*ProcessConfigFile *is a bug from a signal handler is a bug, right? Since
it uses AllocSet
Thanks for the new patches.
On Thu, Aug 22, 2024 at 03:14:32PM +, Amonson, Paul D wrote:
> I reran all the basic tests again to make sure that the performance
> numbers were within the margin of error when compared to my original
> finding. This step showed similar numbers (see origin post) ar
On Thu, Aug 22, 2024 at 05:37:13PM +0530, Lakshmi Narayana Velayudam wrote:
> Later I have seen almost
> all postgresql processes/bgworkers use signal handler to set a
> variable *ConfigReloadPending
> *which will later be read in main code to process guc changes but for
> postmaster *ProcessConfig
Hi,
Here are the latest patches for the accelerated CRC32c algorithm. I did the
following to create these refactored patches:
1) From the main branch I moved all x86_64 hardware checks from the various
locations into a single location. I did not move any ARM tests as I would have
no way to tes
On 2024-Aug-22, Michael Paquier wrote:
> On Wed, Aug 21, 2024 at 01:55:06PM -0400, Alvaro Herrera wrote:
> > Also, maybe it'd make sense for stats to be globally enabled, and that
> > only the tests that require it would disable them? (It's probably easy
> > enough to have a value "injection_poi
Hi.
Em qui., 22 de ago. de 2024 às 04:34, Richard Guo
escreveu:
> I ran into a query plan where the Result node seems redundant to me:
>
> create table t (a int, b int, c int);
> insert into t select i%10, i%10, i%10 from generate_series(1,100)i;
> create index on t (a, b);
> analyze t;
>
> set
On Thu, Aug 22, 2024 at 8:07 AM Jelte Fennema-Nio wrote:
> Are the disabled node counts still expected to be stable even with
> GEQO? If not, maybe we should have a way to turn them off after all.
> Although I agree that always disabling them when COSTS OFF is set is
> probably also undesirable. H
Hi hackers,
Please find attached a patch to $SUBJECT.
This module provides SQL functions to inspect the contents of serialized logical
snapshots of a running database cluster, which I think could be useful for
debugging or educational purposes.
It's currently made of 2 functions, one to return t
On Thu, 22 Aug 2024 at 17:08, bucoo wrote:
>
> > 0) The patch does not apply anymore, thanks to David committing a patch
>
> > yesterday. Attached is a patch rebased on top of current master.
>
> That patch is based on PG17. I have now rewritten it based on the master
> branch and added some comm
On 8/22/24 10:50 AM, 陈宗志 wrote:
I disagree with the point made in the article. The article mentions
that ‘prevents the kernel from reordering reads and writes to optimize
performance,’ which might be referring to the file system’s IO
scheduling and merging. However, this can be handled within the
> 0) The patch does not apply anymore, thanks to David committing a patch> yesterday. Attached is a patch rebased on top of current master.That patch is based on PG17. I have now rewritten it based on the master branch and added some comments.> 1) Wouldn't it be easier (and just as efficient) to us
On Wed, 31 Jul 2024 at 18:23, Robert Haas wrote:
> - If we do commit 0002, I think it's a good idea to have the number of
> disabled nodes displayed even with COSTS OFF, because it's stable, and
> it's pretty useful to be able to see this in the regression output. I
> have found while working on t
Hi pgsql hacker,
Recently I have been trying to understand why GUC changes will be visible
even though they are done in the signal handler as part of
*ProcessConfigfile* (done in some extension code). Later I have seen almost
all postgresql processes/bgworkers use signal handler to set a
variable
On Thu, 22 Aug 2024 at 23:33, Peter Eisentraut wrote:
> > I wonder if we need to invent a function to compare two PathTargets.
>
> Wouldn't the normal node equal() work?
It might. I think has_volatile_expr might be missing a
pg_node_attr(equal_ignore).
David
On 21/8/2024 17:28, Alexander Korotkov wrote:
I've changed oid -> OID in the comments and in the commit message.
I passed through the patch again: no objections and +1 to the changes of
comments proposed by Pavel.
--
regards, Andrei Lepikhov
On Thu, 22 Aug 2024 at 10:22, Shubham Khanna
wrote:
>
> On Fri, Aug 16, 2024 at 2:47 PM vignesh C wrote:
> >
> > On Fri, 16 Aug 2024 at 10:04, Shubham Khanna
> > wrote:
> > >
> > > On Thu, Aug 8, 2024 at 12:43 PM Peter Smith wrote:
> > > >
> > > > Hi Shubham,
> > > >
> > > > I think the v25-000
On 22.08.24 09:34, Richard Guo wrote:
I looked into this a little bit and found that in function
create_ordered_paths, we decide whether a projection step is needed
based on a simple pointer comparison between sorted_path->pathtarget
and final_target.
/* Add projection step if needed */
This is a good idea to extend parallelism in postgres.
I went through this patch, and here are a few review comments,
+ Size pscan_len; /* size of parallel tid range scan descriptor */
The other name for this var could be tidrs_PscanLen, following the pattern
in indexScanState and IndexOnlyScanSt
Hi Michael,
Thanks for the patch.
I quickly tried running some ANALYZE ONLY queries, it seems like it works
fine.
-ANALYZE [ ( option [, ...] )
> ] [ table_and_columns [, ...] ]
> +ANALYZE [ ( option [, ...] )
> ] [ [ ONLY ] table_and_columns
> [, ...] ]
It seems like extended_relation_expr all
On Thu, 22 Aug 2024 at 19:34, Richard Guo wrote:
> /* Add projection step if needed */
> if (sorted_path->pathtarget != target)
> sorted_path = apply_projection_to_path(root, ordered_rel,
>sorted_path, target);
>
> This does not seem
On Thu, Aug 22, 2024 at 8:11 AM Peter Eisentraut wrote:
>
> On 15.08.24 08:38, Peter Eisentraut wrote:
> > On 08.08.24 19:42, Robert Haas wrote:
> >>> I'm thinking pg_upgrade could have a mode where it adds the
> >>> checksum during the upgrade as it copies the files (essentially a subset
> >>> of
On Wed, Aug 21, 2024 at 9:11 PM Tomas Vondra wrote:
>
>
>
> On 8/8/24 13:48, Jelte Fennema-Nio wrote:
> > SUMMARY OF THREAD
> >
> > The design of patch 0001 is agreed upon by everyone on the thread (so
> > far). This adds the PARTIAL_AGGREGATE label for aggregates, which will
> > cause the finalfu
On Thu, Aug 22, 2024 at 7:22 PM Anthonin Bonnefoy
wrote:
> Ideally, the llvm fix will be merged and backported
> in llvm but the PR has been open for some time now.
I fear that back-porting, for the LLVM project, would mean "we fix it
in main/20.x, and also back-port it to 19.x". Do distros back
Thanks Tom and Ashutosh for your responses!
I also agree that, v1 patch set was applying SQL syntax restrictions to all
FDWs,
which is not reasonable.
PFA v2 patch set. This is based on the suggestion given by Ashutosh to have
the
check in postgres_fdw validator. As it fits to apply the SQL synta
On Wed, Aug 21, 2024 at 4:08 PM Nisha Moond wrote:
>
> The patches have been rebased on the latest pgHead following the merge
> of the conflict detection patch [1].
Thanks for working on patches.
Summarizing the issues which need some suggestions/thoughts.
1)
For subscription based resolvers, c
Hi, Alexander!
On Wed, 21 Aug 2024 at 19:29, Alexander Korotkov
wrote:
> Hi, Pavel!
>
>
> On Wed, Aug 21, 2024 at 4:28 PM Pavel Borisov
> wrote:
> > I've looked at patch v8.
> >
> > 1.
> > In function check_insert_rel_type_cache() the block:
> >
> > +#ifdef USE_ASSERT_CHECKING
> > +
> > +
Hi hackers,
Cc people involved in the related work.
In the original conflict resolution thread[1], we have decided to split the
conflict resolution work into multiple patches to facilitate incremental
progress towards supporting conflict resolution in logical replication, and one
of the work is st
Hello hackers,
While investigating a recent copperhead failure [1] with the following
diagnostics:
2024-08-20 20:56:47.318 CEST [2179731:95] LOG: server process (PID 2184722)
was terminated by signal 11: Segmentation fault
2024-08-20 20:56:47.318 CEST [2179731:96] DETAIL: Failed process was ru
Hi Jelte,
On Thu, 22 Aug 2024 at 09:32, Jelte Fennema-Nio wrote:
> It looks like you want one directory per extension, so that list would
> get pretty long if you have multiple extensions. Maybe (as a follow up
> change), we should start to support a * as a wildcard in both of these
> GUCs. So y
Hi Craig,
On Thu, 22 Aug 2024 at 01:07, Craig Ringer
wrote:
> It's also very relevant for local development and testing.
>
Yep, which is the original goal of Christoph IIRC.
> It may be possible to weaken this restriction somewhat thanks to the
> upcoming
> https://kubernetes.io/blog/2024/08/
Hi All,
Here is a first draft of a patch to implement the ONLY option for
VACUUM and ANALYZE.
I'm a little nervous about the implications of changing the behaviour of VACUUM
for inheritance structures; I can imagine people having regularly
executed scripts
that currently vacuum all the tables in
On Thu, Aug 22, 2024 at 1:33 PM Peter Smith wrote:
>
> Do you think the documentation for the 'column_value' parameter of the
> conflict logging should say that the displayed value might be
> truncated?
>
I updated the patch to mention this and pushed it.
--
With Regards,
Amit Kapila.
I disagree with the point made in the article. The article mentions
that ‘prevents the kernel from reordering reads and writes to optimize
performance,’ which might be referring to the file system’s IO
scheduling and merging. However, this can be handled within the
database itself, where IO schedul
For other approaches, such as whether to use an LRU list to manage the
shared_buffer or to use a clock sweep for management, both methods
have their pros and cons. But for these two issues, there is a clearly
better solution. For example, using DirectIO avoids the problem of
double-copying data, an
On 22.08.24 09:59, Yugo NAGATA wrote:
Although ERRCODE_INVALID_TABLE_DEFINITION is used for en error on changing
type of inherited column, I guess that is because it prevents from breaking
consistency between inherited and inheriting tables as a result of the command.
In this sense, maybe, ERRCO
Hi Mark,
On Wed, Aug 21, 2024 at 2:25 PM Mark Dilger
wrote:
>
>
> For validation purposes, the first patch creates shallow copies of hash and
> btree named "xash" and "xtree" and introduces some infrastructure to run the
> src/test/regress and src/test/isolation tests against them without needi
Hello,
I think that pgstattuple should use PageGetExactFreeSpace() instead of
PageGetHeapFreeSpace() or PageGetFreeSpace(). The latter two compute the
free space minus the space of a line pointer. They are used like this in
the rest of the code (heapam.c):
pagefree = PageGetHeapFreeSpace(pag
Hi Hou-san.
I was experimenting with some conflict logging and found that large
column values are truncated in the log DETAIL.
E.g. Below I have a table where I inserted a 3000 character text value
'bigbigbig..."
Then I caused a replication conflict.
test_sub=# delete fr2024-08-22 17:50:17.181
On Thu, 22 Aug 2024 09:10:52 +0200
Peter Eisentraut wrote:
> On 22.08.24 08:15, Yugo Nagata wrote:
> > On Thu, 22 Aug 2024 11:38:49 +0800
> > jian he wrote:
> >
> >> On Wed, Aug 21, 2024 at 4:57 PM Peter Eisentraut
> >> wrote:
> >>>
> >>
> >> + /*
> >> + * Cannot specify USING when altering t
I ran into a query plan where the Result node seems redundant to me:
create table t (a int, b int, c int);
insert into t select i%10, i%10, i%10 from generate_series(1,100)i;
create index on t (a, b);
analyze t;
set enable_hashagg to off;
set enable_seqscan to off;
explain (verbose, costs off)
s
On Wed, Aug 21, 2024 at 09:29:04AM +0200, Anthonin Bonnefoy wrote:
> Here's the patch with \bindx renamed to \bind_named.
Looks OK to me. I have spent more time double-checking the whole, and
it looks like we're there, so applied. Now let's play with it in more
regression tests. Note that the r
On Tue, Aug 20, 2024 at 11:59:45AM +0300, Heikki Linnakangas wrote:
> On 17/08/2024 07:07, Noah Misch wrote:
> > On Fri, Aug 16, 2024 at 12:26:28PM +0300, Heikki Linnakangas wrote:
> > > I wonder if the functions should be called "systable_*" and placed in
> > > genam.c rather than in heapam.c. The
On Thu, 22 Aug 2024 at 01:08, Craig Ringer
wrote:
> SET extension_search_path = $extsdir,
> /mnt/extensions/pg16/postgis-vX.Y/extensions,
> /mnt/extensions/pg16/gosuperfast/extensions;
It looks like you want one directory per extension, so that list would
get pretty long if you have multiple
On Mon, May 20, 2024 at 10:46 PM Melanie Plageman
wrote:
> On Wed, May 15, 2024 at 2:18 PM Nazir Bilal Yavuz
> wrote:
> >
> > On Mon, 29 Apr 2024 at 18:41, Nazir Bilal Yavuz
> wrote:
> > >
> > > On Mon, 8 Apr 2024 at 04:21, Thomas Munro
> wrote:
> > > I wanted to discuss what will happen to th
Hi!
I have an instance that started to consistently crash with segfault or
bus error and most of the generated coredumps had corrupted stacks.
Some salvageable frames showed the error happening within
ExecRunCompiledExpr. Sure enough, running the query with jit disabled
stopped the crashes. The is
On Thursday, August 22, 2024 11:25 AM shveta malik
wrote:
>
> On Wed, Aug 21, 2024 at 3:04 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> >
> > Attach the V20 patch set which addressed above, Shveta[1][2] and
> > Kuroda-san's[3] comments.
> >
>
> Thank You for the patch. Few comments:
Thanks for the
On 22.08.24 08:15, Yugo Nagata wrote:
On Thu, 22 Aug 2024 11:38:49 +0800
jian he wrote:
On Wed, Aug 21, 2024 at 4:57 PM Peter Eisentraut wrote:
+ /*
+ * Cannot specify USING when altering type of a generated column, because
+ * that would violate the generation expression.
+ */
+ if (attT
1 - 100 of 101 matches
Mail list logo
