On Sat, May 25, 2024 at 2:39 AM Tomas Vondra
wrote:
>
> 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
On Fri, May 24, 2024 at 09:05:35AM -0300, Ranier Vilela wrote:
> The function *get_attname* palloc the result name (pstrdup).
> Isn't it necessary to free the memory here (pfree)?
This is going to be freed with the current memory context, and all the
callers of getIdentitySequence() are in query
On Fri, 24 May 2024 at 08:34, Andrew Dunstan wrote:
> That's all pretty nice! I'd take the win on this rather than wait for
> some hypothetical patch that changes how output functions work.
On re-think of that, even if we changed the output functions to write
directly to a StringInfo, we
On 26.05.24 09:16, Junwang Zhao wrote:
This patch refactors the alignment checks for direct I/O to preprocess phase,
thereby reducing some CPU cycles.
This patch replaces for example
if (PG_O_DIRECT != 0 && PG_IO_ALIGN_SIZE <= BLCKSZ)
Assert((uintptr_t) buffer ==
> On 26 May 2024, at 23:25, Tom Lane wrote:
>
> Hannu Krosing writes:
>> Attached is a minimal patch to allow missing roles in REVOKE command
>
> FTR, I think this is a very bad idea.
Agreed, this is papering over a bug. If we are worried about pg_upgrade it
would be better to add a check to
Hannu Krosing writes:
> Attached is a minimal patch to allow missing roles in REVOKE command
FTR, I think this is a very bad idea.
It might be OK if we added some kind of IF EXISTS option,
but I'm not eager about that concept either.
The right thing here is to fix the backend so that pg_dump
Attached is a minimal patch to allow missing roles in REVOKE command
This should fix the pg_upgrade issue and also a case where somebody
has dropped a role you are trying to revoke privileges from :
smalltest=# create table revoketest();
CREATE TABLE
smalltest=# revoke select on revoketest from
On Sun, May 26, 2024, 12:26 Jelte Fennema-Nio wrote:
> DISCARD PLANS should probably forget about it though indeed.
>
DISCARD PLANS should probably **not** forget about it
> > Note that any change in behavior there would affect prepared
> > statements in general, not only plpgsql.
>
> DISCARD
ne 26. 5. 2024 v 21:27 odesílatel Jelte Fennema-Nio
napsal:
> On Sun, 26 May 2024 at 19:39, Tom Lane wrote:
> > Hm, should it be? That's hard-won knowledge, and I'm not sure there
> > is a good reason to believe it's no longer applicable.
>
> I think for DISCARD ALL it would probably make
On Sun, 26 May 2024 at 19:39, Tom Lane wrote:
> Hm, should it be? That's hard-won knowledge, and I'm not sure there
> is a good reason to believe it's no longer applicable.
I think for DISCARD ALL it would probably make sense to forget this
knowledge . Since that is advertised as "reset the
Jelte Fennema-Nio writes:
> I got a report on the PgBouncer repo[1] that running DISCARD ALL was
> not sufficient between connection handoffs to force replanning of
> stored procedures. Turns out that while DISCARD AL and DISCARD PLAN
> reset the plan cache they do not reset the num_custom_plans
I got a report on the PgBouncer repo[1] that running DISCARD ALL was
not sufficient between connection handoffs to force replanning of
stored procedures. Turns out that while DISCARD AL and DISCARD PLAN
reset the plan cache they do not reset the num_custom_plans fields of
the existing PlanSources.
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
This patch refactors the alignment checks for direct I/O to preprocess phase,
thereby reducing some CPU cycles.
--
Regards
Junwang Zhao
0001-Improve-conditional-compilation-for-direct-I-O-align.patch
Description: Binary data
18 matches
Mail list logo
