On 28/2/2024 13:53, Tender Wang wrote:
The attached patch is a new version based on v3(not including Andrei's
the test case). There is no need to call datumCopy when
isnull is true.
I have not added a new runtime memoryContext so far. Continue to use
mstate->tableContext, I'm not sure the
Hi,
On Wed, Feb 28, 2024 at 06:48:37AM +, Zhijie Hou (Fujitsu) wrote:
> On Wednesday, February 28, 2024 2:38 PM Bertrand Drouvot
> wrote:
> > On Wed, Feb 28, 2024 at 08:49:19AM +0530, Amit Kapila wrote:
> > > On Mon, Feb 26, 2024 at 9:13 AM shveta malik
> > wrote:
> > > >
> > > > On Fri,
On Wed, Feb 28, 2024 at 8:49 AM Amit Kapila wrote:
>
>
> Few comments:
Thanks for the feedback.
> ===
> 1.
> - if (logical)
> + if (logical || !replication)
> {
>
> Can we add a comment about connection types that require
> ALWAYS_SECURE_SEARCH_PATH_SQL?
>
> 2.
> Can we add a test
The attached patch is a new version based on v3(not including Andrei's the
test case). There is no need to call datumCopy when
isnull is true.
I have not added a new runtime memoryContext so far. Continue to use
mstate->tableContext, I'm not sure the memory used of probeslot will affect
On Wednesday, February 28, 2024 2:38 PM Bertrand Drouvot
wrote:
> On Wed, Feb 28, 2024 at 08:49:19AM +0530, Amit Kapila wrote:
> > On Mon, Feb 26, 2024 at 9:13 AM shveta malik
> wrote:
> > >
> > > On Fri, Feb 23, 2024 at 7:41 PM Bertrand Drouvot
> > > wrote:
> > > >
> > > > Hi,
> > > > > I
On Mon, Feb 26, 2024 at 5:47 PM torikoshia wrote:
>
> >
> > It looks good to me.
>
> Here are comments on the v2 patch.
Thanks for looking at it.
> + if (cstate->opts.on_error != COPY_ON_ERROR_STOP)
> + {
> + ereport(NOTICE,
>
> I think
Hi,
On Wed, Feb 28, 2024 at 08:49:19AM +0530, Amit Kapila wrote:
> On Mon, Feb 26, 2024 at 9:13 AM shveta malik wrote:
> >
> > On Fri, Feb 23, 2024 at 7:41 PM Bertrand Drouvot
> > wrote:
> > >
> > > Hi,
> > > > I think to set secure search path for remote connection, the standard
> > > >
Hi,
On Wed, Feb 28, 2024 at 01:26:46PM +0900, Michael Paquier wrote:
> On Tue, Feb 27, 2024 at 01:39:59PM +, Bertrand Drouvot wrote:
> > So, I'm ok with the new helper too.
>
> If both of you feel strongly about that, I'm OK with introducing
> something like that.
Thanks!
> Now, a routine
On Mon, Feb 26, 2024 at 5:31 PM torikoshia wrote:
> It would be nice if there was a place accessed once every few seconds or
> so..
I think this comment earlier from Andres deserves close attention:
# If we went with something like tht approach, I think we'd have to do something
# like
On Mon, Feb 26, 2024 at 7:54 PM Masahiko Sawada wrote:
>
A few comments on 0003:
===
1.
+/*
+ * Threshold of the total number of top-level and sub transactions
that controls
+ * whether we switch the memory track state. While the MAINTAIN_HEAP state is
+ * effective when there
> On 28 Feb 2024, at 09:26, Michael Paquier wrote:
>
> Now, a routine should be only about waiting on
> pg_stat_activity to report something
BTW, if we had an SQL function such as injection_point_await(name), we could
use it in our isolation tests as well as our TAP tests :)
However, this
On Wed, 28 Feb 2024 at 04:59, Michael Paquier wrote:
> Cool. I have applied 0004 and most of 0002. Attached is what
> remains, where I am wondering if it would be cleaner to do these bits
> together (did not look at the whole, yet).
Feel free to squash them if you prefer that. I think now that
On Tue, Feb 27, 2024 at 01:39:59PM +, Bertrand Drouvot wrote:
> So, I'm ok with the new helper too.
If both of you feel strongly about that, I'm OK with introducing
something like that. Now, a routine should be only about waiting on
pg_stat_activity to report something, as for the logs we
On 26/2/2024 11:10, Alena Rybakina wrote:
On 24.02.2024 14:28, jian he wrote:
Hi.
I wrote the first draft patch of the documentation.
it's under the section: Planner Method Configuration
(runtime-config-query.html)
but this feature's main meat is in src/backend/parser/parse_expr.c
so it may
út 27. 2. 2024 v 21:03 odesílatel Alexander Korotkov
napsal:
> Hi!
>
> On Tue, Jan 30, 2024 at 8:46 PM Pavel Stehule
> wrote:
> > I marked this patch as ready for committer.
>
> The last version of the patch still provides transform for builtin
> type in a separate extension. As discussed
On Wed, Feb 28, 2024 at 09:41:42AM +0800, Japin Li wrote:
> On Wed, 28 Feb 2024 at 00:06, Jelte Fennema-Nio wrote:
>> Attached is v5 of the patchset that also includes this change (with
>> you listed as author).
>
> Thanks for updating the patch!
Cool. I have applied 0004 and most of 0002.
On Wed, Feb 28, 2024 at 12:24:01AM +0400, Heikki Linnakangas wrote:
> Here's a patch to fully remove AIX support.
> Subject: [PATCH 1/1] Remove AIX support
>
> There isn't a lot of user demand for AIX support, no one has stepped
> up to the plate to properly maintain it, so it's best to remove
On Tue, Feb 27, 2024 at 11:41 PM Alvaro Herrera
wrote:
> On 2024-Feb-27, Alvaro Herrera wrote:
>
> > Here's the complete set, with these two names using the singular.
>
> BTW one thing I had not noticed is that before this patch we have
> minimum shmem size that's lower than the lowest you can
On 28/2/2024 04:19, Tom Lane wrote:
Andrei Lepikhov writes:
IMO, the routine eval_const_expressions_mutator contains some stale code:
I'd like to push back against the idea that eval_const_expressions
is expected to return a freshly-copied tree. Its API specification
contains no such claim.
On Mon, Feb 26, 2024 at 9:13 AM shveta malik wrote:
>
> On Fri, Feb 23, 2024 at 7:41 PM Bertrand Drouvot
> wrote:
> >
> > Hi,
> > > I think to set secure search path for remote connection, the standard
> > > approach
> > > could be to extend the code in libpqrcv_connect[1], so that we don't
On Tuesday, February 27, 2024 3:18 PM Peter Smith wrote:
>
> Here are some review comments for v99-0001
Thanks for the comments!
> Commit Message
>
> 1.
> A new parameter named standby_slot_names is introduced.
>
> Maybe quote the GUC names here to make it more readable.
Added.
>
> ~~
>
On 2024-02-27 Tu 05:03, Benoit Lobréau wrote:
On 2/25/24 23:32, Peter Smith wrote:
Also, I don't understand how the word "draught" (aka "draft") makes
sense here -- I assume the intended word was "drought" (???).
yes, that was the intent, sorry about that. English is not my native
On Wed, 28 Feb 2024 at 00:06, Jelte Fennema-Nio wrote:
> On Tue, 27 Feb 2024 at 16:04, Japin Li wrote:
>> I see the config_group_names[] needs null-terminated because of help_config,
>> however, I didn't find the reference in help_config.c. Is this comment
>> outdated?
>
> Yeah, you're
New version attached.
Do we need a documentation update here? If so, where would be a good
place?
On Fri, 2024-02-23 at 15:30 -0600, Nathan Bossart wrote:
> Why is this change needed? Is the idea to make amcheck follow the
> same
> rules as maintenance commands to encourage folks to set up
Here’s a patch for this.- Kori
session-user-prompt.patch
Description: Binary data
On May 27, 2023, at 8:52 AM, Andrew Dunstan wrote:
I don't recall if this has come up before.
I'm sometimes mildly annoyed when I get on
a new system and find the username missing in my
On Tue, Feb 27, 2024 at 09:24:25AM +0100, Daniel Gustafsson wrote:
> I have it on my TODO for the upcoming CF.
Okay, thanks.
--
Michael
signature.asc
Description: PGP signature
On Wed, Feb 28, 2024 at 9:24 AM Heikki Linnakangas wrote:
> Here's a patch to fully remove AIX support.
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -3401,7 +3401,7 @@ export MANPATH
PostgreSQL can be expected to work on current
versions of these
Andrei Lepikhov writes:
> IMO, the routine eval_const_expressions_mutator contains some stale code:
I'd like to push back against the idea that eval_const_expressions
is expected to return a freshly-copied tree. Its API specification
contains no such claim. It's true that it appears to do that
> On 27 Feb 2024, at 22:03, Heikki Linnakangas wrote:
> Any objections to removing the ./configure --with-CC option? It's been
> deprecated since commit cb292206c5 from July 2000:
None, and removing it will chip away further at getting autoconf and meson
fully in sync so +1.
--
Daniel
Any objections to removing the ./configure --with-CC option? It's been
deprecated since commit cb292206c5 from July 2000:
# For historical reasons you can also use --with-CC to specify the C compiler
# to use, although the standard way to do this is to set the CC environment
# variable.
Hi,
On 2024-02-27 15:45:45 -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> With AIX out of the picture, lapwing will be the only remaining
> animal testing MAXALIGN less than 8. That seems like a single
> point of failure ... should we spin up another couple 32-bit
> animals? I had
Andres,
After consulting some Intel internal experts on MSVC the linking issue as it
stood was not resolved. Instead, I created a MSVC ONLY work-around. This adds
one extra functional call on the Windows builds (The linker resolves a real
function just fine but not a function pointer of the
Heikki Linnakangas writes:
> What do y'all think of adding a check for
> ALIGNOF_DOUBLE==MAXIMUM_ALIGNOF to configure.ac and meson.build? It's
> not a requirement today, but I believe AIX was the only platform where
> that was not true. With AIX gone, that combination won't be tested, and
>
On 26/02/2024 06:18, Michael Paquier wrote:
On Mon, Feb 26, 2024 at 09:42:03AM +0530, Robert Haas wrote:
On Mon, Feb 26, 2024 at 1:21 AM Tom Lane wrote:
So, we now need to strip the remnants of AIX support from the code and
docs? I don't see that much of it, but it's misleading to leave it
Hi!
On Tue, Jan 30, 2024 at 8:46 PM Pavel Stehule wrote:
> I marked this patch as ready for committer.
The last version of the patch still provides transform for builtin
type in a separate extension. As discussed upthread such transforms
don't need separate extensions, and could be provided as
Hi Hackers,
The current descriptions for server_ca.config and client_ca.config are
not so accurate. For example, one of the descriptions in
server_ca.config states, "This certificate is used to sign server
certificates. It is self-signed." However, the server_ca.crt and
client_ca.crt are
On Tue, Feb 27, 2024 at 11:20 AM Jacob Champion
wrote:
> This is done in v17, which is also now based on the two patches pulled
> out by Daniel in [1].
It looks like my patchset has been eaten by a malware scanner:
550 Message content failed content scanning
On Tue, Feb 27, 2024 at 11:59:00PM +0500, Kirill Reshke wrote:
> Do we need to test the pg_cancel_backend vs autovacuum case at all?
> I think we do. Would it be better to split work into 2 patches: first one
> with tests against current logic, and second
> one with some changes/enhancements which
I wrote:
> Hmm, yeah. The "stride_usecs > 1" test seems like it's a partial
> attempt to account for this that is probably redundant given the
> additional condition. Also, can we avoid computing tm_diff %
> stride_usecs twice? Maybe the compiler is smart enough to remove the
> common
On Tue, Feb 27, 2024 at 01:22:31AM +0500, Kirill Reshke wrote:
> Also, tap tests for functionality added. I'm not sure where to place them,
> so I placed them in a separate directory in `src/test/`
> Seems that regression tests for this feature are not possible, am i right?
It might be difficult
On Tue, 27 Feb 2024 at 01:22, Kirill Reshke wrote:
>
>
> On Mon, 26 Feb 2024 at 20:10, Nathan Bossart
> wrote:
>
>> On Mon, Feb 26, 2024 at 12:38:40PM +0500, Kirill Reshke wrote:
>> > I see 2 possible ways to implement this. The first one is to have hool
>> in
>> > pg_signal_backend, and define
On Tue, 27 Feb 2024 at 15:49, Ivan Trofimov wrote:
> Caching the result of PQfnumber could be done, but would result in
> somewhat of a mess on a call-site.
To be clear I meant your wrapper around libpq could internally cache
this, then the call sites of users of your wrapper would not need to
On 2024-Feb-27, Alvaro Herrera wrote:
> Here's the complete set, with these two names using the singular.
BTW one thing I had not noticed is that before this patch we have
minimum shmem size that's lower than the lowest you can go with the new
code.
This means Postgres may no longer start when
> On 27 Feb 2024, at 22:33, Alvaro Herrera wrote:
>
>
These patches look amazing!
Best regards, Andrey Borodin.
Here's the complete set, with these two names using the singular.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Uno puede defenderse de los ataques; contra los elogios se esta indefenso"
>From 225b2403f7bb9990656d18c8339c452fcd6822c5 Mon Sep 17 00:00:00 2001
On Sat, 24 Feb 2024 at 17:10, Tomas Vondra
wrote:
>
> Hi Dean,
>
> I did a quick review and a little bit of testing on the patch today. I
> think it's a good/useful idea, and I think the code is ready to go (the
> code is certainly much cleaner than anything I'd written ...).
>
Thanks for
Moaaz Assali writes:
> The date_bin() function has a bug where it returns an incorrect binned date
> when both of the following are true:
> 1) the origin timestamp is before the source timestamp
> 2) the origin timestamp is exactly equivalent to some valid binned date in
> the set of binned dates
On Mon, 12 Feb 2024 at 14:27, Jelte Fennema-Nio wrote:
> Would a backtrace_functions_level GUC that would default to ERROR be
> acceptable in this case?
I implemented it this way in the attached patchset.
From 71e2c1f1fa903ecfce4a79ff5981d0d754d134a2 Mon Sep 17 00:00:00 2001
From: Jelte
On 2024-Feb-27, Andrey M. Borodin wrote:
> Sorry for the late reply, I have one nit. Are you sure that
> multixact_members and multixact_offsets are plural, while transaction
> and commit_timestamp are singular?
> Maybe multixact_members and multixact_offset? Because there are many
> members and
> On 27 Feb 2024, at 21:03, Alvaro Herrera wrote:
>
> On 2024-Feb-27, Dilip Kumar wrote:
>
>>> static const char *const slru_names[] = {
>>>"commit_timestamp",
>>>"multixact_members",
>>>"multixact_offsets",
>>>"notify",
>>>"serializable",
>>>
On Tue, 27 Feb 2024 at 16:04, Japin Li wrote:
> I see the config_group_names[] needs null-terminated because of help_config,
> however, I didn't find the reference in help_config.c. Is this comment
> outdated?
Yeah, you're correct. That comment has been outdated for more than 20
years. The
On 2024-Feb-27, Dilip Kumar wrote:
> > static const char *const slru_names[] = {
> > "commit_timestamp",
> > "multixact_members",
> > "multixact_offsets",
> > "notify",
> > "serializable",
> > "subtransaction",
> > "transaction",
> >
On Mon, Feb 26, 2024 at 9:20 PM Andrew Dunstan wrote:
> The good news is that the parser is doing fine - this issue was due to a
> thinko on my part in the test program that got triggered by the input
> file size being an exact multiple of the chunk size. I'll have a new
> patch set later this
On Tue, 27 Feb 2024 at 19:55, Jelte Fennema-Nio wrote:
> On Tue, 27 Feb 2024 at 12:52, Jelte Fennema-Nio wrote:
>> Attached is an updated patchset to also convert pg_enc2icu_tbl and
>> pg_enc2gettext_tbl. I converted pg_enc2gettext_tbl in a separate
>> commit, because it actually requires some
On Mon, 26 Feb 2024 at 12:33, Masahiko Sawada wrote:
>
> On Fri, Feb 23, 2024 at 6:24 PM vignesh C wrote:
> >
> > On Fri, 9 Feb 2024 at 20:51, Masahiko Sawada wrote:
> > >
> > >
> > > I think this performance regression is not acceptable. In this
> > > workload, one transaction has 10k
However, I do think you could convert this per-row overhead in your
case to per-query overhead by caching the result of PQfnumber for each
unique C++ string_view. Afaict that should solve your performance
problem.
Absolutely, you're right.
The problem here is not that it's impossible to write
Greetings,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> On 2024-Feb-26, Stephen Frost wrote:
> > Here's an updated patch which tries to improve on the wording a bit by
> > having it be a bit more consistent. Would certainly welcome feedback on
> > it though, of course. This is a tricky
On 2024-Feb-27, Peter Geoghegan wrote:
> I have a feeling that there are going to be real problems with
> alerting, at least if it's introduced right away. I'd feel much better
> about it if there was an existing body of suppressions, that more or
> less worked as a reference of agreed upon best
On Mon, 26 Feb 2024 at 10:57, Andrew Dunstan wrote:
>
>
> On 2024-02-25 Su 11:18, vignesh C wrote:
> > On Thu, 15 Feb 2024 at 08:36, vignesh C wrote:
> >> On Thu, 15 Feb 2024 at 07:24, Michael Paquier wrote:
> >>> On Wed, Feb 14, 2024 at 03:51:08PM +0530, vignesh C wrote:
> First regex is
On Tue, Feb 27, 2024 at 9:03 AM Alvaro Herrera wrote:
> Now, maybe a buildfarm animal is not the right tool, and instead we need
> a separate system that tests for it and emails pg-hackers when it breaks
> or whatever. That's fine with me, but it seems a pretty minor
> implementation detail.
On 2/27/24 10:55, Benoit Lobréau wrote:
> On 2/25/24 20:13, Tomas Vondra wrote:
>> 1) name of the GUC
> ...
>> 2) logging just the failures provides an incomplete view
>> log_parallel_workers = {none | failures | all}>
>> where "failures" only logs when at least one worker fails to start, and
>>
On 2024-Feb-27, Peter Geoghegan wrote:
> On Tue, Feb 27, 2024 at 8:25 AM Alvaro Herrera
> wrote:
> > The way I see this working, is that we set up a buildfarm animal [per
> > architecture] that runs the new rules produced by the abidw option and
> > stores the result locally, so that for stable
On Tue, Feb 27, 2024 at 8:25 AM Alvaro Herrera wrote:
> The way I see this working, is that we set up a buildfarm animal [per
> architecture] that runs the new rules produced by the abidw option and
> stores the result locally, so that for stable branches it can turn red
> when an ABI-breaking
Hi,
On Tue, Feb 27, 2024 at 04:49:03PM +0500, Andrey M. Borodin wrote:
> Hi,
>
> > On 27 Feb 2024, at 16:08, Bertrand Drouvot
> > wrote:
> >
> > On Tue, Feb 27, 2024 at 11:00:10AM +0500, Andrey M. Borodin wrote:
> >>
> >> But, AFAICS, the purpose is the same: wait until event happened.
> >
Hi Amit,
On Tuesday, February 27, 2024 16:00 MSK, Amit Kapila
wrote:
As we do XLogFlush() at the time of prepare then why it is not available? OR
are you talking about this state after your idea/patch where you are trying to
make both Prepare and Commit_prepared records async?Right, I'm
On 2023-Nov-01, Peter Eisentraut wrote:
> v3-0001-abidw-option.patch
>
> This adds the abidw meson option, which produces the xml files with the ABI
> description. With that, you can then implement a variety of workflows, such
> as the abidiff proposed in the later patches, or something rigged
On Tue, Feb 27, 2024 at 2:00 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > We do append dbname=replication even in libpqrcv_connect for .pgpass
> > lookup as mentioned in comments. See below:
> > libpqrcv_connect()
> > {
> >
> > else
> > {
> > /*
> > * The database name is ignored by the server in
On Tue, Feb 27, 2024 at 12:40 PM Andrew Dunstan wrote:
>
> On 2024-02-02 Fr 00:31, Jeevan Chalke wrote:
>
>
>
> On Thu, Feb 1, 2024 at 11:25 AM Kyotaro Horiguchi
> wrote:
>
>> At Thu, 1 Feb 2024 09:22:22 +0530, Jeevan Chalke <
>> jeevan.cha...@enterprisedb.com> wrote in
>> > On Thu, Feb 1, 2024
On Tue, Feb 27, 2024 at 4:49 PM Давыдов Виталий
wrote:
>
> Thank you for your interest in the discussion!
>
> On Monday, February 26, 2024 16:24 MSK, Amit Kapila
> wrote:
>
>
> I think the reason is probably that when the WAL record for prepared is
> already flushed then what will be the idea
On Fri, 23 Feb 2024 at 00:12, Tom Lane wrote:
>
> So after studying this for awhile, I see that the planner is emitting
> a PlanRowMark that presumes that the UNION ALL subquery will be
> scanned as though it's a base relation; but since we've converted it
> to an appendrel, the executor just
Hello,
On 2024-Feb-26, Stephen Frost wrote:
> Here's an updated patch which tries to improve on the wording a bit by
> having it be a bit more consistent. Would certainly welcome feedback on
> it though, of course. This is a tricky bit of language to write and
> a complex optimization to
On Tue, 27 Feb 2024 at 00:31, Ivan Trofimov wrote:
> I see now that I failed to express myself clearly: it's not a per-query
> overhead, but rather a per-result-field one.
I'm fairly sympathetic to decreasing the overhead of any per-row
operation. And looking at the code, it doesn't surprise me
On Tue, Feb 27, 2024 at 12:48 PM Peter Smith wrote:
>
> Here are some review comments for v99-0001
>
> ==
> 0. GENERAL.
>
> +#standby_slot_names = '' # streaming replication standby server slot names
> that
> + # logical walsender processes will wait for
>
> IMO the GUC name is too
On Tue, 27 Feb 2024 at 08:57, Alvaro Herrera wrote:
> What this says to me is that ObjectClass is/was a somewhat useful
> abstraction layer on top of catalog definitions. I'm now not 100% that
> poking this hole in the abstraction (by expanding use of catalog OIDs at
> the expense of
Dear Postgres Community,
I hope this email finds you well. I am reaching out to seek clarification
on an issue I am encountering with logical replication in PostgreSQL.
My specific question pertains to determining the appropriate LSN (Log
Sequence Number) from which to start logical replication.
On Tue, Feb 27, 2024 at 4:07 PM Bertrand Drouvot
wrote:
>
> On Tue, Feb 27, 2024 at 06:17:44PM +1100, Peter Smith wrote:
> > +static bool
> > +validate_standby_slots(char **newval)
> > +{
> > + char*rawname;
> > + List*elemlist;
> > + ListCell *lc;
> > + bool ok;
> > +
> > + /* Need a
On Tue, 27 Feb 2024 at 12:52, Jelte Fennema-Nio wrote:
> Attached is an updated patchset to also convert pg_enc2icu_tbl and
> pg_enc2gettext_tbl. I converted pg_enc2gettext_tbl in a separate
> commit, because it actually requires some codechanges too.
Another small update to also make all arrays
On Tue, 27 Feb 2024 at 07:25, Michael Paquier wrote:
> About 0002, I can't help but notice pg_enc2icu_tbl and
> pg_enc2gettext_tb. There are exceptions like MULE_INTERNAL, but is it
> possible to do better?
Attached is an updated patchset to also convert pg_enc2icu_tbl and
pg_enc2gettext_tbl. I
Hi,
> On 27 Feb 2024, at 16:08, Bertrand Drouvot
> wrote:
>
> On Tue, Feb 27, 2024 at 11:00:10AM +0500, Andrey M. Borodin wrote:
>>
>> But, AFAICS, the purpose is the same: wait until event happened.
>
> I think it's easier to understand the tests (I mean what the purpose of the
> injection
Patches attached.
PS Correction to my earlier statement about POSIX: the traditional K
interfaces were indeed in the original POSIX.1 1988 but it was the
1990 edition (approximately coinciding with standard C) that adopted
void, size_t, const and invented ssize_t.
Hi Amit,
Thank you for your interest in the discussion!
On Monday, February 26, 2024 16:24 MSK, Amit Kapila
wrote:
I think the reason is probably that when the WAL record for prepared is already
flushed then what will be the idea of async commit here?I think, the idea of
async commit
On Mon, Feb 12, 2024 at 7:47 PM Peter Eisentraut wrote:
>
>
> In principle, hashRowType() could process all the fields that
> equalRowTypes() does. But since it's only a hash function, it doesn't
> have to be perfect. (This is also the case for the current
> hashTupleDesc().) I'm not sure
Hi,
On Tue, Feb 27, 2024 at 11:00:10AM +0500, Andrey M. Borodin wrote:
>
>
> > On 27 Feb 2024, at 04:29, Michael Paquier wrote:
> >
> > For
> > example, the test just posted here does not rely on that:
> >
On Tue, 27 Feb 2024 at 07:25, Michael Paquier wrote:
>
> On Mon, Feb 26, 2024 at 05:00:13PM +0800, Japin Li wrote:
> > On Mon, 26 Feb 2024 at 16:41, jian he wrote:
> >> obvious typo errors.
>
> These would cause compilation failures. Saying that, this is a very
> nice cleanup, so I've fixed
Hi,
On Tue, Feb 27, 2024 at 06:17:44PM +1100, Peter Smith wrote:
> +static bool
> +validate_standby_slots(char **newval)
> +{
> + char*rawname;
> + List*elemlist;
> + ListCell *lc;
> + bool ok;
> +
> + /* Need a modifiable copy of string */
> + rawname = pstrdup(*newval);
> +
> + /*
Hello Daniel,
I have added a test case for this in timestamp.sql and timestamp.out, and
tests pass when using the bug fix patch in the first email.
I have attached a new patch in this email below with the new tests only
(doesn't include the bug fix).
P.S. I forgot to CC the mailing list in my
On Fri, Feb 23, 2024 at 6:05 PM Ashutosh Bapat
wrote:
>
> On Tue, Feb 20, 2024 at 3:51 PM Peter Eisentraut wrote:
> >
> > I have reverted the patch for now (and re-opened the commitfest entry).
> > We should continue to work on this and see if we can at least try to get
> > the pg_dump test
On 2/25/24 23:32, Peter Smith wrote:
Also, I don't understand how the word "draught" (aka "draft") makes
sense here -- I assume the intended word was "drought" (???).
yes, that was the intent, sorry about that. English is not my native
langage and I was convinced the spelling was correct.
Dear Euler,
> Sorry, which pg_rewind option did you mention? I cannot find.
> IIUC, -l is an only option which can accept the path, but it is not related
> with us.
Sorry, I found [1]. I was confused with pg_resetwal. But my opinion was not so
changed.
The reason why --config-file exists is
On Mon, Feb 26, 2024 at 9:46 PM Alvaro Herrera
wrote:
> On 2024-Feb-23, Dilip Kumar wrote:
>
> +
> + For each SLRU area that's part of the core server,
> + there is a configuration parameter that controls its size, with the
> suffix
> + _buffers appended. For historical
> + reasons,
On 2/25/24 20:13, Tomas Vondra wrote:
> 1) name of the GUC
...
> 2) logging just the failures provides an incomplete view
> log_parallel_workers = {none | failures | all}>
> where "failures" only logs when at least one worker fails to start, and
> "all" logs everything.
>
> AFAIK Sami made the
> On 27 Feb 2024, at 09:42, Moaaz Assali wrote:
> To account for this edge, we simply add another condition in the if statement
> to not perform the subtraction by one stride interval if the time difference
> is divisible by the stride.
I only skimmed the patch, but I recommend adding a
Hello,
The date_bin() function has a bug where it returns an incorrect binned date
when both of the following are true:
1) the origin timestamp is before the source timestamp
2) the origin timestamp is exactly equivalent to some valid binned date in
the set of binned dates that date_bin() can
> PSA the patch for implementing it. It is basically same as Ian's one.
> However, this patch still cannot satisfy the condition 3).
>
> `pg_basebackup -D data_N2 -d "user=postgres" -R`
> -> dbname would not be appeared in primary_conninfo.
>
> This is because `if (connection_string)` case in
Dear Amit,
> We do append dbname=replication even in libpqrcv_connect for .pgpass
> lookup as mentioned in comments. See below:
> libpqrcv_connect()
> {
>
> else
> {
> /*
> * The database name is ignored by the server in replication mode,
> * but specify "replication" for .pgpass lookup.
>
Dear Amit,
> When dbname is NULL or not given, it defaults to username. This
> follows the specs of the connection string. See (dbname #
> The database name. Defaults to be the same as the user name...) [1].
> Your patch breaks that specs, so I don't think it is correct.
I have proposed the
> On 27 Feb 2024, at 06:08, Michael Paquier wrote:
>
> On Mon, Feb 26, 2024 at 12:28:51AM +0100, Daniel Gustafsson wrote:
>> Yeah, I think this is for HEAD only, especially given the lack of complaints
>> against backbranches.
>
> Daniel, are you planning to look at that? I haven't done any
97 matches
Mail list logo
