On Sun, May 26, 2024 at 10:10:00AM +0200, Álvaro Herrera wrote:
> On 2024-May-25, Bruce Momjian wrote:
>
> > On Thu, May 23, 2024 at 01:22:51PM +0200, Álvaro Herrera wrote:
>
> > > Can we make them a single item? Maybe something like
> > >
> > > : Improve reset routines for shared statistics
On 2024-05-24 Fr 16:00, Noah Misch wrote:
On Thu, May 23, 2024 at 02:00:00PM +0300, Alexander Lakhin wrote:
I'd like to discuss ways to improve the buildfarm experience for anyone who
are interested in using information which buildfarm gives to us.
Unless I'm missing something, as of now
On Sun, May 26, 2024 at 12:08:46AM -0400, Tom Lane wrote:
> After a few minutes' thought, how about:
>
> Assert((uint64) blocknum + (uint64) nblocks <= (uint64) mdnblocks(reln,
> forknum));
LGTM. Yeah that should be OK this way.
--
Michael
signature.asc
Description: PGP signature
On Sun, May 26, 2024 at 3:16 PM Junwang Zhao wrote:
>
> This patch refactors the alignment checks for direct I/O to preprocess phase,
> thereby reducing some CPU cycles.
>
> --
> Regards
> Junwang Zhao
Patch v2 with some additional minor polishment of the comments in `mdwriteback`.
--
Regards
On 2024-May-25, Bruce Momjian wrote:
> On Thu, May 23, 2024 at 01:22:51PM +0200, Álvaro Herrera wrote:
> > Can we make them a single item? Maybe something like
> >
> > : Improve reset routines for shared statistics (Atsushi Torikoshi, Bharath
> > Rupireddy)
> > :
> > : Resetting all shared
I wrote:
> Hmm ... I agree that this is better normally. But there's an
> edge case where it would fail to notice a problem that the
> existing code does notice: if blocknum is close to UINT32_MAX
> and adding nblocks causes it to wrap around to a small value.
> Is there an inexpensive way to
On Thu, May 23, 2024 at 07:03:20PM +0300, Heikki Linnakangas wrote:
> > Can you provide some more details on the expectations here?
>
> Smallest possible patch that makes Postgres work on AIX again.
>
> Perhaps start with the patch you posted yesterday, but remove hunks from it
> one by one, to
Michael Paquier writes:
> On Sat, May 25, 2024 at 11:52:22PM +0800, Xing Guo wrote:
>> #ifdef CHECK_WRITE_VS_EXTEND
>> -Assert(blocknum < mdnblocks(reln, forknum));
>> +Assert(blocknum + nblocks <= mdnblocks(reln, forknum));
>> #endif
> Yes, it looks like you're right that this can be
On Sat, May 25, 2024 at 3:53 PM Alexander Korotkov wrote:
> On Fri, May 24, 2024 at 11:00 PM Alexander Lakhin wrote:
> >
> > 24.05.2024 22:29, Tom Lane wrote:
> > > The partition_split test has unstable results, as shown at [1].
> > > I suggest adding "ORDER BY conname" to the two queries shown
On Thu, May 23, 2024 at 08:19:15PM -0400, Peter Geoghegan wrote:
> On Wed, May 22, 2024 at 6:50 PM Bruce Momjian wrote:
> > Agreed, patch applied, thanks.
>
> The item for my commit 5bf748b8 currently reads:
>
> "Allow btree indexes to more efficiently find array matches"
>
> I think that this
On Sat, May 25, 2024 at 8:53 PM Justin Pryzby wrote:
> On Fri, May 03, 2024 at 04:32:25PM +0300, Alexander Korotkov wrote:
> > On Fri, May 3, 2024 at 4:23 PM Justin Pryzby wrote:
> > > Note that the error that led to "EXCLUDING IDENTITY" is being discused
> > > over here:
> > >
On Thu, May 23, 2024 at 04:54:28PM -0300, Marcos Pegoraro wrote:
> • Rename SLRU columns in system view pg_stat_slru (Alvaro Herrera)
>
> The column names accepted by pg_stat_slru_rest() are also changed.
>
> Is pg_stat_slru_rest() correct ?
Oops, typo, fixed, thanks.
--
Bruce
On Thu, May 23, 2024 at 01:22:51PM +0200, Álvaro Herrera wrote:
> Hello,
>
> Regarding this item
>
> : Allow the SLRU cache sizes to be configured (Andrey Borodin, Dilip Kumar)
> :
> : The new server variables are commit_timestamp_buffers,
> : multixact_member_buffers, multixact_offset_buffers,
On Fri, May 24, 2024 at 11:23:29AM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-05-22 18:33:03 -0400, Bruce Momjian wrote:
> > On Tue, May 21, 2024 at 09:40:28AM -0700, Andres Freund wrote:
> > > On 2024-05-18 11:13:54 -0400, Bruce Momjian wrote:
> > > I agree keeping things reasonably short is
On Fri, May 24, 2024 at 10:50:28AM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-05-23 23:27:04 -0400, Bruce Momjian wrote:
> > On Thu, May 23, 2024 at 11:11:10PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > I am not sure Bruce that you realize that your disregard for
> > >
On Sat, May 25, 2024 at 11:52:22PM +0800, Xing Guo wrote:
> In commit 4908c58[^1], a vectored variant of smgrwrite() is added and
> the assertion condition in mdwritev() no longer matches the comment.
> This patch helps fix it.
>
> /* This assert is too expensive to have on normally ... */
>
On Sat, May 25, 2024 at 4:48 PM Tom Lane wrote:
>
> Hannu Krosing writes:
> > Having an pg_init_privs entry referencing a non-existing user is
> > certainly of no practical use.
>
> Sure, that's not up for debate. What I think we're discussing
> right now is
>
> 1. What other cases are badly
On Fri, May 03, 2024 at 04:32:25PM +0300, Alexander Korotkov wrote:
> On Fri, May 3, 2024 at 4:23 PM Justin Pryzby wrote:
> > Note that the error that led to "EXCLUDING IDENTITY" is being discused
> > over here:
> >
Hannu Krosing writes:
> Having an pg_init_privs entry referencing a non-existing user is
> certainly of no practical use.
Sure, that's not up for debate. What I think we're discussing
right now is
1. What other cases are badly handled by the pg_init_privs
mechanisms.
2. How much of that is
On Fri, May 24, 2024 at 10:00 PM Tom Lane wrote:
>
> Robert Haas writes:
> > On Fri, May 24, 2024 at 2:57 PM Tom Lane wrote:
> >> Doesn't seem right to me. That will give pg_dump the wrong idea
> >> of what the initial privileges actually were, and I don't see how
> >> it can construct correct
On Fri, May 24, 2024 at 11:00 PM Alexander Lakhin wrote:
>
> 24.05.2024 22:29, Tom Lane wrote:
> > The partition_split test has unstable results, as shown at [1].
> > I suggest adding "ORDER BY conname" to the two queries shown
> > to fail there. Better look at other queries in the test for
> >
Hello Amit and Noah,
24.05.2024 14:15, Amit Kapila wrote:
I feel it is a good idea to do something about this. It makes sense to
start with something simple and see how it works. I think this can
also help us whether we need to chase a particular BF failure
immediately after committing.
On Tue, 18 Jul 2023 at 05:29, Thomas Munro wrote:
> It's possible that fcntl(F_FULLFSYNC) might fail with ENOSUPP or other
> errors in obscure cases (eg unusual file systems). In that case, you
> could manually lower fsync to just "on" and do your own research on
> whether power loss can toast
On Sat, 25 May 2024 at 06:40, Jelte Fennema-Nio wrote:
> On Thu, 23 May 2024 at 20:12, Tom Lane wrote:
> >
> > Jelte Fennema-Nio writes:
> > > On Fri, 17 May 2024 at 21:24, Robert Haas
> wrote:
> > >> Perhaps these are all minority positions, but I can't tell you what
> > >> everyone thinks,
so 25. 5. 2024 v 10:24 odesílatel napsal:
> Pavel Stehule:
> > Sure there is more possibilities, but I don't want to lost the
> > possibility to write code like
> >
> > CREATE TEMP VARIABLE _x;
> >
> > LET _x = 'hello';
> >
> > DO $$
> > BEGIN
> >RAISE NOTICE '%', _x;
> > END;
> > $$;
> >
>
(pressed send to early)
On Sat, 25 May 2024 at 12:39, Jelte Fennema-Nio wrote:
> But again if I'm alone in this, then I don't
... mind budging on this to move this decision along. Using _pq_.xxx
parameters for all protocol changes would totally be acceptable to me.
On Thu, 23 May 2024 at 20:12, Tom Lane wrote:
>
> Jelte Fennema-Nio writes:
> > On Fri, 17 May 2024 at 21:24, Robert Haas wrote:
> >> Perhaps these are all minority positions, but I can't tell you what
> >> everyone thinks, only what I think.
>
> > I'd love to hear some opinions from others on
any pooler support
(apart from syncing the feature value when re-assigning the
connectin): Automatic binary encoding for a list of types
All others need some support from poolers, at the very least they need
new message types to not error out. But in many cases more complex
stuff is needed.
Pavel Stehule:
Sure there is more possibilities, but I don't want to lost the
possibility to write code like
CREATE TEMP VARIABLE _x;
LET _x = 'hello';
DO $$
BEGIN
RAISE NOTICE '%', _x;
END;
$$;
So I am searching for a way to do it safely, but still intuitive and
user friendly.
Maybe
so 25. 5. 2024 v 3:29 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > we can introduce special safe mode started by
> > set enable_direct_variable_read to off;
> > and allowing access to variables only by usage dedicated function
> > (supported by parser) named like variable or
On Thu, Mar 14, 2024 at 01:12:05PM +1300, Thomas Munro wrote:
> Short sales pitch for these patches:
>
> * the default settings eat data on Macs and Windows
> * nobody understands what wal_sync_method=fsync_writethrough means anyway
> * it's a weird kludge that it affects not only WAL, let's
Pavel Stehule writes:
> we can introduce special safe mode started by
> set enable_direct_variable_read to off;
> and allowing access to variables only by usage dedicated function
> (supported by parser) named like variable or pg_variable
Didn't we learn twenty years ago that GUCs that change
Hi
st 22. 5. 2024 v 19:25 odesílatel Tom Lane napsal:
> Peter Eisentraut writes:
> > On 18.05.24 13:29, Alvaro Herrera wrote:
> >> I want to note that when we discussed this patch series at the dev
> >> meeting in FOSDEM, a sort-of conclusion was reached that we didn't want
> >> schema
ign_hook.
3. Logic in all connection poolers to change GUC values to the
client's expected values whenever a server connection is handed off to
a client
4. Permission checking, if we want some protocol extensions to only be
configurable by a highly privileged user
All of those things would have to be
On Wed, Nov 29, 2023 at 1:17 AM Thomas Munro wrote:
> Done. I like it, I just feel a bit bad about moving the p*v()
> replacement functions around a couple of times already! I figured it
> might as well be static inline even if we use the fallback (= Solaris
> and Windows).
Just for the
Tomas Vondra writes:
> I personally don't think the FOSDEM triage is a very productive use of
> our time - we go through patches top to bottom, often with little idea
> what the current state of the patch is. We always ran out of time after
> looking at maybe 1/10 of the list.
> Having an
On 5/24/24 22:44, Tom Lane wrote:
> Joe Conway writes:
>> On 5/24/24 15:45, Tom Lane wrote:
>>> I was *not* proposing doing a regular review, unless of course
>>> somebody really wants to do that. What I am thinking about is
>>> suggesting how to make progress on patches that are stuck, or in
On 5/23/24 08:36, shveta malik wrote:
> Hello hackers,
>
> Please find the proposal for Conflict Detection and Resolution (CDR)
> for Logical replication.
> below details.>
>
> Introduction
>
> In case the node is subscribed to multiple providers, or when local
> writes happen
Joe Conway writes:
> On 5/24/24 15:45, Tom Lane wrote:
>> I was *not* proposing doing a regular review, unless of course
>> somebody really wants to do that. What I am thinking about is
>> suggesting how to make progress on patches that are stuck, or in some
>> cases delivering the bad news that
On 5/24/24 15:45, Tom Lane wrote:
I was *not* proposing doing a regular review, unless of course
somebody really wants to do that. What I am thinking about is
suggesting how to make progress on patches that are stuck, or in some
cases delivering the bad news that this patch seems unlikely to
On Thu, May 23, 2024 at 02:00:00PM +0300, Alexander Lakhin wrote:
> I'd like to discuss ways to improve the buildfarm experience for anyone who
> are interested in using information which buildfarm gives to us.
>
> Unless I'm missing something, as of now there are no means to determine
> whether
Robert Haas writes:
> On Fri, May 24, 2024 at 2:57 PM Tom Lane wrote:
>> Doesn't seem right to me. That will give pg_dump the wrong idea
>> of what the initial privileges actually were, and I don't see how
>> it can construct correct delta GRANT/REVOKE on the basis of false
>> information.
Hello,
24.05.2024 22:29, Tom Lane wrote:
The partition_split test has unstable results, as shown at [1].
I suggest adding "ORDER BY conname" to the two queries shown
to fail there. Better look at other queries in the test for
possible similar problems, too.
Yes, I've just reproduced it on an
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
This is an interesting feature on PostgreSQL server side where it can swap
On Fri, May 24, 2024 at 2:57 PM Tom Lane wrote:
> Doesn't seem right to me. That will give pg_dump the wrong idea
> of what the initial privileges actually were, and I don't see how
> it can construct correct delta GRANT/REVOKE on the basis of false
> information. During the dump reload, the
Tomas Vondra writes:
> On 5/24/24 19:09, Tom Lane wrote:
... Maybe we could divide and conquer: get a
dozen-or-so senior contributors to split up the list of pending
patches and then look at each one with an eye to what needs to
happen to move it along (*not* to commit it
The partition_split test has unstable results, as shown at [1].
I suggest adding "ORDER BY conname" to the two queries shown
to fail there. Better look at other queries in the test for
possible similar problems, too.
regards, tom lane
[1]
On 5/24/24 19:09, Tom Lane wrote:
> Tomas Vondra writes:
>> On 5/20/24 16:16, Robert Haas wrote:
>>> On Sun, May 19, 2024 at 3:18 PM Tom Lane wrote:
* Before starting this thread, Robert did a lot of very valuable
review of some individual patches. I think what prompted him to
On Fri, May 24, 2024 at 3:11 PM Phil Eaton wrote:
> > I think this should say something more like "Here is how an extension
> > SQL script might create a table access method handler".
>
> Fair point. It is referred to elsewhere [0] in docs as a "script
> file", so I've done that.
>
> > Shouldn't
Robert Haas writes:
> On Fri, May 24, 2024 at 11:59 AM Tom Lane wrote:
>> So this goal seems to
>> mean that neither ALTER OWNER nor REASSIGN OWNED should touch
>> pg_init_privs at all, as that would break its function of recording
>> a historical state. Only DROP OWNED should get rid of
On Fri, May 24, 2024 at 2:02 PM wrote:
> I am not sure, whether it's really a bug. I personally wouldn't be brave
> enough to back patch this. I don't want to deal with complaining end
> users. Suddenly their optimizer, which always had horrible estimates,
> was actually able to do harmful stuff
On Fri, May 24, 2024 at 1:50 PM Andres Freund wrote:
> Bruce, just about everyone seems to disagree with your current approach. And
> not just this year, this has been a discussion in most if not all release note
> threads of the last few years.
+1.
> People, including me, *have* addressed your
Hi,
On 2024-05-22 18:33:03 -0400, Bruce Momjian wrote:
> On Tue, May 21, 2024 at 09:40:28AM -0700, Andres Freund wrote:
> > On 2024-05-18 11:13:54 -0400, Bruce Momjian wrote:
> > I agree keeping things reasonably short is important. But I don't think
> > you're
> > evenly applying it as a goal.
On Fri, May 24, 2024 at 11:59 AM Tom Lane wrote:
> Thinking about this some more: the point of pg_init_privs is to record
> an object's privileges as they stood at the end of CREATE EXTENSION
> (or extension update), with the goal that pg_dump should be able to
> compute the delta between that
> I think this should say something more like "Here is how an extension
> SQL script might create a table access method handler".
Fair point. It is referred to elsewhere [0] in docs as a "script
file", so I've done that.
> Shouldn't "mem_tableam_handler" be "my_tableam_handler"?
Sorry about
Hi Ashutosh,
thanks for bringing this to my attention. I'll first share a few
thoughts about the change and respond regarding the test below.
I clearly understand your intention with this patch. It's an issue I run
into from time to time.
I did some testing with some benchmark sets back
Hi,
On 2024-05-23 23:27:04 -0400, Bruce Momjian wrote:
> On Thu, May 23, 2024 at 11:11:10PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > I am not sure Bruce that you realize that your disregard for
> > performance improvements is shared by nobody. Arguably,
> > performance is 90% of
Hans Buschmann writes:
> When I tried to connect to the restored database with psql \c I got:
> ...
> postgres=# \c cpsdb
> pgbeta/bin/psql: symbol lookup error: pgbeta/bin/psql: undefined symbol:
> PQsocketPoll
> (To my understanding) the problem comes from incompatible libpq.so libraries
>
Hi,
On 2024-05-24 16:17:37 +0200, Peter Eisentraut wrote:
> I'm not sure what the backpatching expectations of this kind of thing is.
> The history of this CI setup is relatively short, so this hasn't been
> stressed too much. I see that we once backpatched the macOS update, but
> that might
On Fri, May 24, 2024 at 11:48 AM Justin Pryzby wrote:
> You give me too much credit..
Gee, usually I'm very good at avoiding that mistake. :-)
> We don't want to change the behavior to allow this to succeed -- it
> would allow leaving the server in a state that it fails to start (rather
> than
Tomas Vondra writes:
> On 5/20/24 16:16, Robert Haas wrote:
>> On Sun, May 19, 2024 at 3:18 PM Tom Lane wrote:
>>> * Before starting this thread, Robert did a lot of very valuable
>>> review of some individual patches. I think what prompted him to
>>> start the thread was the realization that
Daniel Gustafsson writes:
> On 24 May 2024, at 16:20, Tom Lane wrote:
>> Another point: shdepReassignOwned explicitly does not touch grants
>> or default ACLs. It feels like the same should be true of
>> pg_init_privs entries,
> Agreed, I can't see why pg_init_privs should be treated
On Fri, May 24, 2024 at 09:26:54AM -0400, Robert Haas wrote:
> On Thu, Jul 6, 2023 at 4:15 PM Justin Pryzby wrote:
> But then I realized, reading another email, that Justin already knew
> that the behavior would change, or at least I'm 90% certain that he
> knows that.
You give me too much
On Tue, Apr 30, 2024 at 2:29 PM Jacob Champion
wrote:
> Attached is a draft patch to illustrate what I mean, but it's
> incomplete: it only solves the problem for scalar values.
(Attached is a v2 of that patch; in solving a frontend leak I should
probably not introduce a backend segfault.)
On 5/20/24 16:16, Robert Haas wrote:
> On Sun, May 19, 2024 at 3:18 PM Tom Lane wrote:
>
>...
>
>> * Another reason for things sitting a long time is that they're too
>> big to review without an unreasonable amount of effort. We should
>> encourage authors to break large patches into smaller
Peter, thank you for the feedback. Attached is a new patch with "address"
rather than "interface", plus a new default of "local" if there is no
address. I also removed the questionable comment, and updated the
commitfest title.
Cheers,
Greg
From bfa69fc2fffcb29dee0c6acfa4fc3749f987b272 Mon Sep 17
> On 24 May 2024, at 16:20, Tom Lane wrote:
> I've tentatively concluded that I shouldn't have modeled
> SHARED_DEPENDENCY_INITACL so closely on SHARED_DEPENDENCY_ACL,
> in particular the decision that we don't need such an entry if
> there's also SHARED_DEPENDENCY_OWNER.
+1, in light of this
Peter Eisentraut writes:
> Ok, I have an improved plan. I'm wrapping all the code related to this
> in #ifdef DEBUG_NODE_TESTS_ENABLED. This in turn is defined in
> assert-enabled builds, or if you define it explicitly, or if you define
> one of the legacy individual symbols. That way you
Daniel Gustafsson writes:
> I had a look, but I didn't beat you to a fix since it's not immediately clear
> to me how this should work for REASSING OWNED (DROP OWNED seems a simpler
> case). Should REASSIGN OWNED alter the rows in pg_shdepend matching init
> privs
> from SHARED_DEPENDENCY_OWNER
On 13.05.24 12:57, Nazir Bilal Yavuz wrote:
Bookworm versions of the Debian CI images are available now [0]. The
patches to use these images are attached.
'v1-0001-Upgrade-Debian-CI-images-to-Bookworm_REL_16+.patch' patch can
be applied to both upstream and REL_16 and all of the tasks finish
Thanks for the reply,yeah i know about FreeWaitEventSet() but that is being
used in few places but not for handling backends.
i got it that FDs like FeBeWaitSet->epoll_fd will be free'd when connection is
terminated but as i mentioned wouldn't it be an issue if the connection is long
living
"Karki, Sanjay" writes:
> I need to grant select on privilege in pg_catalog to user so I can connect
> via Toad Data point ,
Why do you think you need to do that? Most catalogs have public
select privilege already, and for the ones that don't, there are
very good reasons why not. I don't know
On Thu, May 23, 2024 at 11:04 PM Bruce Momjian wrote:
> For a case where O(N^2) become O(N), we might not even know the
> performance change since it is a micro-optimization. That is why I
> suggested we call it "Internal Performance".
I don't get this at all. If we can't tell the difference
On 24/05/2024 15:17, Srinath Reddy Sadipiralla wrote:
Hi PostgreSQL Community,
when a backend process starts, pq_init is called where it opens a FD during
CreateWaitEventSet()
if (!AcquireExternalFD())
{
/* treat this as though epoll_create1 itself returned EMFILE */
elog(ERROR,
On Thu, May 23, 2024 at 4:00 PM Tom Lane wrote:
> I don't recall exactly what I thought earlier, but now I think we'd
> be better off with separate infrastructure. guc.c is unduly complex
> already. Perhaps there are bits of it that could be factored out
> and shared, but I bet not a lot.
OK.
On Thu, Jul 6, 2023 at 4:15 PM Justin Pryzby wrote:
> I'm still hoping.
Hi,
I got asked to take a look at this thread.
First, I want to explain why I think this thread hasn't gotten as much
feedback as Justin was hoping. It is always possible for any thread to
have that problem just because
>
>
>
>
>>
>> As far as I can see now, it's a major design flaw that could keep the
>> patch from being accepted. Fortunately there are few good proposals how
>> to address this, folks are genuinely trying to help. What do you think
>> about trying some of them out, as an alternative approach, to
On the basis of the parser infrastructure fixup, 0002 patch adds the
nullingrel bit that references the grouping RTE to the grouping
expressions.
However, it seems to me that we have to manually remove this nullingrel
bit from expressions in various cases where these expressions are
logically
Hi
pá 24. 5. 2024 v 13:32 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Wed, May 22, 2024 at 08:44:28PM +0200, Pavel Stehule wrote:
> > st 22. 5. 2024 v 19:25 odesílatel Tom Lane napsal:
> >
> > > Peter Eisentraut writes:
> > > > On 18.05.24 13:29, Alvaro Herrera wrote:
> > >
:
>
>
>
> 获取Outlook for Android
>
> From: Heikki Linnakangas
> Sent: Thursday, May 23, 2024 8:47:29 PM
> To: Wang Yao ; PostgreSQL Hackers
>
> Cc: inte...@outlook.com
> Subject: Re: 回复: An implementation of multi-key sort
>
&
Em sex., 24 de mai. de 2024 às 08:48, Ashutosh Bapat <
ashutosh.bapat@gmail.com> escreveu:
>
>
> On Fri, May 24, 2024 at 12:16 PM Michael Paquier
> wrote:
>
>> On Fri, May 24, 2024 at 11:58:51AM +0530, Ashutosh Bapat wrote:
>> > If we are looking for avoiding a segfault and get a message
On Fri, May 24, 2024 at 12:16 PM Michael Paquier
wrote:
> On Fri, May 24, 2024 at 11:58:51AM +0530, Ashutosh Bapat wrote:
> > If we are looking for avoiding a segfault and get a message which helps
> > debugging, using get_attname and get_attnum might be better options.
> > get_attname throws an
> On Wed, May 22, 2024 at 08:44:28PM +0200, Pavel Stehule wrote:
> st 22. 5. 2024 v 19:25 odesílatel Tom Lane napsal:
>
> > Peter Eisentraut writes:
> > > On 18.05.24 13:29, Alvaro Herrera wrote:
> > >> I want to note that when we discussed this patch series at the dev
> > >> meeting in FOSDEM,
> On 24 May 2024, at 01:01, Tom Lane wrote:
>
> Hannu Krosing writes:
>> While the 'DROP OWNED BY fails to clean out pg_init_privs grants'
>> issue is now fixed,we have a similar issue with REASSIGN OWNED BY that
>> is still there:
>
> Ugh, how embarrassing. I'll take a look tomorrow, if no
On Thu, May 23, 2024 at 4:30 PM Alexander Lakhin wrote:
>
> I'd like to discuss ways to improve the buildfarm experience for anyone who
> are interested in using information which buildfarm gives to us.
>
> Unless I'm missing something, as of now there are no means to determine
> whether some
On Thursday, May 23, 2024, Karki, Sanjay wrote:
>
> I need to grant select on privilege in pg_catalog to user so I can connect
> via Toad Data point ,
>
> Users can already select from the tables in pg_catalog, grant able
privileges not required or allowed. Of course, some specific data is
On 21.05.24 20:48, Andres Freund wrote:
Where I'd be more concerned about peformance is the added branch in
READ_LOCATION_FIELD. There are a lot of calls to that, addding runtime
branches to each, with external function calls inside, is somewhat likely to
be measurable.
Ok, I have an improved
On Wed, 22 May 2024 at 16:50, Amit Kapila wrote:
>
> On Mon, May 20, 2024 at 4:30 PM Shlok Kyal wrote:
> > >
> > > I was trying to test this utility when 'sync_replication_slots' is on
> > > and it gets in an ERROR loop [1] and never finishes. Please find the
> > > postgresql.auto used on the
Ilya Gladyshev писал(а) 2024-05-24 00:14:
Hi,
Hi.
I think it's well worth the effort to revive the patch, so I rebased it
on master, updated it and will return it back to the commitfest.
Alexander, Justin feel free to add yourselves as authors
On 29.01.2024 12:43, Alexander Pyhalov
On Fri, May 24, 2024 at 12:52 PM Ashutosh Sharma
wrote:
> Hi All,
>
> We all know that installing an extension typically requires superuser
> privileges, which means the database objects it creates are owned by the
> superuser.
>
> If the extension creates any SECURITY DEFINER functions, it can
Rebased.
Along with rebasing, I changed the interface of XLogFsyncFile() to
return a boolean instead of an error message.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From bed74e638643d7491bbd86fe640c33db1e16f0e5 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: Mon, 15
On Fri, May 24, 2024 at 11:58:51AM +0530, Ashutosh Bapat wrote:
> If we are looking for avoiding a segfault and get a message which helps
> debugging, using get_attname and get_attnum might be better options.
> get_attname throws an error. get_attnum doesn't throw an error and returns
>
On Thu, Nov 23, 2023 at 1:43 PM Alexander Korotkov
wrote:
> Hello PostgreSQL Hackers,
>
> I am pleased to submit a series of patches related to the Table Access
> Method (AM) interface, which I initially announced during my talk at
> PGCon 2023 [1]. These patches are primarily designed to
On Fri, May 24, 2024 at 11:03 AM Michael Paquier
wrote:
> On Thu, May 23, 2024 at 08:54:12AM -0300, Ranier Vilela wrote:
> > All calls to functions like SearchSysCacheAttName, in the whole codebase,
> > checks if returns are valid.
> > It must be for a very strong reason, such a style.
>
>
On Thu, May 23, 2024 at 08:54:12AM -0300, Ranier Vilela wrote:
> All calls to functions like SearchSysCacheAttName, in the whole codebase,
> checks if returns are valid.
> It must be for a very strong reason, such a style.
Usually good practice, as I've outlined once upthread, because we do
Ashutosh Bapat writes:
> OJ is an outer join, AFAIU. OJ's have their own relids. If you are
> wondering why not all joins - I think inner joins need not be tracked as
> separated relations in parse tree, but OJ's need to be.
An outer join is necessarily associated with explicit JOIN syntax
in
On Fri, May 24, 2024 at 9:09 AM jian he wrote:
> On Fri, May 24, 2024 at 11:14 AM Tom Lane wrote:
> >
> > jian he writes:
> > > imho, the above comment is not very helpful.
> > > we should say more about what kind of information relid says about a
> base rel?
> >
> > "Relid" is defined at the
med relation
-sub get_toast_for
-{
- my ($relname) = @_;
-
- return $node->safe_psql(
- 'postgres', qq(
- SELECT 'pg_toast.' || t.relname
- FROM pg_catalog.pg_class c, pg_catalog.pg_class t
- WHERE c.relname = '$relname'
- AND c.reltoastrelid = t.oid));
-}
-
# (Re)create and populate a test
On Fri, May 24, 2024 at 11:14 AM Tom Lane wrote:
>
> jian he writes:
> > imho, the above comment is not very helpful.
> > we should say more about what kind of information relid says about a base
> > rel?
>
> "Relid" is defined at the very top of the file:
>
> /*
> * Relids
> *
On Thu, May 23, 2024 at 11:11:10PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, May 23, 2024 at 02:27:07PM +1200, David Rowley wrote:
> >> I also don't agree these should be left to "Source code" section. I
> >> feel that section is best suited for extension authors who might care
>
1 - 100 of 157100 matches
Mail list logo
