On Sat, Jun 22, 2024, at 11:44, Joel Jacobson wrote:
> * v5-0001-Add-pg_get_acl.patch
> * v2-0002-Add-pg_get_acl-overloads.patch
Rename files to ensure cfbot applies them in order; both need to have same
version prefix.
v6-0001-Add-pg_get_acl.patch
Description: Binary data
v6-0002-Add-pg_get
On Mon, Mar 25, 2024 at 12:55:39PM +0100, Peter Eisentraut wrote:
> I have committed your version v33.
> commit d44032d
> --- /dev/null
> +++ b/src/bin/pg_basebackup/pg_createsubscriber.c
> +static char *
> +concat_conninfo_dbname(const char *conninfo, const char *dbname)
> +{
> + PQExpBuffe
On Saturday, June 22, 2024, Tatsuo Ishii wrote:
> >>> * As func_expr but does not accept WINDOW functions directly (they
> >>> * can still be contained in arguments for functions etc.)
> >
> >> The "but" is required, add a comma before it. It could also be written
> a
> >> bit more verbosely:
>
>>> * As func_expr but does not accept WINDOW functions directly (they
>>> * can still be contained in arguments for functions etc.)
>
>> The "but" is required, add a comma before it. It could also be written a
>> bit more verbosely:
>
> Perhaps s/As func_expr/Like func_expr/ would be less confu
Hi Shubham,
Thanks for sharing new patch! You shared as v9, but it should be v10, right?
Also, since there are no commitfest entry, I registered [1]. You can rename the
title based on the needs. Currently CFbot said OK.
Anyway, below are my comments.
01. General
Your patch contains unnecessary c
"David G. Johnston" writes:
> On Sat, Jun 22, 2024 at 9:02 PM Tatsuo Ishii wrote:
>> I was unable to parse a comment in src/backend/parser/gram.y around line
>> 11364:
>>
>> * As func_expr but does not accept WINDOW functions directly (they
>> * can still be contained in arguments for functions
> On Sat, Jun 22, 2024 at 9:02 PM Tatsuo Ishii wrote:
>
>> I was unable to parse a comment in src/backend/parser/gram.y around line
>> 11364:
>>
>> /*
>> * As func_expr but does not accept WINDOW functions directly (they
>> * can still be contained in arguments for functions etc.)
>> * Use thi
On Sat, Jun 22, 2024 at 9:02 PM Tatsuo Ishii wrote:
> I was unable to parse a comment in src/backend/parser/gram.y around line
> 11364:
>
> /*
> * As func_expr but does not accept WINDOW functions directly (they
> * can still be contained in arguments for functions etc.)
> * Use this when wind
I was unable to parse a comment in src/backend/parser/gram.y around line 11364:
/*
* As func_expr but does not accept WINDOW functions directly (they
* can still be contained in arguments for functions etc.)
* Use this when window expressions are not allowed, so to disambiguate
* the grammar.
On Sat, Jun 22, 2024 at 7:21 PM Joseph Koshakow wrote:
> On Sat, Jun 22, 2024 at 6:23 PM David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
> > except invoker and triggerer are the same entity
>
> Maybe "executor" would have been a better term than 'invoker". In this
> specific example th
On Sat, Jun 22, 2024 at 6:23 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> except invoker and triggerer are the same entity
Maybe "executor" would have been a better term than 'invoker". In this
specific example they are not the same entity. The trigger is
triggered and queued by on
On Sat, Jun 8, 2024 at 2:37 PM Joseph Koshakow wrote:
>
>
Something like
> `SECURITY INVOKER | SECURITY TRIGGERER` (modeled after the modifiers in
> `CREATE FUNCTION`) that control which role is used.
>
I'm inclined toward this option (except invoker and triggerer are the same
entity, we need ow
On Mon, Jun 10, 2024 at 1:00 PM Laurenz Albe
wrote:
>Like you, I was surprised by the current behavior. There is a design
>principle that PostgreSQL tries to follow, called the "Principle of
>least astonishment". Things should behave like a moderately skilled
>user would expect
Hi,
On June 22, 2024 7:32:01 PM GMT+02:00, walt...@technowledgy.de wrote:
>Andres Freund:
>> FWIW, dynamic linking has a noticeable overhead on other platforms too. A
>> non-dependencies-enabled postgres can do about 2x the connections-per-second
>> than a fully kitted out postgres can (basically
On Fri, Jun 21, 2024 at 03:44:07PM -0500, Nathan Bossart wrote:
> I'm still not sure about this approach. At the moment, I'm leaning towards
> something more like v2 [2] where the upper limit is a PGC_POSTMASTER GUC
> (that we would set very low for TAP tests).
Like so.
--
nathan
>From c1c33c6c
On Jun 22, 2024, at 13:15, Tom Lane wrote:
> It's hard to get excited about this.
I freely admit I’m getting into the weeds here. :-)
>> The corresponding jsonpath methods don’t like offsets with seconds *at all*:
>
> Perhaps that should be fixed, but it's pretty low-priority IMO.
> I doubt th
On Fri, Jun 21, 2024 at 8:23 AM Peter Smith wrote:
>
> Hi Shubham, here are some more patch v8-0001 comments that I missed yesterday.
>
> ==
> src/test/subscription/t/011_generated.pl
>
> 1.
> Are the PRIMARY KEY qualifiers needed for the new tab2, tab3 tables? I
> don't think so.
>
> ~~~
>
>
On Thu, Jun 20, 2024 at 9:03 AM Peter Smith wrote:
>
> Hi, here are my review comments for v8-0001.
>
> ==
> Commit message.
>
> 1.
> It seems like the patch name was accidentally omitted, so it became a
> mess when it defaulted to the 1st paragraph of the commit message.
>
> ==
> contrib/
Andres Freund:
FWIW, dynamic linking has a noticeable overhead on other platforms too. A
non-dependencies-enabled postgres can do about 2x the connections-per-second
than a fully kitted out postgres can (basically due to more memory mapping
metadata being copied). But on windows the overhead is
"David E. Wheeler" writes:
> The treatment of timestamptz (and timetz) values with offsets that include
> seconds seems a bit inconsistent.
It's hard to get excited about this. Per the IANA TZ data,
nowhere in the world has used fractional-minute UT offsets
since 1972:
# In 1972 Liberia was th
Hi,
On 2024-06-21 15:36:56 +0100, Dave Page wrote:
> For giggles, I took a crack at doing that, manually creating .pc files for
> everything I've been working with so far.
Cool!
> It seems to work as expected, except that unlike everything else libintl is
> detected entirely based on whether th
Hi,
On 2024-06-21 12:20:49 +0100, Dave Page wrote:
> On Thu, 20 Jun 2024 at 21:58, Andres Freund wrote:
> That is precisely what https://github.com/dpage/winpgbuild/ was intended
> for - and it works well for PG <= 16.
If we develop it into that - I'd be happy. I mostly want to be able to do
aut
Hackers,
The treatment of timestamptz (and timetz) values with offsets that include
seconds seems a bit inconsistent. One can create such timestamps through the
input function:
david=# select '2024-06-22T12:35:00+02:30:15'::timestamptz;
timestamptz
2024-06
On Sat, Jun 22, 2024 at 10:53 AM Peter Geoghegan wrote:
>
> On Sat, Jun 22, 2024 at 10:43 AM Melanie Plageman
> wrote:
> > Hmm. So perhaps this subtraction results in the desired behavior for
> > freeze limit -- but by using FreezeLimit as the cutoff_xid for
> > heap_prepare_freeze_tuple(), you c
Peter Eisentraut writes:
> On 18.06.24 13:43, Ranier Vilela wrote:
>> I found another implementation of strsep, it seems lighter to me.
>> I will attach it for consideration, however, I have not done any testing.
> Yeah, surely there are many possible implementations. I'm thinking,
> since we a
On 18.06.24 13:43, Ranier Vilela wrote:
But I would like to see more const char * where this is possible.
For example, in pg_locale.c
IMO, the token variable can be const char *.
At least strchr expects a const char * as the first parameter.
This would not be future-proof. In C23, if you pas
Hello hackers,
30.03.2024 01:17, Noah Misch wrote:
On Fri, Mar 29, 2024 at 09:17:55AM +0100, Jelte Fennema-Nio wrote:
On Thu, 28 Mar 2024 at 19:03, Tom Lane wrote:
Could we make this test bulletproof by using an injection point?
If not, I remain of the opinion that we're better off without it
On Sat, Jun 22, 2024 at 10:43 AM Melanie Plageman
wrote:
> Hmm. So perhaps this subtraction results in the desired behavior for
> freeze limit -- but by using FreezeLimit as the cutoff_xid for
> heap_prepare_freeze_tuple(), you can still end up considering freezing
> tuples with xmax older than Ol
Bruce Momjian writes:
> FYI, changing this GUC name could force an initdb because
> postgresql.conf would have the old name and removing the comment to
> change it would cause an error. Therefore, we should change it ASAP.
That's not reason for a forced initdb IMO. It's easily fixed by
hand.
A
On Fri, Jun 21, 2024 at 4:22 PM Melanie Plageman
wrote:
>
> While investigating a bug over on [1], I found that
> vacuum_set_xid_limits() is calculating freezeLimit in an unsafe way on
> at least Postgres 14 and 15.
>
> limit = *oldestXmin - freezemin;
> safeLimit = ReadNextTransactionId()
On Fri, Jun 21, 2024 at 7:37 PM Matthias van de Meent
wrote:
> On Tue, 16 Apr 2024 at 12:34, Alexander Korotkov wrote:
> >
> > You're right. No sense trying to fix this. Reverted.
>
> I just noticed that this revert (commit 6377e12a) seems to have
> introduced two comment blocks atop TableAmRou
On Sat, Jun 22, 2024 at 03:17:03PM +0530, Amit Kapila wrote:
> On Sat, Jun 22, 2024 at 1:49 AM Nathan Bossart
> wrote:
> >
> > On Fri, Jun 21, 2024 at 03:50:00PM -0400, Tom Lane wrote:
> > > Allow specification of physical standbys that must be synchronized
> > > before they are visible t
Hi,
On Thu, Jun 13, 2024 at 11:56:26AM +, Bertrand Drouvot wrote:
> == Observations
> ===
>
> As compare to v2:
>
> 1. scanning heap time is about the same
> 2. vacuuming indexes time is about 3 minutes longer on master
> 3. vacuum
On Sat, 22 Jun 2024 at 18:30, Alexander Lakhin wrote:
> So it doesn't seem impossible for this operation to last for more than two
> minutes.
>
> The facts that SyncDataDirectory() is executed between these two messages
> logged, 008_fsm_truncation is the only test which turns fsync on, and we
>
On Sat, Jun 22, 2024 at 1:49 AM Nathan Bossart wrote:
>
> On Fri, Jun 21, 2024 at 03:50:00PM -0400, Tom Lane wrote:
> > Allow specification of physical standbys that must be synchronized
> > before they are visible to subscribers (Hou Zhijie, Shveta Malik)
> >
> > it seems like the name ou
On Sat, Jun 22, 2024, at 02:54, Joel Jacobson wrote:
> Attachments:
> * v4-0001-Add-pg_get_acl.patch
> * 0002-Add-pg_get_acl-overloads.patch
Rebase and reduced diff for src/test/regress/sql/privileges.sql between patches.
/Joel
v5-0001-Add-pg_get_acl.patch
Description: Binary data
v2-0002-Add-
On Fri, Jun 21, 2024 at 8:18 PM Amit Langote wrote:
>
> >> JSON_VALUE on error, on empty semantics should be the same as json_query.
> >> like:
> >> [ { ERROR | NULL | EMPTY { [ ARRAY ] | OBJECT } | DEFAULT expression }
> >> ON EMPTY ]
> >> [ { ERROR | NULL | EMPTY { [ ARRAY ] | OBJECT } | DEFAULT
On Sat, Jun 22, 2024 at 1:49 AM Nathan Bossart wrote:
>
> On Fri, Jun 21, 2024 at 03:50:00PM -0400, Tom Lane wrote:
> > Allow specification of physical standbys that must be synchronized
> > before they are visible to subscribers (Hou Zhijie, Shveta Malik)
> >
> > it seems like the name ou
Hello hackers,
This week dodo started failing on the 008_fsm_truncation test sporadically
due to pg_ctl timeout. For example, [1] (REL_14_STABLE):
### Starting node "standby"
# Running: pg_ctl -D
/media/pi/250gb/proj/bf2/v17/buildroot/REL_14_STABLE/pgsql.build/src/test/recovery/tmp_check/t_008_f
Hi,
Thanks all for chiming in.
On Fri, Jun 21, 2024 at 8:00 PM Markus Winand wrote:
> So updating the three options:
> > 1. Disallow anything but jsonb for context_item (the patch I posted
> > yesterday)
>
> * Non-conforming
> * patch available
>
> > 2. Continue allowing context_item to be non-
On Fri, Jun 21, 2024 at 9:18 PM Amit Langote wrote:
> On Fri, Jun 21, 2024 at 9:47 AM David G. Johnston
> wrote:
> > On Thu, Jun 20, 2024 at 9:01 AM jian he wrote:
> >> playing around with it.
> >> found some minor issues:
> >>
> >> json_exists allow: DEFAULT expression ON ERROR, which is not
>
41 matches
Mail list logo
