On Tue, 11 Jun 2024 at 09:41, Amul Sul wrote:
>
> On Mon, Jun 10, 2024 at 5:00 PM vignesh C wrote:
>>
>> On Mon, 10 Jun 2024 at 12:24, Amul Sul wrote:
>> >
>> >
>> >
>> > On Sat, Jun 8, 2024 at 6:43 PM vignesh C wrote:
>> >>
>> >> On Wed, 5 Jun 2024 at 14:11, Amit Kapila wrote:
>> >> [...]
>>
Hi,
I was looking around for an exotic index type to try the experience of
streamifying an extension, ie out-of-core code. I am totally new to
pgvector, but since everyone keeps talking about it, I could not avoid
picking up some basic facts in the pgconf.dev hallway track, and
understood that
Jeff Davis writes:
> I agree it makes things easier for a caller following that pattern,
> because it doesn't need to recalculate the timeout each time through
> the loop.
> But:
> 1. If your clock goes backwards, you can end up waiting for an
> arbitrarily long time. To prevent that you need
On Mon, Jun 10, 2024 at 07:19:27PM -0700, Noah Misch wrote:
> On Fri, Jun 07, 2024 at 09:08:03AM -0400, Robert Haas wrote:
>> I think the core code should provide an "Injection Point" wait event
>> type and let extensions add specific wait events there, just like you
>> did for "Extension".
>
>
On Mon, 2024-06-10 at 19:57 -0400, Tom Lane wrote:
> Because a common call pattern is to loop around PQsocketPoll calls.
> In that scenario you generally want to nail down the timeout time
> before starting the loop, not have it silently move forward after
> any random event that breaks the
On Mon, Jun 10, 2024 at 5:00 PM vignesh C wrote:
> On Mon, 10 Jun 2024 at 12:24, Amul Sul wrote:
> >
> >
> >
> > On Sat, Jun 8, 2024 at 6:43 PM vignesh C wrote:
> >>
> >> On Wed, 5 Jun 2024 at 14:11, Amit Kapila
> wrote:
> >> [...]
> >> A new catalog table, pg_subscription_seq, has been
Getting the same issue at my end, the error message is "The URL you
specified does not exist.".
On Tue, Jun 11, 2024 at 12:33 AM Mark Hill wrote:
> Is there an issue with the ODBC Source downloads today?
>
> The source download URL isn’t working:
>
On Mon, 10 Jun 2024 at 14:48, Amit Kapila wrote:
>
> On Mon, Jun 10, 2024 at 12:43 PM Masahiko Sawada
> wrote:
> >
> > On Mon, Jun 10, 2024 at 3:14 PM Masahiko Sawada
> > wrote:
> > >
> > > On Fri, Jun 7, 2024 at 7:30 PM Amit Kapila
> > > wrote:
> > > >
> > > >
> > > > Are you imagining the
Hi,
I was reading the walsender.c fileheader comment while studying
another thread. I think if there is logical replication in progress
then the PROCSIG_WALSND_INIT_STOPPING handler will *always* switch to
a "stopping" state: e.g.,
/*
* Handle PROCSIG_WALSND_INIT_STOPPING signal.
*/
void
On Mon, Jun 10, 2024 at 03:51:05PM -0700, John H wrote:
> The existing 'standby_slot_names' isn't great for users who are running
> clusters with quorum-based synchronous replicas. For instance, if
> the user has synchronous_standby_names = 'ANY 3 (A,B,C,D,E)' it's a
> bit tedious to have to
On Fri, Jun 07, 2024 at 09:08:03AM -0400, Robert Haas wrote:
> On Thu, Jun 6, 2024 at 7:20 PM Michael Paquier wrote:
> > On Thu, Jun 06, 2024 at 09:48:51AM -0400, Robert Haas wrote:
> > > It's not this patch set's fault, but I'm not very pleased to see that
> > > the injection point wait events
On Tue, May 28, 2024 at 4:16 PM Peter Smith wrote:
>
...
>
> The new GUC quoting patches are separated by different GUC types only
> to simplify my processing of them.
>
> v7-0001 = Add quotes for GUCs - bool
> v7-0002 = Add quotes for GUCs - int
> v7-0003 = Add quotes for GUCs - real
> v7-0004 =
On Fri, Jun 07, 2024 at 11:10:25AM +0200, Matthias van de Meent wrote:
> My primary concern isn't the IO, but the O(shared_buffers) that we
> have to go through during a checkpoint. As I mentioned upthread, it is
> reasonably possible the new cluster is already setup with a good
> fraction of the
On Tue, May 28, 2024 at 5:29 PM Markus Winand wrote:
>
> Hi!
>
> I’ve noticed two “surprising” (to me) behaviors related to
> the “ON ERROR” clause of the new JSON query functions in 17beta1.
>
> 1. JSON parsing errors are not subject to ON ERROR
>Apparently, the functions expect JSONB so
Hi,
On 2024-06-10 16:46:56 -0400, Andrew Dunstan wrote:
>
> On 2024-06-10 Mo 16:04, Andres Freund wrote:
> > Hi,
> >
> >
> > Just for context for the rest the email: I think we desperately need to move
> > off perl for tests. The infrastructure around our testing is basically
> > unmaintained
On Mon, Jun 10, 2024 at 06:03:40PM +0800, cca5507 wrote:
> Thank you for reply!
No objections here, either.
> I have new a patch in commitfest:Format the code in xact_decode
> (postgresql.org)
Thanks for tracking that. For reference:
https://commitfest.postgresql.org/48/5028/
--
Michael
On Thu, Jun 06, 2024 at 03:19:20PM +0900, Kyotaro Horiguchi wrote:
> During server shutdown, the latter half of the last continuation
> record may fail to be flushed. This is similar to what is described in
> the commit message of commit ff9f111bce. While shutting down,
> WalSndLoop() waits for
Jeff Davis writes:
> I briefly skimmed the thread and didn't find the reason why the API
> requires an absolute time.
Because a common call pattern is to loop around PQsocketPoll calls.
In that scenario you generally want to nail down the timeout time
before starting the loop, not have it
On Mon, 2024-06-10 at 17:39 -0400, Tom Lane wrote:
> What I suggest is that we use int64 microseconds
> since the epoch, which is the same idea as the backend's TimestampTz
> except I think we'd better use the Unix epoch not 2000-01-01.
> Then converting code is just a matter of changing variable
On Sun, Jun 09, 2024 at 10:12:53PM -0400, Tom Lane wrote:
> No doubt. People have done it both ways in the past, but I think
> currently there's a weak consensus in favor of using one line for
> such messages even when it runs past 80 columns, mainly because
> that makes it easier to grep the
Hi hackers,
Building on bf279ddd1c, this patch introduces a GUC
'standby_slot_names_from_syncrep' which allows logical failover slots
to wait for changes to have been synchronously replicated before sending
the decoded changes to logical subscribers.
The existing 'standby_slot_names' isn't great
On Mon, Jun 10, 2024 at 11:36 AM Nathan Bossart
wrote:
> Hm. Should we measure the actual time spent sleeping, or is a rough
> estimate good enough? I believe pg_usleep() might return early (e.g., if
> the process is signaled) or late, so this field could end up being
> inaccurate, although
On Mon, 10 Jun 2024 at 22:47, Andrew Dunstan wrote:
> As for what up and coming developers learn, they mostly don't learn C either,
> and that's far more critical to what we do.
I think many up and coming devs have at least touched C somewhere
(e.g. in university). And because it's more
On Mon, 10 Jun 2024 at 20:46, Jacob Champion
wrote:
> For the v18 cycle, I would like to try to get pytest [1] in as a
> supported test driver, in addition to the current offerings.
Huge +1 from me (but I'm definitely biased here)
> Thoughts? Suggestions?
I think the most important thing is
In [1] Dominique Devienne complained that PQsocketPoll would be
far more useful to him if it had better-than-one-second timeout
resolution. I initially pushed back on that on the grounds that
post-beta1 is a bit late to be redefining public APIs. Which it is,
but if we don't fix it now then
On 2024-06-10 Mo 16:04, Andres Freund wrote:
Hi,
Just for context for the rest the email: I think we desperately need to move
off perl for tests. The infrastructure around our testing is basically
unmaintained and just about nobody that started doing dev stuff in the last 10
years learned
>> This sounds like useful information to me.
> Thanks for looking at it!
The VacuumDelay is the only visibility available to
gauge the cost_delay. Having this information
advertised by pg_stat_progress_vacuum as is being proposed
is much better. However, I also think that the
"number of times"
Hi,
Just for context for the rest the email: I think we desperately need to move
off perl for tests. The infrastructure around our testing is basically
unmaintained and just about nobody that started doing dev stuff in the last 10
years learned perl.
On 2024-06-10 11:46:00 -0700, Jacob
Hi,
On 2024-06-10 15:05:32 -0400, David E. Wheeler wrote:
> > An API break in PostgreSQL 10.4 and 9.6.9 makes it impossible
> > to use these versions: the "extract_actual_join_clauses" function
> > gained an additional parameter.
>
> The 10.4 commit is 68fab04, and it does indeed add a new
On Mon, Jun 10, 2024 at 6:21 PM Tom Lane wrote:
> Magnus Hagander writes:
> > On Mon, Jun 10, 2024 at 5:03 PM Nathan Bossart >
> > wrote:
> >> Is there a particular advantage to that approach as opposed to just
> using
> >> "directory" mode for everything?
>
> > A gazillion files to deal with?
Is there an issue with the ODBC Source downloads today?
The source download URL isn't working:
https://www.postgresql.org/ftp/odbc/versions/src/
Thanks, Mark
On 10.06.2024 09:25, Kyotaro Horiguchi wrote:
I guess that in English, when written as "'Login' = 'yes/no'", it can
be easily understood. However, in Japanese, "'ログイン' = 'はい/いいえ'"
looks somewhat awkward and is a bit difficult to understand at a
glance. "'ログイン' = '可/不可'" (equivalent to "Login is
Hi!
On Mon, Jun 10, 2024 at 9:46 PM Jacob Champion
wrote:
> Thoughts? Suggestions?
Thank you for working on this.
Do you think you could re-use something from testgres[1] package?
Links.
1. https://github.com/postgrespro/testgres
--
Regards,
Alexander Korotkov
Supabase
On Mon, Jun 10, 2024 at 05:48:22PM +, Bertrand Drouvot wrote:
> On Mon, Jun 10, 2024 at 10:36:42AM -0500, Nathan Bossart wrote:
>> I wonder if we should also
>> surface the effective cost limit for each autovacuum worker.
>
> I'm not sure about it as I think that it could be misleading: one
On Jun 4, 2024, at 03:18, Peter Eisentraut wrote:
> This could possibly be avoided by renaming the symbol in backbranches. Maybe
> something like
>
> #define InitResultRelInfo InitResultRelInfo2
>
> Then you'd get a specific error message when loading the module, rather than
> a crash.
That
Hi all,
For the v18 cycle, I would like to try to get pytest [1] in as a
supported test driver, in addition to the current offerings.
(I'm tempted to end the email there.)
We had an unconference session at PGConf.dev [2] around this topic.
There seemed to be a number of nodding heads and some
Hi,
On 2024-06-09 21:57:54 -0400, Tom Lane wrote:
> BTW, while I approve of trying to get rid of our need for -fwrapv,
> I'm quite scared of actually doing it.
I think that's a quite fair concern. One potentially relevant datapoint is
that we actually don't have -fwrapv equivalent on all
Hi,
To investigate a report of both postgres and pgbouncer having issues when a
lot of new connections aree established, I used pgbench -C. Oddly, on an
early attempt, the bottleneck wasn't postgres+pgbouncer, it was pgbench. But
only when using TCP, not with unix sockets.
c=40;pgbench -C -n
Hi,
On Mon, Jun 10, 2024 at 10:36:42AM -0500, Nathan Bossart wrote:
> On Mon, Jun 10, 2024 at 06:05:13AM +, Bertrand Drouvot wrote:
> > During the last pgconf.dev I attended Robert´s presentation about
> > autovacuum and
> > it made me remember of an idea I had some time ago: $SUBJECT
>
>
On 2024-06-10 Mo 12:21, Tom Lane wrote:
Magnus Hagander writes:
On Mon, Jun 10, 2024 at 5:03 PM Nathan Bossart
wrote:
Is there a particular advantage to that approach as opposed to just using
"directory" mode for everything?
A gazillion files to deal with? Much easier to work with
On Sat, 2024-06-08 at 17:36 -0400, Joseph Koshakow wrote:
> I see that this patch is marked as ready for review, so I thought I
> would attempt to review it. This is my first review, so please take it
> with a grain of salt.
Thank you. Your review is valuable and much to the point.
>
> It
Magnus Hagander writes:
> On Mon, Jun 10, 2024 at 5:03 PM Nathan Bossart
> wrote:
>> Is there a particular advantage to that approach as opposed to just using
>> "directory" mode for everything?
> A gazillion files to deal with? Much easier to work with individual custom
> files if you're
On Mon, Jun 10, 2024 at 05:45:19PM +0200, Magnus Hagander wrote:
> On Mon, Jun 10, 2024 at 5:03 PM Nathan Bossart
> wrote:
>> Is there a particular advantage to that approach as opposed to just using
>> "directory" mode for everything? I know pg_upgrade uses "custom" mode for
>> each of the
Ilia Evdokimov writes:
> I have identified a potential memory leak in the
> `addRangeTableEntryForJoin()` function. The second parameter of
> `addRangeTableEntryForJoin()`, `colnames`, is a `List*` that is
> concatenated with another `List*`, `eref->colnames`, using
> `list_concat()`. We need
On Mon, Jun 10, 2024 at 5:03 PM Nathan Bossart
wrote:
> On Mon, Jun 10, 2024 at 04:52:06PM +0200, Magnus Hagander wrote:
> > On Mon, Jun 10, 2024 at 4:14 PM Nathan Bossart >
> > wrote:
> >> I'm curious why we couldn't also support the "custom" format.
> >
> > Or maybe even a combo - a directory
On Mon, Jun 10, 2024 at 06:05:13AM +, Bertrand Drouvot wrote:
> During the last pgconf.dev I attended Robert´s presentation about autovacuum
> and
> it made me remember of an idea I had some time ago: $SUBJECT
This sounds like useful information to me. I wonder if we should also
surface the
On Mon, Jun 10, 2024 at 04:52:06PM +0200, Magnus Hagander wrote:
> On Mon, Jun 10, 2024 at 4:14 PM Nathan Bossart
> wrote:
>> I'm curious why we couldn't also support the "custom" format.
>
> Or maybe even a combo - a directory of custom format files? Plus that one
> special file being globals?
On Mon, Jun 10, 2024 at 10:51:42AM -0400, Andrew Dunstan wrote:
> On 2024-06-10 Mo 10:14, Nathan Bossart wrote:
>> I'm curious why we couldn't also support the "custom" format.
>
> We could, but the housekeeping would be a bit harder. We'd need to keep
> pointers to the offsets of the
On Mon, Jun 10, 2024 at 4:14 PM Nathan Bossart
wrote:
> On Mon, Jun 10, 2024 at 08:58:49AM -0400, Andrew Dunstan wrote:
> > Tom and Nathan opined recently that providing for non-text mode for
> > pg_dumpall would be a Good Thing (TM). Not having it has been a
> > long-standing complaint, so I've
On 2024-06-10 Mo 10:14, Nathan Bossart wrote:
On Mon, Jun 10, 2024 at 08:58:49AM -0400, Andrew Dunstan wrote:
Tom and Nathan opined recently that providing for non-text mode for
pg_dumpall would be a Good Thing (TM). Not having it has been a
long-standing complaint, so I've decided to give it
On Sat, 8 Jun 2024 at 19:39, Ayush Vatsa wrote:
>
> > Attached is a patch for the --filter docs, covering the omissions I can see.
> Thanks Dean for working on this.
> I have reviewed the changes and they look good to me.
>
Thanks for checking. I have committed this now.
Regards,
Dean
On Mon, Jun 10, 2024 at 08:58:49AM -0400, Andrew Dunstan wrote:
> Tom and Nathan opined recently that providing for non-text mode for
> pg_dumpall would be a Good Thing (TM). Not having it has been a
> long-standing complaint, so I've decided to give it a go.
Thank you!
> I think we would need
Thank you for reply!I am trying to fix it. This patch (pass check-world) will
track txns
committed in BUILDING_SNAPSHOT state and can fix this bug.
--
Regards,
ChangAo Chen
v1-0001-Track-transactions-committed-in-BUILDING_SNAPSHOT.patch
Description: Binary data
Em seg., 10 de jun. de 2024 às 10:45, Ilia Evdokimov <
ilya.evdoki...@tantorlabs.com> escreveu:
> >Now you need to analyze whether the memory in question is not managed
> by a Context
> I've already analyzed. Let's explain details:
>
>
> 1. analyze.c
> 1718: List* targetnames;
> 1815:
On Mon, 10 Jun 2024 at 15:10, Shlok Kyal wrote:
>
> On Thu, 6 Jun 2024 at 11:49, Kyotaro Horiguchi
> wrote:
> >
> > At Thu, 6 Jun 2024 12:49:45 +1000, Peter Smith
> > wrote in
> > > Hi, I have reproduced this multiple times now.
> > >
> > > I confirmed the initial post/steps from Alexander.
On Mon, 10 Jun 2024 at 16:38, Amit Kapila wrote:
>
> On Tue, Feb 20, 2024 at 12:35 PM vignesh C wrote:
> >
> > On Sat, 17 Feb 2024 at 12:03, Amit Kapila wrote:
> > >
> > >
> > > @@ -1839,7 +1839,8 @@ LogicalConfirmReceivedLocation(XLogRecPtr lsn)
> > >
> > > SpinLockAcquire(>mutex);
> > >
> >
>Now you need to analyze whether the memory in question is not managed
by a Context
I've already analyzed. Let's explain details:
1. analyze.c
1718: List* targetnames;
1815: targetnames = NIL;
1848: targetnames = lappend(targetnames, makeString(colName));
1871: addRangeTableEntryForJoin(...);
On Mon, Jun 10, 2024 at 3:09 AM Ashutosh Bapat
wrote:
> This is just one instance of measurements. If I run the experiment multiple
> times the results and the patterns will vary. Usually I have found planning
> time to vary within 5% for regular tables and within 9% for partitioned
> tables
>
>
> FWIW, it can be useful to configure the OS with strict memory overcommit.
> That
> causes postgres to fail more gracefully, because the OOM killer won't be
> invoked.
>
In the current setup the database is used as an embedded db, with the
application sharing the same host as the database.
Tom and Nathan opined recently that providing for non-text mode for
pg_dumpall would be a Good Thing (TM). Not having it has been a
long-standing complaint, so I've decided to give it a go.
I think we would need to restrict it to directory mode, at least to
begin with. I would have a
On Mon, 10 Jun 2024 at 16:39, Amit Kapila wrote:
>
> On Tue, Feb 20, 2024 at 12:35 PM vignesh C wrote:
> >
> > On Sat, 17 Feb 2024 at 12:03, Amit Kapila wrote:
> > >
> > >
> > > @@ -1839,7 +1839,8 @@ LogicalConfirmReceivedLocation(XLogRecPtr lsn)
> > >
> > > SpinLockAcquire(>mutex);
> > >
> >
On Wed, Jun 5, 2024 at 5:34 AM David Rowley wrote:
>
> On Sun, 2 Jun 2024 at 10:08, James Coleman wrote:
> > See attached for a small patch fixing some typos and grammatical
> > errors in a couple of comments.
>
> Thanks. I pushed this after messing with the comments a bit more.
Thanks!
> >
Em seg., 10 de jun. de 2024 às 09:11, Ilia Evdokimov <
ilya.evdoki...@tantorlabs.com> escreveu:
> >But callers of addRangeTableEntryForJoin(), expects to handle a list
> or NIL, if we free the memory
> I've thoroughly reviewed all callers of the
> `addRangeTableEntryForJoin()` function and
>But callers of addRangeTableEntryForJoin(), expects to handle a list
or NIL, if we free the memory
I've thoroughly reviewed all callers of the
`addRangeTableEntryForJoin()` function and confirmed that the list is
not used after this function is called. Since
`addRangeTableEntryForJoin()` is
On 6/10/24 12:56, shveta malik wrote:
> On Fri, Jun 7, 2024 at 6:08 PM Tomas Vondra
> wrote:
>>
>
> UPDATE
>
>
> Conflict Detection Method:
>
> Origin conflict detection: The ‘origin’ info is used to detect
>
Em seg., 10 de jun. de 2024 às 07:35, Ilia Evdokimov <
ilya.evdoki...@tantorlabs.com> escreveu:
> Hi Hackers
>
> I have identified a potential memory leak in the
> `addRangeTableEntryForJoin()` function. The second parameter of
> `addRangeTableEntryForJoin()`, `colnames`, is a `List*` that is
>
On 6/10/24 10:54, Amit Kapila wrote:
> On Fri, Jun 7, 2024 at 6:08 PM Tomas Vondra
> wrote:
>>
>> On 5/27/24 07:48, shveta malik wrote:
>>> On Sat, May 25, 2024 at 2:39 AM Tomas Vondra
>>> wrote:
Which architecture are you aiming for? Here you talk about multiple
providers, but
On Mon, 10 Jun 2024 at 12:24, Amul Sul wrote:
>
>
>
> On Sat, Jun 8, 2024 at 6:43 PM vignesh C wrote:
>>
>> On Wed, 5 Jun 2024 at 14:11, Amit Kapila wrote:
>> [...]
>> A new catalog table, pg_subscription_seq, has been introduced for
>> mapping subscriptions to sequences. Additionally, the
On Tue, Feb 20, 2024 at 12:35 PM vignesh C wrote:
>
> On Sat, 17 Feb 2024 at 12:03, Amit Kapila wrote:
> >
> >
> > @@ -1839,7 +1839,8 @@ LogicalConfirmReceivedLocation(XLogRecPtr lsn)
> >
> > SpinLockAcquire(>mutex);
> >
> > - MyReplicationSlot->data.confirmed_flush = lsn;
> > + if (lsn >
On Fri, Jun 7, 2024 at 6:10 PM Tomas Vondra
wrote:
>
> >>> I don't understand the why should update_missing or update_deleted be
> >>> different, especially considering it's not detected reliably. And also
> >>> that even if we happen to find the row the associated TOAST data may
> >>> have
On Fri, Jun 7, 2024 at 6:08 PM Tomas Vondra
wrote:
>
> >>>
> >>> UPDATE
> >>>
> >>>
> >>> Conflict Detection Method:
> >>>
> >>> Origin conflict detection: The ‘origin’ info is used to detect
> >>> conflict which can be obtained from
Hi Hackers
I have identified a potential memory leak in the
`addRangeTableEntryForJoin()` function. The second parameter of
`addRangeTableEntryForJoin()`, `colnames`, is a `List*` that is
concatenated with another `List*`, `eref->colnames`, using
`list_concat()`. We need to pass only the
> On 7 Jun 2024, at 19:14, Jacob Champion
> wrote:
> - Could you separate the two features into two patches? That would
> make it easier for reviewers. (They can still share the same thread
> and CF entry.)
+1, please do.
> - The "curve" APIs have been renamed "group" in newer OpenSSLs for a
Thank you for reply! I have new a patch in commitfest:Format the code in
xact_decode (postgresql.org)
--
Regards,
ChangAo Chen
On Thu, 6 Jun 2024 at 11:49, Kyotaro Horiguchi wrote:
>
> At Thu, 6 Jun 2024 12:49:45 +1000, Peter Smith wrote
> in
> > Hi, I have reproduced this multiple times now.
> >
> > I confirmed the initial post/steps from Alexander. i.e. The test
> > script provided [1] gets itself into a state where
On Fri, 2024-06-07 at 16:30 +, Srirama Kucherlapati wrote:
> Hi Team, We are pursuing to trim the changes wrt AIX. As of now we trimmed
> the changes with respect to XLC and currently with trimmed changes the
> buildfarm script passed (build and all the regression tests)
> The XLC changes were
Changes make the code in case XLOG_XACT_INVALIDATIONS block syntactically
consistent with the other block. LGTM.
On Sun, Jun 9, 2024 at 6:57 PM cca5507 wrote:
> Hello hackers, just as the title says:
> 1. Remove redundant parentheses.
> 2. Adjust the position of the break statement.
> --
>
On Mon, Jun 10, 2024 at 12:43 PM Masahiko Sawada wrote:
>
> On Mon, Jun 10, 2024 at 3:14 PM Masahiko Sawada wrote:
> >
> > On Fri, Jun 7, 2024 at 7:30 PM Amit Kapila wrote:
> > >
> > >
> > > Are you imagining the behavior for sequences associated with tables
> > > differently than the ones
On Wed, Jun 5, 2024 at 5:42 PM Richard Guo wrote:
> Hence here is the v7 patchset. I've also added detailed commit messages
> for the two patches.
This patchset does not apply any more. Here is a new rebase.
While at it, I added more checks for 'root->group_rtindex', and also
added a new test
On Fri, Jun 7, 2024 at 6:08 PM Tomas Vondra
wrote:
>
> On 5/27/24 07:48, shveta malik wrote:
> > On Sat, May 25, 2024 at 2:39 AM Tomas Vondra
> > wrote:
> >>
> >> Which architecture are you aiming for? Here you talk about multiple
> >> providers, but the wiki page mentions active-active. I'm not
Hi,
On Fri, Jun 07, 2024 at 09:24:41AM -0400, Robert Haas wrote:
> On Thu, Jun 6, 2024 at 11:17 PM Andres Freund wrote:
> > If we just want to keep prior stats upon arelation rewrite, we can just copy
> > the stats from the old relfilenode. Or we can decide that those stats don't
> > really
On Mon, Jun 10, 2024 at 07:19:56AM +, Bertrand Drouvot wrote:
> On Tue, Mar 19, 2024 at 06:48:33AM +, Li, Yong wrote:
>> Unfortunately, the test requires a setup of two different versions of PG. I
>> am not
>> aware of an existing test infrastructure which can run automated tests using
On Sun, Jun 09, 2024 at 11:21:52PM +0800, cca5507 wrote:
> Hello hackers, I found that wecurrently don't track txns committed in
> BUILDING_SNAPSHOT state because of the code in xact_decode():
> /*
>* If the snapshot isn't yet fully built, we cannot decode anything, so
>*
On Sat, Jun 8, 2024 at 6:43 PM vignesh C wrote:
> On Wed, 5 Jun 2024 at 14:11, Amit Kapila wrote:
> [...]
> A new catalog table, pg_subscription_seq, has been introduced for
> mapping subscriptions to sequences. Additionally, the sequence LSN
> (Log Sequence Number) is stored, facilitating
Hello hackers, I found that wecurrently don't track txns committed in
BUILDING_SNAPSHOT state because of the code in xact_decode():
/*
* If the snapshot isn't yet fully built, we cannot decode anything, so
* bail out.
*/
if (SnapBuildCurrentState(builder)
Hi,
On Tue, Mar 19, 2024 at 06:48:33AM +, Li, Yong wrote:
>
> Unfortunately, the test requires a setup of two different versions of PG. I
> am not
> aware of an existing test infrastructure which can run automated tests using
> two
> PGs. I did manually verify the output of pg_upgrade.
I
On Mon, Jun 10, 2024 at 3:14 PM Masahiko Sawada wrote:
>
> On Fri, Jun 7, 2024 at 7:30 PM Amit Kapila wrote:
> >
> > On Fri, Jun 7, 2024 at 7:55 AM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Jun 6, 2024 at 6:40 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Thu, Jun 6, 2024 at 11:10 AM
Hi,
On Mon, Jun 10, 2024 at 03:39:34PM +0900, Michael Paquier wrote:
> On Mon, Jun 10, 2024 at 06:29:17AM +, Bertrand Drouvot wrote:
> > Thanks for the report! I think it makes sense to add it to the list of known
> > failures.
> >
> > One way to deal with those corner cases could be to make
On Thu, Jun 6, 2024 at 10:00 PM Robert Haas wrote:
> On Wed, Jun 5, 2024 at 3:48 AM Ashutosh Bapat
> wrote:
> > Here's planning time measurements.
> > num_joins | master (ms) | patched (ms) | change in planning time (ms) |
> change in planning time
> >
>
On Thu, May 16, 2024 at 8:42 PM Robert Haas wrote:
> You don't need to wait for the next CommitFest to fix a comment (or a
> bug). And, indeed, it's better if you do this before we branch.
Patch pushed and the CF entry closed. Thank you for the suggestion.
Thanks
Richard
On Mon, Jun 10, 2024 at 06:29:17AM +, Bertrand Drouvot wrote:
> Thanks for the report! I think it makes sense to add it to the list of known
> failures.
>
> One way to deal with those corner cases could be to make use of injection
> points
> around places where RUNNING_XACTS is emitted,
Hi Alexander,
On Sat, Jun 08, 2024 at 07:00:00AM +0300, Alexander Lakhin wrote:
> Hello Bertrand and Michael,
>
> 23.01.2024 11:07, Bertrand Drouvot wrote:
> > On Tue, Jan 23, 2024 at 02:50:06PM +0900, Michael Paquier wrote:
> >
> > > Anyway, that's not the end of it. What should we do for
At Sat, 8 Jun 2024 14:09:11 -0400, Robert Haas wrote in
> On Sat, Jun 8, 2024 at 10:02 AM Pavel Luzanov
> wrote:
> > Therefore, I think the current patch offers a better version of the \du
> > command.
> > However, I admit that these improvements are not enough to accept the patch.
> > I
On Fri, Jun 7, 2024 at 7:30 PM Amit Kapila wrote:
>
> On Fri, Jun 7, 2024 at 7:55 AM Masahiko Sawada wrote:
> >
> > On Thu, Jun 6, 2024 at 6:40 PM Amit Kapila wrote:
> > >
> > > On Thu, Jun 6, 2024 at 11:10 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Wed, Jun 5, 2024 at 9:30 PM Amit
On Sat, Jun 08, 2024 at 04:52:25PM +0500, Andrey M. Borodin wrote:
> Alvaro, here’s the test for multixact CV sleep that I was talking
> about on PGConf.
> It is needed to test [0]. It is based on loaded injection
> points.
> This technique is not committed yet, but the patch looks good.
OK,
Hi hackers,
During the last pgconf.dev I attended Robert’s presentation about autovacuum and
it made me remember of an idea I had some time ago: $SUBJECT
Please find attached a patch doing so by adding a new field (aka "time_delayed")
to the pg_stat_progress_vacuum view.
Currently one can
96 matches
Mail list logo
