Hi,
On Fri, Mar 22, 2024 at 06:02:11PM +0530, Amit Kapila wrote:
> On Fri, Mar 22, 2024 at 5:30 PM Bertrand Drouvot
> wrote:
> > On Fri, Mar 22, 2024 at 03:56:23PM +0530, Amit Kapila wrote:
> > > >
> > > > That would avoid testing twice "slot->data.persistency ==
> > > > RS_PERSISTENT".
> > > >
On 2024-03-20 12:11, Alexander Korotkov wrote:
On Wed, Mar 20, 2024 at 12:34 AM Kartyshov Ivan
wrote:
> 4.2 With an unreasonably high future LSN, BEGIN command waits
> unboundedly, shouldn't we check if the specified LSN is more than
> pg_last_wal_receive_lsn() error out?
I think limiting
Why not use a single UUID generator for the database table in this case,
similar to autoincrement?
Sergey Prokhorenko
sergeyprokhore...@yahoo.com.au
On Friday, 22 March 2024 at 03:51:20 pm GMT+3, Peter Eisentraut
wrote:
On 21.03.24 16:21, Jelte Fennema-Nio wrote:
> On Wed, 20 Mar
On 22.03.24 13:50, Robert Haas wrote:
On Thu, Mar 21, 2024 at 7:37 PM Peter Eisentraut wrote:
On 20.03.24 17:43, Robert Haas wrote:
0001 removes the "Installation from Binaries" chapter. The whole thing
is four sentences. I moved the most important information into the
"Installation from
> On 22 Mar 2024, at 18:20, Bernd Helmle wrote:
>
> Here is a rebased version of the patch.
FWIW it would be nice at least port tests from commit that I referenced
upthread.
Nowadays we have injection points, so these tests can be much more stable.
Sorry for bringing up this so late.
Robert-
Thank you for your guidance. It turns out the call was coming from
inside the house. The error isn't caused by Postgres. It's the library that
I'm using that reported the error. My extension passes any errors it
generates as Postgres ERRORs.
-Ed
On Thu, Mar 21, 2024 at 8:49
On Fri, Mar 22, 2024 at 11:58 AM Maxim Orlov wrote:
> I've noticed this patch and had a quick look at it. As far as I understand,
> this bug
> does not lead to an incorrect matching, resulting only in degradation in
> speed.
> Anyway, consider this patch useful, hope it will be committed soon.
Hi,
Here is a rebased version of the patch. Since i don't have anything to
add at the moment and the numbers looks promising and to move on, i've
marked this patch "Ready For Committer".
Thanks,
Bernd
diff --git a/contrib/btree_gist/Makefile b/contrib/btree_gist/Makefile
index
> On 20 Mar 2024, at 17:32, Jacob Champion
> wrote:
> I can't find anything else to note; patch LGTM.
While staging this to commit I realized one silly thing about it warranting
another round here. The ASN.1 timediff code can diff against *any* timestamp,
not just the UNIX epoch, so we could
On 21.03.24 16:21, Jelte Fennema-Nio wrote:
On Wed, 20 Mar 2024 at 19:08, Andrey M. Borodin wrote:
Timer-based bits contribute to global sortability. But the real timers we have
are not even millisecond adjusted. We can hope for ~few ms variation in one
datacenter or in presence of atomic
On Thu, Mar 21, 2024 at 7:37 PM Peter Eisentraut wrote:
> On 20.03.24 17:43, Robert Haas wrote:
> > 0001 removes the "Installation from Binaries" chapter. The whole thing
> > is four sentences. I moved the most important information into the
> > "Installation from Source Code" chapter and
On Thu, Mar 21, 2024 at 6:32 PM David G. Johnston
wrote:
> Just going to note that the section on the cumulative statistics views being
> a single page is still a strongly bothersome issue here. Though the quick
> fix actually requires upgrading the section to chapter status...
Yeah, I've
On Fri, Mar 22, 2024 at 5:30 PM Bertrand Drouvot
wrote:
>
> On Fri, Mar 22, 2024 at 03:56:23PM +0530, Amit Kapila wrote:
> > On Fri, Mar 22, 2024 at 3:15 PM Bertrand Drouvot
> > wrote:
> > >
> > > On Fri, Mar 22, 2024 at 01:45:01PM +0530, Bharath Rupireddy wrote:
> > >
> > > 1 ===
> > >
> > > @@
Another thing I noticed while working on [1] is $SUBJECT: this
function checks whether the given query string is non-NULL or not when
creating a WARNING message, but the function is always called with the
query string set, so it should be non-NULL. I removed the check and
instead added an
On Fri, Mar 22, 2024 at 7:15 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Fri, Mar 22, 2024 at 12:39 PM Bertrand Drouvot
> wrote:
> >
> > > > Please find the v14-0001 patch for now.
> >
> > Thanks!
> >
> > > LGTM. Let's wait for Bertrand to see if he has more
Hi,
While working on [1], I noticed $SUBJECT: WaitLatchOrSocket in back
branches is ignoring the possibility of failing partway through, too.
I added a PG_FAINALLY block to that function, like commit 555276f85.
Patch attached.
Best regards,
Etsuro Fujita
[1]
Hi Alexander,
On Fri, Mar 22, 2024 at 7:23 PM Alexander Pyhalov
wrote:
> The updated patch still looks good to me.
Great! I am planning to apply the patch to the back branches next week.
Thanks for the review!
Best regards,
Etsuro Fujita
Hi,
On Fri, Mar 22, 2024 at 04:16:19PM +0530, Amit Kapila wrote:
> On Fri, Mar 22, 2024 at 3:23 PM Bertrand Drouvot
> wrote:
> >
> > On Fri, Mar 22, 2024 at 02:59:21PM +0530, Amit Kapila wrote:
> > > On Fri, Mar 22, 2024 at 2:27 PM Bertrand Drouvot
> > > wrote:
> > > >
> > > > On Fri, Mar 22,
Hi,
On Fri, Mar 22, 2024 at 03:56:23PM +0530, Amit Kapila wrote:
> On Fri, Mar 22, 2024 at 3:15 PM Bertrand Drouvot
> wrote:
> >
> > On Fri, Mar 22, 2024 at 01:45:01PM +0530, Bharath Rupireddy wrote:
> >
> > 1 ===
> >
> > @@ -691,6 +699,13 @@ ReplicationSlotRelease(void)
> >
I think it's better to leave Andrey's patch as is, and add another function in
the future with a customizable UUIDv7 structure for special use cases. The
structure description can be in JSON format. See this discussion.
Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
On Friday, 22
In my queries I often need to do MIN/MAX for tuples, for example:
SELECT MAX(row(year, month))
FROM (VALUES(2025, 1), (2024,2)) x(year, month);
This query throws:
ERROR: function max(record) does not exist
In this case you can replace it with `MAX((year||'-'||month||'-1')::date)`.
On Fri, Mar 22, 2024 at 2:54 PM Amit Langote
wrote:
> >
> > Please let me know if you need anything.
>
> Thanks for repeating the benchmark. So I don't see a problem with
> keeping the existing palloc() way of allocating the
> SpecialJoinInfos(). We're adding a few cycles by adding
>
On Fri, Mar 22, 2024 at 3:23 PM Bertrand Drouvot
wrote:
>
> On Fri, Mar 22, 2024 at 02:59:21PM +0530, Amit Kapila wrote:
> > On Fri, Mar 22, 2024 at 2:27 PM Bertrand Drouvot
> > wrote:
> > >
> > > On Fri, Mar 22, 2024 at 01:45:01PM +0530, Bharath Rupireddy wrote:
> > >
> > > > 0001 Track
On Wed, Mar 13, 2024 at 11:16 AM Peter Smith wrote:
>
> FYI -- some more code has been pushed since this patch was last
> updated. AFAICT perhaps you'll want to update this patch again for the
> following new connection messages on HEAD:
>
> - slotfuncs.c [1]
> - slotsync.c [2]
>
> --
>
On Fri, 22 Mar 2024 at 01:08, Peter Eisentraut wrote:
> Please send a separate patch for this if you want to propose any changes.
>
>
Thank you for your reply. Here is the second one. I've change types and
argument
names for the macro functions, so that they better reflect the reality.
--
On Fri, Mar 22, 2024 at 3:15 PM Bertrand Drouvot
wrote:
>
> On Fri, Mar 22, 2024 at 01:45:01PM +0530, Bharath Rupireddy wrote:
>
> 1 ===
>
> @@ -691,6 +699,13 @@ ReplicationSlotRelease(void)
> ConditionVariableBroadcast(>active_cv);
> }
>
> + if
Etsuro Fujita писал(а) 2024-03-21 13:59:
On Sun, Feb 25, 2024 at 6:34 PM Etsuro Fujita
wrote:
> On Fri, Feb 23, 2024 at 01:21:14PM +0300, Alexander Pyhalov wrote:
> > Recent commit 555276f8594087ba15e0d58e38cd2186b9f39f6d introduced final
> > cleanup of node->as_eventset in
On Thu, Mar 21, 2024 at 8:11 PM Jelte Fennema-Nio wrote:
>
> Attached is a patch that implements this. Since the more I think about
> it, the more I like this approach.
Thanks. Overall the design looks good. log_backtrace is the entry
point for one to control if a backtrace needs to be emitted
On Thu, 21 Mar 2024 at 15:41, Jelte Fennema-Nio wrote:
> Attached is a patch that implements this. Since the more I think about
> it, the more I like this approach.
I now added a 3rd patch to this patchset which changes the
log_backtrace default to "internal", because it seems quite useful to
me
I've noticed this patch and had a quick look at it. As far as I
understand, this bug
does not lead to an incorrect matching, resulting only in degradation in
speed.
Anyway, consider this patch useful, hope it will be committed soon.
--
Best regards,
Maxim Orlov.
Hello postgres hackers:
I recently notice these sql can lead to a assertion error in pg14 and older
version. Here is an example:
postgres=> CREATE TABLE t1 (a int); CREATE TABLE postgres=> INSERT INTO t1
VALUES (1); INSERT 0 1 postgres=> SELECT EXISTS ( SELECT * FROM t1 GROUP BY
GROUPING SETS
Hello,
My team and I have been working on adding Large block size(LBS)
support to XFS in Linux[1]. Once this feature lands upstream, we will be
able to create XFS with FS block size > page size of the system on Linux.
We also gave a talk about it in Linux Plumbers conference recently[2]
for more
Hi,
On Fri, Mar 22, 2024 at 02:59:21PM +0530, Amit Kapila wrote:
> On Fri, Mar 22, 2024 at 2:27 PM Bertrand Drouvot
> wrote:
> >
> > On Fri, Mar 22, 2024 at 01:45:01PM +0530, Bharath Rupireddy wrote:
> >
> > > 0001 Track invalidation_reason in pg_replication_slots
> > > 0002 Track
Hi,
On Fri, Mar 22, 2024 at 01:45:01PM +0530, Bharath Rupireddy wrote:
> On Fri, Mar 22, 2024 at 12:39 PM Bertrand Drouvot
> wrote:
> >
> > > > Please find the v14-0001 patch for now.
> >
> > Thanks!
> >
> > > LGTM. Let's wait for Bertrand to see if he has more comments on 0001
> > > and then
On Fri, Mar 22, 2024 at 2:27 PM Bertrand Drouvot
wrote:
>
> On Fri, Mar 22, 2024 at 01:45:01PM +0530, Bharath Rupireddy wrote:
>
> > 0001 Track invalidation_reason in pg_replication_slots
> > 0002 Track last_inactive_at in pg_replication_slots
> > 0003 Allow setting inactive_timeout for
Hi Ashutosh,
On Tue, Mar 19, 2024 at 12:47 AM Ashutosh Bapat
wrote:
> On Mon, Mar 18, 2024 at 5:40 PM Amit Langote wrote:
>> >>
>> >> Sorry, I should’ve mentioned that I was interested in seeing cpu times to
>> >> compare the two approaches. Specifically, to see if the palloc / frees
>> >>
On 20.03.24 13:03, Matthias van de Meent wrote:
On Wed, 20 Mar 2024 at 12:49, Peter Eisentraut wrote:
On 19.03.24 17:13, Peter Eisentraut wrote:
On 11.03.24 21:52, Matthias van de Meent wrote:
* v7-0003-gen_node_support.pl-Mark-location-fields-as-type-.patch
This looks sensible, but maybe
> On 22 Mar 2024, at 01:29, Michał Kłeczek wrote:
>
>
>
>> On 21 Mar 2024, at 23:42, Matthias van de Meent
>> wrote:
>>
>>> On Tue, 19 Mar 2024 at 17:00, Michał Kłeczek wrote:
>>>
>>> With this operator we can write our queries like:
>>>
>>> account_number ||= [list of account
Hi,
On Fri, Mar 22, 2024 at 01:45:01PM +0530, Bharath Rupireddy wrote:
> On Fri, Mar 22, 2024 at 12:39 PM Bertrand Drouvot
> wrote:
> >
> > > > Please find the v14-0001 patch for now.
> >
> > Thanks!
> >
> > > LGTM. Let's wait for Bertrand to see if he has more comments on 0001
> > > and then
On Thu, 21 Mar 2024 at 03:54, Noah Misch wrote:
>
> On Mon, Mar 18, 2024 at 07:40:10PM +0100, Alvaro Herrera wrote:
> > I enabled the test again and also pushed the changes to dblink,
> > isolationtester and fe_utils (which AFAICS is used by pg_dump,
>
> I recommend adding a libpqsrv_cancel()
On Thu, Mar 21, 2024 at 7:23 PM Peter Eisentraut wrote:
>
> On 20.03.24 12:22, Dean Rasheed wrote:
> > Hmm, for CHECK constraints, the ALTER DOMAIN syntax for adding a
> > constraint is the same as for CREATE DOMAIN, but that's not the case
> > for NOT NULL constraints. So, for example, these
On 22.03.2024 11:02, Pavel Borisov wrote:
Attached is a fix.
Thanks!
--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Hi, Anton!
Looks like an oversight when refactoring BTScanOpaqueData.firstPage into
using function argument in 06b10f80ba4.
@@ -2487,14 +2486,13 @@ _bt_endpoint(IndexScanDesc scan, ScanDirection dir)
104
105 /* remember which buffer we have pinned */
106 so->currPos.buf = buf;
107 -
Hi!
Maybe _bt_readpage(scan, dir, start, true) needed at this line:
https://github.com/postgres/postgres/blob/b4080fa3dcf6c6359e542169e0e81a0662c53ba8/src/backend/access/nbtree/nbtsearch.c#L2501
?
Do we really need to try prechecking the continuescan flag here?
And the current "false" in the
Hi,
On Fri, Mar 22, 2024 at 10:49:17AM +0530, Amit Kapila wrote:
> On Thu, Mar 21, 2024 at 11:21 PM Bharath Rupireddy
> wrote:
> >
> >
> > Please find the v14-0001 patch for now.
Thanks!
> LGTM. Let's wait for Bertrand to see if he has more comments on 0001
> and then I'll push it.
LGTM too.
> On 21 Mar 2024, at 20:21, Jelte Fennema-Nio wrote:
>
> On Wed, 20 Mar 2024 at 19:08, Andrey M. Borodin wrote:
>> Timer-based bits contribute to global sortability. But the real timers we
>> have are not even millisecond adjusted. We can hope for ~few ms variation in
>> one datacenter or
On 21.03.24 10:51, Andrew Dunstan wrote:
At this point, I'm not too stressed about pressing forward with these
last two patches. We can look at them again perhaps if we make
progress
on a more compact node output format. When I started this thread, I
had
a lot of
101 - 147 of 147 matches
Mail list logo
