On Fri, Nov 10, 2023 at 08:32:34PM +0900, torikoshia wrote:
> On 2023-11-10 13:18, Andres Freund wrote:
>> I see no reason to not include slrus. We should never have added the
>> ability to reset them individually, particularly not without a use
>> case - I couldn't find one skimming some
On Fri, Nov 10, 2023 at 01:15:50PM +0900, Michael Paquier wrote:
> The comments added could be better grammatically, but basically LGTM.
> I'll take care of that if there are no objections.
The documentation also needed a few tweaks (for DEFAULT and the
argument name), so I have fixed the whole
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 mean that it necessarily needs to be ordered
according to the
We're about 1/3 of the way through.
At start:
Needs review: 210. Waiting on Author: 42. Ready for Committer: 29.
Committed: 55. Withdrawn: 10. Returned with Feedback: 1. Total: 347.
Today:
Needs review: 197. Waiting on Author: 45. Ready for Committer: 27.
Committed: 63. Withdrawn: 10. Returned
On Sat, Nov 11, 2023 at 09:38:53AM +0900, Michael Paquier wrote:
> On Sat, Nov 11, 2023 at 08:00:00AM +0800, jian he wrote:
>> diff --git a/src/test/regress/sql/type_sanity.sql
>> b/src/test/regress/sql/type_sanity.sql
>> index a546ba89..6d806941 100644
>> ---
Hi,
On 2023-11-06 20:47:34 -0600, Nathan Bossart wrote:
> Separately, I'm wondering whether we should consider using CFLAGS_VECTORIZE
> on the whole tree. Commit fdea253 seems to be responsible for introducing
> this targeted autovectorization strategy, and AFAICT this was just done to
>
On Sun, Nov 12, 2023 at 12:17:54PM +1300, Thomas Munro wrote:
> No opinion on potential advantages to other approaches, but I don't
> see why this way shouldn't be expected to work. So I hope you can
> drop that diff.
Another thing that could be done in stable branches is just to switch
On Sun, Nov 12, 2023 at 9:03 AM Christoph Berg wrote:
> The PGBINDIR mangling is exactly what is breaking the use case now.
> The commit that removed that bit in the 15 branch explains why it was
> there:
>
>
On Sat, Nov 11, 2023 at 07:38:59PM +0700, John Naylor wrote:
> On Tue, Nov 7, 2023 at 9:47 AM Nathan Bossart
> wrote:
>> Separately, I'm wondering whether we should consider using CFLAGS_VECTORIZE
>> on the whole tree. Commit fdea253 seems to be responsible for introducing
>> this targeted
On Wed, 8 Nov 2023 at 02:53, Peter Geoghegan wrote:
>
> On Tue, Nov 7, 2023 at 4:20 AM Matthias van de Meent
> wrote:
> > On Tue, 7 Nov 2023 at 00:03, Peter Geoghegan wrote:
> > > I should be able to post v6 later this week. My current plan is to
> > > commit the other nbtree patch first (the
That's a lot of questions :). Let me try:
> In your chroot after it fails, can you please find xlog_internal.h
> somewhere under tmp_install and tell us the full path, and can you
./build/tmp_install/usr/include/postgresql/13/server/access/xlog_internal.h
./src/include/access/xlog_internal.h
>
Hi,
On 2023-11-12 07:17:02 +1300, Thomas Munro wrote:
> On Sun, Nov 12, 2023 at 12:53 AM Christoph Berg wrote:
> > Re: Thomas Munro
> > > In the 13 branch we see that's in the new scan_server_header()
> > > subroutine where it tries to open the header, after asking pg_config
> > >
Hackers,
As promised in [1], attached are some basic tests for the low-level
backup method.
There are currently no tests for the low-level backup method.
pg_backup_start() and pg_backup_stop() are called but not exercised in
any real fashion.
There is a lot more that can be done, but this
On Sun, Nov 12, 2023 at 7:27 AM Christoph Berg wrote:
> I can confirm that it's also failing in my local chroots if none of
> the postgresql-* packages are preinstalled.
In your chroot after it fails, can you please find xlog_internal.h
somewhere under tmp_install and tell us the full path, and
Re: Thomas Munro
> But then why does that only happen on the salsa build,
> not on the apt.postgresql.org one?
The build chroots there have postgresql-NN already installed so
extension builds don't have to download 7 PG versions over and over.
My guess would be that that's the difference and it's
On Sun, Nov 12, 2023 at 12:53 AM Christoph Berg wrote:
> Re: Thomas Munro
> > In the 13 branch we see that's in the new scan_server_header()
> > subroutine where it tries to open the header, after asking pg_config
> > --includedir-server where it lives. Hmm...
>
> It's no ok to use pg_config at
On Sat, Nov 11, 2023 at 7:49 AM Tom Lane wrote:
> Vladimir Churyukin writes:
> > Why not have an option to return EXPLAIN results as a NoticeResponse
> > instead? That would make its usage more convenient.
>
> That seems quite useless to me, and likely actually counterproductive.
> If you are
11.11.2023 18:18, Andrew Dunstan wrote:
Hmm, maybe we should be using File::Copy::move() instead of rename(). The docco
for that says:
If possible, move() will simply rename the file. Otherwise, it
copies the file to the new location and deletes the original. If an
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 C:/tools/nmsys64/tmp/63ohSgsh21 -p 54699 --checkpoint
Thank you, that answers the first part of my question.
On Sat, Nov 11, 2023 at 2:43 AM Sergei Kornilov wrote:
> Hello
>
> auto_explain.log_level is available since postgresql 12.
>
> postgres=# load 'auto_explain';
> LOAD
> postgres=# set auto_explain.log_min_duration to 0;
> SET
> postgres=#
Vladimir Churyukin writes:
> Why not have an option to return EXPLAIN results as a NoticeResponse
> instead? That would make its usage more convenient.
That seems quite useless to me, and likely actually counterproductive.
If you are manually investigating query performance, you can just use
Hi, Alexander
On 2023-11-11 Sa 08:00, Alexander Lakhin wrote:
Hello Andrew,
08.07.2023 18:52, Andrew Dunstan wrote:
Since this test is passing on HEAD which has slightly shorter paths, I'm
wondering if we should change this:
rename("$pgdata/pg_replslot", "$tempdir/pg_replslot")
Hello Andrew,
08.07.2023 18:52, Andrew Dunstan wrote:
Since this test is passing on HEAD which has slightly shorter paths, I'm
wondering if we should change this:
rename("$pgdata/pg_replslot", "$tempdir/pg_replslot")
or BAIL_OUT "could not move $pgdata/pg_replslot";
On Tue, Nov 7, 2023 at 9:47 AM Nathan Bossart wrote:
> Separately, I'm wondering whether we should consider using CFLAGS_VECTORIZE
> on the whole tree. Commit fdea253 seems to be responsible for introducing
> this targeted autovectorization strategy, and AFAICT this was just done to
> minimize
Hello Heikki,
10.11.2023 17:26, Heikki Linnakangas wrote:
I think that is surprising behavior from the DSA facility. When you make allocations with dsa_allocate() or just call
dsa_get_address() on an existing dsa_pointer, you wouldn't expect the current resource owner to matter. I think
Re: Thomas Munro
> In the 13 branch we see that's in the new scan_server_header()
> subroutine where it tries to open the header, after asking pg_config
> --includedir-server where it lives. Hmm...
It's no ok to use pg_config at test time since `make install` might
not have been called yet:
Hello
auto_explain.log_level is available since postgresql 12.
postgres=# load 'auto_explain';
LOAD
postgres=# set auto_explain.log_min_duration to 0;
SET
postgres=# set auto_explain.log_level to 'notice';
SET
postgres=# select 1;
NOTICE: duration: 0.010 ms plan:
Query Text: select 1;
Result
Hello,
I'm not sure if these ideas were circulated before or not.
We use auto_explain a lot to investigate slow/problematic queries.
One of the main issues with its usability comes from the fact that EXPLAIN
output is logged rather than returned to the caller in some way. If you
have a large
On Thu, Feb 2, 2023 at 10:03 AM vignesh C wrote:
>
> On Wed, 1 Feb 2023 at 14:49, Alvaro Herrera wrote:
> >
> > On 2023-Jan-31, vignesh C wrote:
> >
> > > On Tue, 3 Jan 2023 at 18:38, vignesh C wrote:
> > > There has been no updates on this thread for some time, so this has
> > > been switched
Hi,
I was adding support for the new pg_stat_statements JIT deform_counter in PoWA
when I realized that those were added after jit_generation_time in the
documentation while they're actually at the end of the view. I'm adding Daniel
in Cc as the committer of the original patch.
It looks like
30 matches
Mail list logo
