On Sun, Aug 13, 2023 at 03:25:33PM +0900, Michael Paquier wrote:
> On Tue, Aug 01, 2023 at 10:46:58AM +0800, Julien Rouhaud wrote:
> >
> > Agreed, it should be as trivial to implement as for the 2pc commands :)
>
> Perhaps not as much, actually, because I was just reminded that
> DEALLOCATE is some
On Tue, Aug 01, 2023 at 10:46:58AM +0800, Julien Rouhaud wrote:
> On Tue, Aug 01, 2023 at 11:37:49AM +0900, Michael Paquier wrote:
>> On Tue, Aug 01, 2023 at 10:22:09AM +0800, Julien Rouhaud wrote:
>>> Looking at the rest of the ignored patterns, the only remaining one would be
>>> DEALLOCATE, whic
The attached 010_zero.pl, when run as part of the pg_waldump test suite, fails
at today's master (c36b636) and v15 (1bc19df). It passes at v14 (5a32af3).
Command "pg_waldump --start 0/0100 --end 0/01000100" fails as follows:
pg_waldump: error: WAL segment size must be a power of two between
On Sat, Aug 12, 2023 at 5:20 PM Tom Lane wrote:
> Hm. I was envisioning that we should expect committers to deal
> with this, not original patch submitters. So that's an argument
> against including it in the CI tests. But I'm in favor of anything
> we can do to make it more painless for commit
Peter Geoghegan writes:
> We seem to be seriously contemplating making every patch author do
> this every time they need to get the tests to pass (after adding or
> renaming a struct). Is that really an improvement over the old status
> quo?
Hm. I was envisioning that we should expect committers
On Sat, Aug 12, 2023 at 3:47 PM Tom Lane wrote:
> > It's a somewhat annoying task though, find all the typedefs, add them to the
> > right place in the file (we have an out of order entry right now). I think a
> > script that *adds* (but doesn't remove) local typedefs would make this less
> > pain
Andres Freund writes:
> On 2023-08-12 17:03:37 -0400, Andrew Dunstan wrote:
>> My recollection is that missing typedefs cause indentation that kinda sticks
>> out like a sore thumb.
Yeah, it's usually pretty obvious: "typedef *var" gets changed to
"typedef * var", and similar oddities.
> It's a
Hi,
On 2023-08-12 17:03:37 -0400, Andrew Dunstan wrote:
> On 2023-08-11 Fr 19:02, Tom Lane wrote:
> > Peter Geoghegan writes:
> > > My workflow up until now has avoiding making updates to typedefs.list
> > > in patches. I only update typedefs locally, for long enough to indent
> > > my code. The
On 2023-08-11 Fr 19:02, Tom Lane wrote:
Peter Geoghegan writes:
My workflow up until now has avoiding making updates to typedefs.list
in patches. I only update typedefs locally, for long enough to indent
my code. The final patch doesn't retain any typedefs.list changes.
Yeah, I've done the sa
Hi,
On 2023-08-12 15:50:24 +1200, Thomas Munro wrote:
> Thanks. I realised that it's easy enough to test that theory about
> cleanup locks by hacking ConditionalLockBufferForCleanup() to return
> false randomly. Then the test occasionally fails as described. Seems
> like we'll need to fix that
Hi,
On 2023-08-08 12:45:05 +0900, Masahiko Sawada wrote:
> > I think there could be a quite simple fix: Track by how much we've extended
> > the relation previously in the same bistate. If we already extended by many
> > blocks, it's very likey that we'll do so further.
> >
> > A simple prototype
Hi,
On 2023-08-10 17:48:10 +0900, Masahiko Sawada wrote:
> Good catch! I've confirmed that the issue has been fixed by your patch.
Indeed.
> However, I'm not sure the added regression tests are stable since
> autovacuum workers may scan the pg_database and increment the
> statistics after reset
Hi,
On 2023-08-11 19:35:22 -0700, Jeff Davis wrote:
> Controlling search_path is critical for the correctness and security of
> functions. Right now, the author of a function without a SET clause has
> little ability to control the function's behavior, because even basic
> operators like "+" invol
On Fri, Aug 11, 2023 at 12:48:17PM -0700, David Zhang wrote:
>
> Applied v3 patch to master and verified it with below commands,
Thanks for testing!
> [..]
>
> For below changes,
>
> else if (TailMatches("CREATE", "VIEW", MatchAny, "AS") ||
> - TailMatches("CREATE", "OR", "REPLA
On Sat, 2023-08-12 at 09:50 -0400, Joe Conway wrote:
> Hmm, I guess I was too hasty -- seems we have some magic related to
> this
> already.
I was worried after your first email. But yes, the magic is in
FuncnameGetCandidates(), which simply ignores functions in the temp
namespace.
It would be b
On Sat, 2023-08-12 at 09:15 -0400, Joe Conway wrote:
> It isn't clear to me what is the precise difference between DEFAULT
> and
> SESSION
The the current patch, SESSION always gets the search path from the
session, while DEFAULT is controlled by the GUC
safe_function_search_path. If the GUC is
On 2023-08-11 Fr 19:17, Tom Lane wrote:
Peter Geoghegan writes:
I'm starting to have doubts about this policy. There have now been
quite a few follow-up "fixes" to indentation issues that koel
complained about. None of these fixups have been included in
.git-blame-ignore-revs. If things contin
On Sat, Aug 12, 2023 at 11:50:36AM +0530, Amit Kapila wrote:
> > We will need that complexity somewhere,
> > so why not in pg_upgrade?
> >
>
> I don't think we need the complexity of version-specific checks if we
> do what we do in get_control_data(). Basically, invoke
> version-specific pg_repls
On Fri, Aug 11, 2023 at 2:29 PM Peter Smith wrote:
>
> While reviewing other threads I have been looking more closely at the
> the logicalrep_worker_launch() function. IMO the logic of that
> function seems not quite right.
>
> Here are a few things I felt are strange:
>
...
>
> 2. There is some c
On Fri, Aug 11, 2023 at 7:15 PM Melih Mutlu wrote:
>
> Peter Smith , 11 Ağu 2023 Cum, 01:26 tarihinde şunu
> yazdı:
>>
>> No, I meant what I wrote there. When I ran the tests the HEAD included
>> the v25-0001 refactoring patch, but v26 did not yet exist.
>>
>> For now, we are only performance tes
On 8/12/23 09:15, Joe Conway wrote:
On 8/11/23 22:35, Jeff Davis wrote:
2. We can more accurately serve the user's intent. For instance, the
safe search_path of "pg_catalog, pg_temp" is arcane and seems to be
there just because we don't have a way to specify that pg_temp be
excluded entirely. Bu
On 8/11/23 22:35, Jeff Davis wrote:
The attached patch implements a new SEARCH clause for CREATE FUNCTION.
The SEARCH clause controls the search_path used when executing
functions that were created without a SET clause.
Background:
Controlling search_path is critical for the correctness and sec
On Sat, Aug 12, 2023 at 01:20:03PM +0200, Dmitry Dolgov wrote:
> > On Sat, Aug 12, 2023 at 09:28:19AM +0800, Julien Rouhaud wrote:
> > On Fri, Aug 11, 2023 at 05:55:26PM +0200, Dmitry Dolgov wrote:
> > >
> > > Another confusing example was this one at the end of set_session_variable:
> > >
> > >
> On Sat, Aug 12, 2023 at 09:28:19AM +0800, Julien Rouhaud wrote:
> On Fri, Aug 11, 2023 at 05:55:26PM +0200, Dmitry Dolgov wrote:
> >
> > Another confusing example was this one at the end of set_session_variable:
> >
> > + /*
> > +* XXX While unlikely, an error here is possib
On Fri, Aug 11, 2023 at 4:39 PM Andres Freund wrote:
> Hi,
>
> On 2023-08-11 15:06:44 -0500, Marcelo Juchem wrote:
> > On Fri, Aug 11, 2023 at 2:53 PM Andres Freund
> wrote:
> >
> > > Hi,
> > >
> > > On 2023-08-11 13:43:17 -0500, Marcelo Juchem wrote:
> > > > I'm not sure I know a good way to cl
Hello hackers,
This issue was discussed some time ago as a possible security problem, but
it was concluded that it is not something extraordinary from the security
point of view and it may be a subject for a public discussion.
The issue is that during the backend initialization procedure, the fu
26 matches
Mail list logo
