On 16.12.24 19:19, Andres Freund wrote:
* Why in the world is the default value of max_wal_senders 10?
I find it hard to believe that there are installations using
more than about 3, and even there you can bet they are changing
a lot of other parameters.
I don't think it's that rare as logical
On Tue, 2024-12-17 at 20:36 -0500, Tom Lane wrote:
> Jeff Davis writes:
> > Crazy idea: what if we treated the top-level ORDER BY as special? That
> > is, we create a new node ResultOrderBy and make it visible in EXPLAIN.
> > Then we can have a GUC to control the default collation only for that
>
On Mon, 16 Dec 2024 at 11:27, Amit Kapila wrote:
>
> On Sat, Dec 14, 2024 at 5:28 AM Tom Lane wrote:
> >
> > I suppose this exchange is what led to this bit in
> > getPublicationNamespaces:
> >
> > /*
> > * We always dump publication namespaces unless the corresponding
> >
On Wed, Dec 18, 2024 at 12:49 AM Masahiko Sawada wrote:
>
> Hi,
>
> I found that a server crashes due to a null-pointer-dereference if a
> process attached to the shared radix tree begins an iteration on it,
> because we don't create the memory context for iter_context at
> RT_ATTACH(). There is n
On Tue, Dec 17, 2024 at 2:48 AM Amit Kapila wrote:
>
> On Fri, Dec 13, 2024 at 1:22 AM Masahiko Sawada wrote:
> >
> > On Wed, Dec 11, 2024 at 9:43 PM Amit Kapila wrote:
> > >
> > > On Wed, Dec 11, 2024 at 11:09 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Tue, Dec 10, 2024 at 6:13 PM Zhi
On Mon, Dec 2, 2024 at 2:01 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> One side note, I think it would be great to properly cite the white
> paper the patch is referring to. Besides paying some respect to the
> authors, it will also make it easier to actually find it. After a quick
> searc
Recently, I've encountered a core dump several times on master, with a
backtrace like the one below. This one happened on 0f23dedc9. I was
running some fuzz testing and had started around 20 sessions
concurrently.
(gdb) bt
#0 in GrantLockLocal at lock.c:1758
#1 in GrantAwaitedLock at lock.c:18
On Tue, Dec 17, 2024 at 09:42:36AM +0100, Michael Banck wrote:
> Done.
>
> V3 attached.
Done.
--
Michael
signature.asc
Description: PGP signature
Hi Vignesh,
Here are some review comments for the patch v20241211-0002.
==
doc/src/sgml/ref/create_publication.sgml
1.
+where object
type is one of:
+
+TABLES
+SEQUENCES
The replaceable "object_type" is missing an underscore.
~~~
publish option effect fro SEQUENCE replication?
2.
On Tue, Dec 17, 2024 at 09:35:37AM +, Bertrand Drouvot wrote:
> Agree, we may need to add parameters to it but we'll see when the time comes.
Another thing that's been itching me: the loop in
pg_stat_get_backend_io() that exists as well in pg_stat_get_io() looks
worth refactoring in a single r
Hi AbdelAziz,
On Tue, Dec 17, 2024 at 8:39 PM AbdelAziz Sharaf
wrote:
>
> it' my first time to know about updatable view and may really serve
> I really would appreciate if you discuss my approach also even if not in
> first priority
> thanks for your time and solution, I really appreciate it
G
hi.
/*
* has_session_variable_privilege variants
*These are all named "has_session_variable_privilege" at the SQL level.
*They take various combinations of variable name, variable OID,
*user name, user OID, or implicit user = current_user.
*
*The result is a b
Hi Vignesh.
Here are some review comments for patch v20241211-0001.
==
src/backend/commands/sequence.c
pg_sequence_state:
1.
+ TupleDesc tupdesc;
+ HeapTuple tuple;
+ Datum values[4];
+ bool nulls[4] = {false, false, false, false};
SUGGESTION
bool nulls[4] = {0};
The above achieves the s
David Rowley writes:
> On Wed, 18 Dec 2024 at 14:02, Tom Lane wrote:
>> it appears your patch did not fully adjust BuildTupleHashTableExt
>> for variable input-slot type. You need the attached as well.
> Do you have a test case in master that triggers a problem here?
No, that's what I didn't w
Hi,
I apologize for this late reply.
As you advised, I was able to create the ".pc" file manually and set the
dependencies using pkgconf.
Thank you.
However, I have read the PostgreSQL Documentation and did not realize that
pkgconf is required.
17.4.3.2. PostgreSQL Features
-Dgssapi
On many
On Wed, 18 Dec 2024 at 14:02, Tom Lane wrote:
> So I tried adapting my patch to not make a copy of the input slot,
> and it didn't work: I was still getting assertion failures about
> the slot not being a MinimalTupleSlot as expected. On investigation
> it appears your patch did not fully adjust
Hi Evgeny
> we are causing the target solution to become staled
I think the community is not positive enough about xid64,There is also a
lot of resistance, such as the wal log becomes larger
>I also hope you and the community will support attempts to retain the
> whole xid64 solution in the con
On 17/12/2024 22:32, Nathan Bossart wrote:
Committed.
Thanks, I see you backpatched it all the way to 13.
Will see how far back I can test this, will take a while.
Regards,
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group
Jeff Davis writes:
> Crazy idea: what if we treated the top-level ORDER BY as special? That
> is, we create a new node ResultOrderBy and make it visible in EXPLAIN.
> Then we can have a GUC to control the default collation only for that
> node.
Eeek.
This seems like an amazing kluge, and it's no
On 12/12/24 10:00 AM, Jeff Davis wrote:
Patch attached.
I have not looked at the patch yet but +1 to the idea. I am leaning
towards that the function also optionally normalizing the codepoints
would be handy too since I think that is what most usecases want.
Otherwise people would have to al
David Rowley writes:
> I've pushed the patch now.
So I tried adapting my patch to not make a copy of the input slot,
and it didn't work: I was still getting assertion failures about
the slot not being a MinimalTupleSlot as expected. On investigation
it appears your patch did not fully adjust Bui
Dear team,
We recently observed a few cases where Postgres running on Linux
encountered an issue with WAL segment files. Specifically, two WAL
segments were linked to the same physical file after Postgres ran out
of memory and the OOM killer terminated one of its processes. This
resulted in the WA
Say an application developer wants the results in their application to
appear in an order that matches the application user's locale. They
don't want the results themselves to change; they just want the order
to change for display purposes to the end user. Assume the developer
already has ORDER BY
On 17/12/2024 23:28, Andres Freund wrote:
On 2024-12-17 19:57:13 +0200, Heikki Linnakangas wrote:
On 14/12/2024 01:44, Andres Freund wrote:
The zero_damaged_pages path in bufmgr.c makes sense to me, but this one seems
less sane to me. If you want to recover from a data corruption event and
can
On Wed, 18 Dec 2024 at 11:04, Tom Lane wrote:
>
> David Rowley writes:
> > project and use a virtual slot type. It's maybe worth coming back and
> > adjusting nodeAppend.c so it works a bit harder to fix its slot type.
> > I think that's likely for another patch, however. Tom is also
> > curren
Thanks for the review!
On Tue, Dec 17, 2024 at 10:57 AM Nazir Bilal Yavuz wrote:
>
> Here are couple of code comments:
>
> === [PATCH v2 07/10] ===
>
> It took me a while to understand that heap_vac_scan_next_block() loops
> until rel_pages. What do you think about adding
> Assert(vacrel->current
On Tue, Dec 17, 2024 at 5:27 PM Andres Freund wrote:
> Bitmap heapscans go through a distinct path, so it'd be trivial to accept tids
> pointing into the void for bitmap scans but not index [only] scans.
I wasn't clear. Plain nbtree index scans can drop their leaf page
buffer pin, which makes the
Hi,
On 2024-12-17 17:07:34 -0500, Peter Geoghegan wrote:
> On Tue, Dec 17, 2024 at 4:46 PM Andres Freund wrote:
> > ISTM that we could do better with some fairly simple cooperation between
> > index
> > and table AM. It should be rather rare to look up a TID that was removed
> > between finding
On Tue, Dec 17, 2024 at 4:46 PM Andres Freund wrote:
> ISTM that we could do better with some fairly simple cooperation between index
> and table AM. It should be rather rare to look up a TID that was removed
> between finding the index entry and fetching the table entry, a small amount
> of extra
David Rowley writes:
> The slightly annoying thing here is that the attached patch passes the
> TupleTableSlotOps as NULL in nodeSetOp.c. Per nodeAppend.c line 186,
> Append does not go to much effort to setting a fixed
> TupleTableSlotOps. Really it could loop over all the child plans and
> check
On Tue, 17 Dec 2024 at 07:10, Nathan Bossart wrote:
> git-bisect is pointing me to https://postgr.es/c/0f57382. Here is the
> trace I'm seeing:
>
> TRAP: failed Assert("op->d.fetch.kind == slot->tts_ops"), File:
> "../postgresql/src/backend/executor/execExprInterp.c", Line: 2244, PID: 50
On 2024-12-17 15:32:06 -0600, Nathan Bossart wrote:
> Committed.
Thanks!
Hi,
On 2024-12-17 16:11:53 -0500, Peter Geoghegan wrote:
> On Tue, Dec 17, 2024 at 12:57 PM Heikki Linnakangas wrote:
> > Hmm, looking at index_fetch_heap(), I'm surprised it doesn't throw an
> > error or even a warning if the heap tuple isn't found. That would seem
> > like a useful sanity check
I wrote:
> Andres Freund writes:
>> It'd be helpful if the error message ought to at least include the category
>> being tested, perhaps it's just one category failing or such?
> Yeah, I will poke into this a little harder to see what's going on.
So after a little testing, setlocale(LC_COLLATE,
On Wed, Dec 18, 2024 at 2:50 AM James Coleman wrote:
>
> On Mon, Dec 16, 2024 at 6:17 PM Peter Smith wrote:
> >
> > While revisiting some old threads, I found this one that seemed to
> > reach a conclusion, but then it seemed nothing happened.
> >
> > After multiple suggestions AFAICT James prefe
Committed.
--
nathan
Hi,
On 2024-12-17 19:57:13 +0200, Heikki Linnakangas wrote:
> On 14/12/2024 01:44, Andres Freund wrote:
> > The zero_damaged_pages path in bufmgr.c makes sense to me, but this one
> > seems
> > less sane to me. If you want to recover from a data corruption event and
> > can't dump the data becau
On Tue, Dec 17, 2024 at 12:57 PM Heikki Linnakangas wrote:
> Hmm, looking at index_fetch_heap(), I'm surprised it doesn't throw an
> error or even a warning if the heap tuple isn't found. That would seem
> like a useful sanity check. An index tuple should never point to a
> non-existent heap TID I
Andres Freund writes:
> On 2024-12-17 12:44:46 -0500, Tom Lane wrote:
>> On mamba's host (pretty vanilla NetBSD 10.0):
>> initdb: error: invalid locale settings; check LANG and LC_* environment
>> variables
> It'd be helpful if the error message ought to at least include the category
> being tes
I wrote:
> Sami Imseih writes:
>> I am attaching a patch that deals with the RTE_JOIN case.
> I'll take a look. Thanks for the test demonstrating that
> this makes a visible performance difference.
Pushed with some simplification: we don't need a new flag,
because none of the callers of set_sim
On Tue, Dec 17, 2024 at 1:46 PM Tomas Vondra wrote:
>
> On 12/17/24 18:06, Melanie Plageman wrote:
> > On Tue, Dec 17, 2024 at 9:11 AM Tomas Vondra wrote:
> >>
> >>
> >>
> >> On 12/16/24 19:49, Melanie Plageman wrote:
> >>
> >>> No, I'm talking about the behavior of causing small pockets of
> >>>
Hi,
On 2024-12-17 14:25:01 -0500, Andres Freund wrote:
> On 2024-12-17 13:09:49 -0500, Tom Lane wrote:
> > I wrote:
> > > Andres Freund writes:
> > >> Was about to apply that, but then started to wonder if we don't need the
> > >> same
> > >> for configure? And it sure looks like that has the sa
On Tue, Dec 17, 2024 at 11:44 AM Melanie Plageman
wrote:
> I did look at the wiki page a bit. But one thing I didn't quite grasp
> is how you are proposing to measure the costs/benefits of scanning all
> all-visible pages. When you first mentioned this, I imagined you would
> use visibilitymap_cou
On Mon, Dec 16, 2024 at 7:14 PM Melanie Plageman
wrote:
>
> On Wed, Dec 11, 2024 at 2:18 PM Masahiko Sawada wrote:
> >
> > I agree that it will be unimportant from Melanie's work in this area.
> > Also, I agree that if semi-aggressive vacuum has its own new logging
> > message about what it's don
Hi,
On 2024-12-17 13:09:49 -0500, Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> Was about to apply that, but then started to wonder if we don't need the
> >> same
> >> for configure? And it sure looks like that has the same problem?
> >> Which also confuses me some, at some point thi
Hi,
Sometimes you need to inspect some debug messages from autovacuum worker but
you cannot apply the same setting for backends (that could rapidly fill the log
file). This proposal aims to change log_min_messages to have different log
levels depending on which backend type the message comes from.
Hi,
On 2024-12-17 12:44:46 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-11-12 11:38:11 +0300, Nazir Bilal Yavuz wrote:
> >> It was because initdb was failing on NetBSD when the LANG and LC_ALL
> >> is not set to C. I rephrased the comment and moved this under NetBSD
> >> task.
>
>
On 12/17/24 18:52, Robert Haas wrote:
> On Tue, Dec 17, 2024 at 12:06 PM Melanie Plageman
> wrote:
>> I think your tests show SKIP_PAGES_THRESHOLD has dubious if any
>> benefit related to readahead. But the question is if we care about it
>> for advancing relfrozenxid for small tables.
Yeah, a
On 12/17/24 18:06, Melanie Plageman wrote:
> On Tue, Dec 17, 2024 at 9:11 AM Tomas Vondra wrote:
>>
>>
>>
>> On 12/16/24 19:49, Melanie Plageman wrote:
>>
>>> No, I'm talking about the behavior of causing small pockets of
>>> all-frozen pages which end up being smaller than SKIP_PAGES_THRESHOLD
>>
On 12.12.24 19:20, Jeff Davis wrote:
On Mon, 2024-12-09 at 11:11 +0100, Peter Eisentraut wrote:
I have expanded this patch set. The first three patches are the same
as
before. I have added a new patch that gets rid of lowerstr() from
ts_locale.c and replaces it with the standard str_tolower()
On 17.12.24 16:25, Andreas Karlsson wrote:
On 12/13/24 6:07 PM, Jeff Davis wrote:
OK, that's fine with me for this patch series.
Eventually though, I think we should have built-in versions of these
ASCII functions. Even if there's no actual problem, it would more
clearly indicate that we only c
Sami Imseih writes:
>> It only takes one case to mean we have to deal with it ;-). But I'm
>> fairly sure that there are many other cases, since the parser doesn't
>> restrict the output names of a sub-SELECT to be unique.
> good point. I see the error in my original line of thinking now.
> In f
On Tue, 2024-12-17 at 13:14 +0100, Peter Eisentraut wrote:
> I think we will need to keep the global LC_CTYPE setting set to
> something useful, for example so that system error messages come out
> in
> the right encoding.
Do we need to rely on the global LC_CTYPE setting? We already use
bind_te
I wrote:
> Andres Freund writes:
>> Was about to apply that, but then started to wonder if we don't need the same
>> for configure? And it sure looks like that has the same problem?
>> Which also confuses me some, at some point this presumably worked?
> The configure path does work on NetBSD 10,
On 14/12/2024 01:44, Andres Freund wrote:
The zero_damaged_pages path in bufmgr.c makes sense to me, but this one seems
less sane to me. If you want to recover from a data corruption event and
can't dump the data because a seqscan stumbles over an invalid page -
zero_damaged_pages makes sense.
On Tue, Dec 17, 2024 at 12:06 PM Melanie Plageman
wrote:
> I think your tests show SKIP_PAGES_THRESHOLD has dubious if any
> benefit related to readahead. But the question is if we care about it
> for advancing relfrozenxid for small tables.
It seems like relfrozenxid advancement is really only a
Hi,
I found that a server crashes due to a null-pointer-dereference if a
process attached to the shared radix tree begins an iteration on it,
because we don't create the memory context for iter_context at
RT_ATTACH(). There is no code in the core causing this crash in the
core since in parallel va
On 2024-12-16 Mo 11:44 AM, Andres Freund wrote:
[ file headers follow different patterns ]
It probably doesn't make sense to change all the existing files to follow one
pattern (although perhaps some of the "more odd" ones might be worth
adjusting).
But it seems like it'd be good to define o
Andres Freund writes:
> On 2024-11-12 11:38:11 +0300, Nazir Bilal Yavuz wrote:
>> It was because initdb was failing on NetBSD when the LANG and LC_ALL
>> is not set to C. I rephrased the comment and moved this under NetBSD
>> task.
> Do you happen to have a reference to the failure? The environm
On 2024-12-17 Tu 10:11 AM, Nikita Malakhov wrote:
Hi hackers!
This thread is further work continued in [1], where Amit Langote
suggested starting discussion on the remaining SQL/JSON feature
'PLAN clause for JSON_TABLE' anew.
We'd like to help with merging SQL/JSON patches into vanilla,
and h
On Tue, Dec 17, 2024 at 10:53:07AM -0500, Andres Freund wrote:
> On 2024-12-17 16:50:45 +0900, Michael Paquier wrote:
>> I don't see a huge point in backpatching, FWIW.
>
> I don't see why we wouldn't want to backpatch? The number of objects here
> isn't entirely unrealistic to reach with relation
On Tue, Dec 17, 2024 at 9:11 AM Tomas Vondra wrote:
>
>
>
> On 12/16/24 19:49, Melanie Plageman wrote:
>
> > No, I'm talking about the behavior of causing small pockets of
> > all-frozen pages which end up being smaller than SKIP_PAGES_THRESHOLD
> > and are then scanned (even though they are alrea
I've pushed (and backpatched) a fix for this.
I ended up doing the simplest thing -- error out if the number of
columns does not match, suggesting to update to latest extension version.
I considered handling it in a nicer way, but I didn't like the result
very much and I think that's sufficient f
On Mon, Dec 16, 2024 at 2:18 PM Peter Geoghegan wrote:
>
> On Mon, Dec 16, 2024 at 1:50 PM Melanie Plageman
> wrote:
> > Then in the next vacuum, we end up scanning those all-frozen pages again
> > because the
> > ranges of frozen pages are smaller than SKIP_PAGES_THRESHOLD. This is
> > mostly g
On Wed, Oct 9, 2024 at 7:12 AM Nishant Sharma
wrote:
> I have included them in v3. v3 does not allow empty schema_name &
> table_name options along with column_name.
I was looking at these patches today and trying to understand whether
the proposed error message is consistent with what we have do
Hi,
Missed something until just after I hit send:
On 2024-11-12 11:38:11 +0300, Nazir Bilal Yavuz wrote:
> + matrix:
> +- name: NetBSD - 10 - Meson
> + only_if: $CIRRUS_CHANGE_MESSAGE !=~ '.*\nci-os-only:.*' ||
> $CIRRUS_CHANGE_MESSAGE =~ '.*\nci-os-only:[^\n]*netbsd.*'
...
> +- na
Hi,
On 2024-11-12 11:38:11 +0300, Nazir Bilal Yavuz wrote:
> On Fri, 1 Nov 2024 at 21:44, Andres Freund wrote:
> > > +CCACHE_DIR: /tmp/ccache_dir
> > > +
> > > +PATH: /usr/sbin:$PATH
> > > +
> > > +# Postgres interprets LANG as a 'en_US.UTF-8' but it is 'C', then
> >
> > What does "Po
On Tue, Dec 17, 2024 at 10:51 AM Robert Haas wrote:
> I think this amounts to inventing a new way to mark a tuple as dead,
> but I don't think we need to do that. We could just mark the line
> pointer LP_DEAD without actually touching the space that contains the
> tuple. At least, I think that wou
On Tue, Dec 17, 2024 at 9:11 AM Tomas Vondra wrote:
> I don't follow. How could non-aggressive VACUUM advance relfrozenxid,
> ever? I mean, if it doesn't guarantee freezing all pages, how could it?
Although it's very workload dependent, it still happens all the time.
Just look at the autovacuum l
Hi,
Thank you for working on this!
On Sat, 14 Dec 2024 at 01:53, Melanie Plageman
wrote:
>
> On Thu, Nov 7, 2024 at 10:42 AM Andres Freund wrote:
> >
> > Hi,
>
> Thanks for the review!
> Attached v2 should address your feedback and also fixes a few bugs with v1.
Here are couple of code comment
Hi,
On 2024-12-17 16:50:45 +0900, Michael Paquier wrote:
> On Mon, Dec 16, 2024 at 04:18:26PM -0600, Nathan Bossart wrote:
> > On Mon, Dec 16, 2024 at 08:00:00AM +0100, Andreas 'ads' Scherbaum wrote:
> >> Can confirm that the crash no longer happens when applying your patch.
> >
> > The patch loo
On Mon, Dec 16, 2024 at 2:38 PM Peter Geoghegan wrote:
> The only reason that we require a cleanup lock is to make it safe to
> defragment the page, to free tuple space. Nothing stops you from
> inventing a variant of pruning/freezing that works just like regular
> pruning/freezing, but without at
On Mon, Dec 16, 2024 at 6:17 PM Peter Smith wrote:
>
> While revisiting some old threads, I found this one that seemed to
> reach a conclusion, but then it seemed nothing happened.
>
> After multiple suggestions AFAICT James preferred the docs [1]
> modification suggested [2] by Laurenz.
>
> Shoul
On 12/13/24 6:07 PM, Jeff Davis wrote:
OK, that's fine with me for this patch series.
Eventually though, I think we should have built-in versions of these
ASCII functions. Even if there's no actual problem, it would more
clearly indicate that we only care about ASCII at that particular call
site
it' my first time to know about updatable view and may really serve
I really would appreciate if you discuss my approach also even if not in
first priority
thanks for your time and solution, I really appreciate it
best regards
On Tue, Dec 17, 2024 at 8:16 AM Ashutosh Bapat
wrote:
> On Tue, Dec 1
On 12/16/24 19:49, Melanie Plageman wrote:
> On Mon, Dec 16, 2024 at 12:32 PM Peter Geoghegan wrote:
>>
>> On Mon, Dec 16, 2024 at 10:37 AM Melanie Plageman
>> wrote:
>>> On a related note, the other day I noticed another negative effect
>>> caused in part by SKIP_PAGES_THRESHOLD. SKIP_PAGES_T
On Tue, Dec 3, 2024 at 8:01 PM Robert Haas wrote:
>
> On Mon, Dec 2, 2024 at 2:18 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > I've asked about that in linux-mm [1]. To my surprise, the
> > recommendations were to stick to creating a large mapping in advance,
> > and slice smaller mappings
Hello hackers,
Investigating a recent buildfarm failure [1] with the following
diagnostics:
[12:27:41.437](0.024s) ok 18 - have walreceiver pid 637143
[12:30:42.564](181.127s) not ok 19 - walsender termination logged
[12:30:42.564](0.000s)
[12:30:42.564](0.000s) # Failed test 'walsender termina
On 13.12.24 10:44, Thomas Munro wrote:
On Fri, Dec 13, 2024 at 8:22 AM Jeff Davis wrote:
On Wed, 2024-08-14 at 12:00 -0700, Jeff Davis wrote:
On Wed, 2024-08-14 at 14:31 +1200, Thomas Munro wrote:
1. The process global locale is always "C". If you ever call
uselocale(), it can only be for s
On Tue, 17 Dec 2024 at 16:59, Michael Paquier wrote:
> +1. Robins, feel free to ping me directly if you need help with this
> host.
>
Much appreciated Michael. Thankfully the new client worked without much
hiccup
(once it got the correct config file).
This is an old instance and IIRC gcc 7.3.1
Ryohei Takahashi (Fujitsu) писал(а) 2024-12-16 15:10:
Hi
According to your advice, I created RAM disk and put input files and
data directory on RAM disk.
But the result changed only a few seconds.
In this test case, the table is unlogged table and shared_buffers is
enough.
So, I think the dis
On Sun, Dec 15, 2024 at 10:45 AM Dilip Kumar wrote:
>
> On Fri, Dec 13, 2024 at 3:01 AM Masahiko Sawada wrote:
> >
> > DDLs write not only XLOG_XACT_INVALIDATIONS but also system catalog
> > changes. I think that when decoding these system catalog changes, we
> > end up calling SnapBuildProcessCh
On Wed, Dec 11, 2024 at 4:31 PM Richard Guo wrote:
> As mentioned in that thread, I feel that we can apply a similar
> optimization to more complex non-var expressions: if a strict
> expression contains any variables of rels that are under the same
> lowest nulling outer join as the subquery, we c
On Fri, Dec 13, 2024 at 1:22 AM Masahiko Sawada wrote:
>
> On Wed, Dec 11, 2024 at 9:43 PM Amit Kapila wrote:
> >
> > On Wed, Dec 11, 2024 at 11:09 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Dec 10, 2024 at 6:13 PM Zhijie Hou (Fujitsu)
> > > wrote:
> > > >
> > > > On Wednesday, December
Michael Paquier writes:
> On Mon, Dec 16, 2024 at 12:26:38PM +, Dagfinn Ilmari Mannsåker wrote:
>> s{create tablespace .* location .*\btspitr\K[12]}{N}i for @_;
>>
>> I think I'm leaning towards the latter, for simplicity and robustness.
>
> Simplicity and robustness works here and in the CI
On 12/3/24 11:24 AM, Joel Jacobson wrote:
I've tested the patch successfully and also looked at the code briefly
and at first glance think it looks nice and clean.
Thanks for the interest!
Here is an updated version which adds support for RLS. I am not 100%
sure that my choices for RLS are co
Hi Daniel!
> On 16 Dec 2024, at 19:08, Daniel Verite wrote:
>
> The timestamps are now just a sequence incrementing by 1
> on each call, independently of the server's clock and
> the actual time span between calls. It has become a counter
> and will remain so until the backend terminates.
This
Hi Evgeny
xid64 path split several threads ,The current one should be
this:(https://www.postgresql.org/message-id/flat/CACG=ezawg7_nt-8ey4akv2w9lculthhknwcawmbgeetnjrj...@mail.gmail.com)
,We can do some tests on path so that can merge earlier
Thanks
Hello Wenhui!
Thank you for pointing
No
when specifying search_path, we build another schema, where each duplicate
data must be inside
what I suggested is to have versions/aliases for schemas and any duplicate
table/view/... could be inherited if duplicate with all data inside and
when any version/alias is dropped and another version/
On Mon, 16 Dec 2024 at 17:21, Artur Zakirov wrote:
>
> On Mon, 16 Dec 2024 at 12:05, vignesh C wrote:
> > I prefer the other approach to remove both the checks in
> > getPublicationTables() and getPublicationNamespaces() which also makes
> > it consistent with the other case that Amit mentioned a
Hi,
On Tue, Dec 17, 2024 at 06:13:44PM +0900, Michael Paquier wrote:
> On Tue, Dec 17, 2024 at 08:13:59AM +, Bertrand Drouvot wrote:
> > Having said that, v9-0002 looks good to me (except the
> > pgstat_fetch_proc_stat_io
> > renaming).
>
> This routine returns a PgStat_Backend from a pgstat
On Mon, 16 Dec 2024 at 02:53, Peter Smith wrote:
>
> On Fri, Dec 13, 2024 at 8:31 PM vignesh C wrote:
> >
> > On Fri, 13 Dec 2024 at 10:58, Peter Smith wrote:
> > >
> > > Hi,
> > >
> > > While reviewing the pg_createsubscriber [1] docs I found a potentially
> > > wrong linkend.
> > >
> > > This
On Tue, Dec 17, 2024 at 08:13:59AM +, Bertrand Drouvot wrote:
> Having said that, v9-0002 looks good to me (except the
> pgstat_fetch_proc_stat_io
> renaming).
This routine returns a PgStat_Backend from a pgstats entry of type
PGSTAT_KIND_BACKEND, so the name in v9-0001 would not be true once
On Mon, Dec 16, 2024 at 9:12 PM Pavel Luzanov wrote:
>
> On 16.12.2024 13:56, Amit Kapila wrote:
>
>
> Yeah, the change made by commit 84db9a0eb1 is wrong and your latest
> patch in this thread looks good to me. I am adding Daniel and the
> original author to see if they think differently.
>
> It
Hi,
On Tue, Dec 17, 2024 at 04:43:21PM +0900, Michael Paquier wrote:
> On Mon, Dec 16, 2024 at 10:57:49PM +0100, Michael Banck wrote:
> > Thanks, I have added the documentation now in v2.
>
> The doc additions seem fine to me. I've just grabbed three tiny nits,
> nothing critical.
Thanks for th
On Tue, Dec 17, 2024 at 8:54 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Monday, December 16, 2024 7:21 PM Dilip Kumar
> wrote:
>
> > So IIUC in step 2) we send the message and get the list of all the
> > transactions which are in the commit phase? What do you exactly mean by a
> > transaction which i
Hi,
On Tue, Dec 17, 2024 at 03:26:02PM +0900, Michael Paquier wrote:
> On Mon, Dec 16, 2024 at 03:42:04PM +, Bertrand Drouvot wrote:
> >> Perhaps there's an argument for an entirely separate
> >> callback that would run before pgstat is plugged off, like a new
> >> before_shmem_exit() callback
97 matches
Mail list logo
