On Mon, 24 Apr 2023 at 12:52, Julien Rouhaud wrote:
>
> Hi,
>
> On Tue, Apr 18, 2023 at 01:40:51AM +, Hayato Kuroda (Fujitsu) wrote:
> >
> > I found a cfbot failure on macOS [1]. According to the log,
> > "SELECT count(*) FROM t2" was executed before synchronization was done.
> >
> > ```
> >
On Sat, May 20, 2023 at 10:01 AM Jacob Champion wrote:
> - The client implementation is currently epoll-/Linux-specific. I think
> kqueue shouldn't be too much trouble for the BSDs, but it's even more
> code to maintain.
I guess you also need a fallback that uses plain old POSIX poll()? I
see
Hi
so 1. 7. 2023 v 1:57 odesílatel Joe Conway napsal:
> Greetings,
>
> Attached please find a tarball (rather than a patch) for a proposed new
> contrib extension, pg_stat_logmsg.
>
> The basic idea is to mirror how pg_stat_statements works, except the
> logged messages keyed by filename,
Hi,
On 2023-06-30 14:26:44 +0200, Matthias van de Meent wrote:
> diff --git a/src/backend/postmaster/postmaster.c
> b/src/backend/postmaster/postmaster.c
> index 4c49393fc5..8685b9fde6 100644
> --- a/src/backend/postmaster/postmaster.c
> +++ b/src/backend/postmaster/postmaster.c
> @@ -1002,6
On Thu, Jun 29, 2023 at 3:52 PM Hayato Kuroda (Fujitsu)
wrote:
>
> 2. I want to confirm the reason why new replication command is added.
>
Are you referring LIST_SLOTS command? If so, I don't think that is
required and instead, we can use a query to fetch the required
information.
> IIUC the
>
Hi,
On 2023-06-30 13:44:03 +0200, Alvaro Herrera wrote:
> OK, so here's a new attempt to get this working correctly.
Thanks for continuing to work on this!
> The main novelty in this version of the patch, is that we now emit
> "throwaway" NOT NULL constraints when a column is part of the
Greetings,
Attached please find a tarball (rather than a patch) for a proposed new
contrib extension, pg_stat_logmsg.
The basic idea is to mirror how pg_stat_statements works, except the
logged messages keyed by filename, lineno, and elevel are saved with a
aggregate count. The format
Hi,
On 2023-06-30 16:28:59 -0500, David Christensen wrote:
> On Fri, Jun 30, 2023 at 3:29 PM Andres Freund wrote:
> >> And indeed. Comparing e.g. TPC-H, I see *massive* regressions. Some
> >> queries
> > are the same, sobut others regress by up to 70% (although more commonly
> > around
> >
On Sat, Jul 1, 2023 at 01:18:34AM +0200, Tomas Vondra wrote:
> What does "smartctl -a /dev/nvme0n1" say? There should be something like
> this:
>
> Supported LBA Sizes (NSID 0x1)
> Id Fmt Data Metadt Rel_Perf
> 0 -4096 0 0
> 1 + 512 0 0
>
> which says
On 7/1/23 01:16, Bruce Momjian wrote:
> On Fri, Jun 30, 2023 at 04:04:57PM -0700, Andres Freund wrote:
>> Hi,
>>
>> On 2023-06-30 18:58:20 -0400, Bruce Momjian wrote:
[1] On linux I think you need to use stat() to figure out the st_dev for a
file, then look in /proc/self/mountinfo for
On Fri, Jun 30, 2023 at 04:04:57PM -0700, Andres Freund wrote:
> Hi,
>
> On 2023-06-30 18:58:20 -0400, Bruce Momjian wrote:
> > > [1] On linux I think you need to use stat() to figure out the st_dev for a
> > > file, then look in /proc/self/mountinfo for the block device, use the name
> > > of
On 7/1/23 00:59, Andres Freund wrote:
> On 2023-06-30 18:37:39 -0400, Bruce Momjian wrote:
>> On Sat, Jul 1, 2023 at 12:21:03AM +0200, Tomas Vondra wrote:
>>> On 6/30/23 23:53, Bruce Momjian wrote:
For a 4kB write, to say it is not partially written would be to require
the operating
Hi,
On 2023-06-30 18:58:20 -0400, Bruce Momjian wrote:
> > [1] On linux I think you need to use stat() to figure out the st_dev for a
> > file, then look in /proc/self/mountinfo for the block device, use the name
> > of the file to look in /sys/block/$d/queue/physical_block_size.
>
> I just got a
On Fri, Jun 30, 2023 at 06:58:20PM -0400, Bruce Momjian wrote:
> I just got a new server:
>
> https://momjian.us/main/blogs/blog/2023.html#June_28_2023
>
> so tested this on my new M.2 NVME storage device:
>
> $ /sys/block/nvme0n1/queue/physical_block_size
> 262144
>
> that's
On 2023-06-30 18:37:39 -0400, Bruce Momjian wrote:
> On Sat, Jul 1, 2023 at 12:21:03AM +0200, Tomas Vondra wrote:
> > On 6/30/23 23:53, Bruce Momjian wrote:
> > > For a 4kB write, to say it is not partially written would be to require
> > > the operating system to guarantee that the 4kB write is
On Fri, Jun 30, 2023 at 03:51:18PM -0700, Andres Freund wrote:
> > For a 4kB write, to say it is not partially written would be to require
> > the operating system to guarantee that the 4kB write is not split into
> > smaller writes which might each be atomic because smaller atomic writes
> >
On 7/1/23 00:05, Andres Freund wrote:
> Hi,
>
> On 2023-06-30 23:27:45 +0200, Tomas Vondra wrote:
>> On 6/30/23 23:11, Andres Freund wrote:
>>> ...
>>>
>>> If we really wanted to do this - but I don't think we do - I'd argue for
>>> working on the buildsystem support to build the postgres binary
Hi,
On 2023-06-30 17:53:34 -0400, Bruce Momjian wrote:
> On Fri, Jun 30, 2023 at 11:42:30PM +0200, Tomas Vondra wrote:
> > On 6/30/23 23:11, Andres Freund wrote:
> > > I suspect you're going to see more benefits from going to a *lower*
> > > setting
> > > than a higher one. Some practical issues
On Sat, Jul 1, 2023 at 12:21:03AM +0200, Tomas Vondra wrote:
> On 6/30/23 23:53, Bruce Momjian wrote:
> > For a 4kB write, to say it is not partially written would be to require
> > the operating system to guarantee that the 4kB write is not split into
> > smaller writes which might each be
On Fri, Jun 30, 2023 at 03:18:03PM -0700, Nikolay Samokhvalov wrote:
> I wonder, if we ensure that standbys are fully caught up before upgrading the
> primary, if we check the latest checkpoint positions, are we good to use
> "rsync
> --size-only", or there are still some concerns? It seems so to
On Sat, Jul 01, 2023 at 12:13:26AM +0200, Magnus Hagander wrote:
> Strong +1 from here for removing it, assuming you don't find a bunch
> of users on -general who are using it. Having never come across one
> myself, I think it's unlikely, but I agree it's good to ask.
Cool. I'll let that thread
Hi,
On 2023-06-30 23:42:30 +0200, Tomas Vondra wrote:
> I wonder what are the conditions/options for disabling FPI. I kinda
> assume it'd apply to new drives with 4k sectors, with properly aligned
> partitions etc. But I haven't seen any particularly clear confirmation
> that's correct.
Yea,
On 6/30/23 23:53, Bruce Momjian wrote:
> On Fri, Jun 30, 2023 at 11:42:30PM +0200, Tomas Vondra wrote:
>>
>>
>> On 6/30/23 23:11, Andres Freund wrote:
>>> Hi,
>>>
>>> ...
>>>
>>> I suspect you're going to see more benefits from going to a *lower* setting
>>> than a higher one. Some practical
On Fri, Jun 30, 2023 at 14:33 Bruce Momjian wrote:
> On Fri, Jun 30, 2023 at 04:16:31PM -0400, Robert Haas wrote:
> > I'm not quite clear on how Nikolay got into trouble here. I don't
> > think I understand under exactly what conditions the procedure is
> > reliable and under what conditions it
On Fri, Jun 30, 2023 at 11:43 PM Nathan Bossart
wrote:
>
> On Fri, Jun 30, 2023 at 05:40:18PM -0400, Tom Lane wrote:
> > Might be worth asking on pgsql-general whether anyone knows of
> > active use of this feature. If not, I'm good with killing it.
>
> Will do.
Strong +1 from here for removing
On Fri, Jun 30, 2023 at 10:47 PM Palak Chaturvedi
wrote:
> pgbench=# select count(pg_buffercache_invalidate(bufferid)) from
> pg_buffercache where relfilenode =
> pg_relation_filenode('pgbench_accounts'::regclass);
Hi Palak,
Thanks for working on this! I think this will be very useful for
Hi,
On 2023-06-30 23:27:45 +0200, Tomas Vondra wrote:
> On 6/30/23 23:11, Andres Freund wrote:
> > ...
> >
> > If we really wanted to do this - but I don't think we do - I'd argue for
> > working on the buildsystem support to build the postgres binary multiple
> > times, for 4, 8, 16 kB BLCKSZ
On Fri, Jun 30, 2023 at 11:42:30PM +0200, Tomas Vondra wrote:
>
>
> On 6/30/23 23:11, Andres Freund wrote:
> > Hi,
> >
> > ...
> >
> > I suspect you're going to see more benefits from going to a *lower* setting
> > than a higher one. Some practical issues aside, plenty of storage hardware
> >
On Fri, Jun 30, 2023 at 05:40:18PM -0400, Tom Lane wrote:
> Might be worth asking on pgsql-general whether anyone knows of
> active use of this feature. If not, I'm good with killing it.
Will do.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Jun 30, 2023 at 05:29:04PM -0400, Bruce Momjian wrote:
> I am the original author, and it was a hack designed to support
> per-database user names. I am fine with its removal.
Thanks, Bruce.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On 6/30/23 23:11, Andres Freund wrote:
> Hi,
>
> ...
>
> I suspect you're going to see more benefits from going to a *lower* setting
> than a higher one. Some practical issues aside, plenty of storage hardware
> these days would allow to get rid of FPIs if you go to 4k blocks (although it
>
On Fri, Jun 30, 2023 at 4:17 PM Andres Freund wrote:
>
> Hi,
>
> On 2023-06-30 15:05:54 -0500, David Christensen wrote:
> > > I am fairly certain this is going to be causing substantial performance
> > > regressions. I think we should reject this even if we don't immediately
> > > find
> > >
Nathan Bossart writes:
> I'm personally not aware of anyone using this parameter.
Might be worth asking on pgsql-general whether anyone knows of
active use of this feature. If not, I'm good with killing it.
regards, tom lane
On Wed, Apr 26, 2023 at 03:07:18PM +0300, Aleksander Alekseev wrote:
> The commit message may require a bit of tweaking by the committer but
> other than that the patch seems to be fine. I'm going to mark it as
> RfC in a bit unless anyone objects.
In v4, I've introduced a new BGW_LIBLEN macro
On Fri, Jun 30, 2023 at 05:29:17PM +0900, Masahiro Ikeda wrote:
> Hi,
>
> Thanks for making the release notes. I found the release note of
> PG16 beta2 mentions a reverted following feature.
>
> ```
>
>
>
>
> Have initdb use ICU by default if ICU is enabled in the binary (Jeff Davis)
>
>
>
On Fri, Jun 30, 2023 at 4:27 PM Tomas Vondra
wrote:
> On 6/30/23 23:11, Andres Freund wrote:
> > ...
> >
> > If we really wanted to do this - but I don't think we do - I'd argue for
> > working on the buildsystem support to build the postgres binary multiple
> > times, for 4, 8, 16 kB BLCKSZ and
On Fri, Jun 30, 2023 at 04:16:31PM -0400, Robert Haas wrote:
> On Fri, Jun 30, 2023 at 1:41 PM Bruce Momjian wrote:
> > I think --size-only was chosen only because it is the minimal comparison
> > option.
>
> I think it's worse than that. I think that the procedure relies on
> using the
On Fri, Jun 30, 2023 at 4:12 PM Tomas Vondra
wrote:
>
>
>
> On 6/30/23 22:05, David Christensen wrote:
> > On Fri, Jun 30, 2023 at 2:39 PM Andres Freund wrote:
> >>
> >> ...
> >>
> >> Besides this, I've not really heard any convincing justification for
> >> needing
> >> this in the first place.
On Fri, Jun 30, 2023 at 3:29 PM Andres Freund wrote:
>> And indeed. Comparing e.g. TPC-H, I see *massive* regressions. Some queries
> are the same, sobut others regress by up to 70% (although more commonly around
> 10-20%).
Hmm, that is definitely not good.
> That's larger than I thought,
On Fri, Jun 30, 2023 at 01:05:09PM -0700, Nathan Bossart wrote:
> I think this is the second decennial thread [0] for removing this GUC.
> This topic came up at PGCon, so I thought I'd start the discussion on the
> lists.
>
> I'm personally not aware of anyone using this parameter. A couple of
On 6/30/23 23:11, Andres Freund wrote:
> ...
>
> If we really wanted to do this - but I don't think we do - I'd argue for
> working on the buildsystem support to build the postgres binary multiple
> times, for 4, 8, 16 kB BLCKSZ and having a wrapper postgres binary that just
> exec's the
Hi,
On 2023-06-30 15:05:54 -0500, David Christensen wrote:
> > I am fairly certain this is going to be causing substantial performance
> > regressions. I think we should reject this even if we don't immediately
> > find
> > them, because it's almost guaranteed to cause some.
>
> What would be
On 6/30/23 22:05, David Christensen wrote:
> On Fri, Jun 30, 2023 at 2:39 PM Andres Freund wrote:
>>
>> ...
>>
>> Besides this, I've not really heard any convincing justification for needing
>> this in the first place.
>
> Doing this would open up experiments in larger block sizes, so we
>
On Fri, Jun 30, 2023 at 01:05:09PM -0700, Nathan Bossart wrote:
> The attached patch simply removes the GUC.
And here's a new version of the patch with docs that actually build.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 3b7fdd41eb429bc9bb03dcecf38126fbc63dafa3 Mon Sep
Hi,
On 2023-06-30 14:09:55 -0500, David Christensen wrote:
> On Fri, Jun 30, 2023 at 1:14 PM Tomas Vondra
> > I wonder how to best evaluate/benchmark this. AFAICS what we want to
> > measure is the extra cost of making the values dynamic (which means the
> > compiler can't just optimize them
On Fri, Jun 30, 2023 at 1:41 PM Bruce Momjian wrote:
> I think --size-only was chosen only because it is the minimal comparison
> option.
I think it's worse than that. I think that the procedure relies on
using the --size-only option to intentionally trick rsync into
thinking that files are
On Fri, Jun 30, 2023 at 2:39 PM Andres Freund wrote:
>
> Hi,
>
> On 2023-06-30 12:35:09 -0500, David Christensen wrote:
> > As discussed somewhat at PgCon, enclosed is v1 of a patch to provide
> > variable block sizes; basically instead of BLCKSZ being a compile-time
> > constant, a single set of
I think this is the second decennial thread [0] for removing this GUC.
This topic came up at PGCon, so I thought I'd start the discussion on the
lists.
I'm personally not aware of anyone using this parameter. A couple of my
colleagues claimed to have used it in the aughts, but they also noted
Hi,
On 2023-06-30 12:35:09 -0500, David Christensen wrote:
> As discussed somewhat at PgCon, enclosed is v1 of a patch to provide
> variable block sizes; basically instead of BLCKSZ being a compile-time
> constant, a single set of binaries can support all of the block sizes
> Pg can support,
On Fri, Jun 30, 2023 at 1:14 PM Tomas Vondra
wrote:
> Do we really want to prefix the option with CLUSTER_? That seems to just
> add a lot of noise into the patch, and I don't see much value in this
> rename. I'd prefer keeping BLCKSZ and tweak just the couple places that
> need "default" to use
Hi,
Good catch. Indeed, eb.rel shouldn't be NULL there and the tests should be
unnecessary. However, it doesn't follow from the code of these functions.
>From what I can see eb.rel can be NULL in both of these functions. There is
the following Assert in the beginning of the ExtendBufferedRelTo()
On Thu, Jun 29, 2023 at 10:09:21PM -0700, Nathan Bossart wrote:
> On Thu, Jun 29, 2023 at 08:53:56PM -0400, Tom Lane wrote:
>> I'm leaning to Robert's thought that we need to revert this for now,
>> and think harder about how to make it work cleanly and safely.
>
> Since it sounds like this is
On Mon, May 15, 2023 at 12:36:51PM -0700, Nathan Bossart wrote:
> On Tue, Apr 25, 2023 at 03:18:44PM +0900, Michael Paquier wrote:
>> FWIW, I agree to hold on this stuff for v17~ once it opens for
>> business. There is no urgency here.
>
> There's still some time before we'll be able to commit
On 6/30/23 19:35, David Christensen wrote:
> Hi,
>
> As discussed somewhat at PgCon, enclosed is v1 of a patch to provide
> variable block sizes; basically instead of BLCKSZ being a compile-time
> constant, a single set of binaries can support all of the block sizes
> Pg can support, using the
> This needs to adjust the tests in src/test/ssl which now fails due to SELECT
> *
> returning a row which doesn't match what the test was coded for.
Thank you so much for pointing out. I have adjusted the extra ssl test to
account for the extra columns returned. It should not fail now.
>
On Wed, Jun 21, 2023 at 8:52 PM Kirk Wolak wrote:
> On Mon, Jun 5, 2023 at 7:43 AM Jelte Fennema wrote:
>
>> On Thu, 1 Jun 2023 at 18:57, Kirk Wolak wrote:
>> > Can this get turned into a Patch? Were you offering this code up for
>> others (me?) to pull, and work into a patch?
>> > [If I do
On Thu, Jun 29, 2023 at 02:38:58PM -0400, Robert Haas wrote:
> On Thu, Jun 29, 2023 at 1:50 PM Nikolay Samokhvalov wrote:
> > Does this make sense or I'm missing something and the current docs describe
> > a reliable process? (As I said, we have deviated from the process, to
> > involve logical
Hi,
On 6/30/23 5:54 PM, Tom Lane wrote:
Nathan Bossart writes:
After taking another look at this, I wonder if it'd be better to fail as
soon as we see the database or user name is too long instead of lugging
them around when authentication is destined to fail.
If we're agreed that we aren't
Seino Yuki writes:
> Of course, executing SET TRANSACTION ISOLATION LEVEL with SPI_execute
> will result in error.
> ---
> SPI_execute("SET TRANSACTION ISOLATION LEVEL SERIALIZABLE", false, 0);
> (Log Output)
> ERROR: SET TRANSACTION ISOLATION LEVEL must be called before any query
> CONTEXT:
On 2023-07-01 00:06, Tom Lane wrote:
Seino Yuki writes:
I also thought that using SPI_start_transaction would be more readable
than using SPI_commit/SPI_rollback to implicitly start a transaction.
What do you think?
I think you're trying to get us to undo commit 2e517818f, which
is not going
Em sex., 30 de jun. de 2023 às 13:00, Alexander Lakhin
escreveu:
> Hello Karina,
>
> 30.06.2023 17:25, Karina Litskevich wrote:
> > Hi,
> >
> > Alexander wrote:
> >
> >> It also aligns the code with print_unaligned_vertical(), but I can't
> see why
> >> need_recordsep = true;
> >> is a no-op
Em sex., 30 de jun. de 2023 às 11:26, Karina Litskevich <
litskevichkar...@gmail.com> escreveu:
> Hi,
>
> Alexander wrote:
>
> > It also aligns the code with print_unaligned_vertical(), but I can't see
> why
> > need_recordsep = true;
> > is a no-op here (scan-build dislikes only need_recordsep =
Hello Karina,
30.06.2023 17:25, Karina Litskevich wrote:
Hi,
Alexander wrote:
It also aligns the code with print_unaligned_vertical(), but I can't see why
need_recordsep = true;
is a no-op here (scan-build dislikes only need_recordsep = false;).
I suspect that removing that line will change
Nathan Bossart writes:
> After taking another look at this, I wonder if it'd be better to fail as
> soon as we see the database or user name is too long instead of lugging
> them around when authentication is destined to fail.
If we're agreed that we aren't going to truncate these identifiers,
After taking another look at this, I wonder if it'd be better to fail as
soon as we see the database or user name is too long instead of lugging
them around when authentication is destined to fail.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Heikki Linnakangas writes:
> Except for the translator comments, I think those others forgot about
> the end-guards by accident. But they look just as nice to me. It's
> probably not worth the code churn to remove them from existing comments,
> but how about we stop requiring them in new code,
I spotted this comment in walsender.c:
/*---
* When reading from a historic timeline, and there is a timeline switch
* [.. long comment omitted ...]
* portion of the old segment is copied to the new file. ---
*/
Note the bogus dashes at the
Seino Yuki writes:
> I also thought that using SPI_start_transaction would be more readable
> than using SPI_commit/SPI_rollback to implicitly start a transaction.
> What do you think?
I think you're trying to get us to undo commit 2e517818f, which
is not going to happen. See the threads that
Richard Guo writes:
> On Fri, Jun 30, 2023 at 12:20 AM Tom Lane wrote:
>> Yeah, while looking at this I was wondering why try_mergejoin_path and
>> try_hashjoin_path don't do the same "Paths are parameterized by
>> top-level parents, so run parameterization tests on the parent relids"
>> dance
Thanks for the reply!
On 2023-06-30 23:26, Heikki Linnakangas wrote:
On 30/06/2023 17:15, Seino Yuki wrote:
Hi,
When I read the documents and coding of SPI, [1]
I found that the following the SPI_start_transaction does not support
transaciton_mode(ISOLATION LEVEL, READ WRITE/READ ONLY) like
On 30/06/2023 17:15, Seino Yuki wrote:
Hi,
When I read the documents and coding of SPI, [1]
I found that the following the SPI_start_transaction does not support
transaciton_mode(ISOLATION LEVEL, READ WRITE/READ ONLY) like BEGIN
command. [2]
Is there a reason for this?
Per the documentation
Hi,
Alexander wrote:
> It also aligns the code with print_unaligned_vertical(), but I can't see why
> need_recordsep = true;
> is a no-op here (scan-build dislikes only need_recordsep = false;).
> I suspect that removing that line will change the behaviour in cases when
> need_recordsep = false
Hi,
When I read the documents and coding of SPI, [1]
I found that the following the SPI_start_transaction does not support
transaciton_mode(ISOLATION LEVEL, READ WRITE/READ ONLY) like BEGIN
command. [2]
Is there a reason for this?
I would like to be able to set transaciton_mode in
Dear Amit,
Thank you for giving comments!
> > > Sorry for the delay, I didn't had time to come back to it until this
> > > afternoon.
> >
> > No issues, everyone is busy:-).
> >
> > > I don't think that your analysis is correct. Slots are guaranteed to be
> > > stopped after all the normal
Hi hackers,
At Neon, we've been working on removing the file system dependency
from PostgreSQL and replacing it with a distributed storage layer. For
now, we've seen most success in this by replacing the implementation
of the smgr API, but it did require some core modifications like those
On 6/29/23 22:13, Tristan Partin wrote:
On Mon Jun 5, 2023 at 11:00 AM CDT, Heikki Linnakangas wrote:
I think the uselocale() call renders ineffective the setlocale() calls
that we make later. Maybe we should replace our setlocale() calls with
uselocale(), too.
For what it's worth to
Hi,
attached is a v4 of the patch, with a fairly major shift in the approach.
Until now the patch very much relied on the AM to provide information
which blocks to prefetch next (based on the current leaf index page).
This seemed like a natural approach when I started working on the PoC,
but
On 4/4/2023 02:30, Gregory Stark (as CFM) wrote:
On Mon, 6 Mar 2023 at 00:30, Michał Kłeczek wrote:
Hi All,
I just wanted to ask about the status and plans for this patch.
I can see it being stuck at “Waiting for Author” status in several commit tests.
Sadly it seems to now be badly in
I hope this email finds you well. I am excited to share that I have
extended the functionality of the `pg_buffercache` extension by
implementing buffer invalidation capability, as requested by some
PostgreSQL contributors for improved testing scenarios.
This marks my first time submitting a patch
Michael Paquier writes:
> On Wed, Jun 14, 2023 at 10:30:23AM +0100, Dagfinn Ilmari Mannsåker wrote:
>> Thanks for the review!
>
> v17 is now open, so applied this one.
Thanks for committing!
- ilmari
Michael Paquier writes:
> On Tue, May 09, 2023 at 12:26:16PM +0900, Michael Paquier wrote:
>> That looks pretty much OK to me. One tiny comment I have is that this
>> lacks brackets for the inner blocks, so I have added some in the v4
>> attached.
>
> The indentation was a bit wrong, so fixed
All rebased and tested
--
Ivan Kartyshov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres comp...@postgrespro.ru>
diff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c
index becc2bda62..c7460bd9b8 100644
---
Hi,
Thanks for making the release notes. I found the release note of
PG16 beta2 mentions a reverted following feature.
```
Have initdb use ICU by default if ICU is enabled in the binary (Jeff
Davis)
Option --locale-provider=libc can be used to disable ICU.
```
Unfortunately, the
> On 30 Jun 2023, at 09:09, Michael Paquier wrote:
>
> On Thu, Jun 29, 2023 at 09:05:59AM -0700, Jacob Champion wrote:
>> Sounds good -- 0002 can be ignored as needed, then. (Or I can resend a
>> v3 for CI purposes, if you'd like.)
>
> I am assuming that this is 0001 posted here:
>
On Thu, 2023-06-29 at 20:53 -0400, Tom Lane wrote:
> I think that's a seriously awful kluge. It will mean that things
> behave
> differently for the owner than for MAINTAIN grantees, which pretty
> much
> destroys the use-case for that privilege, as well as being very
> confusing
> and hard to
On Thu, Jun 29, 2023 at 09:05:59AM -0700, Jacob Champion wrote:
> Sounds good -- 0002 can be ignored as needed, then. (Or I can resend a
> v3 for CI purposes, if you'd like.)
I am assuming that this is 0001 posted here:
On Wed, Jun 28, 2023 at 4:30 PM Amit Langote wrote:
>
> Hi,
>
> On Tue, Feb 21, 2023 at 4:12 PM Amit Langote wrote:
> > On Tue, Feb 21, 2023 at 12:40 AM Tom Lane wrote:
> > > Alvaro Herrera writes:
> > > > On 2023-Feb-20, Amit Langote wrote:
> > > >> One more thing we could try is come up with
On Fri, Jun 23, 2023 at 05:37:09PM +0900, torikoshia wrote:
> On 2023-06-22 16:47, Kyotaro Horiguchi wrote:
> Thanks for your review!
I have begun cleaning up my board, and applied 0001 for the moment.
--
Michael
signature.asc
Description: PGP signature
On Wed, Feb 15, 2023 at 11:23 AM John Naylor
wrote:
>
>
> On Tue, Feb 14, 2023 at 5:46 PM David Rowley wrote:
> >
> > I didn't do a detailed review of the sort patch, but I did wonder
> > about the use of the name "fallback" in the new functions. The
> > comment in the following snippet from
Hi Kuroda-san,
On 6/29/23 12:22 PM, Hayato Kuroda (Fujitsu) wrote:
Dear Drouvot,
Hi, I'm also interested in the feature. Followings are my high-level comments.
I did not mention some detailed notations because this patch is not at the
stage.
And very sorry that I could not follow all of this
90 matches
Mail list logo
