Hi, Pavel!
On Fri, May 17, 2024 at 2:02 PM Pavel Borisov wrote:
> On Fri, 17 May 2024 at 14:05, Alexander Korotkov wrote:
>>
>> On Tue, May 14, 2024 at 5:49 PM Justin Pryzby wrote:
>> > On Thu, May 09, 2024 at 12:51:32AM +0300, Alexander Korotkov wrote:
>> &
On Mon, May 13, 2024 at 4:42 AM Alexander Korotkov wrote:
> On Mon, May 13, 2024 at 12:23 AM Alexander Korotkov
> wrote:
> > On Sat, May 11, 2024 at 4:13 AM Mark Dilger
> > wrote:
> > > > On May 10, 2024, at 12:05 PM, Alexander Korotkov
> > > > wr
On Tue, May 14, 2024 at 5:49 PM Justin Pryzby wrote:
> On Thu, May 09, 2024 at 12:51:32AM +0300, Alexander Korotkov wrote:
> > > > However, parent's table extended statistics already covers all its
> > > > children.
> > >
> > > => That's the wrong
nally to
the role names, the lack of permissions on schemas lead to creation of
tables in public schema and potential conflict there. Fixed in
2a679ae94e.
--
Regards,
Alexander Korotkov
On Mon, May 13, 2024 at 12:23 AM Alexander Korotkov
wrote:
> On Sat, May 11, 2024 at 4:13 AM Mark Dilger
> wrote:
> > > On May 10, 2024, at 12:05 PM, Alexander Korotkov
> > > wrote:
> > > The only bt_target_page_check() caller is
> > > bt_check_le
On Sat, May 11, 2024 at 4:13 AM Mark Dilger
wrote:
> > On May 10, 2024, at 12:05 PM, Alexander Korotkov
> > wrote:
> > The only bt_target_page_check() caller is
> > bt_check_level_from_leftmost(), which overrides state->target in the
> > next iteration a
On Fri, May 10, 2024 at 8:35 PM Mark Dilger
wrote:
> > On May 10, 2024, at 5:10 AM, Pavel Borisov wrote:
> > On Fri, 10 May 2024 at 12:39, Alexander Korotkov
> > wrote:
> > On Fri, May 10, 2024 at 3:43 AM Tom Lane wrote:
> > > Alexander Korotkov wri
On Fri, May 10, 2024 at 3:43 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > The revised patchset is attached. I applied cosmetical changes. I'm
> > going to push it if no objections.
>
> Is this really suitable material to be pushing post-feature-freeze?
> It doesn
On Wed, May 1, 2024 at 5:26 AM Alexander Korotkov wrote:
> On Wed, May 1, 2024 at 5:24 AM Noah Misch wrote:
> > On Thu, Apr 25, 2024 at 04:59:54PM +0400, Pavel Borisov wrote:
> > > 0001: Optimize speed by avoiding heap visibility checking for different
> > > no
On Thu, May 9, 2024 at 12:37 AM Justin Pryzby wrote:
>
> On Wed, May 08, 2024 at 09:00:10PM +0300, Alexander Korotkov wrote:
> > On Fri, May 3, 2024 at 4:32 PM Alexander Korotkov
> > wrote:
> > > On Fri, May 3, 2024 at 4:23 PM Justin Pryzby wrote:
> > >
le "public.t3"
Column | Type | Collation | Nullable | Default | Storage | Compression
| Stats target | Description
+-+---+--+-+-+-+------+-
i | integer | | not null | | plain |
| |
Indexes:
"t3_pkey" PRIMARY KEY, btree (i)
Access method: heap
I think this is feasible to avoid. However, it's minor and we exactly
documented how we create new partitions. So, I think it works "as
documented" and we don't have to fix this for v17.
--
Regards,
Alexander Korotkov
Supabase
On Fri, May 3, 2024 at 4:32 PM Alexander Korotkov wrote:
> On Fri, May 3, 2024 at 4:23 PM Justin Pryzby wrote:
> > On Wed, May 01, 2024 at 10:51:24PM +0300, Dmitry Koval wrote:
> > > 30.04.2024 23:15, Justin Pryzby пишет:
> > > > Is this issue already fixed ?
>
to prove there is no bug. Even if there is no bug,
it seems very easy to unintentionally add a bug here. Should we just
accept to always do bms_copy()?
--
Regards,
Alexander Korotkov
Supabase
n invalid pointer. If so, it's
obviously a bug, while it still might be very hard to make this
trigger a segfault.
--
Regards,
Alexander Korotkov
Supabase
om's consent.
Links.
1. https://www.postgresql.org/message-id/3622801.1715010885%40sss.pgh.pa.us
--
Regards,
Alexander Korotkov
Supabase
G as well. If we need to return values for
joined relation, that wouldn't be old values, but values of
snapshot-satisfying tuple which might be even older.
Proper support of this looks like quite amount of work for me.
Committing SJE to v18 with this looks challenging. AFICS, going this
way would require substantial help from you.
--
Regards,
Alexander Korotkov
Supabase
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} synt
bc7-0ef5-6863-c432afac7...@gmail.com
>
> It's possible that once that's addressed, the exclusion should be
> removed here, too.
+1
Links.
1.
https://www.postgresql.org/message-id/edfbd846-dcc1-42d1-ac26-715691b687d3%40postgrespro.ru
--
Regards,
Alexander Korotkov
Supabase
Hi, Tom!
On Fri, May 3, 2024 at 2:19 AM 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
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
>&
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 c
On Wed, May 1, 2024 at 2:00 PM Alexander Lakhin wrote:
> 30.04.2024 13:20, Alexander Korotkov wrote:
> > On Tue, Apr 30, 2024 at 9:00 AM Alexander Lakhin
> > wrote:
> >> I've discovered another failure, introduced by d3d55ce57.
> >> Please try the following:
>
ill be 21% slower w/ checkunique on?
> It's a great improvement vs. current master, but I don't have an obvious
> explanation for the remaining +21%.
I think there is at least extra index tuples comparison.
--
Regards,
Alexander Korotkov
On Tue, Apr 30, 2024 at 7:54 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > Given this, should we try to do better with binary compatibility
> > checks using ControlFileData? AFAICS they are supposed to check if
> > the database cluster is binary compat
e endianness difference.
Given this, should we try to do better with binary compatibility
checks using ControlFileData? AFAICS they are supposed to check if
the database cluster is binary compatible with the running
architecture. But it obviously allows incompatibilities.
--
Regards,
Alexander Korotkov
On Tue, Apr 30, 2024 at 9:00 AM Alexander Lakhin wrote:
> 23.10.2023 12:47, Alexander Korotkov wrote:
> > I think this patch makes substantial improvement to query planning.
> > It has received plenty of reviews. The code is currently in quite
> > good shape. I didn't man
Hi, Alexander!
On Tue, Apr 30, 2024 at 9:00 AM Alexander Lakhin wrote:
> 23.10.2023 12:47, Alexander Korotkov wrote:
> > I think this patch makes substantial improvement to query planning.
> > It has received plenty of reviews. The code is currently in quite
> > good sh
On Sun, Apr 28, 2024 at 2:00 PM Alexander Lakhin wrote:
> 28.04.2024 03:59, Alexander Korotkov wrote:
> > The revised patchset is attached. I'm going to push it if there are
> > no objections.
>
> I have one additional question regarding security, if you don't mind:
>
here.
> > 007 – doc review by Justin [3]
>
> I suggest to drop this patch for now. I'll send some more minor fixes to
> docs and code comments once the other patches are settled.
Your edits are welcome. Dropped this for now. And waiting for the
next revision from you.
Links.
1.
https://www.postgresql.org/message-id/CAPpHfduYuYECrqpHMgcOsNr%2B4j3uJK%2BJPUJ_zDBn-tqjjh3p1Q%40mail.gmail.com
--
Regards,
Alexander Korotkov
Supabase
ss and few reverts!
Many congratulations! Well deserved!
--
Regards,
Alexander Korotkov
On Wed, Apr 17, 2024 at 9:38 AM Peter Eisentraut wrote:
> On 24.10.23 22:13, Alexander Korotkov wrote:
> > On Wed, Sep 28, 2022 at 11:44 AM Aleksander Alekseev
> > wrote:
> >>> I think, this patch was marked as "Waiting on Author", probably, by
> >
ly one tuple for scan key" case
looks like very valuable optimization [1].
I also think we should wrap lVis_* variables into struct. That would
make the way we pass them to functions more elegant.
Links.
1. https://www.postgresql.org/message-id/20240325020323.fd.nmisch%40google.com
--
Regards,
Alexander Korotkov
Hi!
On Thu, Apr 18, 2024 at 1:57 PM Alexander Korotkov wrote:
> Thank you for the fixes you've proposed. I didn't look much into
> details yet, but I think the main concern Tom expressed in [1] is
> whether the feature is reasonable at all. I think at this stage the
> most imp
huge performance benefits it could cause. I will return to this
later today and will try to provide some convincing examples.
Links
1. https://www.postgresql.org/message-id/266850.1712879082%40sss.pgh.pa.us
--
Regards,
Alexander Korotkov
ke
someone to check it before I push.
Links.
1.
https://postgr.es/m/20240408.152402.1485994009160660141.horikyota.ntt%40gmail.com
--
Regards,
Alexander Korotkov
v6-0002-Verify-persistence-of-new-partitions-during-MERGE.patch
Description: Binary data
v6-0004-Grammar-fix-for-tests-of-pa
On Wed, Apr 17, 2024 at 2:37 PM Alexander Korotkov wrote:
> On Tue, Apr 16, 2024 at 7:42 PM Alexander Korotkov
> wrote:
> > On Tue, Apr 16, 2024 at 6:35 PM Andres Freund wrote:
> > > On 2024-04-16 15:45:42 +0300, Alexander Korotkov wrote:
> > > > On Tue, Apr
On Tue, Apr 16, 2024 at 7:42 PM Alexander Korotkov wrote:
>
> On Tue, Apr 16, 2024 at 6:35 PM Andres Freund wrote:
> > On 2024-04-16 15:45:42 +0300, Alexander Korotkov wrote:
> > > On Tue, Apr 16, 2024 at 1:48 AM Andres Freund wrote:
> > > > On 2024-03-06 1
On Tue, Apr 16, 2024 at 6:35 PM Andres Freund wrote:
> On 2024-04-16 15:45:42 +0300, Alexander Korotkov wrote:
> > On Tue, Apr 16, 2024 at 1:48 AM Andres Freund wrote:
> > > On 2024-03-06 14:17:23 +0200, Alexander Korotkov wrote:
> > > > 0001 Turn
On Tue, Apr 16, 2024 at 1:48 AM Andres Freund wrote:
> On 2024-03-06 14:17:23 +0200, Alexander Korotkov wrote:
> > 0001 Turn tail recursion into iteration in CommitTransactionCommand()
> > I did minor revision of comments and code blocks order to improve the
> > readabili
n without any care about
blocks. Possible table_beginscan_analyze() could take an argument of
target number of tuples, then those tuples are just fetches with
table_scan_analyze_next_tuple(). What do you think?
--
Regards,
Alexander Korotkov
On Mon, Apr 15, 2024 at 11:11 PM Andres Freund wrote:
> On 2024-04-12 01:04:03 +0300, Alexander Korotkov wrote:
> > 1) If we just apply my revert patch and leave c6fc50cb4028 and
> > 041b96802ef in the tree, then we get our table AM API narrowed. As
> > you expressed the
eed to
check relpersistence in a similar way ATTACH PARTITION or CREATE TABLE
... PARTITION OF do. I'm going to polish this a little bit more.
--
Regards,
Alexander Korotkov
v6-0001-Fix-for-SPLIT-MERGE-partitions-of-temporary-table.patch
Description: Binary data
Hi, Melanie!
On Fri, Apr 12, 2024 at 8:48 PM Melanie Plageman
wrote:
>
> On Thu, Apr 11, 2024 at 6:04 PM Alexander Korotkov
> wrote:
> >
> > On Fri, Apr 12, 2024 at 12:04 AM Andres Freund wrote:
> > > On 2024-04-11 20:46:02 +0300, Alexander Korotkov w
On Wed, Apr 10, 2024 at 5:27 PM Robert Haas wrote:
>
> On Mon, Apr 8, 2024 at 10:12 PM Tom Lane wrote:
> > I have another one that I'm not terribly happy about:
> >
> > Author: Alexander Korotkov
> > Branch: master [72bd38cc9] 2024-04-08 01:27:52 +
Table "public.tp0"
> ...
> Table "public.tp1"
+1
I think we shouldn't unconditionally copy schema name and
relpersistence from the parent table. Instead we should throw the
error on a mismatch like CREATE TABLE ... PARTITION OF ... does. I'm
working on revising this fix.
--
Regards,
Alexander Korotkov
On Thu, Apr 11, 2024 at 11:27 PM Robert Haas wrote:
> On Thu, Apr 11, 2024 at 1:46 PM Alexander Korotkov
> wrote:
> > I understand that I'm the bad guy of this release, not sure if my
> > opinion counts.
> >
> > But what is going on here? I hope this work is targe
On Fri, Apr 12, 2024 at 12:04 AM Andres Freund wrote:
> On 2024-04-11 20:46:02 +0300, Alexander Korotkov wrote:
> > I hope this work is targeting pg18.
>
> I think anything of the scope discussed by Melanie would be very clearly
> targeting 18. For 17, I don't know yet whethe
going on here? I hope this work is targeting pg18.
Otherwise, do I get this right that this post feature-freeze works on
designing a new API? Yes, 27bc1772fc masked the problem. But it was
committed on Mar 30. So that couldn't justify why the proper API
wasn't designed in time. Are we judging different commits with the
same criteria?
IMHO, 041b96802e should be just reverted.
--
Regards,
Alexander Korotkov
On Thu, Apr 11, 2024 at 8:11 PM Jeff Davis wrote:
> On Wed, 2024-04-10 at 15:19 +0300, Alexander Korotkov wrote:
> > 1) 9bd99f4c26 comprises the reworked patch after working with notes
> > from Jeff Davis. I agree it would be better to wait for him to
> > express explic
Hi, Heikki!
Thank you for your interest in the subject.
On Thu, Apr 11, 2024 at 1:46 AM Heikki Linnakangas wrote:
> On 07/04/2024 00:52, Alexander Korotkov wrote:
> > On Fri, Apr 5, 2024 at 9:15 PM Alvaro Herrera
> > wrote:
> >> I'm still concerned that WaitL
e that v2-0001-Fix-for-SPLIT-MERGE-partitions-of-
> >temporary-table.patch is not complete either.
>
> Added correction (and test), see
> v3-0001-Fix-for-SPLIT-MERGE-partitions-of-temporary-table.patch.
Thank you, I'll review this later today.
--
Regards,
Alexander Korotkov
o store complex data structures in rd_amcache
>
> I am doubtful this is right. Is it really sufficient to have a callback for
> freeing? What happens when relcache entries are swapped as part of a rebuild?
> That works for "flat" caches, but I don't immediately see how it works for
> more complicated datastructures. At least from the commit message it's hard
> to evaluate how this actually intended to be used.
Thank you for your feedback. I've reverted all of above.
--
Regards,
Alexander Korotkov
On Wed, Apr 10, 2024 at 4:19 PM Robert Haas wrote:
>
> On Wed, Apr 10, 2024 at 8:20 AM Alexander Korotkov
> wrote:
> > I agree with the facts. But I have a different interpretation on
> > this. The patch was committed as 11470f544e on March 23, 2023, then
> >
On Mon, Apr 8, 2024 at 9:54 PM Robert Haas wrote:
> On Mon, Apr 8, 2024 at 12:33 PM Alexander Korotkov
> wrote:
> > Yes, it was my mistake. I got rushing trying to fit this to FF, even doing
> > significant changes just before commit.
> > I'll revert this later tod
hnical translation of documentation.
Thank you. I've pushed this fix with minor corrections from me.
--
Regards,
Alexander Korotkov
On Tue, Apr 9, 2024 at 11:42 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Tue, Apr 9, 2024 at 7:27 PM Tom Lane wrote:
> >> Yeah, that's one of the reasons I'm dubious that the committed
> >> patch was ready.
>
> > While inventing this GUC
On Tue, Apr 9, 2024 at 11:37 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Tue, Apr 9, 2024 at 5:12 AM Tom Lane wrote:
> >> * OrClauseGroupKey is not a Node type, so why does it have
> >> a NodeTag? I wonder what value will appear in that field,
> >>
nner development. If you see some way forward to polish this
post-commit, Andrei and I are ready to work hard on this with you. If
you don't see (or don't think that's good), let's revert this.
--
Regards,
Alexander Korotkov
On Tue, Apr 9, 2024 at 8:37 AM Andrei Lepikhov
wrote:
> On 9/4/2024 09:12, Tom Lane wrote:
> > I have another one that I'm not terribly happy about:
> >
> > Author: Alexander Korotkov
> > Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
> >
> &g
indirection. It's not
passed to code that expects real Nodes, it doesn't go to anything
except lists.
Links.
1.
https://www.postgresql.org/message-id/CAPpHfdutHt31sdt2rfU%3D4fsDMWxf6tvtnHARgCzLY2Tf21%2Bfgw%40mail.gmail.com
--
Regards,
Alexander Korotkov
On Tue, Apr 9, 2024 at 8:55 AM Tom Lane wrote:
> Andrei Lepikhov writes:
> > On 9/4/2024 09:12, Tom Lane wrote:
> >> I have another one that I'm not terribly happy about:
> >> Author: Alexander Korotkov
> >> Branch: master [72bd38cc9] 2024-04-08 01:27:52
therwise there is no
warranty to not run into the same problem again.
Links.
1.
https://tiswww.case.edu/php/chet/readline/readline.html#index-rl_005fbasic_005fword_005fbreak_005fcharacters
--
Regards,
Alexander Korotkov
On Mon, Apr 8, 2024 at 9:54 PM Robert Haas wrote:
> On Mon, Apr 8, 2024 at 12:33 PM Alexander Korotkov
> wrote:
> > Yes, it was my mistake. I got rushing trying to fit this to FF, even doing
> > significant changes just before commit.
> > I'll revert this later today.
On Mon, Apr 8, 2024, 19:08 Andres Freund wrote:
> On 2024-04-08 08:37:44 -0700, Andres Freund wrote:
> > On 2024-04-08 11:17:51 +0400, Pavel Borisov wrote:
> > > On Mon, 8 Apr 2024 at 03:25, Alexander Korotkov
> > > > I was under the impression there are
On Mon, Apr 8, 2024 at 10:18 AM Pavel Borisov wrote:
> On Mon, 8 Apr 2024 at 03:25, Alexander Korotkov wrote:
>>
>> Hi,
>>
>> On Mon, Apr 8, 2024 at 12:40 AM Andres Freund wrote:
>> > On 2024-03-30 23:33:04 +0200, Alexander Korotkov wrote:
>> > &
On Mon, Apr 8, 2024 at 2:25 AM Alexander Korotkov wrote:
> On Mon, Apr 8, 2024 at 12:40 AM Andres Freund wrote:
> > On 2024-03-30 23:33:04 +0200, Alexander Korotkov wrote:
> > > I've pushed 0001, 0002 and 0006.
> >
> > I briefly looked at 27bc1772fc81 an
Hi,
On Mon, Apr 8, 2024 at 12:40 AM Andres Freund wrote:
> On 2024-03-30 23:33:04 +0200, Alexander Korotkov wrote:
> > I've pushed 0001, 0002 and 0006.
>
> I briefly looked at 27bc1772fc81 and I don't think the state post this commit
> makes sense. Before this commit another bl
Hi!
On Mon, Apr 1, 2024 at 9:38 AM Andrei Lepikhov
wrote:
> On 28/3/2024 16:54, Alexander Korotkov wrote:
> > The current patch has a boolean guc enable_or_transformation.
> > However, when we have just a few ORs to be transformated, then we
> > should get less
Hi, Alexander!
On Sun, Apr 7, 2024 at 10:00 PM Alexander Lakhin wrote:
> 07.04.2024 01:22, Alexander Korotkov wrote:
> > I've pushed 0001 and 0002. I didn't push 0003 for the following reasons.
>
> Please try the following (erroneous) query:
> CREATE TABLE t1(i int, t text) PA
Hi, Pavel!
On Fri, Apr 5, 2024 at 6:58 PM Pavel Borisov wrote:
> On Tue, 2 Apr 2024 at 19:17, Jeff Davis wrote:
>>
>> On Tue, 2024-04-02 at 11:49 +0300, Alexander Korotkov wrote:
>> > I don't like the idea that every custom table AM reltoptions should
>> >
nk both aspects need to be carefully considered. Even if we
accept them, this needs to be documented. I think now it's too late
for both of these. So, this should wait for v18.
--
Regards,
Alexander Korotkov
t if a process throws an error while waiting, it'll
> not get cleaned up until it exits? Maybe this is not a big deal, but it
> seems odd.
I've added WaitLSNCleanup() to the AbortTransaction(). Just pushed
that together with the improvements upthread.
--
Regards,
Alexander Korotkov
On Wed, Apr 3, 2024 at 10:04 PM Pavel Borisov wrote:
> On Wed, 3 Apr 2024 at 22:18, Alexander Korotkov wrote:
>>
>> On Wed, Apr 3, 2024 at 7:55 PM Alvaro Herrera
>> wrote:
>> >
>> > On 2024-Apr-03, Alexander Korotkov wrote:
>> >
>> >
On Wed, Apr 3, 2024 at 7:55 PM Alvaro Herrera wrote:
>
> On 2024-Apr-03, Alexander Korotkov wrote:
>
> > Regarding the shmem data structure for LSN waiters. I didn't pick
> > LWLock or ConditionVariable, because I needed the ability to wake up
> > only those waiters wh
s not
hard to use for shmem structures. The only memory allocation call in
paritingheap.c is in pairingheap_allocate(). So, it's only needed to
be able to initialize the pairing heap in-place, and it will be fine
for shmem.
I'll come back with switching to the pairing heap shortly.
--
Regards,
Alexander Korotkov
do something to achieve
this at an application level. However, they typically don't know what
exactly they need.
So, blogging about pg_wal_replay_wait() and spreading words about it
at conferences would be highly appreciated.
--
Regards,
Alexander Korotkov
also like to note that pg_wal_replay_wait() comes with a dedicated
wait event. So, one could monitor the average duration of these waits
using sampling of wait events.
--
Regards,
Alexander Korotkov
Hi, Jeff!
On Tue, Apr 2, 2024 at 8:19 AM Jeff Davis wrote:
> On Sat, 2024-03-30 at 23:33 +0200, Alexander Korotkov wrote:
> > I've pushed 0001, 0002 and 0006.
>
> Sorry to jump in to this discussion so late. I had worked on something
> like the custom reloptions
waits for for minitor purpose.
Please, check it more carefully. In v17 timeout is in integer milliseconds.
--
Regards,
Alexander Korotkov
that relation->rd_rel isn't the full copy of pg_class tuple
(see AllocateRelationDesc). RelationParseRelOptions() is going to
update relation->rd_options, and thus needs a full pg_class tuple to
fetch options out of it. However, it is really unnecessary to access
both tuples at the
volve two copies of allegedly the same pg_class tuple, anyhow?
Thank you for reporting this, Tom.
I'm planning to investigate this later today.
--
Regards,
Alexander Korotkov
On Mon, Apr 1, 2024 at 5:25 AM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Mon, Apr 1, 2024 at 5:54 AM Alexander Korotkov
> wrote:
> >
> > > 9. To me the following query blocks even though I didn't mention
> timeout.
> >
Hi Bharath,
Thank you for your feedback.
On Sun, Mar 31, 2024 at 8:44 AM Bharath Rupireddy
wrote:
> On Sun, Mar 31, 2024 at 7:41 AM Alexander Korotkov
> wrote:
> Thanks for the patch. I have a few comments on the v16 patch.
>
> 1. Is there any specific reason for pg_wal_repl
with test).
In the test I change recovery_min_apply_delay to 1s in order to make
the test pass faster.
--
Regards,
Alexander Korotkov
v16-0001-Implement-pg_wal_replay_wait-stored-procedure.patch
Description: Binary data
InsertWithArbiterContext which would contain EState and a
set of callbacks which would avoid table AM from calling the executor
directly. That should be our goal for pg18. Now, this is too close
to FF to design a new API.
--
Regards,
Alexander Korotkov
On Fri, Mar 29, 2024 at 6:50 PM Euler Taveira wrote:
> On Fri, Mar 29, 2024, at 9:44 AM, Alexander Korotkov wrote:
>
> This generally makes sense, but I'm not sure about this. The
> milliseconds timeout was used initially but received critics in [1].
>
>
> Alexander,
Hi, Euler!
On Fri, Mar 29, 2024 at 1:38 AM Euler Taveira wrote:
> On Thu, Mar 28, 2024, at 9:39 AM, Alexander Korotkov wrote:
>
> Fixed along with other issues spotted by Alexander Lakhin.
>
>
> [I didn't read the whole thread. I'm sorry if I missed something ...]
>
>
On Fri, Mar 22, 2024 at 3:45 PM Kartyshov Ivan
wrote:
> 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,
On Tue, Mar 19, 2024 at 7:17 AM Andrei Lepikhov
wrote:
> On 14/3/2024 16:31, Alexander Korotkov wrote:
> > On Wed, Mar 13, 2024 at 2:16 PM Andrei Lepikhov
> > As you can see this case is not related to partial indexes. Just no
> > index selective for the whole query. Ho
ch, thank you.
Fixed along with other issues spotted by Alexander Lakhin.
--
Regards,
Alexander Korotkov
v13-0001-Implement-pg_wait_for_wal_replay_lsn-stored-proc.patch
Description: Binary data
On Thu, Mar 28, 2024 at 2:24 AM Alexander Korotkov wrote:
> On Tue, Mar 26, 2024 at 4:06 PM Kartyshov Ivan
> wrote:
> > Thank you for your interest to the patch.
> > I understand you questions, but I fully support Alexander Korotkov idea
> > to commit the minima
On Tue, Mar 26, 2024 at 4:06 PM Kartyshov Ivan
wrote:
> Thank you for your interest to the patch.
> I understand you questions, but I fully support Alexander Korotkov idea
> to commit the minimal required functionality. And then keep working on
> other improvements.
I did further
1.
https://www.postgresql.org/message-id/CAPpHfdtny81end69PzEdRsROKnsybsj%3DOs8DUM-6HeKGKnCuQQ%40mail.gmail.com
--
Regards,
Alexander Korotkov
On Fri, Mar 22, 2024 at 12:58 AM Peter Eisentraut wrote:
> On 17.03.24 15:09, Alexander Korotkov wrote:
> > My current attempt was to commit minimal implementation as less
> > invasive as possible. A new clause for BEGIN doesn't require
> > additional keywords and doesn't
eger number of milliseconds looks
a bit weird. Could the float8 number of seconds be an option?
--
Regards,
Alexander Korotkov
t this kind of
task. However, having this functionality in core would be great.
Implementing concurrent merge/split seems quite a difficult task,
which needs careful design. It might be too hard to carry around the
syntax altogether. So, I think having basic syntax in-core is a good
step forward. But I think we need a clear notice in the documentation
about the concurrency to avoid wrong user expectations.
--
Regards,
Alexander Korotkov
On Mon, Mar 25, 2024 at 4:47 AM Richard Guo wrote:
> On Mon, Mar 25, 2024 at 10:07 AM Tom Lane wrote:
>>
>> Alexander Korotkov writes:
>> > Here goes the revised patch. I'm going to push this if there are no
>> > objections.
>>
>> Quit
On Tue, Mar 19, 2024 at 5:20 PM Alexander Korotkov wrote:
> On Tue, Nov 28, 2023 at 11:00 AM Pavel Borisov wrote:
> > > You're designing new APIs, days before the feature freeze.
> > On Wed, 5 Apr 2023 at 06:54, Michael Paquier wrote:
> > >
> > > On T
On Wed, Mar 20, 2024 at 7:19 PM Alexander Korotkov wrote:
> On Mon, Mar 11, 2024 at 3:44 PM Maxim Orlov wrote:
> > On Tue, 6 Feb 2024 at 09:22, Michael Paquier wrote:
> >> The problem may be actually trickier than that, no? Could there be
> >> other f
committed soon.
Pushed.
Thanks to Maxim and Pavel.
--
Regards,
Alexander Korotkov
1 - 100 of 1172 matches
Mail list logo
