Hello Tom,
17.11.2024 20:28, Tom Turelinckx wrote:
I have now done just that, but on a new HiFive Premier P550 board [2]. It is
running Ubuntu 24.04 LTS with a board-specific kernel, currently
6.6.21-9-premier (2024-11-09). The buildfarm client is executing within a
Debian Trixie container cr
On 02/12/2024 17:56, Tom Lane wrote:
Vik Fearing writes:
On 02/12/2024 03:15, Tom Lane wrote:
Also, if SQL intended to constrain the search path for unqualified
identifiers to be only the new schema, they'd hardly need a concept
of at all.
I looked up the original paper (MUN-051) that intr
On 12/2/24 08:41, Eric Hanson wrote:
Hi all,
I'd like to revisit a previously discussed feature [1] that PostgreSQL
could benefit from a "role sandbox", a feature that would build on SET
[LOCAL] ROLE, and prevent or restrict RESET ROLE.
Rationale: Connection pooling is widely used to optimi
On Fri, Nov 29, 2024 at 10:01:41AM +, Dean Rasheed wrote:
> On Thu, 21 Nov 2024 at 18:00, Nathan Bossart wrote:
>> The attached patch accomplishes this by establishing a global queue of
>> row-security "nest levels" that the aforementioned higher-level callers can
>> use.
>
> I'm not convince
On Thu, Nov 28, 2024 at 2:53 AM Anthonin Bonnefoy
wrote:
> On Thu, Nov 28, 2024 at 12:26 AM Michael Paquier wrote:
> > I don't mind being more careful here based on your concerns, so I'll
> > go remove that in the stable branches.
>
> Sorry about that. I didn't have a strong need for this to be
>
On Mon, Dec 2, 2024 at 12:11 PM Tom Lane wrote:
> > Freezing a page, and setting a page all-visible are orthogonal.
>
> Sorry, sloppy wording on my part.
Freezing doesn't affect the contents of the visibility map in any way
that seems relevant. The executor only cares about the all-visible bit
(a
> On Tue, Oct 08, 2024 at 09:24:15AM GMT, Alexander Pyhalov wrote:
>
> Attaching rebased patches.
Just to let you know, looks like CFBot tests are red again, but this
time there are some unexpected differences in some test query plan.
Hi all,
I'd like to revisit a previously discussed feature [1] that PostgreSQL
could benefit from a "role sandbox", a feature that would build on SET
[LOCAL] ROLE, and prevent or restrict RESET ROLE.
Rationale: Connection pooling is widely used to optimize database
performance by reducing use of
Hi folks,
Just wanted to mention, that looks like some CFBot test are failing,
something around level_tracking in pgss.
On 2024-Dec-02, Bertrand Drouvot wrote:
> Hi hackers,
>
> da952b415f unintentionally added back the "Lock" suffix into the LWLock wait
> event names:
>
> - "added back" because the "Lock" suffix was removed in 14a9101091
> - "unintentionally" because there is nothing in the thread [2] that expli
> On 2 Dec 2024, at 16:16, Kirill Reshke wrote:
>
> I feel like we are ready to mark this as RFC, WDYT?
+1
Best regards, Andrey Borodin.
Hi,
On Mon, 2 Dec 2024 at 16:30, Andrey M. Borodin wrote:
>
> > On 2 Dec 2024, at 16:16, Kirill Reshke wrote:
> >
> > I feel like we are ready to mark this as RFC, WDYT?
>
> +1
Done.
--
Regards,
Nazir Bilal Yavuz
Microsoft
On Mon, Dec 2, 2024 at 10:15 AM Matthias van de Meent
wrote:
> The running theory is that bitmap executor nodes incorrectly assume
> that the rows contained in the bitmap all are still present in the
> index, and thus assume they're allowed to only check the visibility
> map to see if the referenc
On 02/12/2024 03:15, Tom Lane wrote:
Michael Paquier writes:
If I'm parsing the spec right, the doc mentions in its 5)~6) of the
syntax rules in CREATE SCHEMA that non-schema-qualified objects should
use the new schema name defined in the CREATE SCHEMA query. So that
pretty much settles the
In my opinion, the patches are semantically correct. However, not all
dead code has been removed - I'm referring to pgstat_update_snapshot().
Also, the tests need to be fixed.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
Hi,
On 2024-12-02 11:31:48 -0500, Andres Freund wrote:
> I think it'd be good if we added a test that shows the failure mechanism so
> that we don't re-introduce this in the future. Evidently this failure isn't
> immediately obvious...
Attached is an isolationtest that reliably shows wrong query
On Mon, Dec 2, 2024 at 11:43 AM Tom Lane wrote:
> Whether that's true or not, it seems like it'd be worth bisecting
> to see if we can finger a commit where the behavior changed (and
> the same goes for the question of why-isnt-it-an-IOS-scan). However,
> the reproducer seems to have quite a low
Hi,
On 2024-12-02 12:02:39 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I think the problematic scenario involves tuples that *nobody* can see.
> > During
> > the bitmap index scan we don't know that though. Thus the tid gets inserted
> > into the bitmap. Then, before we visit the heap, a
On 02.12.24 11:50, Nazir Bilal Yavuz wrote:
I applied your patches and the cube example worked. But when I edited
'test_json_parser_perf.c' and 'test_json_parser_incremental.c', meson
did not rebuild. I used the 'meson test -C build --suite setup --suite
test_json_parser' command to test test_jso
On Tue, Dec 3, 2024 at 7:06 AM Tom Lane wrote:
> This is from hake[1], which is running OpenIndiana/illumos.
> That platform shows a couple of other strange warnings, so maybe
> re-eliminating these two is not worth worrying about, but
> nonetheless the casts to void * were doing something here.
On Wed, Nov 20, 2024 at 08:17:07PM -0500, Greg Sabino Mullane wrote:
> Sounds good to me. I think my hesitation was more that the hint was
> overpromising help, so big +1 to more detail and keeping it.
Committed. If anyone wants to try putting together a patch that expands
the "migrating to SCRAM
> On 2 Dec 2024, at 08:52, Tom Lane wrote:
> But isn't there a way to improve the macro so this'd lead to an error?
That sounds like a pretty decent improvement in general. I experimented with
quick hack using a typeof check on the passed symbol which catches symbolname
typos. It might be total
On Tue, Dec 3, 2024 at 7:00 AM Alexander Lakhin wrote:
> A build made with clang-19 without llvm passed `make check` successfully.
We heard in another thread[1] that we'd need to use the JITLink API
for RISCV, instead of the RuntimeDyld API we're using. I have a newer
patch to use JITLink on all
On Mon, Dec 2, 2024 at 11:52 AM Andres Freund wrote:
> I think the problematic scenario involves tuples that *nobody* can see. During
> the bitmap index scan we don't know that though.
Right, exactly.
FWIW, this same issue is why it is safe for nbtree to drop its pin
early during plain index sca
On 02.12.2024 11:27, Alexander Korotkov wrote:
Hi, Alena!
On Wed, Nov 13, 2024 at 6:21 PM Alena Rybakina
wrote:
Updated 0001-v13 attached, as well as the diff between v12 and v13.
Thank you)
And I agree with your changes. And included them in patches.
Thank you for the updated patchset. S
Hi Alexander,
On Mon, Dec 2, 2024, at 2:00 PM, Alexander Lakhin wrote:
> These crashes are hardly related to code changes, so maybe there are
> platform-specific issues still...
I naively assumed that because llvm and clang are available in Trixie on
riscv64 that I could simply install them and
On 26.08.24 08:09, Peter Eisentraut wrote:
This patch allows using text position search functions with
nondeterministic collations. These functions are
- position, strpos
- replace
- split_part
- string_to_array
- string_to_table
which all use common internal infrastructure.
Some explorator
On Sat, 30 Nov 2024 at 02:54, Victor Yegorov wrote:
> I've been testing this patch for the last week, I have M3 and i7 based MBP
> around.
Thanks for having a look at this and running the benchmarks.
> Construct
>sizeof(FormData_pg_attribute) * (src)->natts
> is used in 7 places (in various
On Friday, November 29, 2024 6:35 PM Kuroda, Hayato/黒田 隼人
wrote:
>
> Dear Hou,
>
> Thanks for updating the patch! Here are my comments mainly for 0001.
Thanks for the comments!
>
> 02. maybe_advance_nonremovable_xid
>
> ```
> +case RCI_REQUEST_PUBLISHER_STATUS:
> +reques
On Sat, 30 Nov 2024 at 00:38, tsinghualucky...@foxmail.com
wrote:
>
> Dear Dean Rasheed, I have reviewed the v4 patch and it is very thoughtful and
> reasonable, with a very clever attention to detail (plus I am very happy that
> we can get rid of the goto, which I was not a big fan of).
>
> Thi
On Fri, Nov 29, 2024 at 3:16 PM Peter Eisentraut wrote:
>
> On 14.11.24 10:46, Amit Kapila wrote:
> >> Moreover, we would have to implement some elaborate cross-checks if a
> >> table gets added to a publication. How would that work? "Can't add
> >> table x to publication because it contains a v
This patch changes PL/Python to use the Python "limited API". This API
has stronger ABI stability guarantees.[0] This means, you can build
PL/Python against any Python 3.x version and use any other Python 3.x
version at run time.
This is especially useful for binary packages where the operatin
On 01.10.24 22:15, Daniel Gustafsson wrote:
On 1 Oct 2024, at 16:53, Jelte Fennema-Nio wrote:
On Tue, 1 Oct 2024 at 15:52, Daniel Gustafsson wrote:
Apart from this, I don't changing the placeholders like to < foo >. In
some cases, this really decreases readability. Maybe we should look f
On Mon, Dec 2, 2024 at 12:49 PM Michael Paquier wrote:
>
> On Mon, Dec 02, 2024 at 11:47:09AM +0530, Amit Kapila wrote:
> > We already have PGOutputData->cachectx which could be used for it. I
> > think we should be able to reset such a context when we are
> > revalidating the publications. Even,
On 29.11.24 21:57, Kirill Gavrilov wrote:
> Same thing applies to log_parameter_max_length, for example.
>
> postgres=# set log_parameter_max_length = '1foo';
> ERROR: invalid value for parameter "log_parameter_max_length": "1foo"
> HINT: Valid units for this parameter are "B", "kB", "MB", "GB
On 02.12.24 08:52, Tom Lane wrote:
(Moreover, the current structure assumes that the C character literal
syntax used by the PROKIND_* and other symbols happens to be the same as
the SQL string literal syntax required in those queries, which is just
an accident.)
So? There isn't much about C syn
This patch series changes several parsers in the backend and contrib
modules to use bison pure parsers and flex reentrant scanners. This is
ultimately toward thread-safety, but I think it's also just nicer in
general, and it might also fix a few possible small memory leaks.
I organized this pa
I have noticed that under meson many tests don't have dependencies on
the build artifacts that they are testing. As an example among many, if
you make a source code change in contrib/cube/cube.c (see patch 0001 for
a demo) and then run
make -C contrib/cube check
the test run will reflect
Infamously, the tsearch locale support in
src/backend/tsearch/ts_locale.c still depends on libc environment
variable locale settings and is not caught up with pg_locale_t,
collations, ICU, and all that newer stuff. This is used in the tsearch
facilities themselves, but also in other modules su
On 26.11.2024 01:15, Ilia Evdokimov wrote:
On 22.11.2024 09:08, Alexander Korotkov wrote:
On Wed, Nov 20, 2024 at 12:07 AM Michael Paquier wrote:
On Tue, Nov 19, 2024 at 09:39:21AM -0500, Greg Sabino Mullane wrote:
Oh, and a +1 in general to the patch, OP, although it would also be nice to
On 25.11.24 02:24, Noah Misch wrote:
commit d31bbfb wrote:
--- a/src/backend/catalog/aclchk.c
+++ b/src/backend/catalog/aclchk.c
@@ -659,147 +659,77 @@ ExecGrantStmt_oids(InternalGrant *istmt)
* objectNamesToOids
*
* Turn a list of object names of a given type into an Oid list.
- *
- *
On 02/12/2024 09:32, Thomas Munro wrote:
On Sat, Nov 23, 2024 at 10:58 AM Heikki Linnakangas wrote:
Hmm, so this would replace the maybeSleepingOnInterrupts bitmask I
envisioned. Makes a lot of sense. If it's a single bit though, that
means that you'll still get woken up by interrupts that you'
Hi,
On Mon, 2 Dec 2024 at 13:11, Peter Eisentraut wrote:
>
> I have noticed that under meson many tests don't have dependencies on
> the build artifacts that they are testing. As an example among many, if
> you make a source code change in contrib/cube/cube.c (see patch 0001 for
> a demo) and th
> v4 patch attached
Thank you Guillaume, and nice work! I tried to see if there was anywhere
else in the documentation that would need updating, but it looks like you
covered everywhere already.
> I'm with Robert in that I've not found the buffer counts to be all that
useful most of the time.
I
пн, 2 дек. 2024 г. в 13:24, David Rowley :
> I ended up adjusting the code here so that TupleDescSize() returns the
> full size and TupleDescAttrAddress() manually calculates the offset to
> start the FormData_pg_attribute array. That allows
> TupleDescFullSize() to be deleted. I changed how Tup
Hi,
As many of you are probably aware, I have been doing an annual blog
post on who contributes to PostgreSQL development for some years now.
It includes information on lines of code committed to PostgreSQL, and
also emails sent to the list. This year, I got a jump on analyzing the
commit log, and
Peter Eisentraut writes:
> Committed, thanks.
Now that we have a more-or-less full set of buildfarm results
on this, I checked for new warnings, and found two:
pg_shmem.c: In function 'PGSharedMemoryIsInUse':
pg_shmem.c:323:33: warning: passing argument 1 of 'shmdt' from incompatible
pointer ty
On 2024/10/18 19:07, Seino Yuki wrote:
The choice between adding a new GUC or extending the existing one
(e.g., log_lock_waits)
is debatable, but I prefer the latter. I'm considering extending log_lock_waits
to accept a value like "fail". If set to "on" (the current behavior),
detailed logs ar
Hi,
On 2024-12-02 11:43:42 -0500, Tom Lane wrote:
> Peter Geoghegan writes:
> > This theory seems very believable.
>
> I'm not convinced. I think there are two assumptions underlying
> bitmap scan:
>
> 1. Regardless of index contents, it's not okay for vacuum to remove
> tuples that an open tr
Peter Geoghegan writes:
> On Mon, Dec 2, 2024 at 12:02 PM Tom Lane wrote:
>> Yup. I am saying that that qualifies as too-aggressive setting of the
>> all-visible bit. I'm not sure what rule we should adopt instead of
>> the current one, but I'd much rather slow down page freezing than
>> instit
On Mon, Dec 2, 2024 at 12:02 PM Tom Lane wrote:
> Andres Freund writes:
> > I think the problematic scenario involves tuples that *nobody* can see.
> > During
> > the bitmap index scan we don't know that though. Thus the tid gets inserted
> > into the bitmap. Then, before we visit the heap, a co
On 19.11.2024 00:38, Tomas Vondra wrote:
On 11/18/24 22:15, Tomas Vondra wrote:
...
So I think the correct solution is to not pass any expressions with
RestrictInfo to deparse_expression(). Either by stripping the nodes, or
by not adding them at all.
The patch tries to do the stripping by ma
Commit e9931bfb75 (version 18) contained an unexpected behavior change.
LOWER('I') returns:
In the locale tr_TR.iso88599 (single byte encoding):
17 18
defaulti ı
specified ı ı
In the locale tr_TR.utf8:
On Mon, Dec 2, 2024 at 3:55 PM Andres Freund wrote:
> I suspect one contributor to this avoiding attention till now was that the
> optimization is fairly narrow:
>
> /*
> * We can potentially skip fetching heap pages if we
> do not need
>
On Fri, Nov 29, 2024 at 2:46 PM Masahiko Sawada wrote:
> Finally, in case where we have:
>
> visibility map: 1 pages set all-visible, 1 pages set all-frozen.
>
> We can understand that 1 pages newly became all-frozen, but have
> no idea how many pages became all-visible but not all-fro
Hi hackers,
Attached script reproduces the problem with incorrect results of `select
count(*)` (it returns larger number of records than really available in
the table).
It is not always reproduced, so you may need to repeat it multiple times
- at my system it failed 3 times from 10.
The prob
Andres Freund writes:
> I think the problematic scenario involves tuples that *nobody* can see. During
> the bitmap index scan we don't know that though. Thus the tid gets inserted
> into the bitmap. Then, before we visit the heap, a concurrent vacuum removes
> the tuple from the indexes and then
On 2024-Dec-02, Michael Paquier wrote:
> I am slightly concerned about the current design of GetPublication()
> in the long-term, TBH. LoadPublications() has hidden the leak behind
> two layers of routines in the WAL sender, and that's easy to miss once
> you call anything that loads a Publicatio
On Mon, Dec 2, 2024 at 2:43 PM Andres Freund wrote:
> Attached is an isolationtest that reliably shows wrong query results.
Nice approach with the cursor!
I took what you wrote, and repurposed it to prove my old theory about
GiST index-only scans being broken due to the lack of an appropriate
in
On Mon, Dec 2, 2024 at 3:56 PM Peter Geoghegan wrote:
> I took what you wrote, and repurposed it to prove my old theory about
> GiST index-only scans being broken due to the lack of an appropriate
> interlock against concurrent TID recycling. See the attached patch.
BTW, if you change the test ca
Hi! Thank you for your review!
On 30.11.2024 07:48, Kirill Reshke wrote:
Hello!
After a brief glance, I think this patch set is good.
But there isn't any more time in the current CF to commit this :(.
So I moved to the next CF.
I agree with you. Thank you!)
I also like the 0001 commit message.
On 02.12.2024 17:46, Ilia Evdokimov wrote:
In my opinion, the patches are semantically correct. However, not all
dead code has been removed - I'm referring to
pgstat_update_snapshot(). Also, the tests need to be fixed.
Thank you, I'll fix it
--
Regards,
Alena Rybakina
Postgres Professional
On Mon, Dec 2, 2024 at 11:32 AM Andres Freund wrote:
> On 2024-12-02 16:08:02 +0100, Matthias van de Meent wrote:
> > Concurrency timeline:
> >
> > Session 1. amgetbitmap() gets snapshot of index contents, containing
> > references to dead tuples on heap P1.
>
> IIUC, an unstanted important aspect
Hi,
On 2024-12-02 13:39:43 -0500, Peter Geoghegan wrote:
> I guess it's natural to suspect more recent work -- commit 7c70996e is
> about 6 years old. But I the race condition that I suspect is at play
> here is very narrow.
FWIW, the test I just posted shows the issue down to 11 (although for 11
On 2024-Dec-02, Amit Kapila wrote:
> We already have PGOutputData->cachectx which could be used for it.
> I think we should be able to reset such a context when we are
> revalidating the publications.
I don't see that context being reset anywhere, so I have a hard time
imagining that this would w
On Mon, Dec 2, 2024 at 12:15 PM Peter Geoghegan wrote:
> The underlying reason why nbtree can discriminate like this is that it
> "knows" that plain index scans will always visit the heap proper. If a
> TID points to an LP_UNUSED item, then it is considered dead to the
> scan (even though in gener
Thomas Munro writes:
> I wouldn't change that. illumos is selecting the old pre-standard
> declaration here, but it knows the standard one:
> https://github.com/illumos/illumos-gate/blob/27ecbff00d8c86a2647d6fe325cacb220d712115/usr/src/uts/common/sys/shm.h#L129
> https://illumos.org/man/2/shmdt
Hi,
On 2024-12-02 17:11:30 -0500, Tom Lane wrote:
> I'm inclined to propose adding something like
>
> CPPFLAGS="$CPPFLAGS -D_POSIX_C_SOURCE=200112L"
>
> to src/template/solaris. Not sure if we have a corresponding
> mechanism for meson, though.
elif host_system == 'sunos'
portname = 'solaris
Here is a rebased patch set for cfbot. I'm planning to spend some time
getting these patches into a more reviewable state in the near future.
--
nathan
>From 81fe66e0f0aa4f958a8707df669f60756c89bb85 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 5 Nov 2024 15:59:51 -0600
Subject: [PAT
Vik Fearing writes:
> On 02/12/2024 03:15, Tom Lane wrote:
>> Also, if SQL intended to constrain the search path for unqualified
>> identifiers to be only the new schema, they'd hardly need a concept
>> of at all.
> I looked up the original paper (MUN-051) that introduced the path specification
> On 2 Dec 2024, at 18:39, Joe Conway wrote:
>
> I am very much in favor of functionality of this sort being built in to the
> core database. Very similar functionality is available in an extension I
> wrote years ago (without the SQL grammar support) -- see
> https://github.com/pgaudit/set_u
Hi,
On 2024-12-02 16:08:02 +0100, Matthias van de Meent wrote:
> Concurrency timeline:
>
> Session 1. amgetbitmap() gets snapshot of index contents, containing
> references to dead tuples on heap P1.
IIUC, an unstanted important aspect here is that these dead tuples are *not*
visible to S1. Othe
Eric Hanson:
a) Transaction ("local") Sandbox:
- SET LOCAL ROLE alice NO RESET;
- SET LOCAL ROLE alice WITHOUT RESET;
- BEGIN AS ROLE alice;
Transaction-level sandboxes have the benefit that a pooler can simply
start a new sandboxed transaction for each request and never have to
worry about re
> On Fri, Nov 29, 2024 at 05:47:27PM GMT, Dmitry Dolgov wrote:
> > On Fri, Nov 29, 2024 at 01:56:30AM GMT, Matthias van de Meent wrote:
> >
> > I mean, we can do the following to get a nice contiguous empty address
> > space no other mmap(NULL)s will get put into:
> >
> > /* reserve size bytes
On Mon, Nov 25, 2024 at 08:54:48PM +, Devulapalli, Raghuveer wrote:
> As Nathan suggested, we moved this to a separate thread. The latest set
> of patches here need to applied on top of patches in that thread.
Raghuveer, would you mind rebasing this patch set now that the SSE4.2 patch
is commi
Jeff Davis writes:
> The behavior is commented (commit 176d5bae1d) in formatting.c:
>* ... When using the default
>* collation, we apply the traditional Postgres behavior that
>* forces ASCII-style treatment of I/i, but in non-default
>* collations you get exactly what the collat
Andres Freund writes:
> On 2024-12-02 17:11:30 -0500, Tom Lane wrote:
>> I'm inclined to propose adding something like
>> CPPFLAGS="$CPPFLAGS -D_POSIX_C_SOURCE=200112L"
>> to src/template/solaris. Not sure if we have a corresponding
>> mechanism for meson, though.
> elif host_system == 'sunos'
>
On 2024-12-02 17:42:33 -0500, Tom Lane wrote:
> I'll proceed with improving that (in master only, don't think we need it in
> back branches, at least not today) unless somebody pushes back soon.
+1
On Tue, Oct 29, 2024 at 9:06 PM Peter Eisentraut wrote:
> There are a bunch of (void *) casts in the code that don't make sense to
> me. I think some of these were once necessary because char * was used
> in place of void * for some function arguments.
Some other places that sprang to my eye rec
Ilia Evdokimov writes:
> On 19.11.2024 00:38, Tomas Vondra wrote:
>> On 11/18/24 22:15, Tomas Vondra wrote:
>>> So I think the correct solution is to not pass any expressions with
>>> RestrictInfo to deparse_expression(). Either by stripping the nodes, or
>>> by not adding them at all.
>>>
>>> Th
On Sat, Nov 30, 2024 at 7:01 AM Daniel Verite wrote:
>
> Andrey M. Borodin wrote:
>
>
> > I'm sending amendments addressing your review as a separate step in patch
> > set. Step 1 of this patch set is identical to v39.
>
> Some comments about the implementation of monotonicity:
>
> +/*
> +
Hi,
On Fri, 29 Nov 2024 at 20:05, Matheus Alcantara
wrote:
>
> Hi,
>
>
> On 29/11/24 04:28, Nazir Bilal Yavuz wrote:
> > -for (; blkno < nblocks; blkno++)
> > +p.last_exclusive = nblocks;
> > +
> > +while (BufferIsValid(buf = read_stream_next_buffer(stream, NULL)))
> >
On 28.11.24 07:34, Michael Paquier wrote:
- "WHERE p.prokind = 'a'\n",
+ "WHERE p.prokind = "
CppAsString2(PROKIND_AGGREGATE) "\n",
I noticed something here. If the symbol that is the argument of
Hi hackers,
da952b415f unintentionally added back the "Lock" suffix into the LWLock wait
event names:
- "added back" because the "Lock" suffix was removed in 14a9101091
- "unintentionally" because there is nothing in the thread [2] that explicitly
mentions that the idea was also to revert 14a9101
Hi, Alena!
On Wed, Nov 13, 2024 at 6:21 PM Alena Rybakina
wrote:
> Updated 0001-v13 attached, as well as the diff between v12 and v13.
>
> Thank you)
>
> And I agree with your changes. And included them in patches.
Thank you for the updated patchset. Some points from me.
* I've read the previo
02.12.2024 18:25, Tom Turelinckx wrote:
These crashes are hardly related to code changes, so maybe there are
platform-specific issues still...
I naively assumed that because llvm and clang are available in Trixie on
riscv64 that I could simply install them and enable --with-llvm on copperhead,
On Fri, 29 Nov 2024 at 16:19, Nazir Bilal Yavuz wrote:
> v4 is attached.
Hi!
I feel like we are ready to mark this as RFC, WDYT?
--
Best regards,
Kirill Reshke
On Mon, Dec 2, 2024 at 09:33:39PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Now that we have a warning about non-emittable characters in the PDF
> > build, do you want me to put back the Latin1 characters in the SGML
> > files or leave them as HTML entities?
>
> I think going forward we
On Friday, November 29, 2024 9:08 PM Shlok Kyal
wrote:
>
>
> Thanks for reviewing the patch. I have fixed the issue and updated the patch.
Thanks for updating the patch. I have reviewed and have few suggestions.
Please check the attached diff which includes:
1) Comments in CheckCmdReplicaIde
On Mon, 2024-12-02 at 17:25 -0500, Tom Lane wrote:
> Well, also for compatibility with our SQL parser's understanding
> of identifier lowercasing.
But why only for single-byte encodings? And why not for ICU?
> > Should I put the special case back?
>
> I think so.
Done. I put the special case ba
Jeff Davis writes:
> On Mon, 2024-12-02 at 17:25 -0500, Tom Lane wrote:
>> Well, also for compatibility with our SQL parser's understanding
>> of identifier lowercasing.
> But why only for single-byte encodings? And why not for ICU?
I think the not-for-utf8 exclusion was mostly because that was
On Tue, Dec 03, 2024 at 09:50:42AM +0530, Amit Kapila wrote:
> But that suits the current design more. We allocate PGOutputData and
> other contexts in that structure in a "Logical decoding context". A
> few of its members (publications, publication_names) residing in
> totally unrelated contexts s
On Mon, Dec 2, 2024 at 12:06 AM Sergei Kornilov wrote:
>
> Hello!
> Thanks for the patch, but I think using SPI is still not allowed here:
> https://www.postgresql.org/message-id/9878.1511970441%40sss.pgh.pa.us
>
> > if it uses SPI for sub-operations of ALTER TABLE I think that is sufficient
> >
On Mon, Dec 02, 2024 at 03:29:56PM +0530, Amit Kapila wrote:
> We can look at it from a different angle which is that the
> FreePublication(s) relies on how the knowledge of Publication
> structure is built. So, it doesn't look weird if we think from that
> angle.
OK, I can live with that on all t
On Tue, Dec 3, 2024 at 5:47 PM Michael Paquier wrote:
>
> On Mon, Dec 02, 2024 at 03:29:56PM +0530, Amit Kapila wrote:
> > We can look at it from a different angle which is that the
> > FreePublication(s) relies on how the knowledge of Publication
> > structure is built. So, it doesn't look weird
Hi Nisha, here are a couple of review comments for patch v52-0001.
==
Commit Message
Add check if slot is already acquired, then mark it invalidate directly.
~
/slot/the slot/
"mark it invalidate" ?
Maybe you meant:
"then invalidate it directly", or
"then mark it 'invalidated' directly",
On Tue, 3 Dec 2024 at 10:21, Zhijie Hou (Fujitsu)
wrote:
>
> On Friday, November 29, 2024 9:08 PM Shlok Kyal
> wrote:
> >
> >
> > Thanks for reviewing the patch. I have fixed the issue and updated the
> > patch.
>
> Thanks for updating the patch. I have reviewed and have few suggestions.
>
> Pl
On Mon, Dec 02, 2024 at 09:14:11AM -0500, Robert Haas wrote:
> On Thu, Nov 28, 2024 at 2:53 AM Anthonin Bonnefoy
> wrote:
>> Sorry about that. I didn't have a strong need for this to be
>> backpatched and should have made this clearer.
>
> FWIW, I don't think you did anything wrong. To me, the th
On Wed, Nov 3, 2021 at 7:33 PM Peter Geoghegan wrote:
> But what about index-only scans, which GiST also supports? I think
> that the rules are different there, even though index-only scans use
> an MVCC snapshot.
(Reviving this old thread after 3 years)
I was reminded of this old thread during
On Mon, Dec 2, 2024 at 3:56 PM Peter Geoghegan wrote:
> I took what you wrote, and repurposed it to prove my old theory about
> GiST index-only scans being broken due to the lack of an appropriate
> interlock against concurrent TID recycling. See the attached patch.
I've moved discussion of this
1 - 100 of 115 matches
Mail list logo
