On Wed, May 01, 2024 at 04:12:14PM -0700, Noah Misch wrote:
> While writing an injection point test, I encountered a variant of the race
> condition that f4083c4 fixed. It had three sessions and this sequence of
> events:
>
> s1: local-attach to POINT
> s2: enter InjectionPointRun(POINT), yield C
Hello Ashutosh,
Thank you for your email and for reviewing the patch. I sincerely
apologize for the delay in responding.
On Wed, Mar 6, 2024 at 11:16 PM Ashutosh Bapat
wrote:
> here's summary of observations
> 1. The patch improves planning time significantly (3X to 20X) and the
> improvement i
> On 2 May 2024, at 12:27, Michael Paquier wrote:
>
> On Wed, May 01, 2024 at 04:12:14PM -0700, Noah Misch wrote:
>> While writing an injection point test, I encountered a variant of the race
>> condition that f4083c4 fixed. It had three sessions and this sequence of
>> events:
>>
>> s1: loc
On Thu, May 02, 2024 at 01:33:45PM +0500, Andrey M. Borodin wrote:
> That seems to prevent meaningful use case. If we want exactly one
> session to be waiting just before some specific point, the only way
> to achieve this is to create local injection point. But the session
> must be resumable from
> On 2 May 2024, at 13:43, Michael Paquier wrote:
>
> A detach is not a wakeup.
Oh, now I see. Sorry for the noise.
Detaching local injection point of other backend seems to be useless and can be
forbidden.
As far as I understand, your patch is already doing this in
+ if (!injection_p
On Fri, 26 Apr 2024 12:23:45 +0200
Matthias van de Meent wrote:
> On Fri, 26 Apr 2024 at 10:54, Yugo NAGATA wrote:
> >
> > On Wed, 24 Apr 2024 16:08:39 -0500
> > Nathan Bossart wrote:
> >
> > > On Tue, Apr 23, 2024 at 11:47:38PM -0400, Tom Lane wrote:
> > > > On the whole I find this proposed f
On 5/1/24 18:59, Alexander Korotkov wrote:
I think we probably could forbid SJE for the tables with TABLESAMPLE
altogether. Please, check the attached patch.
Your patch looks good to me. I added some comments and test case into
the join.sql.
One question for me is: Do we anticipate other late
On Thu, May 2, 2024 at 12:45 PM Andrei Lepikhov
wrote:
>
> On 5/1/24 18:59, Alexander Korotkov wrote:
> > I think we probably could forbid SJE for the tables with TABLESAMPLE
> > altogether. Please, check the attached patch.
> Your patch looks good to me. I added some comments and test case into
On Mon, 2024-03-11 at 09:33 +0100, Jelte Fennema-Nio wrote:
> - the subscriber's server log.
> + the subscriber's server log if you remove 23505 from
> + .
>
> This seems like a pretty big regression. Being able to know why your
> replication got closed seems pretty critical.
Yes. But I'd
On Thu, 2 May 2024 at 12:47, Laurenz Albe wrote:
> Yes. But I'd argue that that is a shortcoming of logical replication:
> there should be a ways to get this information via SQL. Having to look into
> the log file is not a very useful option.
Definitely agreed that accessing the error details u
On Thu, 2 May 2024 at 13:08, Jelte Fennema-Nio wrote:
> 2. Change the newly added check in errcode() to only set
> output_to_server to false when IsLogicalWorker() returns false.
Actually a third, and probably even better solution would be to only
apply this new GUC to non-backgroundworker proces
I tried to initialize a table with values for smallint columns.
The final goal is to get mask values for logical operations.
The insert failed with ERROR: smallint out of range.
the same occurs when using a simple select statement like:
select -32768::smallint;
select -2147483648::int;
select
On Thu, 2 May 2024 at 23:25, Hans Buschmann wrote:
> postgres=# select -32768::smallint;
> ERROR: smallint out of range
The precedence order of operations applies the cast before the unary
minus operator.
Any of the following will work:
postgres=# select cast(-32768 as smallint), (-32768)::sma
Hello,
28.04.2024 11:05, David Rowley wrote:
On Sat, 20 Apr 2024 at 16:09, David Rowley wrote:
Here are a few more to see if it motivates anyone else to do a more
thorough search for another batch.
I've pushed these now.
Please look also at the list of other typos and inconsistencies I've
Thank you for your quick response.
This was very helpfull and resolved my problem.
But for me it is a bit counterintuitive that -32768 is not treated as a
negative constant but as a unary operator to a positive constant.
It could be helpfull to remind the user of the nature of negative const
On Thu, May 2, 2024 at 6:08 PM Alexander Korotkov
wrote:
> On Thu, May 2, 2024 at 12:45 PM Andrei Lepikhov
> wrote:
> > One question for me is: Do we anticipate other lateral self-references
> > except the TABLESAMPLE case? Looking into the extract_lateral_references
> > implementation, I see th
hi.
just found out we can:
explain (verbose, verbose off, analyze on, analyze off, analyze on)
select count(*) from tenk1;
similar to COPY, do we want to error out these redundant options?
On Thu, May 2, 2024 at 6:17 AM jian he wrote:
> explain (verbose, verbose off, analyze on, analyze off, analyze on)
>
>
I would just update this paragraph to note the last one wins behavior.
"When the option list is surrounded by parentheses, the options can be
written in any order. However, if
On 30.04.24 14:39, Daniel Verite wrote:
postgres=# SELECT '.foo.' like '_oo' COLLATE ign_punct;
?column?
--
f
(1 row)
The first two results look fine, but the next one is inconsistent.
This is correct, because '_' means "any single character". This is
independent of
On Thu, May 2, 2024, at 10:36 AM, David G. Johnston wrote:
> On Thu, May 2, 2024 at 6:17 AM jian he wrote:
>> explain (verbose, verbose off, analyze on, analyze off, analyze on)
>
> I would just update this paragraph to note the last one wins behavior.
>
> "When the option list is surrounded by
"David G. Johnston" writes:
> On Thu, May 2, 2024 at 6:17 AM jian he wrote:
>> explain (verbose, verbose off, analyze on, analyze off, analyze on)
> I have no desire to introduce breakage here. The implemented concept is
> actually quite common. The inconsistency with COPY seems like a minor
>
On 24.04.24 12:34, Yugo NAGATA wrote:
On Wed, 24 Apr 2024 09:39:02 +0200
Peter Eisentraut wrote:
libpq's pqTraceOutputMessage() used to look like this:
case 'Z': /* Ready For Query */
pqTraceOutputZ(conn->Pfdebug, message, &logCursor);
break;
Commit f4
On Thu, May 2, 2024 at 3:57 PM Yuya Watari wrote:
>
hi. sorry to bother you, maybe a dumb question.
trying to understand something under the hood.
currently I only applied
v24-0001-Speed-up-searches-for-child-EquivalenceMembers.patch.
on v24-0001:
+/*
+ * add_eq_member - build a new Equivalence
On Wed, 1 May 2024 at 00:11, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> Seems to be a meson quirk [1]. I could reproduce this, and adding
> -Db_lundef=false on top of your configuration solved the issue.
>
> [1]: https://github.com/mesonbuild/meson/issues/3853
>
Thank you for a reply! Yes, i
Hello Alvaro,
01.05.2024 20:49, Alvaro Herrera wrote:
Here are two patches that I intend to push soon (hopefully tomorrow).
Thank you for fixing those issues!
Could you also clarify, please, how CREATE TABLE ... LIKE is expected to
work with NOT NULL constraints?
I wonder whether EXCLUDING
On Thu, May 2, 2024 at 2:12 AM Rian McGuire wrote:
> The planner was burning a huge amount of CPU time looking through
> index pages for the first visible tuple. The problem eventually
> resolved when the affected index was vacuumed, but that took several
> hours to complete.
This is exactly the
On Wed, May 1, 2024 at 9:47 PM Tom Lane wrote:
> David Rowley writes:
> > Let's bash it into shape a bit more before going any further on actual
> wording.
>
> FWIW, I want to push back on the idea of making it a tutorial section.
> I too considered that, but in the end I think it's a better ide
> And as far as that goes, I'd like you - and others - to spell out more
> precisely why you think 100 or 200 million tuples is too much. It
> might be, or maybe it is in some cases but not in others. To me,
> that's not a terribly large amount of data. Unless your tuples are
> very wide, it's a fe
Hello Alexander
On 2024-May-02, Alexander Lakhin wrote:
> Could you also clarify, please, how CREATE TABLE ... LIKE is expected to
> work with NOT NULL constraints?
It should behave identically to 16. If in 16 you end up with a
not-nullable column, then in 17 you should get a not-null constrain
I thought that this might be a small quality of life improvement for
people scrolling through logs wondering which tranche name wasn't
registered.
--
Tristan Partin
Neon (https://neon.tech)
From 63c8d92a8a82acc5f8859ab47da5105cef46b88e Mon Sep 17 00:00:00 2001
From: Tristan Partin
Date: Thu, 2
Sorry to have to ask for help here, but no amount of stepping through code
is giving me the answer.
I'm building an index access method which supports an ordering operator:
CREATE OPERATOR pg_catalog.<<=>> (
FUNCTION = rdb.rank_match,
LEFTARG = record,
RIGHTARG = rdb.R
On Thu, 2 May 2024 at 17:19, Tomas Vondra wrote:
>
> Hi,
>
> In PG17 we shall have parallel CREATE INDEX for BRIN indexes, and back
> when working on that I was thinking how difficult would it be to do
> something similar to do that for other index types, like GIN. I even had
> that on my list of
On Thu, 2 May 2024 at 18:50, Chris Cleveland wrote:
>
> Sorry to have to ask for help here, but no amount of stepping through code is
> giving me the answer.
>
> I'm building an index access method which supports an ordering operator:
[...]
> so there's no reason the system needs to know the actu
Chris Cleveland writes:
> I'm building an index access method which supports an ordering operator:
> CREATE OPERATOR pg_catalog.<<=>> (
> FUNCTION = rdb.rank_match,
> LEFTARG = record,
> RIGHTARG = rdb.RankSpec
> );
Okay ...
> ... there's no reason the system nee
> On 17 Apr 2024, at 22:47, Kirk Wolak wrote:
>
> Thoughts?
Today we had a hacking session with Nik and Kirk. We produced a patch to assess
how these links might look like.
Also we needed a url_encode() and found none in a codebase. It would be nice to
have this as an SQL-callable function.
On 5/2/24 19:12, Matthias van de Meent wrote:
> On Thu, 2 May 2024 at 17:19, Tomas Vondra
> wrote:
>>
>> Hi,
>>
>> In PG17 we shall have parallel CREATE INDEX for BRIN indexes, and back
>> when working on that I was thinking how difficult would it be to do
>> something similar to do that for o
čt 2. 5. 2024 v 19:50 odesílatel Andrey M. Borodin
napsal:
>
>
> > On 17 Apr 2024, at 22:47, Kirk Wolak wrote:
> >
> > Thoughts?
>
> Today we had a hacking session with Nik and Kirk. We produced a patch to
> assess how these links might look like.
>
> Also we needed a url_encode() and found none
On Thu, May 02, 2024 at 04:27:12PM +0900, Michael Paquier wrote:
> On Wed, May 01, 2024 at 04:12:14PM -0700, Noah Misch wrote:
> > While writing an injection point test, I encountered a variant of the race
> > condition that f4083c4 fixed. It had three sessions and this sequence of
> > events:
> >
> > ... there's no reason the system needs to know the actual float value
> > returned by rank_match(), the ordering operator distance function. In any
> > case, that value can only be calculated based on information in the index
> > itself, and can't be calculated by rank_match().
>
> This seems t
On 4/30/24 14:07, Daniel Gustafsson wrote:
>> On 26 Apr 2024, at 15:04, Melanie Plageman wrote:
>
>> If this seems correct to you, are you okay with the rest of the fix
>> and test? We could close this open item once the patch is acceptable.
>
> From reading the discussion and the patch this see
Thanks a lot David Rowley for your suggestion in details.
On 2024-04-08 3:23 p.m., David Rowley wrote:
On Tue, 9 Apr 2024 at 09:52, David Zhang wrote:
Finding the exact ctid seems overkill for what you need. Why you
could just find the maximum block with:
N = pg_relation_size('name_of_your_ta
On 4/24/24 22:46, Melanie Plageman wrote:
> On Tue, Apr 23, 2024 at 6:43 PM Tomas Vondra
> wrote:
>>
>> On 4/23/24 18:05, Melanie Plageman wrote:
>>> The patch with a fix is attached. I put the test in
>>> src/test/regress/sql/join.sql. It isn't the perfect location because
>>> it is testing so
Hi Hackers,
There is a comment like below in src/include/libpq/libpq.h,
/*
* prototypes for functions in be-secure.c
*/
extern PGDLLIMPORT char *ssl_library;
extern PGDLLIMPORT char *ssl_cert_file;
...
However, 'ssl_library', 'ssl_cert_file' and the rest are global
parameter settings, no
On Fri, 3 May 2024 at 09:33, David Zhang wrote:
> Is there a simple way to get the min of ctid faster than using min(), but
> similar to get the max of ctid using pg_relation_size?
The equivalent approximation is always '(0,1)'.
David
Hi, Richard!
On Thu, May 2, 2024 at 4:14 PM Richard Guo wrote:
> On Thu, May 2, 2024 at 6:08 PM Alexander Korotkov
> wrote:
>> On Thu, May 2, 2024 at 12:45 PM Andrei Lepikhov
>> wrote:
>> > One question for me is: Do we anticipate other lateral self-references
>> > except the TABLESAMPLE case?
Alexander Korotkov writes:
> I would appreciate your review of this patchset, and review from Andrei as
> well.
I hate to say this ... but if we're still finding bugs this
basic in SJE, isn't it time to give up on it for v17?
I might feel better about it if there were any reason to think
these
On Wed, May 1, 2024 at 8:40 PM Michael Paquier wrote:
>
> On Thu, May 02, 2024 at 11:23:13AM +0900, Michael Paquier wrote:
> > About the fact that we may finish by printing unfinished UTF-8
> > sequences, I'd be curious to hear your thoughts. Now, the information
> > provided about the partial by
Hi,
pg_ugprade from v15 to v16 failed in an environment. Often we get a
reasonable message, but this time it was a bit weird. First, error
message:
=
pg_restore: creating TYPE "foobar._packagestoptemp"
pg_restor
Hi Andrew,
On Mon, 2024-04-15 at 06:35 -0400, Andrew Dunstan wrote:
> It's working on my Fedora 39. This error suggests to me that you don't
> have docbook-dtds installed. If you do, then I don't know :-)
Sorry for the noise. I got a new laptop, and apparently some of the
packages (like this) wer
Hi,
On Wed, 2024-04-24 at 11:02 +, Hans Buschmann wrote:
> Today (24.4.2024) I upgraded my laptop to Fedora 40, but there where
> no repository available, so I ended with a mix of Fedora 40 and Fedora
> 39 installation.
This was caused by an unexpected and very long network outage that
blocke
On Thu, May 2, 2024 at 9:38 AM Peter Eisentraut wrote:
> On 30.04.24 14:39, Daniel Verite wrote:
> >postgres=# SELECT '.foo.' like '_oo' COLLATE ign_punct;
> > ?column?
> >--
> > f
> >(1 row)
> >
> > The first two results look fine, but the next one is inconsistent.
>
>
Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes:
> pg_ugprade from v15 to v16 failed in an environment. Often we get a
> reasonable message, but this time it was a bit weird. First, error
> message:
It seems like the source database must have been in quite a corrupt
state already --- here we have the a
On Mon, Apr 15, 2024 at 05:41:04PM +, Imseih (AWS), Sami wrote:
>> Another option could be to just remove the restart-only GUC and hard-code
>> the upper limit of autovacuum_max_workers to 64 or 128 or something. While
>> that would simplify matters, I suspect it would be hard to choose an
>> a
Similar to 'pg_dump --binary-upgrade' [0], we can speed up pg_dump with
many sequences by gathering the required information in a single query
instead of two queries per sequence. The attached patches are
works-in-progress, but here are the results I see on my machine for
'pg_dump --schema-only --
On 5/3/24 06:19, Tom Lane wrote:
Alexander Korotkov writes:
I would appreciate your review of this patchset, and review from Andrei as well.
I hate to say this ... but if we're still finding bugs this
basic in SJE, isn't it time to give up on it for v17?
I might feel better about it if there
02.05.2024 19:21, Alvaro Herrera wrote:
Now, you could claim that the standard doesn't mention
INCLUDING/EXCLUDING CONSTRAINTS, therefore since we have come up with
its definition then we should make it affect not-null constraints.
However, there's also this note:
NOTE 520 — s, except for NO
I'm trying to figure out why BufFileSize() Asserts that file->fileset
isn't NULL, per 1a990b207.
The discussion for that commit is in [1], but I don't see any
explanation of the Assert in the discussion or commit message and
there's no comment explaining why it's there.
The code that comes after
Hi David
I reviewed the documentation and it's very detailed.
Thanks
Kashif Zeeshan
Bitnine Global
On Thu, May 2, 2024 at 8:24 PM David G. Johnston
wrote:
> On Wed, May 1, 2024 at 9:47 PM Tom Lane wrote:
>
>> David Rowley writes:
>> > Let's bash it into shape a bit more before going any furt
> On 13 Apr 2024, at 11:58, Andrey M. Borodin wrote:
>
> New UUID is assigned RFC number 9562, it was aproved by RFC editors and is
> now in AUTH48 state.
RFC 9562 is not in AUTH48-Done state, it was approved by authors and editor,
and now should be published.
Best regards, Andrey Borodin.
Hello Devrim,
Sorry for the long network outage!
>>This is what I do for the Fedora releases. I'm sure you've noticed that
>>in the past.
No, I didn't notice it and I missed it recently, so I made this proposal (see
1. below).
Here are some points concerning $topic:
1. Availability in be
On Wed, May 1, 2024 at 5:37 AM Masahiko Sawada
wrote:
> Thank you for further testing! I've pushed the patch.
Thanks!
Here is the rebased version for the follow-up patch removing VacuumPage
variables. Though I'm not sure if I should create a dedicated mail thread
since the bug was fixed and the
On Thu, 2024-05-02 at 08:23 -0700, David G. Johnston wrote:
> Version 2 attached. Still a draft, focused on topic picking and overall
> structure.
I'm fine with most of the material (ignoring ellipses and typos), except this:
+The NOT NULL column constraint is largely syntax sugar for the
62 matches
Mail list logo