Hi,
> My understanding of Majid's use-case for tuning MAX_SEND_SIZE is that the
> bottleneck is storage, not network. The reason MAX_SEND_SIZE affects that is
> that it determines the max size passed to WALRead(), which in turn determines
> how much we read from the OS at once. If the storage has
Hi,
Hi,
We can specify more than one privilege type in
"ALTER DEFAULT PRIVILEGES GRANT/REVOKE ON SCHEMAS",
for example,
ALTER DEFAULT PRIVILEGES GRANT USAGE,CREATE ON SCHEMAS TO PUBLIC;
However, the syntax described in the documentation looks to
be allowing only one,
GRANT { USAGE | CREATE
Hello,
A diff tool that would generate create, drop, alter, etc. commands from the
differences between 2 specified schemes would be very useful. The diff
could even manage data, so there would be insert, delete update command
outputs, although I think the schema diff management is much more import
On Mon, Apr 22, 2024 at 5:07 PM Anthonin Bonnefoy
wrote:
>
> On Sat, Apr 20, 2024 at 2:00 PM Alena Rybakina
> wrote:
>>
>> Hi, thank you for your work with this subject.
>>
>> While I was reviewing your code, I noticed that your patch conflicts with
>> another patch [0] that been committed.
>>
On Tue, 23 Apr 2024 23:47:38 -0400
Tom Lane wrote:
> Yugo NAGATA writes:
> > Currently, ALTER DEFAULT PRIVILEGE doesn't support large objects,
> > so if we want to allow users other than the owner to use the large
> > object, we need to grant a privilege on it every time a large object
> > is cr
On 17.04.24 18:15, Tom Lane wrote:
Peter Eisentraut writes:
I checked the generated ecpg_config.h with make and meson, and the meson
one is missing
#define HAVE_LONG_LONG_INT 1
This is obviously quite uninteresting, since that is required by C99.
But it would be more satisfactory if we di
On Wed, Mar 13, 2024 at 9:19 AM vignesh C wrote:
>
> On Tue, 12 Mar 2024 at 09:34, Ajin Cherian wrote:
> >
> >
> >
> > On Tue, Mar 12, 2024 at 2:59 PM vignesh C wrote:
> >>
> >>
> >> Thanks, I have created the following Commitfest entry for this:
> >> https://commitfest.postgresql.org/47/4816/
>
hi.
I found an interesting case.
CREATE TABLE t1 AS
SELECT (i % 10)::numeric AS x,(i % 10)::int8 AS y,'abc' || i % 10 AS
z, i::int4 AS w
FROM generate_series(1, 100) AS i;
CREATE INDEX t1_x_y_idx ON t1 (x, y);
ANALYZE t1;
SET enable_hashagg = off;
SET enable_seqscan = off;
EXPLAIN (COSTS OFF)
On Tue, 16 Apr 2024 at 13:30, David Rowley wrote:
> In [1] Andres mentioned that there's no way to determine the memory
> context type in pg_backend_memory_contexts. This is a bit annoying as
> I'd like to add a test to exercise BumpStats().
>
> Having the context type in the test's expected outpu
On Tue, Apr 23, 2024 at 12:37 PM Amit Kapila wrote:
>
> On Mon, Apr 22, 2024 at 7:04 PM Masahiko Sawada wrote:
> >
> > On Mon, Apr 22, 2024 at 9:02 PM shveta malik wrote:
> > >
> > > Thanks for the patch, the changes look good Amit. Please find the merged
> > > patch.
> > >
> >
> > I've reviewe
On Tue, Apr 23, 2024 at 9:07 AM Amit Kapila wrote:
>
> On Mon, Apr 22, 2024 at 7:04 PM Masahiko Sawada wrote:
> >
> > On Mon, Apr 22, 2024 at 9:02 PM shveta malik wrote:
> > >
> > > Thanks for the patch, the changes look good Amit. Please find the merged
> > > patch.
> > >
> >
> > I've reviewed
Yugo NAGATA writes:
> Currently, ALTER DEFAULT PRIVILEGE doesn't support large objects,
> so if we want to allow users other than the owner to use the large
> object, we need to grant a privilege on it every time a large object
> is created. One of our clients feels that this is annoying, so I wou
On Mon, Apr 22, 2024 at 2:31 PM Bertrand Drouvot
wrote:
>
> On Mon, Apr 22, 2024 at 11:32:14AM +0530, shveta malik wrote:
> > On Mon, Apr 22, 2024 at 5:57 AM Zhijie Hou (Fujitsu)
> > wrote:
> > > Attach the V3 patch which also addressed Shveta[1] and Bertrand[2]'s
> > > comments.
>
> Thanks!
>
>
Hi Vik and Champion,
I think the current RPR patch is not quite correct in handling
count(*).
(using slightly modified version of Vik's example query)
SELECT v.a, count(*) OVER w
FROM (VALUES ('A'),('B'),('B'),('C')) AS v (a)
WINDOW w AS (
ORDER BY v.a
ROWS BETWEEN CURRENT ROW AND UNBOUNDED
Michael Paquier writes:
> On Tue, Apr 23, 2024 at 01:01:04PM -0400, Tom Lane wrote:
>> That is, query jumbling no longer distinguishes "DEALLOCATE x" from
>> "DEALLOCATE ALL", because the DeallocateStmt.name field is marked
>> query_jumble_ignore. Now maybe that's fine, but it's a point
>> we'd n
On Tue, Apr 23, 2024 at 01:01:04PM -0400, Tom Lane wrote:
> That is, query jumbling no longer distinguishes "DEALLOCATE x" from
> "DEALLOCATE ALL", because the DeallocateStmt.name field is marked
> query_jumble_ignore. Now maybe that's fine, but it's a point
> we'd not considered so far in this th
Hi,
Currently, ALTER DEFAULT PRIVILEGE doesn't support large objects,
so if we want to allow users other than the owner to use the large
object, we need to grant a privilege on it every time a large object
is created. One of our clients feels that this is annoying, so I would
like propose to exten
I've attached a patch with a few typo fixes and what looks like an
incorrect type for max_ios. It's an int16 and I think it needs to be
an int. Doing "max_ios = Min(max_ios, PG_INT16_MAX);" doesn't do
anything when max_ios is int16.
David
diff --git a/src/backend/storage/aio/read_stream.c
b/src/b
> I am also a bit surprised with the choice of using the first Query
> available in the list for the ID, FWIW.
IIUC, the query trees returned from QueryRewrite
will all have the same queryId, so it appears valid to
use the queryId from the first tree in the list. Right?
Here is an example I was
Rebased over ca89db5f.
I looked into whether we could drop the "old pass manager" code
too[1]. Almost, but nope, even the C++ API lacks a way to set the
inline threshold before LLVM 16, so that would cause a regression.
Although we just hard-code the threshold to 512 with a comment that
sounds li
On 4/22/24 23:53, Robert Haas wrote:
On Sun, Apr 21, 2024 at 8:47 PM David Steele wrote:
I figured that wouldn't be particularly meaningful, and
that's pretty much the only kind of validation that's even
theoretically possible without a bunch of extra overhead, since we
compute checksums on ent
On 4/23/24 18:05, Melanie Plageman wrote:
> On Mon, Apr 22, 2024 at 1:01 PM Melanie Plageman
> wrote:
>>
>> On Thu, Apr 18, 2024 at 5:39 AM Tomas Vondra
>> wrote:
>>>
>>> On 4/18/24 09:10, Michael Paquier wrote:
On Sun, Apr 07, 2024 at 10:54:56AM -0400, Melanie Plageman wrote:
> I've
On Tue, Apr 23, 2024 at 10:08:13PM +0200, Daniel Gustafsson wrote:
> Hearing no objections to this plan (and the posted v10), I'll go ahead with
> 0001, 0003 and 0004 into v17 tomorrow.
WFM, thanks.
--
Michael
signature.asc
Description: PGP signature
With one eye on the beta-release calendar, I thought it'd be a
good idea to test whether our tarball build script works for
the new plan where we'll use "git archive" instead of the
traditional process.
It doesn't.
It makes tarballs all right, but whatever commit ID you specify
is semi-ignored, a
Hi,
On 2024-04-23 14:47:31 +0200, Jakub Wartak wrote:
> On Tue, Apr 23, 2024 at 2:24 AM Michael Paquier wrote:
> >
> > > Any news, comments, etc. about this thread?
> >
> > FWIW, I'd still be in favor of doing a GUC-ification of this part, but
> > at this stage I'd need more time to do a proper s
On 23/04/2024 22:33, Jacob Champion wrote:
On Tue, Apr 23, 2024 at 10:43 AM Robert Haas wrote:
I've not followed this thread closely enough to understand the comment
about requiredirect maybe not actually requiring direct, but if that
were true it seems like it might be concerning.
It may be
> On 19 Apr 2024, at 10:06, Peter Eisentraut wrote:
>
> On 19.04.24 07:37, Michael Paquier wrote:
>> On Thu, Apr 18, 2024 at 12:53:43PM +0200, Peter Eisentraut wrote:
>>> If everything is addressed, I agree that 0001, 0003, and 0004 can go into
>>> PG17, the rest later.
>> About the PG17 bits, wo
On Mon, Apr 22, 2024 at 03:20:10PM -0500, Nathan Bossart wrote:
> On Mon, Apr 22, 2024 at 04:08:08PM -0400, Tom Lane wrote:
>> The problem with the README is that it describes that process,
>> rather than the now-typical workflow of incrementally keeping
>> the tree indented. I don't think we want
On Tue, Apr 23, 2024 at 10:43 AM Robert Haas wrote:
> I've not followed this thread closely enough to understand the comment
> about requiredirect maybe not actually requiring direct, but if that
> were true it seems like it might be concerning.
It may be my misunderstanding. This seems to imply
On Tue, Apr 23, 2024 at 1:39 PM Melanie Plageman
wrote:
> Since you are going to share the patches anyway at the workshop, do
> you mind giving an example of a patch that is a good fit for the
> workshop? Alternatively, you could provide a hypothetical example. I,
> of course, have patches that I'
On Tue, Apr 23, 2024 at 1:22 PM Jacob Champion
wrote:
> On Mon, Apr 22, 2024 at 10:42 PM Michael Paquier wrote:
> > On Mon, Apr 22, 2024 at 10:47:51AM +0300, Heikki Linnakangas wrote:
> > > On 22/04/2024 10:19, Michael Paquier wrote:
> > >> As a whole, I can get behind a unique GUC that forces th
On Mon, Apr 22, 2024 at 2:20 PM Jelte Fennema-Nio wrote:
> 1. I strongly believe minor protocol version bumps after the initial
> 3.1 one can be made painless for clients/poolers (so the ones to
> 3.2/3.3/etc). Similar to how TLS 1.3 can be safely introduced, and not
> having to worry about breaki
On Tue, Apr 23, 2024 at 1:27 PM Robert Haas wrote:
>
> Hi,
>
> Just a quick update. We have so far had 8 suggested patches from 6
> people, if I haven't missed anything. I'm fairly certain that not all
> of those patches are going to be good candidates for this session, so
> it would be great if a
Hi,
Just a quick update. We have so far had 8 suggested patches from 6
people, if I haven't missed anything. I'm fairly certain that not all
of those patches are going to be good candidates for this session, so
it would be great if a few more people wanted to volunteer their
patches.
Thanks,
...
On Mon, Apr 22, 2024 at 10:42 PM Michael Paquier wrote:
>
> On Mon, Apr 22, 2024 at 10:47:51AM +0300, Heikki Linnakangas wrote:
> > On 22/04/2024 10:19, Michael Paquier wrote:
> >> As a whole, I can get behind a unique GUC that forces the use of
> >> direct. Or, we could extend the existing "ssl"
On Fri, Apr 19, 2024 at 2:43 PM Heikki Linnakangas wrote:
>
> On 19/04/2024 19:48, Jacob Champion wrote:
> > On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
> >> With direct SSL negotiation, we always require ALPN.
> >
> > (As an aside: I haven't gotten to test the version of the patc
Michael Paquier writes:
> On Mon, Apr 22, 2024 at 06:46:27PM +0200, Matthias van de Meent wrote:
>> On Mon, 22 Apr 2024 at 17:41, Tom Lane wrote:
>>> I think it would be a good idea to push 0003 for v17, just so nobody
>>> grows an unnecessary dependency on that field. 0001 and 0005 could
>>> be
Hi,
On 2024-04-15 11:25:05 +0300, Nazir Bilal Yavuz wrote:
> I am able to reproduce this. I regenerated the debian bookworm image
> and ran CI on REL_15_STABLE with this image.
>
> CI Run: https://cirrus-ci.com/task/4978799442395136
Hm, not sure why I wasn't able to repro - now I can.
It actual
On Tue, 23 Apr 2024, 05:52 Tom Lane, wrote:
> Jeff Davis writes:
> > On Mon, 2024-04-22 at 16:19 -0400, Tom Lane wrote:
> >> Loading data without stats, and hoping
> >> that auto-analyze will catch up sooner not later, is exactly the
> >> current behavior that we're doing all this work to get out
Hi,
On Tue, Apr 23, 2024 at 04:59:09AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Mon, Apr 22, 2024 at 03:00:00PM +0300, Alexander Lakhin wrote:
> > 22.04.2024 13:52, Bertrand Drouvot wrote:
> > >
> > > That's weird, I just launched it several times with the patch applied and
> > > I'm not
> >
On Mon, Apr 22, 2024 at 1:01 PM Melanie Plageman
wrote:
>
> On Thu, Apr 18, 2024 at 5:39 AM Tomas Vondra
> wrote:
> >
> > On 4/18/24 09:10, Michael Paquier wrote:
> > > On Sun, Apr 07, 2024 at 10:54:56AM -0400, Melanie Plageman wrote:
> > >> I've added an open item [1], because what's one open it
On Thu, Apr 18, 2024 at 05:13:58PM -0500, Nathan Bossart wrote:
> Makes sense, thanks. I'm planning to commit this fix sometime early next
> week.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Sushrut Shivaswamy writes:
> I'm developing a postgres extension as a custom Table Interface method
> definition.
> WIthin the extension, I"m planning to create two background processes using
> `fork()` that will process data in the background.
> Are there any recommendations / guidelines around
Daniel Gustafsson writes:
>> On 22 Apr 2024, at 18:04, Tom Lane wrote:
>> Seems like a useful change
> Agreed.
>> ... about like this?
> Patch LGTM.
Pushed.
regards, tom lane
On 2024-03-14 Th 02:39, Jeff Davis wrote:
Introduce "builtin" collation provider.
The new value "b" for pg_collation.collprovider doesn't seem to be
documented. Is that deliberate?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Hey,
I'm developing a postgres extension as a custom Table Interface method
definition.
WIthin the extension, I"m planning to create two background processes using
`fork()` that will process data in the background.
Are there any recommendations / guidelines around creating background
processes wi
On Mon, Apr 22, 2024 at 5:19 PM Jelte Fennema-Nio wrote:
> On Mon, 22 Apr 2024 at 16:26, Robert Haas wrote:
> > That's a fair point, but I'm still not seeing much practical
> > advantage. It's unlikely that a client is going to set a random bit in
> > a format parameter for no reason.
>
> I think
"Guo, Adam" writes:
> I would like to report an issue with the pg_trgm extension on
> cross-architecture replication scenarios. When an x86_64 standby
> server is replicating from an aarch64 primary server or vice versa,
> the gist_trgm_ops opclass returns different results on the primary
> and st
Hi all,
I would like to report an issue with the pg_trgm extension on
cross-architecture replication scenarios. When an x86_64 standby server is
replicating from an aarch64 primary server or vice versa, the gist_trgm_ops
opclass returns different results on the primary and standby. Masahiko
pr
Alvaro Herrera writes:
> On 2024-Apr-22, Tom Lane wrote:
>> The main reason there's a delta is that people don't manage to
>> maintain the in-tree copy perfectly (at least, they certainly
>> haven't done so for this past year). So we need to do that
>> to clean up every now and then.
> Out of cu
On Wed, 24 Apr 2024 at 00:11, Tatsuo Ishii wrote:
> Just out of a curiosity, is it possible to say "low a wal_level on the
> primary"? (just "too" is removed)
Prefixing the adjective with "too" means it's beyond the acceptable
range. "This coffee is too hot".
https://dictionary.cambridge.org/gr
Hi Maxim Orlov
Thank you so much for your tireless work on this. Increasing the WAL
size by a few bytes should have very little impact with today's disk
performance(Logical replication of this feature wal log is also increased a
lot, logical replication is a milestone new feature, and the commun
> On 23 Apr 2024, at 11:23, Maxim Orlov wrote:
>
> Make multixact offsets 64 bit.
- ereport(ERROR,
- (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
-errmsg("multixact \"members\" limit exceeded"),
Personally, I'd be happy
On Tue, Apr 23, 2024 at 2:24 AM Michael Paquier wrote:
>
> On Mon, Apr 22, 2024 at 03:40:01PM +0200, Majid Garoosi wrote:
> > Any news, comments, etc. about this thread?
>
> FWIW, I'd still be in favor of doing a GUC-ification of this part, but
> at this stage I'd need more time to do a proper stu
> On 22 Apr 2024, at 18:04, Tom Lane wrote:
> Seems like a useful change
Agreed.
> ... about like this?
Patch LGTM.
--
Daniel Gustafsson
Dear hackers,
Per recent commit (b29cbd3da), our patch needed to be rebased.
Here is an updated version.
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
https://www.fujitsu.com/
v6-0001-Allow-altering-of-two_phase-option-of-a-SUBSCRIPT.patch
Description: v6-0001-Allow-altering-of-two_phase-opti
On Tue, Apr 23, 2024 at 6:23 AM Alvaro Herrera wrote:
> I wonder if we're interested in keeping a (very short) manually-
> maintained list of symbols that we know are in use but the scripts
> don't extract for whatever reason.
+1. I think this idea has been proposed and rejected before, but I
thi
>> I think "too low a" should be "too low" ('a' is not
>> necessary). Attached is the patch.
>
> The existing text looks fine to me. The other form would use "of a"
> and become "too low of a wal_level on the primary".
>
> "too low wal_level on the primary" sounds wrong to my native
> English-sp
On Tue, Apr 23, 2024 at 11:49 AM vignesh C wrote:
>
> On Sat, 20 Apr 2024 at 10:30, Alexander Lakhin wrote:
> >
> > Hello Michael and Robert,
> >
> > 20.04.2024 05:57, Michael Paquier wrote:
> > > On Fri, Apr 19, 2024 at 01:57:41PM -0400, Robert Haas wrote:
> > >> It looks to me like in the first
On Tue, 23 Apr 2024 at 23:17, Tatsuo Ishii wrote:
>Number of uses of logical slots in this database that have been
>canceled due to old snapshots or too low a linkend="guc-wal-level"/>
>on the primary
>
> I think "too low a" should be "too low" ('a' is not
> necessary). At
On Wed, Mar 13, 2024 at 11:59 AM vignesh C wrote:
>
> On Wed, 13 Mar 2024 at 10:12, Zhijie Hou (Fujitsu)
> wrote:
> >
> >
> > For 0002, instead of avoid resetting the latch, is it possible to let the
> > logical rep worker wake up the launcher once after attaching ?
>
> Waking up of the launch pr
Hi,
doc/src/sgml/monitoring.sgml seems to have a minor typo:
In pg_stat_database_conflicts section (around line 3621) we have:
Number of uses of logical slots in this database that have been
canceled due to old snapshots or too low a
on the primary
I think "t
On 2024-Apr-22, Tom Lane wrote:
> The main reason there's a delta is that people don't manage to
> maintain the in-tree copy perfectly (at least, they certainly
> haven't done so for this past year). So we need to do that
> to clean up every now and then.
Out of curiosity, I downloaded the build
On 4/23/24 12:49, Michael Paquier wrote:
On Tue, Apr 23, 2024 at 11:42:41AM +0700, Andrei Lepikhov wrote:
On 23/4/2024 11:16, Imseih (AWS), Sami wrote:
+ pgstat_report_query_id(linitial_node(Query, psrc->query_list)->queryId,
true);
set_ps_display("BIND");
@@ -2146,6 +2147,7 @@
On 23/04/2024 11:23, Maxim Orlov wrote:
PROPOSAL
Make multixact offsets 64 bit.
+1, this is a good next step and useful regardless of 64-bit XIDs.
@@ -156,7 +148,7 @@
((uint32) ((0x % MULTIXACT_MEMBERS_PER_PAGE) + 1))
/* page in which a member is to be found */
-#d
Andrey M. Borodin 于2024年4月8日周一 17:40写道：
>
>
> > On 27 Sep 2023, at 16:06, tender wang wrote:
> >
> >Do you have any comments or suggestions on this issue? Thanks.
> Hi Tender,
>
> there are some review comments in the thread, that you might be interested
> in.
> I'll mark this [0] entry "Wai
Hi!
I've been trying to introduce 64-bit transaction identifications to
Postgres for quite a while [0]. All this implies,
of course, an enormous amount of change that will have to take place in
various modules. Consider this, the
patch set become too big to be committed “at once”.
The obvious sol
> On Mon, Apr 15, 2024 at 06:09:29PM +0900, Sutou Kouhei wrote:
>
> Thanks. I'm not familiar with this code base but I've
> reviewed these patches because I'm interested in this
> feature too.
Thanks for the review! The commentaries for the first patch make sense
to me, will apply.
> 0003:
>
> >
On Tue, Apr 23, 2024 at 01:48:04AM +0300, Heikki Linnakangas wrote:
> Here's the patch for that. The error message is:
>
> "direct SSL connection was established without ALPN protocol negotiation
> extension"
WFM.
> That's accurate, but I wonder if we could make it more useful to a user
> who's
69 matches
Mail list logo
