On Mon, Aug 26, 2024 at 6:41 PM Alena Rybakina
wrote:
>
> + /* Construct the list of nested OR arguments */
> + for (j = group_start; j < i; j++)
> + {
> + Node *arg = list_nth(orargs, matches[j].argindex);
> +
> + rargs = lappend(rargs, arg);
> + if (IsA(arg, RestrictInfo))
> + args = lappend(a
Here's a really simple way to see the new unfairness at the end of a
parallel scan:
drop table if exists t;
create table t (i int);
insert into t select generate_series(1, 10);
alter table t set (parallel_workers = 2);
set parallel_setup_cost = 0;
set parallel_leader_participation = off;
expla
Hi
út 27. 8. 2024 v 8:15 odesílatel Laurenz Albe
napsal:
> On Thu, 2024-08-15 at 07:55 +0200, Pavel Stehule wrote:
> > út 30. 7. 2024 v 21:46 odesílatel Laurenz Albe
> napsal:
> > > - A general reminder: single line comments should start with a lower
> case
> > > letter and have to period in
At 2024-08-27 00:32:53, "Robert Haas" wrote:
>I'm somewhat expecting to be flamed to a well-done crisp for saying
>this, but I think we need better ways for extensions to control the
>behavior of PostgreSQL's query planner. I know of two major reasons
>why somebody might want to
On Thu, 2024-08-15 at 07:55 +0200, Pavel Stehule wrote:
> út 30. 7. 2024 v 21:46 odesílatel Laurenz Albe
> napsal:
> > - A general reminder: single line comments should start with a lower case
> > letter and have to period in the end:
>
> Should it be "have not to period in the end" ?
I made
On Tue, Aug 27, 2024 at 12:58 AM John H wrote:
>
> For instance, in Shveta's suggestion of
>
> > > > We can perform this test with both of the below settings and say make
> > > > D and E slow in sending responses:
> > > > 1) synchronous_standby_names = 'ANY 3 (A,B,C,D,E)'
> > > > 2) standby_slot_n
On Mon, 2024-08-26 at 23:59 +0200, Matthias van de Meent wrote:
> Specifically, I'm having trouble seeing how this could be used to
> implement ```INSERT INTO ... SELECT ... RETURNING ctid``` as I see no
> returning output path for the newly inserted tuples' data, which is
> usually required for ou
Thans for your responses.
> I think you see such a behavior because you have disabled
> 'synchronized_standby_slots'
> in your script (# disable "synchronized_standby_slots"). You need to enable
> that to
> avoid data loss. Considering that, I don't think your proposed text is an
> improvement.
On Monday, August 26, 2024, Amit Kapila wrote:
> On Mon, Aug 26, 2024 at 6:38 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Monday, August 26, 2024 5:37 PM Amit Kapila
> wrote:
> > >
> > > On Mon, Aug 26, 2024 at 1:30 PM wrote:
> > > >
> > > > When I read the following documentation related to t
On Thu, Aug 22, 2024 at 9:02 PM Ranier Vilela wrote:
> Em qui., 22 de ago. de 2024 às 04:34, Richard Guo
> escreveu:
>> This does not seem right to me, as PathTargets are not canonical, so
>> we cannot guarantee that two identical PathTargets will have the same
>> pointer. Actually, for the que
On Sat, Aug 24, 2024 at 4:50 AM Jeff Davis wrote:
>
>
> I have attached version 28j as one giant patch covering what was
> previously 0001-0003. It's a bit rough (tests in particular need some
> work), but it implelements the logic to replace only those values
> specified rather than the whole tup
On Mon, Aug 26, 2024 at 8:58 PM Peter Eisentraut wrote:
> On 23.08.24 10:27, Richard Guo wrote:
> > Fair point. After looking at the code for a while, I believe it is
> > sufficient to compare PathTarget.exprs after we've checked that the
> > two targets have different pointers.
>
> -
On Mon, Aug 26, 2024 at 6:38 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Monday, August 26, 2024 5:37 PM Amit Kapila
> wrote:
> >
> > On Mon, Aug 26, 2024 at 1:30 PM wrote:
> > >
> > > When I read the following documentation related to the
> > "synchronized_standby_slots", I misunderstood that data l
On Mon, Aug 26, 2024 at 1:30 PM wrote:
>
> When I read the following documentation related to the
> "synchronized_standby_slots", I misunderstood that data loss would not occur
> in the case of synchronous physical replication. However, this is incorrect
> (see reproduce.txt).
>
I think you se
On Mon, Aug 26, 2024 at 10:13 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Monday, August 26, 2024 3:30 PM Peter Smith wrote:
> >
> > ==
> > src/include/replication/conflict.h
> >
> > nit - defined 'NUM_CONFLICT_TYPES' inside the enum (I think this way is
> > often used in other PG source enums)
>
>
On Sat, Aug 17, 2024 at 9:44 PM Thomas Munro wrote:
> On Sat, Aug 17, 2024 at 11:36 AM David Rowley wrote:
> > I don't really object, but I think a better aim would be to merge
> > CFbot with CF so that we could get to those places from the CF entry.
I've built a system for pushing all the data
On Tue, Aug 27, 2024 at 11:32 AM Thomas Munro wrote:
> SectorMemoryManager
Erm, "Section". (I was working on some file system stuff at the
weekend, and apparently my fingers now auto-complete "sector".)
Here is an experimental attempt to steal the SectorMemoryManager from
https://github.com/llvm/llvm-project/pull/71968, rename it to
SafeSectorMemoryManager, and inject it as shown in the previous patch.
Another approach might be to try to make a new class that derives from
SectorMemoryManager and a
On Mon, Aug 26, 2024 at 1:18 AM Peter Eisentraut wrote:
> Or, if people find that too scary, something like
>
> #ifdef JSONAPI_USE_PQEXPBUFFER
>
> #define jsonapi_StringInfo PQExpBuffer
> [...]
>
> That way, it's at least more easy to follow the source code because
> you see a mostly-familiar API.
On Mon, Aug 26, 2024 at 2:27 PM Nathan Bossart wrote:
>
> On Mon, Aug 26, 2024 at 11:25:53AM -0700, Masahiko Sawada wrote:
> > Thank you for reviewing the patch. Pushed.
>
> nitpick: I think this one needs a pgindent run.
Thank you for pointing it out. I forgot to check with pgindent. I've
pushed
On Mon, Aug 26, 2024 at 7:52 PM Amit Kapila wrote:
>
> On Thu, Aug 22, 2024 at 2:21 PM Amit Kapila wrote:
> >
> > On Thu, Aug 22, 2024 at 1:33 PM Peter Smith wrote:
> > >
> > > Do you think the documentation for the 'column_value' parameter of the
> > > conflict logging should say that the displ
On Mon, 26 Aug 2024 at 23:18, Jeff Davis wrote:
>
> On Mon, 2024-08-26 at 11:09 +0530, Bharath Rupireddy wrote:
> > On Wed, Jun 5, 2024 at 12:42 PM Bharath Rupireddy
> > wrote:
> > >
> > > Please find the v22 patches with the above changes.
> >
> > Please find the v23 patches after rebasing 0005
On Tue, 27 Aug 2024 at 02:07, David E. Wheeler wrote:
> On Aug 21, 2024, at 19:07, Craig Ringer wrote:
> But even if it’s just one or two, the only proper way an extension directory
> would work, IME, is to define a directory-based structure for extensions,
> where every file for an extension
On Mon, Aug 26, 2024 at 11:25:53AM -0700, Masahiko Sawada wrote:
> Thank you for reviewing the patch. Pushed.
nitpick: I think this one needs a pgindent run.
--
nathan
On Mon, 2024-08-26 at 11:09 +0530, Bharath Rupireddy wrote:
> On Wed, Jun 5, 2024 at 12:42 PM Bharath Rupireddy
> wrote:
> >
> > Please find the v22 patches with the above changes.
>
> Please find the v23 patches after rebasing 0005 and adapting 0004 for
> 9758174e2e.
Thank you.
0001 API desi
On Tue, Aug 27, 2024 at 2:16 AM Anthonin Bonnefoy
wrote:
> There's a possible alternative, but it's definitely in the same
> category as the hot-patching idea. llvmjit uses
> LLVMOrcCreateRTDyldObjectLinkingLayerWithSectionMemoryManager to
> create the ObjectLinkingLayer and it will be created wit
On 26/8/2024 21:44, Robert Haas wrote:
On Mon, Aug 26, 2024 at 2:00 PM Andrei Lepikhov wrote:
My personal most wanted list:
- Selectivity list estimation hook
- Groups number estimation hook
- hooks on memory estimations, involving work_mem
- add_path() hook
- Hook on final RelOptInfo pathlist
On 2024-08-22 Th 2:28 PM, Mark Dilger wrote:
On Aug 22, 2024, at 1:36 AM, Alexandra Wang
wrote:
I had to make some changes to the first two patches in order to run
"make check" and compile the treeb code on my machine. I’ve attached
my changes.
Thank you for the review, and the patches!
In general, +1 for $SUBJECT.
printf(_(" -k, --data-checksums use data page checksums\n"));
+printf(_(" --no-data-checksums do not use data page checksums\n"));
Should we error if both --data-checksum and --no-data-checksums are
specified? IIUC with 0001, we'll use whichever
On Mon, Aug 26, 2024 at 2:00 PM Andrei Lepikhov wrote:
> It is the change I have been waiting for a long time. Remember how many
> kludge codes in pg_hint_plan, aqo, citus, timescale, etc., are written
> for only the reason of a small number of hooks - I guess many other
> people could cheer such
On Mon, Aug 26, 2024 at 07:15:47PM +, Amonson, Paul D wrote:
>> +#define COMP_CRC32C_SMALL(crc, data, len) \
>> +((crc) = pg_comp_crc32c_sse42((crc), (data), (len)))
>>
>> My interpretation of Andres's upthread suggestion is that we'd add the length
>> check within the macro instead of int
Hi Bertrand,
On Sun, Jul 28, 2024 at 10:00 PM Bertrand Drouvot
wrote:
> Yeah, at the same place as the static lsn[] declaration, something like:
>
> static XLogRecPtr lsn[NUM_SYNC_REP_WAIT_MODE]; /* cached LSNs */
>
> but that may just be a matter of taste.
>
I've updated the patch to ref
On Mon, Aug 26, 2024 at 1:37 PM Tom Lane wrote:
> Robert Haas writes:
> > I'm somewhat expecting to be flamed to a well-done crisp for saying
> > this, but I think we need better ways for extensions to control the
> > behavior of PostgreSQL's query planner.
>
> Nah, I won't flame you for that, it
Hi Shveta, Amit,
> > > > ... We should try to
> > > > find out if there is a performance benefit with the use of
> > > > synchronous_standby_names in the normal configurations like the one
> > > > you used in the above tests to prove the value of this patch.
I don't expect there to be a performan
Hi Shveta,
On Sun, Jul 21, 2024 at 8:42 PM shveta malik wrote:
> > Ah that's a gap. Let me add some logging/warning in a similar fashion.
> > Although I think I'd have the warning be relatively generic (e.g.
> > changes are blocked because
> > they're not synchronously committed)
> >
>
> okay, s
> IMHO that would be useful to establish the current state of the patch set from
> a performance standpoint, especially since you've added code intended to
> mitigate the regression.
Ok.
> +#define COMP_CRC32C_SMALL(crc, data, len) \
> + ((crc) = pg_comp_crc32c_sse42((crc), (data), (len)))
>
On Mon, Aug 26, 2024 at 06:54:58PM +, Amonson, Paul D wrote:
>> And this still shows the ~14% regression in your original post?
>
> At the small buffer sizes the margin of error or "noise" is larger,
> 7-11%. My average could be just bad luck. It will take me a while to
> re-setup for full dat
> And this still shows the ~14% regression in your original post?
At the small buffer sizes the margin of error or "noise" is larger, 7-11%. My
average could be just bad luck. It will take me a while to re-setup for full
data collection runs but I can try it again if you like.
Paul
On Mon, Aug 26, 2024 at 06:44:55PM +, Amonson, Paul D wrote:
>> I'm curious about where exactly the regression is coming from. Is it
>> possible
>> that your build for the SSE 4.2 tests was using it unconditionally, i.e.,
>> optimizing away the function pointer?
>
> I am calling the SSE 4.2
> I'm curious about where exactly the regression is coming from. Is it possible
> that your build for the SSE 4.2 tests was using it unconditionally, i.e.,
> optimizing away the function pointer?
I am calling the SSE 4.2 implementation directly; I am not even building the
pg_sse42_*_choose.c fil
On Mon, Aug 26, 2024 at 05:09:35PM +, Amonson, Paul D wrote:
> Ok I added a patch that exposed a new macro CRC32C_COMP_SMALL for
> targeted fixed size < 256 use cases in Postgres. As for mitigating the
> regression in general, I have not been able to work up a fallback (i.e.
> <256 bytes) that
On Sun, Aug 25, 2024 at 9:29 PM Amit Kapila wrote:
>
> On Fri, Aug 23, 2024 at 3:44 PM Masahiko Sawada wrote:
> >
> > On Tue, Aug 20, 2024 at 9:29 PM Amit Kapila wrote:
> > >
> >
> > I've updated the updated patch with regression tests.
> >
>
> LGTM.
Thank you for reviewing the patch. Pushed.
On Mon, Aug 26, 2024 at 01:35:52PM -0400, Robert Haas wrote:
> On Mon, Aug 26, 2024 at 1:26 PM Nathan Bossart
> wrote:
>> While it is apparently pretty uncommon to use pgstattuple on sequences,
>> this is arguably a bug that should be fixed and back-patched.
>
> I don't understand what would mak
> You state that the
> information pgstattuple provides isn't really useful for sequences, so
> that means there's no real reason to do (1)
That's correct, but we should consider that up until v11,
sequences were supported in pgstattuple. Their support
was removed unintentionally (I believe so). Th
On 26/8/2024 18:32, Robert Haas wrote:
I'm somewhat expecting to be flamed to a well-done crisp for saying
this, but I think we need better ways for extensions to control the
behavior of PostgreSQL's query planner. I know of two major reasons
It is the change I have been waiting for a long time.
On 26/08/2024 20:38, Peter Eisentraut wrote:
On 24.08.24 15:55, Heikki Linnakangas wrote:
Come to think of it, the pg_get_user_name() function is just a thin
wrapper around getpwuid_r(). It doesn't provide a lot of value.
Perhaps we should remove pg_get_user_name() and pg_get_user_home_dir()
a
On Mon, Aug 26, 2024, at 1:34 PM, Ayush Vatsa wrote:
> I noticed that my last commit needs rebase through cfbot -
> http://cfbot.cputube.org/ayush-vatsa.html
> PFA the rebased patch for the same.
>
There is no list concept for OPTIONS. What happen if you use it in a non-list
value?
ALTER SERVER
On 24.08.24 15:55, Heikki Linnakangas wrote:
Come to think of it, the pg_get_user_name() function is just a thin
wrapper around getpwuid_r(). It doesn't provide a lot of value. Perhaps
we should remove pg_get_user_name() and pg_get_user_home_dir()
altogether and call getpwuid_r() directly.
Ye
Robert Haas writes:
> I'm somewhat expecting to be flamed to a well-done crisp for saying
> this, but I think we need better ways for extensions to control the
> behavior of PostgreSQL's query planner.
Nah, I won't flame you for that, it's a reasonable thing to think
about. However, the devil is
On Mon, Aug 26, 2024 at 1:26 PM Nathan Bossart wrote:
> While it is apparently pretty uncommon to use pgstattuple on sequences,
> this is arguably a bug that should be fixed and back-patched.
I don't understand what would make it a bug.
> IMHO it would be good to establish some level of consiste
On Mon, Aug 26, 2024 at 12:34 PM Ayush Vatsa wrote:
> I noticed that my last commit needs rebase through cfbot -
> http://cfbot.cputube.org/ayush-vatsa.html
> PFA the rebased patch for the same.
Hi Ayush,
Thanks for working on this. One problem that I notice is that your
documentation changes s
On Mon, Aug 26, 2024 at 09:14:27PM +0530, Ayush Vatsa wrote:
> Given the situation, I see two potential paths forward:
> *1/ Reintroduce Support for Sequences in pgstattuple*: This would be a
> relatively small change. However, it's important to note that the purpose
> of pgstattuple is to provide
> Upthread [0], Andres suggested dispatching to a different implementation for
> compile-time-known small lengths. Have you looked into that? In your
> original post, you noted a 14% regression for records smaller than 256 bytes,
> which is not an uncommon case for Postgres. IMO we should try to
On Mon, Aug 26, 2024 at 11:44 AM Ayush Vatsa wrote:
> Hi PostgreSQL Community,
> I have encountered an issue when attempting to use pgstattuple extension with
> sequences. When executing the following command:
>
> SELECT * FROM pgstattuple('serial');
> ERROR: only heap AM is supported
>
> This b
Hello PostgreSQL Community,
I noticed that my last commit needs rebase through cfbot -
http://cfbot.cputube.org/ayush-vatsa.html
PFA the rebased patch for the same.
Regards
Ayush Vatsa
AWS
v3-0002-fix-alter_server-alter_foreign_data_wrapper-alter.patch
Description: Binary data
v3-0001-Enhance-
I'm somewhat expecting to be flamed to a well-done crisp for saying
this, but I think we need better ways for extensions to control the
behavior of PostgreSQL's query planner. I know of two major reasons
why somebody might want to do this. First, you might want to do
something like what pg_hint_pla
Hi,
I'm getting back to work on the index prefetching patch [1], but one
annoying aspect of that patch is that it's limited to the context of a
single executor node. It can be very effective when there's an index
scan with many matches for a key, but it's entirely useless for plans
with many tiny
Hi PostgreSQL Community,
I have encountered an issue when attempting to use pgstattuple extension
with sequences. When executing the following command:
SELECT * FROM pgstattuple('serial');
ERROR: only heap AM is supported
This behaviour is observed in PostgreSQL versions post v11 [1] , where
seq
On Sun, Aug 25, 2024 at 01:14:36PM -0400, Greg Sabino Mullane wrote:
> I'm not happy about making this and the const char[] change their structure
> based on the ifdefs - could we not just leave forkchild in? Their usage is
> already protected by the ifdefs in the calling code.
Here's an attempt a
> On Aug 26, 2024, at 5:21 AM, Peter Eisentraut wrote:
>
> On 21.08.24 21:25, Mark Dilger wrote:
>> The next twenty patches are a mix of fixes of various layering
>> violations, such as not allowing non-core index AMs from use in replica
>> identity full, or for speculative insertion, or for f
po 26. 8. 2024 v 16:30 odesílatel Jim Jones
napsal:
>
>
> On 26.08.24 14:15, Pavel Stehule wrote:
> > I am not strongly against enhancing XMLSERIALIZE, but it can be nice
> > to see some wider concept first. Currently the state looks just random
> > - and I didn't see any serious discussion about
On Mon, Aug 26, 2024 at 10:00 AM Alexander Lakhin wrote:
> I'm sorry to bother you again, but I've come across another assertion
> failure.
You've found a real bug. I should be the one apologizing - not you.
> Please try the following query (I use a clean "postgres" database,
> just after initdb
Robert Haas writes:
> On Wed, Jun 19, 2024 at 2:21 PM Melanie Plageman
> wrote:
>> If we want to make it possible to use no tools and only manually grep
>> for struct members, that means we can never reuse struct member names.
>> Across a project of our size, that seems like a very serious
>> res
On 26.08.24 14:15, Pavel Stehule wrote:
> I am not strongly against enhancing XMLSERIALIZE, but it can be nice
> to see some wider concept first. Currently the state looks just random
> - and I didn't see any serious discussion about implementation fo
> SQL/XML. We don't need to be necessarily c
On Wed, Jun 19, 2024 at 2:21 PM Melanie Plageman
wrote:
> If we want to make it possible to use no tools and only manually grep
> for struct members, that means we can never reuse struct member names.
> Across a project of our size, that seems like a very serious
> restriction. Adding prefixes in
On Mon, Aug 26, 2024 at 11:11:55AM +0900, Michael Paquier wrote:
> It seems to me that we'd live better without it, at least it matters
> for the sequence AM patch, because some of its callbacks are also
> shaped around the fact that WAL may not be required for sequence value
> computations. Provi
On Mon, Aug 26, 2024 at 4:33 AM Thomas Munro wrote:
> IIUC this one is a random and rare crash depending on malloc() and
> perhaps also the working size of your virtual memory dart board.
> (Annoyingly, I had tried to reproduce this quite a few times on small ARM
> systems when earlier reports cam
Hi Hackers,
Apologies for the delay in reply; I’ve been at the XOXO Festival and almost
completely unplugged for the first time in ages. Happy to see this thread
coming alive, though. Thank you Gabriele, Craig, and Jelte!
On Aug 21, 2024, at 19:07, Craig Ringer wrote:
> So IMO this should be
Hello Peter,
22.04.2024 20:59, Peter Geoghegan wrote:
Pushed a fix like that just now.
I'm sorry to bother you again, but I've come across another assertion
failure. Please try the following query (I use a clean "postgres" database,
just after initdb):
EXPLAIN SELECT conname
FROM pg_constr
On 19/06/2024 18:55, Melanie Plageman wrote:
On Tue, Jun 18, 2024 at 6:02 PM Tomas Vondra
wrote:
I went through v22 to remind myself of what the patches do and do some
basic review - I have some simple questions / comments for now, nothing
major. I've kept the comments in separate 'review' pat
On Thu, Aug 22, 2024 at 5:56 PM Bertrand Drouvot
wrote:
>
> Please find attached a patch to $SUBJECT.
>
> This module provides SQL functions to inspect the contents of serialized
> logical
> snapshots of a running database cluster, which I think could be useful for
> debugging or educational purp
On 8/26/24 03:58, Daniel Gustafsson wrote:
On 26 Aug 2024, at 05:21, 王春桂 wrote:
hello,all, I am a newcomer who recently joined the PostgreSQL
community. I logged into the community using my GitHub account and
wanted to start familiarizing myself with community work by
reviewing patches. However
On Monday, August 26, 2024 5:37 PM Amit Kapila wrote:
>
> On Mon, Aug 26, 2024 at 1:30 PM wrote:
> >
> > When I read the following documentation related to the
> "synchronized_standby_slots", I misunderstood that data loss would not occur
> in the case of synchronous physical replication. Howeve
You must use a where clause on the FDW table or you get a full load/SEQ scan of
that table, per documentation.
Select * is not recommended for FDW tables.
From: Tobias Hoffmann
Date: Sunday, August 25, 2024 at 8:10 AM
To: "pgsql-hack...@postgresql.org"
Subject: Non-trivial condition is only pr
On 23.08.24 10:27, Richard Guo wrote:
On Fri, Aug 23, 2024 at 11:56 AM Tom Lane wrote:
Richard Guo writes:
I agree that it’s always desirable to postpone work from path-creation
time to plan-creation time. In this case, however, it’s a little
different. The projection step could actually be
On Fri, Aug 23, 2024 at 3:40 PM Jacob Champion
wrote:
> Agreed on the name. I've attached a reconfigured version of v15-0003,
> with an extension that should hopefully not throw off the cfbot, and a
> commit message that should hopefully not misrepresent the discussion
> so far?
LGTM. Objections?
On 21.08.24 21:25, Mark Dilger wrote:
The next twenty patches are a mix of fixes of various layering
violations, such as not allowing non-core index AMs from use in replica
identity full, or for speculative insertion, or for foreign key
constraints, or as part of merge join; with updates to the "
po 26. 8. 2024 v 13:28 odesílatel Jim Jones
napsal:
>
>
> On 26.08.24 12:30, Pavel Stehule wrote:
> > I think so there should be specified the target of CANONICAL - it is a
> > partial replacement of NO INDENT or it produces format just for
> > comparing? The CANONICAL format is not probably ext
On Monday, August 26, 2024 6:36 PM shveta malik wrote:
>
> On Mon, Aug 26, 2024 at 3:22 PM Amit Kapila
> wrote:
> >
> > On Thu, Aug 22, 2024 at 2:21 PM Amit Kapila
> wrote:
> > >
> > > On Thu, Aug 22, 2024 at 1:33 PM Peter Smith
> wrote:
> > > >
> > > > Do you think the documentation for the '
On Monday, August 26, 2024 3:30 PM Peter Smith wrote:
>
> ==
> src/include/replication/conflict.h
>
> nit - defined 'NUM_CONFLICT_TYPES' inside the enum (I think this way is
> often used in other PG source enums)
I think we have recently tended to avoid doing that, as it has been commented
Just in case, I have attached a diff file to show the changes for the
latest version attached here [0] to make the review process easier.
[0]
https://www.postgresql.org/message-id/c4e4e305-7119-4183-b49a-d7092f4efba3%40postgrespro.ru
--
Regards,
Alena Rybakina
Postgres Professional: http://ww
Hi,
> On 19.08.24 16:10, Aleksander Alekseev wrote:
> > To clarify, supporting bytea<->integer (and/or bytea<->numeric) casts
> > doesn't strike me as a terrible idea but it doesn't address the issue
> > I'm proposing to solve.
>
> What is the issue you are proposing to solve?
>
> You linked to a
On 26.08.24 12:30, Pavel Stehule wrote:
> I think so there should be specified the target of CANONICAL - it is a
> partial replacement of NO INDENT or it produces format just for
> comparing? The CANONICAL format is not probably extra standardized,
> because libxml2 removes indenting, but examp
On Wed, 21 Aug 2024 at 10:07, jian he wrote:
>
> in Var comments:
>
> * varlevelsup is greater than zero in Vars that represent outer references.
> * Note that it affects the meaning of all of varno, varnullingrels, and
> * varnosyn, all of which refer to the range table of that query level.
>
Hi Robert,
On Tue, May 14, 2024 at 5:36 PM Robert Haas wrote:
>
> On Tue, May 14, 2024 at 6:13 AM Jakub Wartak
> wrote:
> > OK I'll try to explain using assembly, but I'm not an expert on this.
> > Let's go to the 1st post, assume we run with backtrace_function set:
>
> I feel like this explanat
On Mon, Aug 26, 2024 at 11:44 AM Bharath Rupireddy
wrote:
>
Few comments on 0001:
1.
@@ -651,6 +651,13 @@ synchronize_one_slot(RemoteSlot *remote_slot, Oid
remote_dbid)
" name slot \"%s\" already exists on the standby",
remote_slot->name));
+ /*
+ * Skip the sync if the local slot is a
Hi Shawn,
It will be good to document usage of this function. Please add
document changes in your patch. We need to document the impact of this
function so that users can judiciously decide whether or not to use
this function and under what conditions. Also they would know what to
expect when they
Dean Rasheed writes:
Hello Dean,
>> I did have some issue to run 'make html', but the
>> error exists before my patch, so I change the document carefully without
>> testing it. do you know how to fix the below error in 'make html'?
>>
>> $/usr/bin/xsltproc --nonet --path . --path . --stringpara
On Sat, 24 Aug 2024 at 19:17, Tom Lane wrote:
>
> About a dozen buildfarm members are complaining
>
Ah, OK. I've pushed a fix.
Regards,
Dean
Hi!
On 26.08.2024 06:12, jian he wrote:
On Fri, Aug 23, 2024 at 8:58 PM Alexander Korotkov wrote:
based on v37.
+ {
+ /*
+ * We have only Const's. In this case we can construct an array
+ * directly.
+ */
+ int16 typlen;
+ bool typbyval;
+ char typalign;
+ Datum *elems;
+ int i = 0;
+ Arra
On Mon, Aug 26, 2024 at 3:22 PM Amit Kapila wrote:
>
> On Thu, Aug 22, 2024 at 2:21 PM Amit Kapila wrote:
> >
> > On Thu, Aug 22, 2024 at 1:33 PM Peter Smith wrote:
> > >
> > > Do you think the documentation for the 'column_value' parameter of the
> > > conflict logging should say that the displ
po 26. 8. 2024 v 11:32 odesílatel Jim Jones
napsal:
> Hi Pavel
>
> On 25.08.24 20:57, Pavel Stehule wrote:
> >
> > There is unwanted white space in the patch
> >
> > -<-><--><-->xmlFreeDoc(doc);
> > +<->else if (format == XMLSERIALIZE_CANONICAL || format ==
> > XMLSERIALIZE_CANONICAL_WITH_NO_COMM
On 21/08/2024 15:51, Thomas Munro wrote:
On Sun, Apr 14, 2024 at 3:16 PM Thomas Munro wrote:
So I'll go ahead and add the storage class to the next version, and
contemplate a couple of different options for the tss stuff, including
perhaps leaving it out if that seems doable.
Here is a new at
On Thu, Aug 22, 2024 at 2:21 PM Amit Kapila wrote:
>
> On Thu, Aug 22, 2024 at 1:33 PM Peter Smith wrote:
> >
> > Do you think the documentation for the 'column_value' parameter of the
> > conflict logging should say that the displayed value might be
> > truncated?
> >
>
> I updated the patch to
On Mon, Aug 26, 2024 at 2:23 PM Amit Kapila wrote:
>
> On Thu, Aug 22, 2024 at 3:45 PM shveta malik wrote:
> >
> > On Wed, Aug 21, 2024 at 4:08 PM Nisha Moond
> > wrote:
> > >
> > > The patches have been rebased on the latest pgHead following the merge
> > > of the conflict detection patch [1].
On Mon, Aug 26, 2024 at 1:30 PM wrote:
>
> When I read the following documentation related to the
> "synchronized_standby_slots", I misunderstood that data loss would not occur
> in the case of synchronous physical replication. However, this is incorrect
> (see reproduce.txt).
>
> > Note that i
Hi Pavel
On 25.08.24 20:57, Pavel Stehule wrote:
>
> There is unwanted white space in the patch
>
> -<-><--><-->xmlFreeDoc(doc);
> +<->else if (format == XMLSERIALIZE_CANONICAL || format ==
> XMLSERIALIZE_CANONICAL_WITH_NO_COMMENTS)
> + <>{
> +<-><-->xmlChar *xmlbuf = NULL;
> +<-><-->int
On Mon, Aug 26, 2024 at 7:28 AM Peter Smith wrote:
>
> On Thu, Aug 22, 2024 at 8:15 PM shveta malik wrote:
> >
>
> Hi Shveta,
>
> I felt it would be better to keep the syntax similar to the existing
> INSERT ... ON CONFLICT [1].
>
> I'd suggest a syntax like this:
>
> ... ON CONFLICT ['conflict_t
Hi Peter,
I've applied and tested your patch, it works at least on MacOS with
meson build. A couple of thoughts about this patch inline below.
On Mon, Aug 26, 2024 at 8:23 AM Peter Eisentraut wrote:
> The purpose of this patch is to allow using pg_upgrade between clusters
> that have different c
> On 26 Aug 2024, at 10:45, chungui.wcg wrote:
> At 2024-08-26 15:58:00, "Daniel Gustafsson" wrote:
> >> On 26 Aug 2024, at 05:21, 王春桂 wrote:
> >>
> >> hello,all,
> >> I am a newcomer who recently joined the PostgreSQL community. I logged
> >> into the community using my GitHub account and wan
1 - 100 of 109 matches
Mail list logo
