On Tue, 7 May 2024 at 17:28, Tom Lane wrote:
>
> David Rowley writes:
> > Yeah, before the revert, that did:
> > - sjinf->syn_lefthand = replace_relid(sjinf->syn_lefthand, relid,
> > subst);
> > That replace code seems to have always done a bms_copy()
>
> Hmm, not always; see e0477837c.
On Mon May 6, 2024 at 9:50 PM CDT, Michael Paquier wrote:
On Mon, May 06, 2024 at 02:07:53PM -0500, Tristan Partin wrote:
> This was originally thought of by Andres in
> 5891c7a8ed8f2d3d577e7eea34dacff12d7b6bbd.
+1 because you are removing a duplication between the order of the
items in
David Rowley writes:
> Yeah, before the revert, that did:
> - sjinf->syn_lefthand = replace_relid(sjinf->syn_lefthand, relid,
> subst);
> That replace code seems to have always done a bms_copy()
Hmm, not always; see e0477837c.
What I'm trying to figure out here is whether we have a live
On Tue, 7 May 2024 at 15:35, jian he wrote:
> i also found that not specifying c_args: `-DREALLOCATE_BITMAPSETS`,
> the regress test won't fail.
It would be good to get some build farm coverage of this so we don't
have to rely on manual testing. I wonder if it's a good idea to just
define
On Tue, 7 May 2024 at 17:11, David Rowley wrote:
> sjinf->syn_lefthand = bms_del_member(sjinf->syn_lefthand, relid);
>
> I've not looked, but I assumed the revert must have removed some
> common code that was added and reverted with SJE.
Yeah, before the revert, that did:
-
On Tue, 7 May 2024 at 17:01, Tom Lane wrote:
>
> Richard Guo writes:
> > Thank you for the report. I looked at this a little bit and I think
> > here is what happened. In deconstruct_distribute_oj_quals we call
> > distribute_quals_to_rels using the uncopied sjinfo->syn_lefthand as
> >
Richard Guo writes:
> Thank you for the report. I looked at this a little bit and I think
> here is what happened. In deconstruct_distribute_oj_quals we call
> distribute_quals_to_rels using the uncopied sjinfo->syn_lefthand as
> outerjoin_nonnullable, which eventually becomes
On Tue, 7 May 2024 at 16:47, Richard Guo wrote:
> --- a/src/backend/optimizer/plan/initsplan.c
> +++ b/src/backend/optimizer/plan/initsplan.c
> @@ -1888,7 +1888,7 @@ deconstruct_distribute_oj_quals(PlannerInfo *root,
> qualscope = bms_union(sjinfo->syn_lefthand, sjinfo->syn_righthand);
>
On Tue, May 7, 2024 at 11:35 AM jian he wrote:
> hi,
>
> SELECT table_name, column_name, is_updatable
> FROM information_schema.columns
> WHERE table_name LIKE E'r_\\_view%'
> ORDER BY table_name, ordinal_position;
>
> at d1d286d83c0eed695910cb20d970ea9bea2e5001,
> this query in
Hi Daniel，
Thank you for explaining the ins and outs of this problem.
On 2024/4/30 17:14, Daniel Gustafsson wrote:
>> On 30 Apr 2024, at 04:41, Jingxian Li wrote:
>
>> Attached is a patch that fixes bug when calling strncmp function, in
>> which case the third argument (authmethod -
On Tue, May 7, 2024 at 12:00 AM Christophe Pettus wrote:
> Thank you for the reply!
>
> > On May 1, 2024, at 02:18, Ashutosh Bapat
> wrote:
> > Is there a large transaction which is failing to be replicated
> repeatedly - timeouts, crashes on upstream or downstream?
>
> AFAIK, no, although I am
David Rowley writes:
> Why not "Fix INSERT with multi-row VALUES clauses ..."?
To my mind, the VALUES clause is the data source for INSERT,
so "from" seems appropriate. I'm not going to argue hard
about it.
regards, tom lane
On Tue, 7 May 2024 at 15:48, Tom Lane wrote:
>
> David Rowley writes:
> > I know this is the same wording as Tom added in [1], I might just have
> > failed to comprehend something, but if I strip out the links and try
> > to make sense of "Fix INSERT from multiple VALUES rows into", I just
> >
David Rowley writes:
> I know this is the same wording as Tom added in [1], I might just have
> failed to comprehend something, but if I strip out the links and try
> to make sense of "Fix INSERT from multiple VALUES rows into", I just
> can't figure out how to parse it. I'm pretty sure it means
On Fri, May 03, 2024 at 07:05:38AM -0700, Jacob Champion wrote:
> On Fri, May 3, 2024 at 4:54 AM Peter Eisentraut wrote:
>> but for the general encoding conversion we have what
>> would appear to be the same behavior in report_invalid_encoding(), and
>> we go out of our way there to produce a
hi,
SELECT table_name, column_name, is_updatable
FROM information_schema.columns
WHERE table_name LIKE E'r_\\_view%'
ORDER BY table_name, ordinal_position;
at d1d286d83c0eed695910cb20d970ea9bea2e5001,
this query in src/test/regress/sql/updatable_views.sql
makes regress tests fail. maybe
On Tue, 7 May 2024 at 15:09, Jonathan S. Katz wrote:
> I opted for that; and it turned out the other fix was simple, so here's
> an updated draft.
Thanks
> * Fix [`INSERT`](https://www.postgresql.org/docs/current/sql-insert.html) from
> multiple
On 5/6/24 11:05 PM, David Rowley wrote:
On Tue, 7 May 2024 at 14:58, Jonathan S. Katz wrote:
* Throw an error if an index is accessed while it is being reindexed.
Based on this, I'd vote to just remove it from the release announcement.
I'd prefer that over leaving the wording the way it
On Tue, 7 May 2024 at 14:58, Jonathan S. Katz wrote:
> >> * Throw an error if an index is accessed while it is being reindexed.
> >
>
> Based on this, I'd vote to just remove it from the release announcement.
I'd prefer that over leaving the wording the way it is. Looking at
the test case in
"Jonathan S. Katz" writes:
> On 5/6/24 5:08 PM, David Rowley wrote:
>>> * Throw an error if an index is accessed while it is being reindexed.
>>Maybe we should give more detail
>> there so people don't think we made such a silly mistake. The release
>> note version I think does have enough
On 5/6/24 5:36 PM, Sutou Kouhei wrote:
Hi,
In
<779790c7-45d7-4010-9305-c3f9e6a60...@postgresql.org>,<779790c7-45d7-4010-9305-c3f9e6a60...@postgresql.org>
"2024-05-09 release announcement draft,2024-05-09 release announcement
draft" on Mon, 6 May 2024 13:44:05 -0400,
"Jonathan S. Katz"
On 5/6/24 5:08 PM, David Rowley wrote:
On Tue, 7 May 2024 at 05:44, Jonathan S. Katz wrote:
Please provide feedback no later (and preferably sooner) than 2024-05-09
12:00 UTC.
Thanks for the draft. Here's some feedback.
* Fix
On Mon, May 06, 2024 at 02:07:53PM -0500, Tristan Partin wrote:
> This was originally thought of by Andres in
> 5891c7a8ed8f2d3d577e7eea34dacff12d7b6bbd.
+1 because you are removing a duplication between the order of the
items in PgStat_Kind and the order when these are read. I suspect
that
On Mon, May 06, 2024 at 02:23:24PM -0700, Noah Misch wrote:
> Here's how I've patched it locally. It does avoid changing the backend-side,
> which has some attraction. Shall I just push this?
It looks like you did not rebase on top of HEAD to avoid the spinlock
taken with InjectionPointDetach()
On Fri, May 03, 2024 at 10:39:15AM +0200, Daniel Gustafsson wrote:
> They are no-ops when linking against v18, but writing an extension which
> targets all supported versions of postgres along with their respective
> supported OpenSSL versions make them still required, or am I missing
>
Robert pointed out [1] that the planner fails if we have $SUBJECT,
because tidpath.c can seize on the RLS-derived ctid constraint
instead of the CurrentOfExpr. Since the executor can only handle
CurrentOfExpr in a TidScan's tidquals, that leads to a confusing
runtime error.
Here's a patch for
On Tue, 7 May 2024 at 09:18, Tom Lane wrote:
>
> SAIKIRAN AVULA writes:
> > I have been working on partitioned tables recently, and I have noticed
> > something that doesn't seem correct with the EXPLAIN output of an
> > update/delete query with a returning list.
>
> What do you think is not
On Tue, May 7, 2024 at 6:21 AM Justin Pryzby wrote:
> FWIW: both are running zfs-2.2.3 RPMs from zfsonlinux.org.
...
> Yes, they're running centos7 with the indicated kernels.
So far we've got:
* spurious EIO when opening a file (your previous report)
* hanging with CPU spinning (?) inside
Hi,
In <7a978dd2-371b-4d10-b58e-cb32ef728...@eisentraut.org>
"Re: Is it acceptable making COPY format extendable?" on Thu, 25 Apr 2024
09:59:18 +0200,
Peter Eisentraut wrote:
> PostgreSQL development is currently in feature freeze for PostgreSQL
> 17 (since April 8). So most participants
Hi,
In
<779790c7-45d7-4010-9305-c3f9e6a60...@postgresql.org>,<779790c7-45d7-4010-9305-c3f9e6a60...@postgresql.org>
"2024-05-09 release announcement draft,2024-05-09 release announcement draft"
on Mon, 6 May 2024 13:44:05 -0400,
"Jonathan S. Katz" wrote:
> * Added optimization for certain
Hi all,
Recently I dealt with a server where PAM had hung a connection
indefinitely, suppressing our authentication timeout and preventing a
clean shutdown. Worse, the xmin that was pinned by the opening
transaction cascaded to replicas and started messing things up
downstream.
The DBAs didn't
On Mon, May 06, 2024 at 10:03:37AM +0900, Michael Paquier wrote:
> On Thu, May 02, 2024 at 12:35:55PM -0700, Noah Misch wrote:
> > I should have given a simpler example:
> >
> > s1: local-attach to POINT
> > s2: enter InjectionPointRun(POINT), yield CPU just before
> > injection_callback()
> >
SAIKIRAN AVULA writes:
> I have been working on partitioned tables recently, and I have noticed
> something that doesn't seem correct with the EXPLAIN output of an
> update/delete query with a returning list.
What do you think is not right exactly? The output has to use some
one of the
On Tue, 7 May 2024 at 05:44, Jonathan S. Katz wrote:
> Please provide feedback no later (and preferably sooner) than 2024-05-09
> 12:00 UTC.
Thanks for the draft. Here's some feedback.
> * Fix [`INSERT`](https://www.postgresql.org/docs/current/sql-insert.html) from
> multiple
Hi PostgreSQL Community,
I have been working on partitioned tables recently, and I have noticed
something that doesn't seem correct with the EXPLAIN output of an
update/delete query with a returning list.
For example, consider two partitioned tables, "t1" and "t2," with
partitions "t11," "t12,"
Op 5/6/24 om 19:44 schreef Jonathan S. Katz:
Hi,
Please find the draft of the 2024-05-09 release announcement.
'procedures that returns' should be
'procedures that return'
On Mon, May 6, 2024 at 8:27 AM Robert Haas wrote:
> Stepping back a bit, my current view of this area is: disable_cost is
> highly imperfect both as an idea and as implemented in PostgreSQL.
> Although I'm discovering that the current implementation gets more
> things right than I had realized,
Robert Haas writes:
> I'll look into this, unless you want to do it.
I have a draft patch already. Need to add a test case.
> Incidentally, another thing I just noticed is that
> IsCurrentOfClause()'s test for (node->cvarno == rel->relid) is
> possibly dead code. At least, there are no
On Mon, May 6, 2024 at 3:27 PM Alexander Korotkov wrote:
> I agree it was a hurry to put the plan into commit message. I think
> Tom already gave valuable feedback [1] and probably we will get more.
> So, plan is to be decided. One way or the other I'm not going to
> re-commit this without
On Mon, May 6, 2024 at 3:26 PM Tom Lane wrote:
> Nah, I'm wrong: we do treat it as leakproof, and the comment about
> that in contain_leaked_vars_walker shows that the interaction with
> RLS quals *was* thought about. What wasn't thought about was the
> possibility of RLS quals that themselves
On Mon, May 6, 2024 at 5:44 PM Robert Haas wrote:
> I want to go on record right now as disagreeing with the plan proposed
> in the commit message for the revert commit, namely, committing this
> again early in the v18 cycle. I don't think Tom would have proposed
> reverting this feature unless
I wrote:
> Robert Haas writes:
>> ... Which then allowed me to
>> construct the example above, where there are two possible TID quals
>> and the logic in tidpath.c latches onto the wrong one.
> Hmm. Without having traced through it, I'm betting that the
> CurrentOfExpr qual is rejected as a
On Mon, May 6, 2024 at 6:54 PM Tom Lane wrote:
> Robert Haas writes:
> > I want to go on record right now as disagreeing with the plan proposed
> > in the commit message for the revert commit, namely, committing this
> > again early in the v18 cycle. I don't think Tom would have proposed
> >
Instead of needing to be explicit, we can just iterate the
pgstat_kind_infos array to find the memory locations to read into.
This was originally thought of by Andres in
5891c7a8ed8f2d3d577e7eea34dacff12d7b6bbd.
Not a fix, per se, but it does remove a comment. Perhaps the discussion
will just
Robert Haas writes:
> On Mon, May 6, 2024 at 9:39 AM Robert Haas wrote:
>> It's not very clear that this mechanism is actually 100% reliable,
> It isn't. Here's a test case.
Very interesting.
> ... Which then allowed me to
> construct the example above, where there are two possible TID quals
Thank you for the reply!
> On May 1, 2024, at 02:18, Ashutosh Bapat wrote:
> Is there a large transaction which is failing to be replicated repeatedly -
> timeouts, crashes on upstream or downstream?
AFAIK, no, although I am doing this somewhat by remote control (I don't have
direct access to
On Mon, May 06, 2024 at 10:51:08AM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-05-06 12:37:26 -0500, Justin Pryzby wrote:
> > On Mon, May 06, 2024 at 10:04:13AM -0700, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2024-05-06 09:05:38 -0500, Justin Pryzby wrote:
> > > > In March, I noticed that
On Mon, May 6, 2024 at 9:39 AM Robert Haas wrote:
> It's not very clear that this mechanism is actually 100% reliable,
It isn't. Here's a test case. As a non-superuser, do this:
create table foo (a int, b text, primary key (a));
insert into foo values (1, 'Apple');
alter table foo enable row
Hi,
On 2024-05-06 12:37:26 -0500, Justin Pryzby wrote:
> On Mon, May 06, 2024 at 10:04:13AM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2024-05-06 09:05:38 -0500, Justin Pryzby wrote:
> > > In March, I noticed that a backend got stuck overnight doing:
> > >
> > > backend_start| 2024-03-27
Hi,
Please find the draft of the 2024-05-09 release announcement.
Please review for corrections and any omissions that should be called
out as part of this release.
Please provide feedback no later (and preferably sooner) than 2024-05-09
12:00 UTC.
Thanks,
Jonathan
The PostgreSQL Global
On Mon, May 06, 2024 at 10:04:13AM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-05-06 09:05:38 -0500, Justin Pryzby wrote:
> > In March, I noticed that a backend got stuck overnight doing:
> >
> > backend_start| 2024-03-27 22:34:12.774195-07
> > xact_start | 2024-03-27
On Mon, May 6, 2024 at 12:24:41PM -0400, Robert Haas wrote:
> Now that being said, I do also agree that the planner code is quite
> hard to understand, for various reasons. I don't think the structure
> of that code and the assumptions underlying it are as well-documented
> as they could be, and
Hi,
On 2024-05-06 09:05:38 -0500, Justin Pryzby wrote:
> In March, I noticed that a backend got stuck overnight doing:
>
> backend_start| 2024-03-27 22:34:12.774195-07
> xact_start | 2024-03-27 22:34:39.741933-07
> query_start | 2024-03-27 22:34:41.997276-07
> state_change |
On Mon, May 06, 2024 at 06:34:16PM +0200, Alvaro Herrera wrote:
> On 2024-May-06, Justin Pryzby wrote:
>
> > > (Do you really want the partition to be
> > > created without the primary key already there?)
> >
> > Why not ? The PK will be added when I attach it one moment later.
> >
> > CREATE
On 2024-May-06, Justin Pryzby wrote:
> > (Do you really want the partition to be
> > created without the primary key already there?)
>
> Why not ? The PK will be added when I attach it one moment later.
>
> CREATE TABLE part (LIKE parent);
> ALTER TABLE parent ATTACH PARTITION part ...
Well,
On Mon, May 6, 2024 at 12:01 PM Andrei Lepikhov
wrote:
> Right now, it evolves extensively - new structures, variables,
> alternative copies of the same node trees with slightly changed
> properties ... This way allows us to quickly introduce some planning
> features (a lot of changes in planner
On Tue, 23 Apr 2024 at 19:39, Jacob Champion
wrote:
>
> On Mon, Apr 22, 2024 at 2:20 PM Jelte Fennema-Nio wrote:
> > 1. I strongly believe minor protocol version bumps after the initial
> > 3.1 one can be made painless for clients/poolers (so the ones to
> > 3.2/3.3/etc). Similar to how TLS 1.3
On Tue, 23 Apr 2024 at 17:03, Robert Haas wrote:
> If a client doesn't know about encrypted columns and sets that
> bit at random, that will break things, and formally I think that's a
> risk, because I don't believe we document anywhere that you shouldn't
> set unused bits in the format mask.
On Mon, May 06, 2024 at 05:56:54PM +0200, Alvaro Herrera wrote:
> On 2024-May-04, Alvaro Herrera wrote:
> > On 2024-May-03, Justin Pryzby wrote:
> >
> > > But if it's created with LIKE:
> > > postgres=# CREATE TABLE t1 (LIKE t);
> > > postgres=# ALTER TABLE t ATTACH PARTITION t1 DEFAULT ;
> > >
On 6/5/2024 21:44, Robert Haas wrote:
On Sat, May 4, 2024 at 10:46 PM Andrei Lepikhov
wrote:
Having no objective negative feedback, we have no reason to change
anything in the design or any part of the code. It looks regrettable and
unusual.
To me, this sounds like you think it's someone
On 2024-May-04, Alvaro Herrera wrote:
> On 2024-May-03, Justin Pryzby wrote:
>
> > But if it's created with LIKE:
> > postgres=# CREATE TABLE t1 (LIKE t);
> > postgres=# ALTER TABLE t ATTACH PARTITION t1 DEFAULT ;
> >
> > ..one also sees:
> >
> > Not-null constraints:
> > "t1_i_not_null"
simple there are already too many of them. Perhaps we should begin
tracking all that as a set of bitmasks, then plug in the tracked state
in shmem for consumption in some SQL function.
Hi!
Michael, Tristan
as a first step I have introduced the `SharedRecoveryDataFlags` bitmask
instead of
Robert Haas writes:
> I want to go on record right now as disagreeing with the plan proposed
> in the commit message for the revert commit, namely, committing this
> again early in the v18 cycle. I don't think Tom would have proposed
> reverting this feature unless he believed that it had more
On Mon, May 6, 2024 at 10:44:33AM -0400, Robert Haas wrote:
> I want to go on record right now as disagreeing with the plan proposed
> in the commit message for the revert commit, namely, committing this
> again early in the v18 cycle. I don't think Tom would have proposed
> reverting this
Currently, it is pretty easy to subvert the restrictions imposed
by row-level security and security_barrier views. All you have to
to is use EXPLAIN (ANALYZE) and see how many rows were filtered
out by the RLS policy or the view condition.
This is not considered a security bug (I asked), but I
On Sat, May 4, 2024 at 10:46 PM Andrei Lepikhov
wrote:
> Having no objective negative feedback, we have no reason to change
> anything in the design or any part of the code. It looks regrettable and
> unusual.
To me, this sounds like you think it's someone else's job to tell you
what is wrong
This seven email thread should never have appeared on the hackers list.
It is more appropriate for the pgsql-gene...@postgresql.org email list.
---
On Mon, May 6, 2024 at 08:53:15AM +0500, Kashif Zeeshan wrote:
> Hi
>
>
Hi Team, on further investigation we were able to resolve the perl issue by
setting the right PERL env location. Earlier it was pointing to the 32bit perl,
as a result the perl lib mismatch seems to be happening.
Now we have successfully built release 15 and 16 stable branches on the OSU lab
In March, I noticed that a backend got stuck overnight doing:
backend_start| 2024-03-27 22:34:12.774195-07
xact_start | 2024-03-27 22:34:39.741933-07
query_start | 2024-03-27 22:34:41.997276-07
state_change | 2024-03-27 22:34:41.997307-07
wait_event_type | IO
wait_event
> On Mon, May 06, 2024 at 06:52:41PM +0530, Ashutosh Bapat wrote:
> On Sun, May 5, 2024 at 1:43 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > I had a quick look, it covers the issues mentioned above in the thread.
> > Few nitpicks/questions:
> >
> > * I think it makes sense to verify if the
On Sat, May 4, 2024 at 12:57 PM Tom Lane wrote:
> There is also some weirdness around needing to force use of tidscan
> if we have WHERE CURRENT OF. But perhaps a different hack could be
> used for that.
Yeah, figuring out what to do about this was the trickiest part of the
experimental patch
On 2024-May-06, David G. Johnston wrote:
> On Monday, May 6, 2024, Peter Burbery wrote:
>
> >
> > Business Use-case: I want to create a table named things_that_take_up_a_
> > lot_of_storage_and_space_on_a_computer_and_hard_drive of 75 characters. I
> > also want to create a column named
On Sun, May 5, 2024 at 1:43 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Tue, Apr 30, 2024 at 04:29:11PM +0530, Ashutosh Bapat wrote:
> > On Sun, Apr 28, 2024 at 12:29 PM Alexander Lakhin
> > wrote:
> >
> > > 27.04.2024 18:00, Alexander Lakhin wrote:
> > > >
> > > > Please look also at
On Mon, May 6, 2024 at 4:26 PM Jakub Wartak
wrote:
> Hi Ashutosh & hackers,
>
> On Mon, Apr 15, 2024 at 9:00 AM Ashutosh Bapat
> wrote:
> >
> > Here's patch with
> >
> [..]
> > Adding to the next commitfest but better to consider this for the next
> set of minor releases.
>
> 1. The patch does
On Monday, May 6, 2024, Peter Burbery wrote:
>
> Business Use-case: I want to create a table named things_that_take_up_a_
> lot_of_storage_and_space_on_a_computer_and_hard_drive of 75 characters. I
> also want to create a column named thing_that_takes_up_a_
>
One-line Summary: There are use cases for long table names so people might
use Oracle and MS SQL Server because Postgres does not support table names
longer than 63 characters, so the max character limit should be increased
to 128 or higher.
Business Use-case: I want to create a table
named
Greetings,
I've been asked by the debezium developers if it is possible to include
xid8 in the logical replication protocol. Are there any previous threads on
this topic?
Any reason why we wouldn't include the epoch ?
Dave Cramer
On Sat, May 4, 2024 at 9:16 AM David Rowley wrote:
> I don't think you'd need to wait longer than where we do set_cheapest
> and find no paths to find out that there's going to be a problem.
I'm confused by this response, because I thought that the main point
of my previous email was explaining
Hi Ashutosh & hackers,
On Mon, Apr 15, 2024 at 9:00 AM Ashutosh Bapat
wrote:
>
> Here's patch with
>
[..]
> Adding to the next commitfest but better to consider this for the next set of
> minor releases.
1. The patch does not pass cfbot -
https://cirrus-ci.com/task/5486258451906560 on master
On 2024-04-03 Wn 04:21, Andrew Dunstan
> I don't think a cast that doesn't cater for all the forms json can take
is going to work very well. At the very least you would need to error out
in cases you didn't want to cover, and have tests for all of > > those
errors. But the above is only a tiny
Hi, Anton!
On Mon, May 6, 2024 at 9:05 AM Anton A. Melnikov
wrote:
> On 14.03.2024 17:57, Alexander Korotkov wrote:
> > On Sun, Mar 3, 2024 at 5:37 PM Erik Wienhold wrote:
> >> On 2024-03-03 03:00 +0100, Steve Chavez wrote:
> >>> psql has the :{?name} syntax for testing a psql variable
On 04.05.24 00:29, David Zhang wrote:
On 2024-05-03 4:53 a.m., Daniel Gustafsson wrote:
On 3 May 2024, at 13:48, Peter Eisentraut wrote:
Maybe it's easier if we just replaced
prototypes for functions in xxx.c
with
declarations for xxx.c
throughout src/include/libpq/libpq.h.
+1
+1
On Tue, Apr 30, 2024 at 10:36 PM Noah Misch wrote:
>
> >
> > > One could argue the function should also check
> > > isBackgroundWorker and ignore even bgworkers that set proc->roleId, but
> > > I've
> > > not done that.
> >
> > What is the argument for ignoring such workers?
>
> One of the
Hello hackers,
While trying to catch a sporadic regression test failure, I've discovered
that tests tsearch and advisory_lock in the parallel_schedule's group:
test: select_views ... tsearch ... advisory_lock indirect_toast equivclass
might fail, depending on timing, because the test
Hello Antonin,
Thanks for interesting with this topic!
> * I think that, before EC is considered suitable for an UK, its ec_opfamilies
> field needs to be checked. I try to do that in
> find_ec_position_matching_expr(), see 0004.
Could you make the reason clearer for adding 'List
Hello!
On 14.03.2024 17:57, Alexander Korotkov wrote:
On Sun, Mar 3, 2024 at 5:37 PM Erik Wienhold wrote:
On 2024-03-03 03:00 +0100, Steve Chavez wrote:
psql has the :{?name} syntax for testing a psql variable existence.
But currently doing \echo :{?VERB doesn't trigger tab completion.
86 matches
Mail list logo
