On 13.04.2025 08:29, Tom Lane wrote:
Abhishek Chanda writes:
Currently, some slash commands in psql return an error saying "Did not
find any named " while some return an empty table. This patch
changes a few of the slash commands to return a similar error message.
+1 for this patch.
Hello Andres,
07.04.2025 22:10, Alexander Lakhin wrote:
I ran it for a while in a VM, it hasn't triggered yet. Neither on xfs nor on
tmpfs.
Before sharing the script I tested it on two my machines, but I had
anticipated that the error can be hard to reproduce. Will try to reduce
the reproducer
Abhishek Chanda writes:
> Currently, some slash commands in psql return an error saying "Did not
> find any named " while some return an empty table. This patch
> changes a few of the slash commands to return a similar error message.
Personally, if I were trying to make these things cons
Sorry, I forgot to attach example usage. Here is how these currently behave:
postgres=> \dT foo
List of data types
Schema | Name | Description
+--+-
(0 rows)
postgres => \du foo
List of roles
Role name | Attributes
---+
postgres => \df foo
Hello hackers,
Currently, some slash commands in psql return an error saying "Did not
find any named " while some return an empty table. This patch
changes a few of the slash commands to return a similar error message.
I did not change all of the slash commands in this initial patch to
wa
On Sat, Apr 12, 2025 at 07:51:06PM +0200, Wolfgang Walther wrote:
> With injection points enabled, I get the following errors in test_aio:
>
>
> [15:14:45.408](0.000s) not ok 187 - worker: first hard IO error is reported:
> expected stderr
> [15:14:45.409](0.000s)
> [15:14:45.409](0.000s) # Fai
Hi Andrew.
I just saw the fix commit.
My fault.
I'm sorry.
best regards,
Ranier Vilela
On Sat, 12 Apr 2025 at 23:56, Andrew Dunstan wrote:
>
>
> On 2025-04-11 Fr 1:36 PM, Mahendra Singh Thalor wrote:
> > Hi,
> > In the current master code, 3 places we are using appendStringInfoChar
> > call with explicit type conversion into char. This is not needed as
> > all other places, we are u
>
> You might be getting confused because the code does look at the
> pg_class fields, but that's only to estimate the tuple density. When
> pg_class has those estimates, they're used to calculate the estimated
> density by doing reltuples / relpages, but that average rows per page
>
>
Thanks for t
On 2025-04-11 Fr 1:36 PM, Mahendra Singh Thalor wrote:
Hi,
In the current master code, 3 places we are using appendStringInfoChar
call with explicit type conversion into char. This is not needed as
all other places, we are using direct character to append.
--- a/src/backend/tcop/postgres.c
+++
I recently enabled more features on my two buildfarm animals basilisk
and dogfish, which are running on Alpine with musl-libc in a docker
container.
--with-libnuma and --with-liburing seemed to work fine and have been
enabled for the last few runs, but --enable-injection-points does not [1].
Working on the patch. I will update you.
-Sriram.
It's hard to know how to set io_workers=3. If it's too small,
io_method=worker's small submission queue overflows and it silently
falls back to synchronous IO. If it's too high, it generates a lot of
pointless wakeups and scheduling overhead, which might be considered
an independent problem or no
Here are some stats wrt to loop and native memset after enabling optimization
with the same test tool(tested for long and long align using MemSetAligned).
Corresponding glibc is linked on PPcle and AIX libc is linked on AIX.
https://postgrespro.com/list/thread-id/1673194
On Mon, Dec 02, 2024 at 10:24:07PM -0800, Jeff Davis wrote:
> On Mon, 2024-12-02 at 17:25 -0500, Tom Lane wrote:
> > > Should I put the special case back?
> >
> > I think so.
>
> Done. I put the special case back in (commit e3fa2b037c) because the
> earlier commit wasn't intended to be a behavio
On Sat, 12 Apr 2025 at 20:29, Corey Huinker wrote:
>>
>> at the *actual size* of the relation and takes that into account when
>> scaling the statistics (see table_block_relation_estimate_size() in
>> tableam.c). If the table sizes don't match between the two servers
>> then there's no guarantees
>
> The whole thing might take about 20 to 30 hours wall-clock time.
>
After this dev cycle, things with a defined end to them hold a greater
attraction than they did previously.
> So, there is some time to think about this. Please discuss here if
> you're interested or have questions.
>
I am
>
> * Question
>
> By using Statistics Import and Export feature, is it possible to achieve
> the above request by following procedure?
>
>
>
> (1) Export the statistics from production environment by using pg_dump
> --statistics-only.
>
> (2) On the staging environment, set the autovacuum related
>
> at the *actual size* of the relation and takes that into account when
> scaling the statistics (see table_block_relation_estimate_size() in
> tableam.c). If the table sizes don't match between the two servers
> then there's no guarantees the planner will produce the same plan.
>
Sorry that I d
On Tue, Apr 8, 2025 at 1:43 AM Andres Freund wrote:
> On 2025-04-07 16:03:48 +0300, Nazir Bilal Yavuz wrote:
> > On Wed, 5 Mar 2025 at 18:51, Andres Freund wrote:
> > > I'm inclined to think we should apply to this to all branches with CI
> > > support,
> > > not just master. It's kind of annoyi
20 matches
Mail list logo
