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
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 } |
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
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
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
Hi,
> Hi,
>
> On 2024-06-17 15:39:27 -0400, Robert Haas wrote:
>> As I mentioned in my talk at 2024.pgconf.dev, I think that the biggest
>> problem with autovacuum as it exists today is that the cost delay is
>> sometimes too low to keep up with the amount of vacuuming that needs
>> to be done.
Hi,
Let's me clarify the current state of this patch and what kind of help
is needed. You can check [1] for what kind of problem it try to solve
and what is the current approach.
The current blocker is if the approach is safe (potential to memory leak
crash etc.). And I want to have some
On Fri, Jun 21, 2024, at 05:25, Michael Paquier wrote:
> Interesting idea.
>
> I am not really convinced that the regproc and regclass overloads are
> really necessary, considering the fact that one of the goals
> mentioned, as far as I understand, is to be able to get an idea of the
> ACLs
On 21.06.2024 23:35, Robert Haas wrote:
On Fri, Jun 21, 2024 at 1:05 PM Alena Rybakina
wrote:
I'm confused, I have seen that we have two threads [1] and [2] about this
thread and I haven't found any explanation for how they differ.
And I don't understand, why am I not listed as the author
On 20/06/2024 19:12, Robert Haas wrote:
I'm working to start a mentoring program where code contributors can
be mentored by current committers. Applications are now open:
https://forms.gle/dgjmdxtHYXCSg6aB7
Periodically, someone -- most likely not me, since a few people have
been kind
On Thu, Jun 13, 2024 at 05:35:49PM -0700, Noah Misch wrote:
> On Mon, Jun 10, 2024 at 07:45:25PM -0700, Noah Misch wrote:
> > On Thu, Jun 06, 2024 at 09:48:51AM -0400, Robert Haas wrote:
> > > It's not this patch set's fault, but I'm not very pleased to see that
> > > the injection point wait
Hi, Alena.
On Fri, Jun 21, 2024 at 8:05 PM Alena Rybakina
wrote:
>
> I'm confused, I have seen that we have two threads [1] and [2] about this
> thread and I haven't found any explanation for how they differ.
>
> And I don't understand, why am I not listed as the author of the patch? I was
>
On Fri, Jun 21, 2024 at 11:22:05AM +0200, Jelte Fennema-Nio wrote:
> 0001 is some cleanup after f4b54e1ed9
Oops. I'll plan on committing this after the 17beta2 release freeze is
lifted.
--
nathan
Hannu Krosing writes:
> This is my current patch which also adds running % and optionally uses
> faster way to count leading zeros, though I did not see a change from
> that.
I've not read the patch yet, but I did create a CF entry [1]
to get some CI cycles on this. The cfbot complains [2]
On Tue, Jun 18, 2024 at 07:43:36PM -0500, Nathan Bossart wrote:
> On Tue, Jun 18, 2024 at 02:33:31PM -0700, Andres Freund wrote:
>> Another one:
>>
>> Have a general cap of 64, but additionally limit it to something like
>> max(1, min(WORKER_CAP, max_connections / 4))
>>
>> so that cases
On Fri, Jun 21, 2024 at 1:05 PM Alena Rybakina
wrote:
> I'm confused, I have seen that we have two threads [1] and [2] about this
> thread and I haven't found any explanation for how they differ.
>
> And I don't understand, why am I not listed as the author of the patch? I was
> developing the
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 ought to have some connection to
> synchronization. Perhaps
Thanks Tom Lane. You are more insightful.
Regards,
Ikram
On Sat, Jun 22, 2024 at 12:50 AM Tom Lane wrote:
> Muhammad Ikram writes:
> > A humble input, as on primary we have #primary_slot_name = '' then
> should
> > not it be okay to have standby_slot_names or standby_slot_name ? It seems
> >
Muhammad Ikram writes:
> A humble input, as on primary we have #primary_slot_name = '' then should
> not it be okay to have standby_slot_names or standby_slot_name ? It seems
> consistent with the Guc on primary.
> Another suggestion is *standby_replication_slots*.
IIUC, Bruce's complaint is
Jelte Fennema-Nio writes:
> On Fri, 21 Jun 2024 at 10:46, Дмитрий Питаков wrote:
>> Why not increase the buffer size?
> I think changing the buffer size sounds like a reasonable idea, if
> that speeds stuff up. But I think it would greatly help your case if
> you showed the perf increase using
Hi,
A humble input, as on primary we have #primary_slot_name = '' then should
not it be okay to have standby_slot_names or standby_slot_name ? It seems
consistent with the Guc on primary.
Another suggestion is *standby_replication_slots*.
Regards,
Muhammad Ikram
Bitnine Global.
On Fri, Jun
John Naylor writes:
> Pushed. I'll clear the open item once all buildfarm members have reported in.
Just to confirm, my raspberry pi 4 got through "make
installcheck-parallel" under valgrind after this commit.
regards, tom lane
On Fri Jun 21, 2024 at 10:46 AM CDT, Dave Page wrote:
On Fri, 21 Jun 2024 at 16:15, Robert Haas wrote:
> As a practical matter, I don't think MSVC is coming back. The
> buildfarm was already changed over to use meson, and it would be
> pretty disruptive to try to re-add buildfarm
I'm confused, I have seen that we have two threads [1] and [2] about
this thread andIhaven'tfoundanyexplanationfor howtheydiffer.
And I don't understand, whyam Inotlistedas the authorof the patch?
Iwasdevelopingthe firstpartof the patchbeforeAndreycameto review it[3]
We are continuing to work on the changes…
> Do you still care about 32-bit binaries on AIX? If not, let's make that
> the default in configure or a check for it, and remove the instructions
> on building 32-bit binaries from the docs.
As most of the products are moving towards 64bit, we
Hi,
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 TableAmRoutine's
scan_analyze_next_block, and I can't find a clear reason why
On 6/21/24 00:07, Tomas Vondra wrote:
> Here's a fix adding the missing headers to pg_combinebackup, and fixing
> some compile-time issues in the ifdef-ed block.
>
> I've done some basic manual testing today - I plan to test this a bit
> more tomorrow, and I'll also look at integrating this into
pá 21. 6. 2024 v 17:55 odesílatel Nathan Bossart
napsal:
> On Fri, Jun 21, 2024 at 04:36:13PM +0200, Jelte Fennema-Nio wrote:
> > I recently got write access to the cfbot repo[1] and machine from
> > Thomas. And I deployed a few improvements this week. The most
> > significant one is that it is
pá 21. 6. 2024 v 16:36 odesílatel Jelte Fennema-Nio napsal:
>
> I recently got write access to the cfbot repo[1] and machine from
> Thomas. And I deployed a few improvements this week. The most
> significant one is that it is now much easier to use GitHub as part of
> your patch review workflow.
On Fri, Jun 21, 2024 at 04:36:13PM +0200, Jelte Fennema-Nio wrote:
> I recently got write access to the cfbot repo[1] and machine from
> Thomas. And I deployed a few improvements this week. The most
> significant one is that it is now much easier to use GitHub as part of
> your patch review
On Fri, Jun 21, 2024 at 11:37:54AM -0400, Bruce Momjian wrote:
> The release notes have this item:
>
> Allow specification of physical standbys that must be synchronized
> before they are visible to subscribers (Hou Zhijie, Shveta Malik)
>
> The new server variable is
here was a mad
rush to get things working under Meson in any way possible.
> As a practical matter, I don't think MSVC is coming back. The
> buildfarm was already changed over to use meson, and it would be
> pretty disruptive to try to re-add buildfarm coverage for a
> resurrected MSVC o
On Thu, Jun 20, 2024 at 07:57:16PM -0700, David G. Johnston wrote:
> I like this. Losing the table turned out to be ok. Thank you.
Awesome.
> I would probably put pg_monitor first in the list.
Done.
> + A user granted this role cannot however send signals to a backend owned
> by a superuser.
On Fri, 21 Jun 2024 07:12:25 +
wrote:
> * Is this feature useful? Is there a possibility it will be accepted?
I think adding such information to EXPLAIN outputs is useful because it
will help users confirm the effect of a multicolumn index on a certain query
and decide to whether leave,
nged over to use meson, and it would be
pretty disruptive to try to re-add buildfarm coverage for a
resurrected MSVC on the eve of beta2. I think we should focus on
improving whatever isn't quite right in meson -- plenty of other
people have also complained about various things there, me include
Peter Eisentraut writes:
> - strlcpy(errbuf, strerror(ERR_GET_REASON(ecode)), SSL_ERR_LEN);
> + strerror_r(ERR_GET_REASON(ecode), errbuf, SSL_ERR_LEN);
Most of libpq gets at strerror_r via SOCK_STRERROR for Windows
portability. Is that relevant here?
Hi
On Fri, 21 Jun 2024 at 12:20, Dave Page wrote:
>
> We/I *could* add cmake/pc file generation to that tool, which would make
> things work nicely with PostgreSQL 17 of course.
>
For giggles, I took a crack at doing that, manually creating .pc files for
everything I've been working with so
On 21/06/2024 02:25, Heikki Linnakangas wrote:
Hmm, looking closer, I think this might be a more appropriate place for
the RelationCloseSmgr() call:
/*
* If it's a mapped relation, immediately update its
rd_locator in
*
Hi,
Thanks for taking a look.
On Fri, Jun 21, 2024 at 4:05 PM jian he wrote:
> On Tue, Jun 18, 2024 at 5:02 PM Amit Langote wrote:
> > On Tue, Jun 4, 2024 at 7:03 PM Amit Langote wrote:
> > > On Tue, Jun 4, 2024 at 2:20 AM Tom Lane wrote:
> > > > Peter Eisentraut writes:
> > > > > On
> On 21 Jun 2024, at 13:15, Peter Eisentraut wrote:
> I noticed that this change uses not-thread-safe strerror() in libpq code.
>
> Perhaps something like this would be better (and simpler):
Nice catch, LGTM.
--
Daniel Gustafsson
Hi,
On Wed, Jun 19, 2024 at 02:11:50PM +, Bertrand Drouvot wrote:
> To sum up, I did not see any cases that did not lead to 1. or 2., so I think
> it's safe to not add an extra lock for the RelationRelationId case. If, for
> any
> reason, there is still cases that are outside 1. or 2. then
On Fri, Jun 21, 2024 at 12:42 PM wrote:
> Hi,
>
>
>
> Regarding the multicolumn B-Tree Index, I'm considering
>
> if we can enhance the EXPLAIN output. There have been requests
>
> for this from our customer.
>
>
>
> As the document says, we need to use it carefully.
>
> > The exact rule is that
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:
>>
>> On Thu, Jun 20, 2024 at 5:46 PM Amit Langote wrote:
>> >
>> > On Thu, Jun 20, 2024 at 1:03 AM David G. Johnston
>> > wrote:
>> > > On Wed, Jun 19, 2024 at 8:29 AM jian he
>> > >
On Fri, 21 Jun 2024 at 10:46, Дмитрий Питаков wrote:
> Why not increase the buffer size?
I think changing the buffer size sounds like a reasonable idea, if
that speeds stuff up. But I think it would greatly help your case if
you showed the perf increase using a simple benchmark, especially if
Hi,
On Thu, Jun 20, 2024 at 5:58 PM V N G Samba Siva Reddy Chinta <
sambasivareddychi...@gmail.com> wrote:
> Hello Team,
> Good Day,
>
> I have been working on adding a CustomScanState object in the executor
> state in my project. As part of CustomScanState, I execute queries and
> store their
Hi
On Thu, 20 Jun 2024 at 21:58, Andres Freund wrote:
>
> > I don't think requiring or expecting vcpkg or conan is reasonable at all,
> > for a number of reasons:
> >
> > - Neither supports all the dependencies at present.
> > - There are real supply chain verification concerns for vendors.
> >
On 08.03.24 01:46, Tom Lane wrote:
Daniel Gustafsson writes:
On 7 Mar 2024, at 20:58, Tom Lane wrote:
This could probably do with a comment, and we need to propagate
the fix into libpq's copy of the function too. Barring objections,
I'll take care of that and push it later today.
LGTM.
On Thu, Jun 20, 2024 at 2:58 PM John Naylor wrote:
> the struct. If that's agreeable I'll commit it that way tomorrow
> unless someone beats me to it.
Pushed. I'll clear the open item once all buildfarm members have reported in.
> On 21.06.2024, at 07:38, David G. Johnston wrote:
>
> On Thursday, June 20, 2024, Markus Winand wrote:
>
>
> > On 21.06.2024, at 06:46, David G. Johnston
> > wrote:
> >>
>
> >
> > 2 also has the benefit of being standard conforming while 1 does not.
>
> Why do you think so? Do you
Hello, Michael!
> This is a non-fresh Friday-afternoon idea, but it would make sure that
> we don't have any transactions using the indexes switched to _ccold
> with indisvalid that are waiting for a drop in phase 5. Your tests
> seem to pass with that, and that keeps the operation intact
>
On Fri, Jun 21, 2024 at 11:11 AM David G. Johnston
wrote:
>
> On Thu, Jun 20, 2024 at 7:30 PM jian he wrote:
>>
>> "predicate check expressions return the single three-valued result of
>>
>> the predicate: true, false, or unknown."
>> "unknown" is wrong, because `select 'unknown'::jsonb;` will
> On 21 Jun 2024, at 10:36, Michael Paquier wrote:
>
> On Fri, Jun 14, 2024 at 03:12:50PM -0500, Nathan Bossart wrote:
>> On Fri, Jun 14, 2024 at 12:06:36PM +0500, Andrey M. Borodin wrote:
>>> This patch looks good to me.
>>
>> Thanks for looking.
>
> While double-checking the whole, where
Hi,
> > I'm working to start a mentoring program where code contributors can
> > be mentored by current committers. Applications are now open:
> > https://forms.gle/dgjmdxtHYXCSg6aB7
>
> This is amazing! Thank you for putting it together, Robert.
Great initiative! Thanks Rovert and to everyone
Hi Shubham/Shlok.
FYI, there is some other documentation page that mentions generated
column replication messages.
This page [1] says:
"Next, the following message part appears for each column included in
the publication (except generated columns):"
But, with the introduction of your new
Hi, Here are some review comments for patch v9-0003
==
Commit Message
/fix/fixes/
==
1.
General. Is tablesync enough?
I don't understand why is the patch only concerned about tablesync?
Does it make sense to prevent VIRTUAL column replication during
tablesync, if you aren't also going
On Tue, Jun 18, 2024 at 5:02 PM Amit Langote wrote:
>
> On Tue, Jun 4, 2024 at 7:03 PM Amit Langote wrote:
> > On Tue, Jun 4, 2024 at 2:20 AM Tom Lane wrote:
> > > Peter Eisentraut writes:
> > > > On 02.06.24 21:46, Tom Lane wrote:
> > > >> If you don't
> > > >> like our current behavior, then
On Mon, Jun 17, 2024 at 07:00:51PM +0200, Michail Nikolaev wrote:
> The simplest possible fix is to use ShareLock
> instead ShareUpdateExclusiveLock in the index_concurrently_swap
>
> oldClassRel = relation_open(oldIndexId, ShareLock);
> newClassRel =
On Thu, Jun 20, 2024 at 6:36 AM Peter Smith wrote:
>
> Hi Amit.
>
> I modified the patch text slightly according to Peter E's suggestion [1].
>
> I also tested the above examples against all older PostgreSQL versions
> 12,13,14,15,16,17. The logical replication behaviour of skipping
> generated
On 20.06.24 16:34, Noah Misch wrote:
On Thu, Jun 20, 2024 at 09:29:45AM +0200, Peter Eisentraut wrote:
On 16.06.24 21:34, Noah Misch wrote:
On Thu, Oct 05, 2023 at 05:46:46PM +0200, Peter Eisentraut wrote:
--- a/src/backend/Makefile
+++ b/src/backend/Makefile
On Wed, Jun 19, 2024 at 10:44 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Horiguchi-san,
>
> Thanks for sharing the patch! I agree this approach (ensure WAL records are
> flushed)
> Is more proper than others.
>
> I have an unclear point. According to the comment atop GetInsertRecPtr(), it
>
On 20.06.24 14:05, Andrew Dunstan wrote:
On 2024-06-18 Tu 7:48 AM, Peter Eisentraut wrote:
I have this patch series that fixes up the types of the new
incremental JSON API a bit. Specifically, it uses "const" throughout
so that the top-level entry points such as pg_parse_json_incremental()
On Thursday, June 20, 2024, Markus Winand wrote:
>
>
> > On 21.06.2024, at 06:46, David G. Johnston
> wrote:
> >>
>
> >
> > 2 also has the benefit of being standard conforming while 1 does not.
>
> Why do you think so? Do you have any references or is this just based on
> previous statements in
On Fri, Jun 21, 2024 at 10:31:30AM +0500, Andrey M. Borodin wrote:
> Thanks for the pointer, I’ll try this approach!
Thanks. FWIW, I've put my mind into it, and fixed the thing a few
minutes ago:
https://www.postgresql.org/message-id/ZnURUaujl39wSoEW%40paquier.xyz
--
Michael
signature.asc
On Fri, Jun 14, 2024 at 03:12:50PM -0500, Nathan Bossart wrote:
> On Fri, Jun 14, 2024 at 12:06:36PM +0500, Andrey M. Borodin wrote:
> > This patch looks good to me.
>
> Thanks for looking.
While double-checking the whole, where I don't have much to say about
0001, I have fixed a few issues with
> On 21 Jun 2024, at 09:01, Michael Paquier wrote:
>
> On Fri, Jun 14, 2024 at 12:06:36PM +0500, Andrey M. Borodin wrote:
>> I’ve tried to dig into the test.
>> The problem is CV is allocated in
>>
>> inj_state = GetNamedDSMSegment("injection_points”,
>>
>> which seems to be destroyed in
>>
> On 21.06.2024, at 06:46, David G. Johnston wrote:
>>
>> On Thursday, June 20, 2024, Pavel Stehule wrote:
>>
>>
>> pá 21. 6. 2024 v 6:01 odesílatel Amit Langote
>> napsal:
>> On Fri, Jun 21, 2024 at 10:01 AM David G. Johnston
>> wrote:
>>
>> > > By the standard, it is
> On 21.06.2024, at 03:00, David G. Johnston wrote:
>
> On Thu, Jun 20, 2024 at 5:22 PM Amit Langote wrote:
>
> Soft error handling *was* used for catching cast errors in the very
> early versions of this patch (long before I got involved and the
> infrastructure you mention got added). It
Hi Shubham/Shlok.
FYI, my patch describing the current PG17 behaviour of logical
replication of generated columns was recently pushed [1].
Note that this will have some impact on your patch set. e.g. You are
changing the current replication behaviour, so the "Generated Columns"
section note
On Thursday, June 20, 2024, Pavel Stehule wrote:
>
>
> pá 21. 6. 2024 v 6:01 odesílatel Amit Langote
> napsal:
>
>> On Fri, Jun 21, 2024 at 10:01 AM David G. Johnston
>> wrote:
>>
>> > > By the standard, it is implementation-defined whether JSON parsing
>> errors
>> > > should be caught by ON
pá 21. 6. 2024 v 6:01 odesílatel Amit Langote
napsal:
> On Fri, Jun 21, 2024 at 10:01 AM David G. Johnston
> wrote:
> > On Thu, Jun 20, 2024 at 5:22 PM Amit Langote
> wrote:
> >>
> >>
> >> Soft error handling *was* used for catching cast errors in the very
> >> early versions of this patch
On Fri, Jun 21, 2024 at 01:09:10PM +0900, Kyotaro Horiguchi wrote:
> At Thu, 13 Jun 2024 16:59:50 +0900, Michael Paquier
> wrote in
>> * The kind IDs may change across restarts, meaning that any stats data
>> associated to a custom kind is stored with the *name* of the custom
>> stats kind.
pá 21. 6. 2024 v 2:22 odesílatel Amit Langote
napsal:
> On Fri, Jun 21, 2024 at 1:11 AM David G. Johnston
> wrote:
> > On Thu, Jun 20, 2024 at 2:19 AM Amit Langote
> wrote:
> >> On Mon, Jun 17, 2024 at 10:07 PM Markus Winand
> wrote:
> >> > > On 17.06.2024, at 08:20, Amit Langote
> wrote:
>
At Thu, 13 Jun 2024 16:59:50 +0900, Michael Paquier wrote
in
> * The kind IDs may change across restarts, meaning that any stats data
> associated to a custom kind is stored with the *name* of the custom
> stats kind. Depending on the discussion happening here, I'd be open
> to use the same
On Fri, Jun 14, 2024 at 12:06:36PM +0500, Andrey M. Borodin wrote:
> I’ve tried to dig into the test.
> The problem is CV is allocated in
>
> inj_state = GetNamedDSMSegment("injection_points”,
>
> which seems to be destroyed in
>
> shmem_exit() calling dsm_backend_shutdown()
>
> This happens
On Fri, Jun 21, 2024 at 10:01 AM David G. Johnston
wrote:
> On Thu, Jun 20, 2024 at 5:22 PM Amit Langote wrote:
>>
>>
>> Soft error handling *was* used for catching cast errors in the very
>> early versions of this patch (long before I got involved and the
>> infrastructure you mention got
On Thu, 20 Jun 2024 at 23:44, Tom Lane wrote:
> Michael Paquier writes:
> > On Thu, Jun 20, 2024 at 08:32:57AM +0200, Joel Jacobson wrote:
> >> I've added overloaded versions for regclass and regproc so far:
> >>
> >> \df pg_get_acl
> >> List of functions
> >> Schema |Name| Result
On Thu, 20 Jun 2024 at 02:33, Joel Jacobson wrote:
> On Wed, Jun 19, 2024, at 16:23, Isaac Morland wrote:
> > I have no idea how often this would be useful, but I wonder if it could
> > work to have overloaded single-parameter versions for each of
> > regprocedure (pg_proc.proacl), regclass
Michael Paquier writes:
> On Thu, Jun 20, 2024 at 08:32:57AM +0200, Joel Jacobson wrote:
>> I've added overloaded versions for regclass and regproc so far:
>>
>> \df pg_get_acl
>> List of functions
>> Schema |Name| Result data type | Argument data types | Type
>>
en the columns
(including the generated ones) are all in different orders on the
pub/sub tables.
~~~
3. General - varnames.
It would help with understanding if the 'attgenlist' variables in all
these functions are re-named to make it very clear that this is
referring to the *remote* (publisher-side)
On Thu, Jun 20, 2024 at 08:32:57AM +0200, Joel Jacobson wrote:
> I've added overloaded versions for regclass and regproc so far:
>
> \df pg_get_acl
> List of functions
>Schema |Name| Result data type | Argument data types | Type
>
Andy Fan writes:
> I relies on some compiler's check to reduce some simple coding issues, I
> use clang 18.1.6 for now. however "CFLAGS='-Wall -Werror ' ./configure"
> would fail,
Nope, you cannot do that: -Werror breaks many of configure's tests.
See
On Thu, Jun 20, 2024 at 7:30 PM jian he wrote:
> "predicate check expressions return the single three-valued result of
>
the predicate: true, false, or unknown."
> "unknown" is wrong, because `select 'unknown'::jsonb;` will fail.
> here "unknown" should be "null"? see jsonb_path_query doc entry
On Tue, Jun 18, 2024 at 9:52 AM Nathan Bossart
wrote:
> On Mon, Jun 17, 2024 at 02:10:22PM -0400, Robert Haas wrote:
> > On Thu, Jun 13, 2024 at 3:48 PM Nathan Bossart
> wrote:
> >> I think we could improve matters by abandoning the table and instead
> >> documenting these roles more like we
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.
~~~
2.
+$result = $node_subscriber->safe_psql('postgres', "SELECT * FROM
On Mon, Jan 15, 2024 at 1:50 PM Richard Guo wrote:
> Updated this patch over 29f114b6ff, which indicates that we should apply
> the same rules for PHVs.
Here is a new rebase of this patch, with some tweaks to comments. I've
also updated the commit message to better explain the context.
To
On Thu, Jun 20, 2024 at 08:01:19PM -0400, Bruce Momjian wrote:
> FYI, looking at the release notes, I see 15 GUC variables added in this
> release, and two removed. That 15 number seemed unusually high so I
> thought I would report it.
Scanning pg_settings across the two versions, I'm seeing:
-
On Wed, Jun 19, 2024 at 05:14:50AM +, Hayato Kuroda (Fujitsu) wrote:
> I have an unclear point. According to the comment atop GetInsertRecPtr(), it
> just
> returns the approximated value - the position of the last full WAL page [1].
> If there is a continuation WAL record which across a
On Thu, Jun 20, 2024 at 5:22 PM Amit Langote
wrote:
>
> Soft error handling *was* used for catching cast errors in the very
> early versions of this patch (long before I got involved and the
> infrastructure you mention got added). It was taken out after Pavel
> said [1] that he didn't like
On Thu, Jun 20, 2024 at 9:01 AM jian he wrote:
> On Thu, Jun 20, 2024 at 5:46 PM Amit Langote
> wrote:
> >
> > On Thu, Jun 20, 2024 at 1:03 AM David G. Johnston
> > wrote:
> > > On Wed, Jun 19, 2024 at 8:29 AM jian he
> wrote:
> > >>
> > >> On Mon, Jun 17, 2024 at 9:05 PM Chapman Flack
>
On Fri, Jun 21, 2024 at 1:11 AM David G. Johnston
wrote:
> On Thu, Jun 20, 2024 at 2:19 AM Amit Langote wrote:
>> On Mon, Jun 17, 2024 at 10:07 PM Markus Winand
>> wrote:
>> > > On 17.06.2024, at 08:20, Amit Langote wrote:
>> > > Agree that the documentation needs to be clear about this. I'll
On Thu, Jun 20, 2024 at 7:42 PM Melanie Plageman
wrote:
> If vacuum fails to remove a tuple with xmax older than
> VacuumCutoffs->OldestXmin and younger than
> GlobalVisState->maybe_needed, it will ERROR out when determining
> whether or not to freeze the tuple with "cannot freeze committed
>
On Thu, Jun 20, 2024 at 4:13 PM Heikki Linnakangas wrote:
> > By "negotiation" I mean the server's response to the startup packet.
> > I.e. "supported"/"not supported"/"error".
>
> Ok, I'm still a little confused, probably a terminology issue. The
> server doesn't respond with "supported" or "not
On 21/06/2024 02:12, Tom Lane wrote:
Heikki Linnakangas writes:
In commit af0e7deb4a, I removed the call to RelationCloseSmgr() from
RelationCacheInvalidate(). I thought it was no longer needed, because we
no longer free the underlying SmgrRelation.
However, it meant that if the relfilenode
On Thu, Jun 20, 2024 at 02:27:14PM +, Bertrand Drouvot wrote:
> On Thu, Jun 20, 2024 at 09:46:30AM +0900, Michael Paquier wrote:
> I think it makes sense to follow the same "behavior" as the custom
> wal resource managers. That, indeed, looks much more simpler than v1.
Thanks for the
On 20/06/2024 20:02, Jacob Champion wrote:
On Mon, Jun 17, 2024 at 9:23 AM Jacob Champion
wrote:
I think the behavior with v2 and v3 errors should be the same. And I
think an immediate failure is appropriate on any v2/v3 error during
negotiation, assuming we don't use those errors for things
Heikki Linnakangas writes:
> In commit af0e7deb4a, I removed the call to RelationCloseSmgr() from
> RelationCacheInvalidate(). I thought it was no longer needed, because we
> no longer free the underlying SmgrRelation.
> However, it meant that if the relfilenode of the relation was changed,
>
On Thu, Jun 20, 2024 at 01:05:42PM +, Bertrand Drouvot wrote:
> On Thu, Jun 13, 2024 at 04:59:50PM +0900, Michael Paquier wrote:
>> * Making custom stats data persistent is an interesting problem, and
>> there are a couple of approaches I've considered:
>> ** Allow custom kinds to define
On 19/06/2024 23:00, Alexander Lakhin wrote:
Please look at a new anomaly, that I've discovered in master.
...
triggers a segfault:
2024-06-19 19:22:49.009 UTC [1607210:6] LOG: server process (PID 1607671) was
terminated by signal 11: Segmentation fault
...
server.log might also contain:
Here's a fix adding the missing headers to pg_combinebackup, and fixing
some compile-time issues in the ifdef-ed block.
I've done some basic manual testing today - I plan to test this a bit
more tomorrow, and I'll also look at integrating this into the existing
tests.
regards
--
Tomas Vondra
Hi,
On 2024-06-19 14:47:50 +0100, Dave Page wrote:
> > I'm *NOT* sure that vcpkg is the way to go, fwiw. It does seem
> > advantageous to
> > use one of the toolkits thats commonly built for building dependencies on
> > windows, which seems to mean vcpkg or conan.
> >
>
> I don't think requiring
101 - 200 of 158748 matches
Mail list logo
