Hi,
On Thu, Mar 21, 2024 at 11:53:32AM +0530, Amit Kapila wrote:
> On Thu, Mar 21, 2024 at 11:37 AM Bertrand Drouvot
> wrote:
> >
> > We could also do the above 3 and altering the timeout with a replication
> > connection but the SQL API seems more natural to me.
> >
>
> If we want to go with th
Hi,
On Thu, Mar 21, 2024 at 11:43:54AM +0530, Amit Kapila wrote:
> On Thu, Mar 21, 2024 at 11:23 AM Bertrand Drouvot
> wrote:
> >
> > On Thu, Mar 21, 2024 at 08:47:18AM +0530, Amit Kapila wrote:
> > > On Wed, Mar 20, 2024 at 1:51 PM Bertrand Drouvot
> > > wrote:
> > > >
> > > > On Wed, Mar 20, 2
Hi,
On 2024-03-20 17:41:45 -0700, Andres Freund wrote:
> 2024-03-20 22:14:01.904 UTC [56343][client backend][6/1925:0] LOG:
> connection authorized: user=bf database=postgres
> application_name=027_stream_regress.pl
> 2024-03-20 22:14:01.930 UTC [56343][client backend][6/1926:0] LOG:
> statem
On Tue, 2024-03-19 at 05:16 -0400, Corey Huinker wrote:
> v11 attached.
Thank you.
Comments on 0001:
This test:
+SELECT
+format('SELECT pg_catalog.pg_set_attribute_stats( '
...
seems misplaced. It's generating SQL that can be used to restore or
copy the stats -- that seems like th
On Thu, Mar 21, 2024 at 11:37 AM Bertrand Drouvot
wrote:
>
> On Thu, Mar 21, 2024 at 10:53:54AM +0530, Bharath Rupireddy wrote:
> > On Thu, Mar 21, 2024 at 9:07 AM Amit Kapila wrote:
> > > > > But the issue is that it would make it inconsistent with the new
> > > > > inactivetimeout
> > > > > in
> On 29 Jun 2022, at 17:43, Robins Tharakan wrote:
Sorry to bump ancient thread, I have some observations that might or might not
be relevant.
Recently we noticed a corruption on one of clusters. The corruption at hand is
not in system catalog, but in user indexes.
The cluster was correctly
On Thu, Mar 21, 2024 at 11:23 AM Bertrand Drouvot
wrote:
>
> On Thu, Mar 21, 2024 at 08:47:18AM +0530, Amit Kapila wrote:
> > On Wed, Mar 20, 2024 at 1:51 PM Bertrand Drouvot
> > wrote:
> > >
> > > On Wed, Mar 20, 2024 at 12:48:55AM +0530, Bharath Rupireddy wrote:
> > > >
> > > > 2. last_inactive
On Thu, Mar 21, 2024 at 12:40 PM John Naylor wrote:
>
> On Thu, Mar 21, 2024 at 9:37 AM Masahiko Sawada wrote:
> >
> > On Wed, Mar 20, 2024 at 11:19 PM John Naylor
> > wrote:
> > > Are they (the blocks to be precise) really out of order? The VALUES
> > > statement is ordered, but after insertin
Hi,
On Thu, Mar 21, 2024 at 10:53:54AM +0530, Bharath Rupireddy wrote:
> On Thu, Mar 21, 2024 at 9:07 AM Amit Kapila wrote:
> > > > But the issue is that it would make it inconsistent with the new
> > > > inactivetimeout
> > > > in the subscription that is added in "v12-0005".
> > >
> > > Can yo
Hi,
On Thu, Mar 21, 2024 at 08:47:18AM +0530, Amit Kapila wrote:
> On Wed, Mar 20, 2024 at 1:51 PM Bertrand Drouvot
> wrote:
> >
> > On Wed, Mar 20, 2024 at 12:48:55AM +0530, Bharath Rupireddy wrote:
> > >
> > > 2. last_inactive_at and inactive_timeout are now tracked in on-disk
> > > replication
On Wed, Mar 20, 2024 at 6:21 PM Andres Freund wrote:
> Hi,
>
> On 2024-03-21 11:02:27 +1300, David Rowley wrote:
> > On Thu, 21 Mar 2024 at 11:00, Andres Freund wrote:
> > >
> > > On 2024-03-20 17:49:14 -0400, Dave Cramer wrote:
> > > > First off this is on an ARM64 machine
> > >
> > > Uh, that'
Hi Aadhav Vignesh,
Interestingly, Alexander asked for ideas for GSoC projects at Supabase
(I'm on the Auth team), and I proposed the RLS templates idea. As you
already pointed out, the idea comes out of us seeing how RLS policies
are used in real-life and the pain points associated with managing a
Hi, Alexander!
On Wed, 20 Mar 2024 at 09:22, Pavel Borisov wrote:
> Hi, Alexander!
>
> For 0007:
>
> Code inside
>
> +heapam_reloptions(char relkind, Datum reloptions, bool validate)
> +{
> + if (relkind == RELKIND_RELATION ||
> + relkind == RELKIND_TOASTVALUE ||
> + relkind == RE
On Thu, Mar 21, 2024 at 8:47 AM Amit Kapila wrote:
>
> On Wed, Mar 20, 2024 at 1:51 PM Bertrand Drouvot
> wrote:
> >
> > On Wed, Mar 20, 2024 at 12:48:55AM +0530, Bharath Rupireddy wrote:
> > >
> > > 2. last_inactive_at and inactive_timeout are now tracked in on-disk
> > > replication slot data s
On Thu, Mar 21, 2024 at 9:07 AM Amit Kapila wrote:
>
> I also don't see any obvious problem with such an API. However, this
> is not a good time to invent new APIs. Let's keep the feature simple
> and then we can extend it in the next version after more discussion
> and probably by that time we wi
On Wed, Mar 20, 2024, at 7:16 AM, Shubham Khanna wrote:
> On Tue, Mar 19, 2024 at 8:54 PM vignesh C wrote:
> >
> > If you are not planning to have the checks for name length, this could
> > alternatively be fixed by including database id also while querying
> > pg_subscription like below in set_re
On Tue, Mar 19, 2024, at 8:57 AM, Peter Eisentraut wrote:
> On 19.03.24 12:26, Shlok Kyal wrote:
> >
> > I have added a top-up patch v30-0003. The issue in [1] still exists in
> > the v30 patch. I was not able to come up with an approach to handle it
> > in the code, so I have added it to the docu
On Mon, Mar 18, 2024, at 2:43 AM, Hayato Kuroda (Fujitsu) wrote:
> Thanks for updating the patch. Here are my comments.
> I used Grammarly to proofread sentences.
> (The tool strongly recommends to use active voice, but I can ignore for now)
Thanks for another review. I posted a new patch (v32) th
On Thu, Mar 21, 2024 at 2:55 AM Nathan Bossart wrote:
>
> On Wed, Mar 20, 2024 at 09:31:16AM -0500, Nathan Bossart wrote:
> > I don't mind removing the 2-register stuff if that's what you think we
> > should do. I'm cautiously optimistic that it'd help more than the extra
> > branch prediction m
On Mon, Mar 18, 2024, at 10:52 AM, Peter Eisentraut wrote:
> On 16.03.24 16:42, Euler Taveira wrote:
> > I'm attaching a new version (v30) that adds:
>
> I have some review comments and attached a patch with some smaller
> fixups (mainly message wording and avoid fixed-size string buffers).
Than
On Tue, Mar 19, 2024 at 10:40 AM Masahiko Sawada wrote:
>
> I've not reviewed the patches in depth yet, but run performance tests
> for CREATE MATERIALIZED VIEW. The test scenarios is:
Thanks for looking into this.
> Is there any reason why we copy a buffer-heap tuple to another
> buffer-heap tu
On Thu, Mar 21, 2024 at 9:37 AM Masahiko Sawada wrote:
>
> On Wed, Mar 20, 2024 at 11:19 PM John Naylor wrote:
> > Are they (the blocks to be precise) really out of order? The VALUES
> > statement is ordered, but after inserting it does not output that way.
> > I wondered if this is platform inde
On Thu, Mar 21, 2024 at 5:19 AM Bharath Rupireddy
wrote:
>
> On Wed, Mar 20, 2024 at 7:08 PM Bertrand Drouvot
> wrote:
> >
> > Regarding v12-0004: "Allow setting inactive_timeout in the replication
> > command",
> > shouldn't we also add an new SQL API say: pg_alter_replication_slot() that
> >
On Wed, Mar 20, 2024 at 1:51 PM Bertrand Drouvot
wrote:
>
> On Wed, Mar 20, 2024 at 12:48:55AM +0530, Bharath Rupireddy wrote:
> >
> > 2. last_inactive_at and inactive_timeout are now tracked in on-disk
> > replication slot data structure.
>
> Should last_inactive_at be tracked on disk? Say the en
On Wed, 20 Mar 2024 at 17:09, Amit Kapila wrote:
>
> On Tue, Mar 19, 2024 at 5:18 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Thanks for giving comments!
> >
> > > This behavior makes sense to me. But do we want to handle the case of
> > > using environment variables too?
> >
> > Yeah, v5 does no
On Mon, Mar 18, 2024 at 07:40:10PM +0100, Alvaro Herrera wrote:
> I enabled the test again and also pushed the changes to dblink,
> isolationtester and fe_utils (which AFAICS is used by pg_dump,
I recommend adding a libpqsrv_cancel() function to libpq-be-fe-helpers.h, to
use from dblink and postgr
Hi,
On 2024-03-20 17:41:47 -0700, Andres Freund wrote:
> There's a lot of other animals on the same machine, however it's rarely fuly
> loaded (with either CPU or IO).
>
> I don't think the test just being slow is the issue here, e.g. in the last
> failing iteration
>
> [...]
>
> I suspect we have
On Wed, Mar 20, 2024 at 11:19 PM John Naylor wrote:
>
> On Wed, Mar 20, 2024 at 8:30 PM Masahiko Sawada wrote:
> > I forgot to report the results. Yes, I did some tests where I inserted
> > many TIDs to make the tidstore use several GB memory. I did two cases:
> >
> > 1. insert 100M blocks of TID
On Mon, Mar 18, 2024 at 11:43 PM Tom Lane wrote:
>
> Alexander Korotkov writes:
> > On Mon, Mar 18, 2024 at 2:01 AM jian he wrote:
> >> `
> >> Datum
> >> pg_basetype(PG_FUNCTION_ARGS)
> >> {
> >> Oid oid;
> >>
> >> oid = get_fn_expr_argtype(fcinfo->flinfo, 0);
> >> PG_RETURN_OID(
On Wed, Mar 20, 2024 at 8:52 PM Robert Haas wrote:
> On Wed, Mar 20, 2024 at 3:17 PM Magnus Hagander
> wrote:
> > Right, what I meant is that making it a packaging decision is the better
> place. Wherever it goes, allowing the administrator to choose what fits
> them should be made possible.
>
>
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
can see the state both before and after the unstable tests.
On Thu, 21 Mar 2024 at 12:36, Tom Lane wrote:
> So yeah, if we could have log_autovacuum_min_duration = 0 perhaps
> that would yield a clue.
FWIW, I agree with your earlier statement about it looking very much
like auto-vacuum has run on that table, but equally, if something like
the pg_index rec
On Thu, 21 Mar 2024 at 13:24, Melih Mutlu wrote:
> What if I do a simple comparison like PqSendStart == PqSendPointer instead of
> calling pq_is_send_pending() as Heikki suggested, then this check should not
> hurt that much. Right? Does that make sense?
As I understand the code, there's no pro
Hi,
On 2024-03-14 16:56:39 -0400, Tom Lane wrote:
> Thomas Munro writes:
> > On Fri, Mar 15, 2024 at 7:00 AM Alexander Lakhin
> > wrote:
> >> Could it be that the timeout (360 sec?) is just not enough for the test
> >> under the current (changed due to switch to meson) conditions?
>
> > But yo
On Wed, 20 Mar 2024 at 11:56, Amonson, Paul D wrote:
> Changed in this patch set.
>
> * Rebased.
> * Direct *slow* calls via macros as shown in example patch.
> * Changed the choose filename to be platform specific as suggested.
> * Falls back to intermediate "Fast" methods if AVX512 is not availa
David Rowley , 21 Mar 2024 Per, 00:54 tarihinde şunu
yazdı:
> On Fri, 15 Mar 2024 at 02:03, Jelte Fennema-Nio
> wrote:
> >
> > On Thu, 14 Mar 2024 at 13:12, Robert Haas wrote:
> > >
> > > On Thu, Mar 14, 2024 at 7:22 AM Melih Mutlu
> wrote:
> > > > 1- Even though I expect both the patch and HEA
On Wed, Mar 20, 2024 at 7:08 PM Bertrand Drouvot
wrote:
>
> Regarding v12-0004: "Allow setting inactive_timeout in the replication
> command",
> shouldn't we also add an new SQL API say: pg_alter_replication_slot() that
> would
> allow to change the timeout property?
>
> That would allow users t
On Mar 20, 2024, at 17:23, Tom Lane wrote:
> Pushed with some editorialization. Mostly, I whacked the
> documentation around pretty heavily: we have a convention for what
> examples in function descriptions should look like, and this wasn't
> it. Not entirely your fault, since some nearby entri
David Rowley writes:
> Is it worth running that animal with log_autovacuum_min_duration = 0
> so we can see what's going on in terms of auto-vacuum auto-analyze in
> the log?
Maybe, but I'm not sure. I thought that if parula were somehow
hitting an ill-timed autovac/autoanalyze, it should be pos
> On 20 Mar 2024, at 22:21, Jacob Champion
> wrote:
>
> On Wed, Mar 20, 2024 at 2:15 PM Jacob Champion
> wrote:
>> I think solutions for case 1 and case 2 are necessarily at odds under
>> the current design, if auth_delay relies on slot exhaustion to do its
>> work effectively. Weakening that o
Hi,
On 2024-03-21 11:02:27 +1300, David Rowley wrote:
> On Thu, 21 Mar 2024 at 11:00, Andres Freund wrote:
> >
> > On 2024-03-20 17:49:14 -0400, Dave Cramer wrote:
> > > First off this is on an ARM64 machine
> >
> > Uh, that's a fairly crucial bit - you're actually trying to cross compile
> > the
On Thu, 21 Mar 2024 at 11:00, Andres Freund wrote:
>
> On 2024-03-20 17:49:14 -0400, Dave Cramer wrote:
> > First off this is on an ARM64 machine
>
> Uh, that's a fairly crucial bit - you're actually trying to cross compile
> then. I don't know much about cross compiling on windows, so it's certa
Hi,
On 2024-03-20 17:49:14 -0400, Dave Cramer wrote:
> On Wed, 20 Mar 2024 at 17:11, Andres Freund wrote:
> > On 2024-03-20 16:14:23 -0400, Dave Cramer wrote:
> > > I am getting the following error
> > >
> > > meson.build:1479:17: ERROR: Can not run test applications in this cross
> > > environme
On Fri, 15 Mar 2024 at 01:46, Heikki Linnakangas wrote:
> - the "(int *) &len)" cast is not ok, and will break visibly on
> big-endian systems where sizeof(int) != sizeof(size_t).
I think fixing this requires adjusting the signature of
internal_flush_buffer() to use size_t instead of int. That
On Fri, 15 Mar 2024 at 02:03, Jelte Fennema-Nio wrote:
>
> On Thu, 14 Mar 2024 at 13:12, Robert Haas wrote:
> >
> > On Thu, Mar 14, 2024 at 7:22 AM Melih Mutlu wrote:
> > > 1- Even though I expect both the patch and HEAD behave similarly in case
> > > of small data (case 1: 100 bytes), the patc
On Wed, 20 Mar 2024 at 08:58, Tom Lane wrote:
> I suppose we could attach "autovacuum=off" settings to these tables,
> but it doesn't seem to me that that should be necessary. These test
> cases are several years old and haven't given trouble before.
> Moreover, if that's necessary then there are
Robert Haas writes:
> On Wed, Mar 20, 2024 at 5:05 PM Alvaro Herrera
> wrote:
>> I think you can achieve this with a much smaller patch that just changes
>> the outer tag in each file so that each file is a , then create a
>> single file that includes all of these plus an additional outer tag fo
"David E. Wheeler" writes:
> Thanks, fixed in the attached patch.
Pushed with some editorialization. Mostly, I whacked the
documentation around pretty heavily: we have a convention for what
examples in function descriptions should look like, and this wasn't
it. Not entirely your fault, since so
On Wed, Mar 20, 2024 at 5:05 PM Alvaro Herrera wrote:
> I think you can achieve this with a much smaller patch that just changes
> the outer tag in each file so that each file is a , then create a
> single file that includes all of these plus an additional outer tag for
> the (or maybe just add t
On Wed, Mar 20, 2024 at 2:15 PM Jacob Champion
wrote:
> I think solutions for case 1 and case 2 are necessarily at odds under
> the current design, if auth_delay relies on slot exhaustion to do its
> work effectively. Weakening that on purpose doesn't make much sense to
> me; if a DBA is uncomfort
On 3/20/24 22:30, Michael Banck wrote:
On Tue, Mar 19, 2024 at 10:51:50AM -0400, Tom Lane wrote:
Heikki Linnakangas writes:
Perhaps we could make that even better with a GUC though. I propose a
GUC called 'configuration_managed_externally = true / false". If you set
it to true, we prevent ALT
Hi,
On 2024-03-20 16:14:23 -0400, Dave Cramer wrote:
> I am getting the following error
>
> meson.build:1479:17: ERROR: Can not run test applications in this cross
> environment.
>
> Have configured for amd64_x86
>
> Running `meson setup --wipe build --prefix=c:\postgres86`
This is not enough
On 2024-Mar-20, Robert Haas wrote:
> 0003 merges all of the "Internals" chapters whose names are the names
> of built-in index access methods (Btree, Gin, etc.) into a single
> chapter called "Built-In Index Access Methods". All of these chapters
> have a very similar structure and none of them ar
On Wed, Mar 20, 2024 at 03:15:49PM +0200, Heikki Linnakangas wrote:
>
> 0009-: The rest of the v4 patches, rebased over the WAL format changes. I
> also added a few small commits for little cleanups that caught my eye, let
> me know if you disagree with those.
This review is just of the patches co
Greetings,
I am getting the following error
meson.build:1479:17: ERROR: Can not run test applications in this cross
environment.
Have configured for amd64_x86
Running `meson setup --wipe build --prefix=c:\postgres86`
The docs say it is possible to build postgres for x86. Are there specific
ins
On Wed, Mar 20, 2024 at 4:06 PM Melanie Plageman
wrote:
> > What about the issue of cleanup locks, which aren't needed and aren't
> > taken with the current heapam VACUUM record type? Will you preserve
> > that aspect of the existing design?
>
> Yep, we have a flag to indicate whether or not a cle
On Wed, Mar 20, 2024 at 4:04 PM Peter Geoghegan wrote:
>
> On Wed, Mar 20, 2024 at 9:15 AM Heikki Linnakangas wrote:
> > > I made it its own sub-record (xlhp_conflict_horizon) less to help with
> > > alignment (though we can use all the help we can get there) and more to
> > > keep it from gettin
On Wed, Mar 20, 2024 at 9:15 AM Heikki Linnakangas wrote:
> > I made it its own sub-record (xlhp_conflict_horizon) less to help with
> > alignment (though we can use all the help we can get there) and more to
> > keep it from getting lost. When you look at heapam_xlog.h, you can see
> > what a XLO
Hi,
On Wed, Mar 20, 2024 at 08:11:32PM +0100, Magnus Hagander wrote:
> (And FWIW also already solved on debian-based platforms for example,
> which but the main config files in /etc with postgres only having read
> permissions on them
JFTR - Debian/Ubuntu keep postgresql.conf under /etc/postgres
On Wed, Mar 20, 2024 at 09:31:16AM -0500, Nathan Bossart wrote:
> On Wed, Mar 20, 2024 at 01:57:54PM +0700, John Naylor wrote:
>> On Tue, Mar 19, 2024 at 11:30 PM Nathan Bossart
>> wrote:
>>> I tried to trim some of the branches, and came up with the attached patch.
>>> I don't think this is exact
On Wed, Mar 20, 2024 at 3:17 PM Magnus Hagander wrote:
> Right, what I meant is that making it a packaging decision is the better
> place. Wherever it goes, allowing the administrator to choose what fits them
> should be made possible.
+1. Which is also the justification for this patch, when it
On Sat, 16 Mar 2024 at 01:12, Peter Geoghegan wrote:
>
> On Fri, Mar 8, 2024 at 9:00 AM Matthias van de Meent
> wrote:
> > I've attached v14, where 0001 is v13, 0002 is a patch with small
> > changes + some large comment suggestions, and 0003 which contains
> > sorted merge join code for _bt_merg
On Wed, Mar 20, 2024 at 10:00 AM Alexander Lakhin wrote:
>
> Hello Melanie,
>
> 20.03.2024 16:15, Melanie Plageman wrote:
> > Seems like we could just add autovacuum_enabled=false to the table like
> > this:
> > diff --git a/src/test/recovery/t/031_recovery_conflict.pl
> > b/src/test/recovery/t/0
On Wed, Mar 20, 2024 at 02:53:01PM -0400, Robert Haas wrote:
> On Wed, Mar 20, 2024 at 2:35 PM Nathan Bossart
> wrote:
>> Committed.
>
> Thanks. Sorry you had to clean up after me. :-(
No worries.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Mar 20, 2024 at 03:15:49PM +0200, Heikki Linnakangas wrote:
> On 20/03/2024 03:36, Melanie Plageman wrote:
> > On Mon, Mar 18, 2024 at 01:15:21AM +0200, Heikki Linnakangas wrote:
> > > On 15/03/2024 02:56, Melanie Plageman wrote:
> > > > Okay, so I was going to start using xl_heap_prune for
On Wed, Mar 20, 2024 at 8:14 PM Robert Haas wrote:
> On Wed, Mar 20, 2024 at 3:11 PM Magnus Hagander
> wrote:
> > I would argue that having the default permissions not allow postgres to
> edit it's own config files *except* for postgresql.auto.conf would be a
> better default than what we have n
On Wed, Mar 20, 2024 at 3:11 PM Magnus Hagander wrote:
> I would argue that having the default permissions not allow postgres to edit
> it's own config files *except* for postgresql.auto.conf would be a better
> default than what we have now, but that's completely independent of the patch
> bei
On Wed, Mar 20, 2024 at 8:04 PM Robert Haas wrote:
> On Wed, Mar 20, 2024 at 11:07 AM Jelte Fennema-Nio
> wrote:
> > > Ugh, please let's not do this. This was bouncing around in my head
> last night, and this is really a quite radical change - especially just to
> handle the given ask, which is
This new return path...
> + if (!tok_done)
> + {
> + if (lex->inc_state->is_last_chunk)
> + return JSON_INVALID_TOKEN;
...also needs to set the token pointers. See one approach in the
attached diff, which additionally asserts that we've consumed the
entire chun
On Wed, Mar 20, 2024 at 11:07 AM Jelte Fennema-Nio wrote:
> > Ugh, please let's not do this. This was bouncing around in my head last
> > night, and this is really a quite radical change - especially just to
> > handle the given ask, which is to prevent a specific command from running.
> > Not
On Wed, 20 Mar 2024 at 11:50, Matthias van de Meent
wrote:
>
> On Tue, 19 Mar 2024 at 20:58, Tom Lane wrote:
> >
> > For the last few days, buildfarm member parula has been intermittently
> > failing the partition_prune regression test, due to unexpected plan
> > changes [1][2][3][4]. The sympto
On Wed, Mar 20, 2024 at 2:35 PM Nathan Bossart wrote:
> On Tue, Mar 19, 2024 at 01:15:02PM -0500, Nathan Bossart wrote:
> > Assuming there are no objections or feedback, I plan to commit these two
> > patches within the next couple of days.
>
> Committed.
Thanks. Sorry you had to clean up after m
On Wed, Mar 20, 2024 at 1:26 PM Étienne BERSAC
wrote:
> The usual case is: a superuser grants writers role to alice. In
> directory, alice is degraded to readers. ldap2pg is not superuser but
> has CREATEROLE. ldap2pg applies the changes. In Postgres 15, revocation
> is completed. In Postgres 16,
On Wed, 20 Mar 2024 at 07:35, Peter Eisentraut wrote:
> If we want to be robust without any guarantees from gettimeofday(), then
> arguably gettimeofday() is not the right underlying function to use for
> UUIDv7.
There's also clock_gettime which exposes its resolution using clock_getres
On Tue, Mar 19, 2024 at 01:15:02PM -0500, Nathan Bossart wrote:
> Assuming there are no objections or feedback, I plan to commit these two
> patches within the next couple of days.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Mar 20, 2024 at 1:35 PM Bruce Momjian wrote:
> On Wed, Mar 20, 2024 at 12:43:08PM -0400, Robert Haas wrote:
> > Overall, I think this achieves a minor but pleasant level of
> > de-cluttering of the index. It's going to take a lot more than one
> > morning's work to produce a major improvem
On Thu, Mar 14, 2024 at 9:07 PM James Coleman wrote:
> Obviously I have reasons for the other changes I made: for example,
> "no longer visible" improves the correctness, since being an old
> version isn't sufficient. I removed the "In summary" sentence because
> it simply doesn't follow from the
On 3/18/24 16:19, Melanie Plageman wrote:
> On Mon, Mar 18, 2024 at 02:10:28PM +0200, Heikki Linnakangas wrote:
>> On 14/02/2024 21:42, Andres Freund wrote:
>>> On 2024-02-13 18:11:25 -0500, Melanie Plageman wrote:
patch 0004 is, I think, a bug fix. see [2].
>>>
>>> I'd not quite call it a bug
> On 19 Mar 2024, at 13:55, Peter Eisentraut wrote:
>
> On 16.03.24 18:43, Andrey M. Borodin wrote:
>>> On 15 Mar 2024, at 14:47, Aleksander Alekseev
>>> wrote:
>>>
>>> +1 to the idea. I doubt that anyone will miss it.
>> PFA v22.
>> Changes:
>> 1. Squashed all editorialisation by Jelte
>> 2
On Wed, Mar 20, 2024 at 12:43:08PM -0400, Robert Haas wrote:
> Overall, I think this achieves a minor but pleasant level of
> de-cluttering of the index. It's going to take a lot more than one
> morning's work to produce a major improvement, but at least this is
> something.
I think this kind of d
Hi,
> https://dev.mysql.com/doc/refman/8.0/en/revoke.html documents an "IF
> EXISTS" option whose documentation reads, in relevant part,
> "Otherwise, REVOKE executes normally; if the user does not exist, the
> statement raises an error."
>
> https://community.snowflake.com/s/article/Access-Con
On Mon, Mar 11, 2024 at 3:44 PM Maxim Orlov wrote:
> On Tue, 6 Feb 2024 at 09:22, Michael Paquier wrote:
>> The problem may be actually trickier than that, no? Could there be
>> other factors to take into account for their classification, like
>> their sizes (typically, we'd want to process the
On Tue, Mar 19, 2024 at 3:07 PM Andrew Dunstan wrote:
> On Mon, Mar 18, 2024 at 3:35 PM Jacob Champion
> wrote:
>> With the incremental parser, I think prev_token_terminator is not
>> likely to be safe to use except in very specific circumstances, since
>> it could be pointing into a stale chunk
David Wheeler complained over in [1] that genbki.pl fails to produce a
useful error message if there's anything wrong in a catalog data file.
He's right about that, but the band-aid patch he proposed doesn't
improve the situation much. The actual problem is that key error
messages in genbki.pl exp
On Wed, Mar 20, 2024 at 7:50 AM Daniel Gustafsson wrote:
> We are subtracting 30 years from a calculation that we know didnt overflow, so
> I guess if the certificate notBefore (the notAfter cannot be that early since
> we wouldn't be able to connect with it) was set to early enough? It didn't
>
On Wed, 2024-03-20 at 14:26 +0700, John Naylor wrote:
> This was the culprit. The search path cache didn't trigger this when
> it went in, but it seems for frontend a read past the end of malloc
> fails -fsantize=address. By the same token, I'm guessing the only
> reason this didn't fail for backen
My mistake. Attached please find version 3, which should hopefully make
cfbot happy again.
pgbench.dash.d.or.not.dash.d.v3.patch
Description: Binary data
On Tue, Mar 19, 2024 at 09:15:22PM -0400, Greg Sabino Mullane wrote:
> Rebased version attached (v2), with another sentence in the sgml to explain
> the optional use of -d
cfbot seems quite unhappy with this:
https://cirrus-ci.com/build/6429518263484416
--
Nathan Bossart
Amazon Web Serv
On Wed, Mar 20, 2024 at 2:24 PM vignesh C wrote:
>
> On Tue, 19 Mar 2024 at 17:18, Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Dear Sawada-san,
> >
> > Thanks for giving comments!
> >
> > > This behavior makes sense to me. But do we want to handle the case of
> > > using environment variables too?
>
On Wed, 20 Mar 2024 at 14:04, Greg Sabino Mullane wrote:
>>
>> As a bonus, if that GUC is set, we could even check at server startup that
>> all the configuration files are not writable by the postgres user,
>> and print a warning or refuse to start up if they are.
>
>
> Ugh, please let's not do
> On 20 Mar 2024, at 15:28, Jacob Champion
> wrote:
>> + result -= ((POSTGRES_EPOCH_JDATE - UNIX_EPOCH_JDATE) * USECS_PER_DAY);
>> + return TimestampTzGetDatum(result);
>
> Is that final bare subtraction able to wrap around for dates far in the past?
We are subtracting 30 years from a calc
On Mon, Mar 18, 2024 at 5:40 PM Laurenz Albe wrote:
> I also disagree that chapters 4 to 6 are a continuation of the tutorial.
> Or at least, they shouldn't be.
> When I am looking for a documentation reference on something like
> security considerations of SECURITY DEFINER functions, my first
> i
On Wed, Mar 20, 2024 at 01:57:54PM +0700, John Naylor wrote:
> On Tue, Mar 19, 2024 at 11:30 PM Nathan Bossart
> wrote:
>> I tried to trim some of the branches, and came up with the attached patch.
>> I don't think this is exactly what you were suggesting, but I think it's
>> relatively close. My
On 2024-Mar-19, Tom Lane wrote:
> The bit about "(Not meaningful if the relation has no on-disk file.)"
> is not correct, and now it's adjacent to text that contradicts it.
> Maybe more like
>
>The tablespace in which this relation is stored.
>If zero, the database's default table
On Wed, Mar 20, 2024 at 7:03 AM Daniel Gustafsson wrote:
> The issue here is that postgres use a different epoch from the unix epoch, so
> any dates calcuated based on the unix epoch need to be adjusted.
Ah, thank you! I had just reproduced Cary's problem and was really confused...
> I've hacked
> On 29 Feb 2024, at 20:58, Jacob Champion
> wrote:
>
> On Wed, Feb 28, 2024 at 2:54 PM Daniel Gustafsson wrote:
>> I rank that as one of my better typos actually. Fixed though.
>
> LGTM!
Thanks for review, and since Heikki marked it ready for committer I assume that
counting as a +1 as well.
Hi,
Could someone review the v17 patch to proceed this?
The v17 patch:
https://www.postgresql.org/message-id/flat/20240305.171808.667980402249336456.kou%40clear-code.com#d2ee079b75ebcf00c410300ecc4a357a
Some profiles by Michael:
https://www.postgresql.org/message-id/flat/ZelfYatRdVZN3FbE%40paqui
On Tue, Mar 19, 2024 at 8:48 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Sawada-san,
>
> Thanks for giving comments!
>
> > This behavior makes sense to me. But do we want to handle the case of
> > using environment variables too?
>
> Yeah, v5 does not consider which libpq parameters are specified b
> -Original Message-
> From: David Rowley
> Sent: Tuesday, March 19, 2024 9:26 PM
> To: Amonson, Paul D
>
> AMD's Zen4 also has AVX512, so it's misleading to indicate it's an Intel only
> instruction. Also, writing the date isn't necessary as we have "git blame"
Fixed.
Thanks,
Paul
On Wed, Mar 20, 2024 at 8:30 PM Masahiko Sawada wrote:
> I forgot to report the results. Yes, I did some tests where I inserted
> many TIDs to make the tidstore use several GB memory. I did two cases:
>
> 1. insert 100M blocks of TIDs with an offset of 100.
> 2. insert 10M blocks of TIDs with an o
1 - 100 of 130 matches
Mail list logo
