Hi,
On Sat, Feb 17, 2024 at 10:10:18AM +0530, Amit Kapila wrote:
> On Fri, Feb 16, 2024 at 4:10 PM shveta malik wrote:
> >
> > On Thu, Feb 15, 2024 at 10:48 PM Bertrand Drouvot
> > wrote:
> >
> > > 5 ===
> > >
> > > + if (SlotSyncWorker->syncing)
> > > {
> > > -
On Mon, Feb 19, 2024 at 03:01:40PM +0900, Michael Paquier wrote:
> 0002 is a polished version of the TAP test that makes use of this
> facility, providing coverage for the bug fixed by 7863ee4def65
> (reverting this commit causes the test to fail), where a restart point
> runs across a promotion
Hi,
On Mon, Feb 19, 2024 at 03:14:07PM +0900, Michael Paquier wrote:
> On Thu, Feb 15, 2024 at 11:24:59AM +, Bertrand Drouvot wrote:
> > Thanks for looking at it!
> >
> > Agree, using an assertion instead in v3 attached.
>
> And you did not forget the PG_USED_FOR_ASSERTS_ONLY.
Thanks to
Hi,
On Thu, 18 Jan 2024 at 04:22, Michael Paquier wrote:
>
> On Wed, Jan 17, 2024 at 03:20:39PM +0300, Nazir Bilal Yavuz wrote:
> > I agree with your points. While the other I/O related work is
> > happening we can discuss what we should do in the variable op_byte
> > cases. Also, this is
On Sun, Feb 18, 2024 at 7:29 AM Tomas Vondra
wrote:
>
>
> Also, now that I looked at the v2 patch again, I see it only really
> tweaked the pg_proc.dat entry, but the code still does PG_GETARG_OID (so
> the "any" bit is not really correct).
>
PG_GETARG_OID part indeed is wrong. so I change to
Hi,
Currently ALTER SUBSCRIPTION ... SET PUBLICATION will break the
logical replication in certain cases. This can happen as the apply
worker will get restarted after SET PUBLICATION, the apply worker will
use the existing slot and replication origin corresponding to the
subscription. Now, it is
On Mon, Feb 19, 2024 at 12:14 PM Amit Kapila wrote:
>
> On Mon, Feb 19, 2024 at 11:42 AM Robert Haas wrote:
> >
> > On Mon, Feb 19, 2024 at 11:04 AM Kyotaro Horiguchi
> > wrote:
> > > Or I thought the values could be moved to DETAILS: line.
> >
> > Yeah, I think that's likely to be the right
On Mon, Feb 19, 2024 at 6:54 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Thanks for reviewing! PSA new version.
>
Pushed this after making minor changes in the comments.
--
With Regards,
Amit Kapila.
On Sun, Feb 18, 2024 at 02:28:06AM +0100, Tomas Vondra wrote:
> Thanks for the updated patch. I don't have a clear opinion on the
> feature and whether this is the way to implement it, but I have two
> simple questions.
Some users I know of would be really happy to be able to get this
information
On Mon, Feb 19, 2024 at 11:42 AM Robert Haas wrote:
>
> On Mon, Feb 19, 2024 at 11:04 AM Kyotaro Horiguchi
> wrote:
> > Or I thought the values could be moved to DETAILS: line.
>
> Yeah, I think that's likely to be the right approach here. The details
> aren't too clear to me.
>
> Does the
On Mon, Feb 19, 2024 at 4:22 AM Michael Paquier wrote:
> On Thu, Feb 15, 2024 at 05:41:46PM +0530, Robert Haas wrote:
> > On Thu, Feb 15, 2024 at 3:05 PM Amul Sul wrote:
> > > Kindly have a look at the attached version.
> >
> > IMHO, 0001 looks fine, except probably the comment could be phrased
On Thu, Feb 15, 2024 at 11:24:59AM +, Bertrand Drouvot wrote:
> Thanks for looking at it!
>
> Agree, using an assertion instead in v3 attached.
And you did not forget the PG_USED_FOR_ASSERTS_ONLY.
> > It seems important to document why we are saving this data here; while
> > we hold the
On Mon, Feb 19, 2024 at 11:04 AM Kyotaro Horiguchi
wrote:
> Or I thought the values could be moved to DETAILS: line.
Yeah, I think that's likely to be the right approach here. The details
aren't too clear to me.
Does the primary error message really need to say "could not sync
slot"? If it will
Hi all,
(Ashutosh in CC as he was involved in the discussion last time.)
I have proposed on the original thread related to injection points to
have more stuff to be able to wait at an arbtrary point and wake at
will the process waiting so as it is possible to control the order of
actions taken in
On Mon, Feb 19, 2024 at 2:05 AM Andres Freund wrote:
> We probably should address that independently of making shared_buffers
> PGC_SIGHUP. The queue gets absurdly large once s_b hits a few GB. It's not
> that much memory compared to the buffer blocks themselves, but a sync queue of
> many
On Mon, Feb 19, 2024 at 11:10 AM Amit Kapila wrote:
>
> On Thu, Feb 15, 2024 at 11:49 AM Kyotaro Horiguchi
> wrote:
> >
> > At Thu, 15 Feb 2024 09:22:23 +0530, shveta malik
> > wrote in
> > >
> > > +1 on changing the msg(s) suggested way. Please find the patch for the
> > > same. It also
At Mon, 19 Feb 2024 11:02:39 +0530, Bharath Rupireddy
wrote in
> > After all, the patch looks good to me.
>
> Thanks. It was committed -
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=73f0a1326608ac3a7d390706fdeec59fe4dc42c0.
Yeah. I realied that after I had already sent
On Thu, Feb 15, 2024 at 11:49 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 15 Feb 2024 09:22:23 +0530, shveta malik
> wrote in
> >
> > +1 on changing the msg(s) suggested way. Please find the patch for the
> > same. It also removes double quotes around the variable names
>
> Thanks for the
At Mon, 19 Feb 2024 10:31:33 +0530, Robert Haas wrote
in
> On Mon, Feb 19, 2024 at 10:10 AM Kyotaro Horiguchi
> wrote:
> > A recent commit (7a424ece48) added the following message:
> >
> > > could not sync slot information as remote slot precedes local slot:
> > > remote slot "%s": LSN
On Mon, Feb 19, 2024 at 8:26 AM Kyotaro Horiguchi
wrote:
>
> On
> the flip side, SimpleXLogPageRead always reads a whole page and
> returns XLOG_BLCKSZ. However, as you know, the returned buffer doesn't
> contain random garbage bytes.
Is this assumption true when wal_init_zero is off? I think
On Mon, Feb 19, 2024 at 10:31 AM Robert Haas wrote:
>
> On Mon, Feb 19, 2024 at 10:10 AM Kyotaro Horiguchi
> wrote:
> > A recent commit (7a424ece48) added the following message:
> >
> > > could not sync slot information as remote slot precedes local slot:
> > > remote slot "%s": LSN (%X/%X),
On 18/2/2024 23:18, Alexander Korotkov wrote:
On Sun, Feb 18, 2024 at 5:04 PM Alexander Korotkov wrote:
On Sun, Feb 18, 2024 at 3:00 PM Alexander Lakhin wrote:
09.01.2024 01:09, Alexander Korotkov wrote:
Fixed in 30b4955a46.
Please look at the following query which fails with an error
On Mon, Feb 19, 2024 at 10:10 AM Kyotaro Horiguchi
wrote:
> A recent commit (7a424ece48) added the following message:
>
> > could not sync slot information as remote slot precedes local slot:
> > remote slot "%s": LSN (%X/%X), catalog xmin (%u) local slot: LSN
> > (%X/%X), catalog xmin (%u)
>
>
A recent commit (7a424ece48) added the following message:
> could not sync slot information as remote slot precedes local slot:
> remote slot "%s": LSN (%X/%X), catalog xmin (%u) local slot: LSN
> (%X/%X), catalog xmin (%u)
Since it is a bit overloaded but doesn't have a separator between
On Monday, February 19, 2024 11:39 AM shveta malik
wrote:
>
> On Sun, Feb 18, 2024 at 7:40 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Friday, February 16, 2024 6:41 PM shveta malik
> wrote:
> > Thanks for the patch. Here are few comments:
>
> Thanks for the comments.
>
> >
> > 2.
> >
> >
On Mon, 19 Feb 2024 at 06:54, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Vignesh,
>
> Thanks for reviewing! PSA new version.
>
> >
> > Thanks for the updated patch, Few suggestions:
> > 1) This can be moved to keep it similar to other tests:
> > +# Setup a disabled subscription. The upcoming test
On Fri, Jan 19, 2024 at 4:10 PM Masahiko Sawada wrote:
>
> if (opts_out->json_mode && is_from)
> ereport(ERROR, ...);
>
> if (!opts_out->json_mode && opts_out->force_array)
> ereport(ERROR, ...);
>
> Also these checks can be moved close to other checks at the end of
> ProcessCopyOptions().
>
>
On Sun, Feb 18, 2024 at 7:40 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Friday, February 16, 2024 6:41 PM shveta malik
> wrote:
> Thanks for the patch. Here are few comments:
Thanks for the comments.
>
> 2.
>
> +static bool
> +validate_remote_info(WalReceiverConn *wrconn, int elevel)
> ...
> +
> +
On Sat, Feb 17, 2024 at 12:24:33PM -0800, Andres Freund wrote:
> I wonder if we should move the core part for converting to hex to numutils.c,
> we already have code the for the inverse. There does seem to be further
> optimization potential in the conversion, and that seems better done somewhere
On Thu, Feb 15, 2024 at 05:17:17PM +0700, Oleg Tselebrovskiy wrote:
> Thanks for review!
dt_common.c is quite amazing, the APIs that we have in it rely on
strcpy() but we have no idea of the length of the buffer string given
in input to store the result. This would require breaking the
existing
At Mon, 19 Feb 2024 11:56:22 +0900 (JST), Kyotaro Horiguchi
wrote in
> Yeah, perhaps I was overly concerned. The removed comment made me
> think that someone could add code relying on the incorrect assumption
> that the remaining bytes beyond the returned count are cleared out. On
> the flip
At Fri, 16 Feb 2024 19:50:00 +0530, Bharath Rupireddy
wrote in
> On Fri, Feb 16, 2024 at 7:10 AM Kyotaro Horiguchi
> wrote:
> > 1. It's useless to copy the whole page regardless of the 'count'. It's
> > enough to copy only up to the 'count'. The patch looks good in this
> > regard.
>
>
On Mon, 19 Feb 2024 at 00:56, Tomas Vondra
wrote:
> On 2/18/24 03:30, Li Japin wrote:
>>
>> I find it seems need to change MAX_SIMUL_LWLOCKS if we enlarge the
>> NUM_BUFFER_PARTITIONS,
>> I didn’t find any comments to describe the relation between
>> MAX_SIMUL_LWLOCKS and
>>
On Fri, Feb 16, 2024 at 12:41 PM John Naylor wrote:
>
> On Fri, Feb 16, 2024 at 10:05 AM Masahiko Sawada
> wrote:
> > > v61-0007: Runtime-embeddable tids -- Optional for v17, but should
> > > reduce memory regressions, so should be considered. Up to 3 tids can
> > > be stored in the last level
On 19/2/2024 06:05, Tomas Vondra wrote:
However, this is a somewhat extreme example - it's joining 5 tables,
each with 1000 partitions, using a partition-wise join. It reduces the
amount of memory, but the planning time is still quite high (and
essentially the same as without the patch). So it's
Dear Vignesh,
Thanks for reviewing! PSA new version.
>
> Thanks for the updated patch, Few suggestions:
> 1) This can be moved to keep it similar to other tests:
> +# Setup a disabled subscription. The upcoming test will check the
> +# pg_createsubscriber won't work, so it is sufficient.
>
Hi,
In <20240218200906.zvihkrs46yl2j...@awork3.anarazel.de>
"Re: Why is pq_begintypsend so slow?" on Sun, 18 Feb 2024 12:09:06 -0800,
Andres Freund wrote:
>> [1]
>>
On 2024-02-14 We 11:52, Peter Eisentraut wrote:
On 08.02.24 16:53, Tom Lane wrote:
Daniel Gustafsson writes:
On 8 Feb 2024, at 08:01, Peter Eisentraut
wrote:
I suppose we could start using it for completely new scripts.
+1, it would be nice to eventually be able to move to it everywhere
On Mon, Feb 19, 2024 at 4:44 AM Alvaro Herrera wrote:
> On 2024-Feb-18, Tom Lane wrote:
>
> > So I'd blame this on faulty handling of the zero-partitions case in
> > the RTEPermissionInfo refactoring. (I didn't bisect to prove that
> > a61b1f748 is exactly where it broke, but I do see that the
Hi,
After taking a look at the patch optimizing SpecialJoinInfo allocations,
I decided to take a quick look at this one too. I don't have any
specific comments on the code yet, but it seems quite a bit more complex
than the other patch ... it's introducing a HTAB into the optimizer,
surely that
On Thu, Feb 15, 2024 at 05:41:46PM +0530, Robert Haas wrote:
> On Thu, Feb 15, 2024 at 3:05 PM Amul Sul wrote:
> > Kindly have a look at the attached version.
>
> IMHO, 0001 looks fine, except probably the comment could be phrased a
> bit more nicely.
And the new option should be documented at
On Sun, Feb 18, 2024 at 12:09:06PM -0800, Andres Freund wrote:
> On 2024-02-18 17:38:09 +0900, Sutou Kouhei wrote:
>> @@ -1966,7 +1992,7 @@ CopyReadBinaryAttribute(CopyFromState cstate, FmgrInfo
>> *flinfo,
>> if (fld_size == -1)
>> {
>> *isnull = true;
>> -
On 2024-02-18 20:00 +0100, Pavel Stehule wrote:
> The overhead of parse_type_and_format can be related to higher planning
> time. PL/pgSQL can assign composite without usage FROM clause.
Thanks, didn't know that this makes a difference. In that case both
variants are on par.
BEGIN;
Hi,
On 2024-02-18 17:06:09 +0530, Robert Haas wrote:
> On Sat, Feb 17, 2024 at 12:38 AM Andres Freund wrote:
> > IMO the ability to *shrink* shared_buffers dynamically and cheaply is more
> > important than growing it in a way, except that they are related of
> > course. Idling hardware is
Hi,
On 2024-02-18 17:38:09 +0900, Sutou Kouhei wrote:
> In <20240218015955.rmw5mcmobt5hb...@awork3.anarazel.de>
> "Re: Why is pq_begintypsend so slow?" on Sat, 17 Feb 2024 17:59:55 -0800,
> Andres Freund wrote:
>
> > v3-0008-wip-make-in-out-send-recv-calls-in-copy.c-cheaper.patch
>
> It
On 2024-Feb-18, Tom Lane wrote:
> So I'd blame this on faulty handling of the zero-partitions case in
> the RTEPermissionInfo refactoring. (I didn't bisect to prove that
> a61b1f748 is exactly where it broke, but I do see that the query
> successfully does nothing in v15.)
You're right, this is
Alexander, thanks for pushing this! This is small but very awaited feature.
> On 16 Feb 2024, at 02:08, Andres Freund wrote:
>
> Isn't this test going to be very fragile on busy / slow machines? What if the
> pg_sleep() takes one second, because there were other tasks to schedule? I'd
> be
Alena Rybakina writes:
> After starting the server (initdb + pg_ctl start) I ran a regress test
> create_misc.sql ('\i src/test/regress/sql/create_misc.sql') and, after
> that,
> I ran the fdw test ('\i contrib/postgres_fdw/sql/postgres_fdw.sql') in
> the psql, and it failed in the core-dump
Hi
ne 18. 2. 2024 v 19:50 odesílatel Erik Wienhold napsal:
> On 2024-02-12 19:20 +0100, Tom Lane wrote:
> > I wrote:
> > > It strikes me that this is basically to_regtype() with the additional
> > > option to return the typmod. That leads to some questions:
> >
> > BTW, another way that this
On 2024-02-12 19:20 +0100, Tom Lane wrote:
> I wrote:
> > It strikes me that this is basically to_regtype() with the additional
> > option to return the typmod. That leads to some questions:
>
> BTW, another way that this problem could be approached is to use
> to_regtype() as-is, with a
Hi, hackers!
After starting the server (initdb + pg_ctl start) I ran a regress test
create_misc.sql ('\i src/test/regress/sql/create_misc.sql') and, after
that,
I ran the fdw test ('\i contrib/postgres_fdw/sql/postgres_fdw.sql') in
the psql, and it failed in the core-dump due to the worked
18.02.2024 19:18, Alexander Korotkov wrote:
Attached is a draft patch fixing this query. Could you, please, recheck?
Yes, this patch fixes the behavior for that query (I've also tried several
similar queries). Though I don't know the code well enough to judge the
code change.
Best regards,
Hi,
I took a quick look at this patch today. I certainly agree with the
intent to reduce the amount of memory during planning, assuming it's not
overly disruptive. And I think this patch is fairly localized and looks
sensible.
That being said I'm a big fan of using a local variable on stack and
On 2/18/24 03:30, Li Japin wrote:
>
>
>> On Feb 10, 2024, at 20:15, Tomas Vondra
>> wrote:
>>
>> On 2/8/24 14:27, wenhui qiu wrote:
>>> Hi Heikki Linnakangas
>>>I think the larger shared buffer higher the probability of multiple
>>> backend processes accessing the same bucket slot
On Sun, Feb 18, 2024 at 5:04 PM Alexander Korotkov wrote:
> On Sun, Feb 18, 2024 at 3:00 PM Alexander Lakhin wrote:
> > 09.01.2024 01:09, Alexander Korotkov wrote:
> >
> > Fixed in 30b4955a46.
> >
> >
> > Please look at the following query which fails with an error since
> > d3d55ce57:
> >
> >
On Sun, Feb 18, 2024 at 3:00 PM Alexander Lakhin wrote:
> 09.01.2024 01:09, Alexander Korotkov wrote:
>
> Fixed in 30b4955a46.
>
>
> Please look at the following query which fails with an error since
> d3d55ce57:
>
> create table t (i int primary key);
>
> select t3.i from t t1
> join t t2 on
On Friday, February 16, 2024 6:41 PM shveta malik
wrote:
>
> On Thu, Feb 15, 2024 at 10:48 PM Bertrand Drouvot
> wrote:
> >
> > Looking at v88_0001, random comments:
>
> Thanks for the feedback.
>
> >
> > 1 ===
> >
> > Commit message "Be enabling slot synchronization"
> >
> > Typo? s:Be/By
>
On Sun, 18 Feb 2024 at 02:03, Andres Freund wrote:
>
> Hi,
>
> On 2024-02-17 23:40:51 +0100, Matthias van de Meent wrote:
> > > 5. Re-map the shared_buffers when needed.
> > >
> > > Between transactions, a backend should not hold any buffer pins. When
> > > there are no pins, you can munmap() the
On 16/02/2024 10:37 pm, Thomas Munro wrote:
On Fri, Feb 16, 2024 at 5:29 PM Robert Haas wrote:
3. Reserve lots of address space and then only use some of it. I hear
rumors that some forks of PG have implemented something like this. The
idea is that you convince the OS to give you a whole
Hi Alexander,
09.01.2024 01:09, Alexander Korotkov wrote:
Fixed in 30b4955a46.
Please look at the following query which fails with an error since
d3d55ce57:
create table t (i int primary key);
select t3.i from t t1
join t t2 on t1.i = t2.i,
lateral (select t1.i limit 1) t3;
ERROR:
On Sat, Feb 17, 2024 at 1:54 AM Heikki Linnakangas wrote:
> A variant of this approach:
>
> 5. Re-map the shared_buffers when needed.
>
> Between transactions, a backend should not hold any buffer pins. When
> there are no pins, you can munmap() the shared_buffers and mmap() it at
> a different
On Sat, Feb 17, 2024 at 12:38 AM Andres Freund wrote:
> IMO the ability to *shrink* shared_buffers dynamically and cheaply is more
> important than growing it in a way, except that they are related of
> course. Idling hardware is expensive, thus overcommitting hardware is very
> attractive (I
On 17.02.2024 00:37, David G. Johnston wrote:
On Mon, Feb 12, 2024 at 2:29 PM Pavel Luzanov
wrote:
regress_du_role1 | no| Inherit | no| 2024-12-31
00:00:00+03(invalid) | 50 | Group role without password but with
valid until
regress_du_role2 | yes
David Rowley writes:
>>
>> The two if-clauses looks unnecessary, it should be handled by
>> pathkeys_count_contained_in already. The same issue exists in
>> pathkeys_useful_for_ordering as well. Attached patch fix it in master.
>
> I agree. I'd rather not have those redundant checks in
>
Hi,
In <20240218015955.rmw5mcmobt5hb...@awork3.anarazel.de>
"Re: Why is pq_begintypsend so slow?" on Sat, 17 Feb 2024 17:59:55 -0800,
Andres Freund wrote:
> v3-0008-wip-make-in-out-send-recv-calls-in-copy.c-cheaper.patch
It seems that this is an alternative approach of [1].
[1]
Hi Ashutosh,
> data_type is described on that page as "Data type of the new column,
> or new data type for an existing column." but CREATE TABLE
> documentation [2] redirects data_type to [3], which mentions serial.
> The impression created by the documentation is the second statement
> above
66 matches
Mail list logo
