Dear Euler,
Again, thanks for updating the patch! There are my random comments for v9.
01.
I cannot find your replies for my comments#7 [1] but you reverted related
changes.
I'm not sure you are still considering it or you decided not to include changes.
Can you clarify your opinion?
(It is
On Fri, 26 Jan 2024 at 19:03, Richard Guo wrote:
> At first I wondered if we should assume that the same param expr must
> have the same equality operator. If not, we should also check the
> operator to tell if the cache key is a duplicate, like
>
> - if (!list_member(*param_exprs,
In 5543677ec9 we introduced an optimization that uses Limit instead of
Unique to implement DISTINCT when all the DISTINCT pathkeys have been
marked as redundant. I happened to notice that this optimization was
not applied to partial DISTINCT, which I think should be. This can
improve plans in
On Thu, Jan 25, 2024 at 10:17 PM Aleksander Alekseev
wrote:
>
> Hi,
>
> > > Here is the corrected patch.
> >
> > Thank you for updating the patch! I have some comments:
>
> Thanks for the review.
>
> > -tuple = (ReorderBufferTupleBuf *)
> > +tuple = (HeapTuple)
> >
On Thursday, January 25, 2024, Yugo NAGATA wrote:
>
> Maybe, we can separate the sentese to two, for example:
>
> COPY stops operation at the first error. (The exception is if the error
> is due to data type incompatibility and a value other than stop is
> specified
> to the ON_ERROR
Currently, nodeMemoize.c builds the hashtable for the cache during
executor startup. This is not what is done in hash joins. I think we
should make the two behave the same way.
Per [1] and the corresponding discussion leading to that, making a
possibly large allocation at executor startup can
On Fri, 26 Jan 2024 15:26:55 +0900
Masahiko Sawada wrote:
> On Fri, Jan 26, 2024 at 2:40 PM Yugo NAGATA wrote:
> >
> > On Fri, 26 Jan 2024 13:59:09 +0900
> > Masahiko Sawada wrote:
> >
> > > On Fri, Jan 26, 2024 at 11:28 AM Yugo NAGATA wrote:
> > > >
> > > > Hi,
> > > >
> > > > I found that
> On 26 Jan 2024, at 11:44, Andrey M. Borodin wrote:
>
>
> 1. It’s unsafe for isaoltion tester to await transaction_timeout within a
> query. Usually it gets
> FATAL: terminating connection due to transaction timeout
> But if VM is a bit slow it can get occasional
> PQconsumeInput failed:
> On 22 Jan 2024, at 11:23, Peter Smith wrote:
>
> Hi, This patch has a CF status of "Needs Review" [1], but it seems
> there was a CFbot test failure last time it was run [2]. Please have a
> look and post an updated version if necessary.
Thanks Peter!
I’ve inspected CI fails and they were
On 2024-Jan-25, Alvaro Herrera wrote:
> Finally, the matter of using ifunc as proposed by Noah seems to be still
> in the air, with no patches offered for the popcount family.
Oh, I just realized that the patch as currently proposed is placing the
optimized popcount code in the path that does
On Thu, Jan 25, 2024 at 10:40 PM Yugo NAGATA wrote:
> On Fri, 26 Jan 2024 13:59:09 +0900
> Masahiko Sawada wrote:
>
> > On Fri, Jan 26, 2024 at 11:28 AM Yugo NAGATA
> wrote:
> > >
> > > Hi,
> > >
> > > I found that the documentation of COPY ON_ERROR said
> > > COPY stops operation at the first
On 25.01.24 17:25, Tristan Partin wrote:
The way that this currently works is that you will fail at configure
time if bz2 doesn't exist on the system. Meson will try to resolve a
.path() method on a NotFoundProgram. You might want to define the bz2
target to just call `exit 1` in this case.
On Fri, Jan 26, 2024 at 2:40 PM Yugo NAGATA wrote:
>
> On Fri, 26 Jan 2024 13:59:09 +0900
> Masahiko Sawada wrote:
>
> > On Fri, Jan 26, 2024 at 11:28 AM Yugo NAGATA wrote:
> > >
> > > Hi,
> > >
> > > I found that the documentation of COPY ON_ERROR said
> > > COPY stops operation at the first
On Fri, Jan 26, 2024 at 12:18 PM David Rowley wrote:
> On Fri, 26 Jan 2024 at 16:51, Tom Lane wrote:
> > >> However ... it seems like we're not out of the woods yet. Why
> > >> is Richard's proposed test case still showing
> > >> + -> Memoize (actual rows=5000 loops=N)
> > >> +
Hello hackers,
After determining a possible cause for intermittent failures of the test
subscription/031_column_list [1], I was wondering what makes another
subscription test (014_binary) fail on the buildfarm:
Dear Euler,
Thanks for updating the patch! Before reading yours, I wanted to reply some of
comments.
>
I'm still thinking about replacing --subscriber-conninfo with separate items
(username, port, password?, host = socket dir). Maybe it is an overengineering.
The user can always prepare the
On Fri, 26 Jan 2024 13:59:09 +0900
Masahiko Sawada wrote:
> On Fri, Jan 26, 2024 at 11:28 AM Yugo NAGATA wrote:
> >
> > Hi,
> >
> > I found that the documentation of COPY ON_ERROR said
> > COPY stops operation at the first error when
> > "ON_ERROR is not specified.", but it also stop when
> >
On Fri, Jan 26, 2024 at 1:22 AM Tom Lane wrote:
> Apologies for not having noticed this thread before. I'm taking
> a look at it now. However, while sniffing around this I found
> what seems like an oversight in paramassign.c's
> assign_param_for_var(): it says it should compare all the same
>
On Fri, Jan 26, 2024 at 11:28 AM Yugo NAGATA wrote:
>
> Hi,
>
> I found that the documentation of COPY ON_ERROR said
> COPY stops operation at the first error when
> "ON_ERROR is not specified.", but it also stop when
> ON_ERROR is specified to the default value, "stop".
>
> I attached a very
On Fri, Jan 26, 2024 at 1:24 PM wrote:
>
> On Thu, 2024-01-25 at 16:11 -0500, reid.thomp...@crunchydata.com wrote:
> >
> > I walked through v6 and didn't note any issues.
Thank you for reviewing the patch!
> >
> > I do want to ask, the patch alters ReorderBufferReturnTupleBuf() and
> > drops
On Thu, 2024-01-25 at 16:11 -0500, reid.thomp...@crunchydata.com wrote:
>
> I walked through v6 and didn't note any issues.
>
> I do want to ask, the patch alters ReorderBufferReturnTupleBuf() and
> drops the unused parameter ReorderBuffer *rb. It seems that
> ReorderBufferFreeSnap(),
On Fri, 26 Jan 2024 at 16:51, Tom Lane wrote:
> >> However ... it seems like we're not out of the woods yet. Why
> >> is Richard's proposed test case still showing
> >> + -> Memoize (actual rows=5000 loops=N)
> >> + Cache Key: t1.two, t1.two
> >> Seems like there is
David Rowley writes:
> I've adjusted the comments to what you mentioned and also leaned out
> the pretty expensive test case to something that'll run much faster
> and pushed the result.
+1, I was wondering if the test could be cheaper. It wasn't horrid
as Richard had it, but core regression
On Fri, 26 Jan 2024 at 07:32, Tom Lane wrote:
>
> David Rowley writes:
> > I'd feel better about doing it your way if Tom could comment on if
> > there was a reason he put the function calls that way around in
> > 5ebaaa494.
>
> I'm fairly sure I thought it wouldn't matter because of the Param
>
On Thu, Jan 25, 2024 at 05:44:52PM -0400, David Steele wrote:
> On 1/25/24 17:42, Tom Lane wrote:
>> We're talking about 1d35f705e, right? That certainly looks harmless
>> and potentially useful. I'm +1 for back-patching.
>
> That's the one. If we were modifying existing messages I would be
On Thu, 2024-01-25 at 14:35 +0530, Bharath Rupireddy wrote:
>
> "expecting zeros at the end" - this can't always be true as the WAL
>
...
> I think this needs to be discussed separately. If okay, I'll start a
> new thread.
Thank you for investigating. When the above issue is handled, I'll be
On Fri, Jan 26, 2024 at 2:32 AM Tom Lane wrote:
> I'm fairly sure I thought it wouldn't matter because of the Param
> de-duplication done in paramassign.c. However, Richard's example
> shows that's not so, because process_subquery_nestloop_params is
> picky about the param ID assigned to a
On Tue, 5 Dec 2023 at 00:57, Thomas Munro wrote:
>
> On second thoughts, I guess it would make more sense to use the exact
> messages Windows' own implementation would return instead of whatever
> we had in the past (probably cribbed from some other OS or just made
> up?). I asked CI to spit
On Mon, 27 Nov 2023 at 21:58, vignesh C wrote:
>
> On Fri, 24 Nov 2023 at 18:37, Shubham Khanna
> wrote:
> >
> > n Fri, Nov 24, 2023 at 6:33 PM vignesh C wrote:
> > >
> > > Hi,
> > >
> > > Improved tab completion for "ALTER DEFAULT PRIVILEGE" and "ALTER TABLE":
> > > 1) GRANT, REVOKE and FOR
On Tue, 24 Oct 2023 at 01:47, Alena Rybakina wrote:
>
> Hi!
>
> I looked through your patch and noticed that it was not applied to the
> current version of the master. I rebased it and attached a version. I didn't
> see any problems and, honestly, no big changes were needed, all regression
>
Hi,
I found that the documentation of COPY ON_ERROR said
COPY stops operation at the first error when
"ON_ERROR is not specified.", but it also stop when
ON_ERROR is specified to the default value, "stop".
I attached a very small patch to fix this just for
making the description more accurate.
On Sun, 5 Nov 2023 at 01:49, Bharath Rupireddy
wrote:
>
> On Thu, Jul 20, 2023 at 8:22 PM Daniel Gustafsson wrote:
> >
> > > On 11 Jan 2023, at 15:44, Bharath Rupireddy
> > > wrote:
> > >
> > > On Wed, Nov 30, 2022 at 11:43 AM Bharath Rupireddy
> > > wrote:
> > >>
> > >> I'm attaching the v22
On Wed, 20 Dec 2023 at 19:17, Jelte Fennema-Nio wrote:
>
> On Thu, 14 Dec 2023 at 13:57, Jelte Fennema-Nio wrote:
> > I changed all the places that were not adhering to those spellings.
>
> It seems I forgot a /g on my sed command to do this so it turned out I
> missed one that caused the test
On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan wrote:
>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>> Yeah, I think the default Developer Command Prompt for VS2022 is set up
>> for x86 builds. AIUI you should start by executing
On Thu, Jan 25, 2024 at 20:33 Amit Kapila wrote:
> On Thu, Jan 25, 2024 at 4:01 PM Wei Wang (Fujitsu)
> wrote:
> >
> >
> > Yes, agree. I think these two parts have become slightly outdated after the
> > commit 1632ea4. So also tried to fix the first part of the comment.
> > Attach the new patch.
On Thu, Jan 25, 2024 at 08:56:52AM -0400, David Steele wrote:
> I would still advocate for a back patch here. It is frustrating to get logs
> from users that just say:
>
> LOG: invalid checkpoint record
> PANIC: could not locate a valid checkpoint record
>
> It would be very helpful to know
Hi,
Attached is a simple patch to rename setup_cancel_handler()
in pg_dump/parallel.c.
I am proposing it because there is a public function with
the same name in fe_utils/cancel.c. I know pg_dump/parallel.c
does not include fe_utils/cancel.h, so there is no conflict,
but I think it is better to
On Tue, 2 Jan 2024 08:00:00 +0800
jian he wrote:
> On Mon, Nov 6, 2023 at 8:00 AM jian he wrote:
> >
> > minor doc issues.
> > Returns the chunk id of the TOASTed value, or NULL if the value is not
> > TOASTed.
> > Should it be "chunk_id"?
Thank you for your suggestion. As you pointed out, it
On Thu, Jan 25, 2024, at 6:05 AM, Hayato Kuroda (Fujitsu) wrote:
> 01.
> ```
> /* Options */
> static char *pub_conninfo_str = NULL;
> static SimpleStringList database_names = {NULL, NULL};
> static int wait_seconds = DEFAULT_WAIT;
> static bool retain = false;
> static bool dry_run = false;
> ```
On Thu, Jan 25, 2024 at 05:45:43PM +0900, Sutou Kouhei wrote:
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Thu, 25 Jan 2024 12:17:55 +0900,
> Michael Paquier wrote:
>> +extern CopyToRoutine CopyToRoutineText;
>> +extern CopyToRoutine
On Tue, Jan 23, 2024, at 10:29 PM, Euler Taveira wrote:
> I'll post a new one soon.
I'm attaching another patch that fixes some of the issues pointed out by
Hayato, Shlok, and Junwang.
* publication doesn't exist. The analysis [1] was done by Hayato but I didn't
use the proposed patch. Instead
On 1/25/24 13:41, Thomas Munro wrote:
On Thu, Jan 25, 2024 at 4:44 PM Thomas Munro wrote:
... A few build farm animals will
now fail in the configure step as discussed, and need some adjustment
(ie disable LLVM or upgrade to LLVM 10+ for the master branch).
Owners pinged.
I think I fixed
On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan wrote:
>
> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>
>
>
> On Thu, 25 Jan 2024 at 16:04, Anthony Roberts
> wrote:
>
>> Hi David,
>>
>> Unix "file" or "dumpbin /headers" in vcvarsall are your best bets.
>>
>> Thanks,
>> Anthony
>>
>
>
> So there is
On 1/25/24 17:42, Tom Lane wrote:
David Steele writes:
Another thing to note here -- knowing the LSN is important but also
knowing that backup recovery was attempted (i.e. backup_label exists) is
really crucial. Knowing both just saves so much time in back and forth
debugging.
It appears
David Steele writes:
> Another thing to note here -- knowing the LSN is important but also
> knowing that backup recovery was attempted (i.e. backup_label exists) is
> really crucial. Knowing both just saves so much time in back and forth
> debugging.
> It appears the tally for back patching
On Thu, Jan 25, 2024 at 4:44 PM Thomas Munro wrote:
> ... A few build farm animals will
> now fail in the configure step as discussed, and need some adjustment
> (ie disable LLVM or upgrade to LLVM 10+ for the master branch).
Owners pinged.
On 1/25/24 09:29, Michael Banck wrote:
Hi,
On Thu, Jan 25, 2024 at 08:56:52AM -0400, David Steele wrote:
I would still advocate for a back patch here. It is frustrating to get logs
from users that just say:
LOG: invalid checkpoint record
PANIC: could not locate a valid checkpoint record
It
On 2024-01-25 Th 16:17, Dave Cramer wrote:
On Thu, 25 Jan 2024 at 16:04, Anthony Roberts
wrote:
Hi David,
Unix "file" or "dumpbin /headers" in vcvarsall are your best bets.
Thanks,
Anthony
So there is another way, select the file in Windows Explorer and right
click,
On 2024-01-25 Th 15:58, Tom Lane wrote:
I wrote:
There's something else going on, because I'm still getting the
assertion failure on my Mac with this fix in place. Annoyingly,
it goes away if I compile with -O0, so it's kind of hard to
identify what's going wrong.
No, belay that: I must've
On Thu, 25 Jan 2024 at 16:04, Anthony Roberts
wrote:
> Hi David,
>
> Unix "file" or "dumpbin /headers" in vcvarsall are your best bets.
>
> Thanks,
> Anthony
>
So there is another way, select the file in Windows Explorer and right
click, in the compatibility tab if the "Windows on ARM" is
On 2024-01-25 Th 15:56, Dave Cramer wrote:
On Thu, 25 Jan 2024 at 14:31, Andrew Dunstan wrote:
On 2024-01-25 Th 08:45, Dave Cramer wrote:
I tried running my buildfarm using my git repo and my branch, but
get the following error
Status Line: 492 bad branch parameter
On Thu, 2024-01-25 at 16:16 +0300, Aleksander Alekseev wrote:
> Hi,
>
> > > Here is the corrected patch.
> >
> > Thank you for updating the patch! I have some comments:
>
> Thanks for the review.
>
> > -tuple = (ReorderBufferTupleBuf *)
> > +tuple = (HeapTuple)
> >
Hi David,
Unix "file" or "dumpbin /headers" in vcvarsall are your best bets.
Thanks,
Anthony
On Thu, 25 Jan 2024, 21:01 Dave Cramer, wrote:
>
>
> On Thu, 25 Jan 2024 at 12:30, Andrew Dunstan wrote:
>
>>
>> On 2024-01-24 We 19:02, Michael Paquier wrote:
>>
>> On Wed, Jan 24, 2024 at
On 2024-01-25 Th 15:33, Tom Lane wrote:
Andrew Dunstan writes:
On 2024-01-25 Th 14:31, Tom Lane wrote:
(The reported crashes seem to be happening later during a
recursive invocation, seemingly because JsonbType(jb) is
returning garbage. So there may be another bug after this one.)
I don't
On Thu, 25 Jan 2024 at 12:30, Andrew Dunstan wrote:
>
> On 2024-01-24 We 19:02, Michael Paquier wrote:
>
> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote:
>
> I managed to get it to build the vcvarsall arch needs to be x64. I need to
> add some options, but the patch above needs to
Hey,
In a nearby user complaint email [1] some missing information regarding
ownership reassignment came to light. I took that and went a bit further
to add what I felt was further missing information and context for how the
privilege system is designed. I've tried to formalize and label
I wrote:
> There's something else going on, because I'm still getting the
> assertion failure on my Mac with this fix in place. Annoyingly,
> it goes away if I compile with -O0, so it's kind of hard to
> identify what's going wrong.
No, belay that: I must've got confused about which version I
On Thu, 25 Jan 2024 at 14:31, Andrew Dunstan wrote:
>
> On 2024-01-25 Th 08:45, Dave Cramer wrote:
>
>
>
>
>
> I tried running my buildfarm using my git repo and my branch, but get the
> following error
> Status Line: 492 bad branch parameter
> Content:
> bad branch parameter fix_arm
>
> Web txn
Hi
čt 11. 1. 2024 v 12:12 odesílatel Jelte Fennema-Nio
napsal:
> On Tue, 12 Sept 2023 at 09:46, Peter Eisentraut
> wrote:
> > ISTM that for a purpose like pgbouncer, it would be simpler to add a new
> > GUC "report these variables" and send that in the startup message? That
> > might not help
Andrew Dunstan writes:
> On 2024-01-25 Th 14:31, Tom Lane wrote:
>> (The reported crashes seem to be happening later during a
>> recursive invocation, seemingly because JsonbType(jb) is
>> returning garbage. So there may be another bug after this one.)
> I don't think so. AIUI The first call
On 2024-01-25 Th 14:31, Tom Lane wrote:
Andrew Dunstan writes:
Thanks, I have pushed this.
The buildfarm is pretty widely unhappy, mostly failing on
select jsonb_path_query('1.23', '$.string()');
On a guess, I tried running that under valgrind, and behold it said
==00:00:00:05.637
On 10/01/2024 18:17, Robert Haas wrote:
I think we should try to pick prefixes that are one or more words
rather than using word fragments. bulkw is an awkward prefix even for
people whose first language is English, and probably more awkward for
others.
Renamed the 'bulkw' variables to
On 2024-01-25 Th 14:31, Tom Lane wrote:
Andrew Dunstan writes:
Thanks, I have pushed this.
The buildfarm is pretty widely unhappy, mostly failing on
select jsonb_path_query('1.23', '$.string()');
On a guess, I tried running that under valgrind, and behold it said
==00:00:00:05.637
On 2024-01-25 Th 08:45, Dave Cramer wrote:
I tried running my buildfarm using my git repo and my branch, but get
the following error
Status Line: 492 bad branch parameter
Content:
bad branch parameter fix_arm
Web txn failed with status: 1
You can't use your own branch with the
Andrew Dunstan writes:
> Thanks, I have pushed this.
The buildfarm is pretty widely unhappy, mostly failing on
select jsonb_path_query('1.23', '$.string()');
On a guess, I tried running that under valgrind, and behold it said
==00:00:00:05.637 435530== Conditional jump or move depends on
On Thu, 25 Jan 2024 at 12:30, Andrew Dunstan wrote:
>
> On 2024-01-24 We 19:02, Michael Paquier wrote:
>
> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote:
>
> I managed to get it to build the vcvarsall arch needs to be x64. I need to
> add some options, but the patch above needs to
David Rowley writes:
> I think fixing it your way makes sense. I don't really see any reason
> why we should have two. However...
> Another way it *could* be fixed would be to get rid of pull_paramids()
> and change create_memoize_plan() to set keyparamids to all the param
> IDs that match are
On 2024-01-24 We 19:02, Michael Paquier wrote:
On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote:
I managed to get it to build the vcvarsall arch needs to be x64. I need to
add some options, but the patch above needs to be applied to build it.
Nice. If I may ask, what kind of host
On Thu, Jan 25, 2024 at 11:22 AM Alvaro Herrera wrote:
> Still with these auto-tuning GUCs, I noticed that the auto-tuning code
> would continue to grow the buffer sizes with shared_buffers to
> arbitrarily large values. I added an arbitrary maximum of 1024 (8 MB),
> which is much higher than
On Thu, Jan 25, 2024 at 11:19 AM Melanie Plageman
wrote:
> Cool. I might add "successfully" or "fully" to "Either way, the page
> hasn't been processed yet"
I'm OK with that.
> > > I think it would be nice to clarify this comment. I think the "when
> > > there is little free space anyway" is
David Rowley writes:
> I'd feel better about doing it your way if Tom could comment on if
> there was a reason he put the function calls that way around in
> 5ebaaa494.
Apologies for not having noticed this thread before. I'm taking
a look at it now. However, while sniffing around this I found
Aleksander,
In this case the documentation must state that the functions
uuid_extract_time() and uuidv7(T) are against the RFC requirements, and that
developers may use these functions with caution at their own risk, and these
functions are not recommended for production environment.
The
On 1/25/24 11:45, Dilip Kumar wrote:
> On Wed, Jan 24, 2024 at 11:43 PM Tomas Vondra
> wrote:
>
>> On 1/22/24 07:35, Konstantin Knizhnik wrote:
>>>
>>> On 22/01/2024 1:47 am, Tomas Vondra wrote:
h, right. Well, you're right in this case we perhaps could set just one
of those flags,
Hi,
As described in 9e2d870119, COPY ON_EEOR is expected to have more
"error_action".
(Note that option name was changed by b725b7eec)
I'd like to have a new option "log", which skips soft errors and logs
information that should have resulted in errors to PostgreSQL log.
I think this
On 2024-Jan-25, Alvaro Herrera wrote:
> Here's a touched-up version of this patch.
> diff --git a/src/backend/storage/lmgr/lwlock.c
> b/src/backend/storage/lmgr/lwlock.c
> index 98fa6035cc..4a5e05d5e4 100644
> --- a/src/backend/storage/lmgr/lwlock.c
> +++ b/src/backend/storage/lmgr/lwlock.c
>
On Thu Jan 25, 2024 at 10:04 AM CST, Peter Eisentraut wrote:
On 22.01.24 21:04, Tristan Partin wrote:
>> + 'HEAD', '.'],
>> + install: false,
>> + output: distdir + '.tar.bz2',
>> +)
>
> The bz2 target should be wrapped in an `if bzip2.found()`.
The way that this currently works
Here's a touched-up version of this patch.
First, PROC_GLOBAL->clogGroupFirst and SlruCtl->latest_page_number
change from being protected by locks to being atomics, but there's no
mention of considering memory barriers that they should have. Looking
at the code, I think the former doesn't need
On Thu, Jan 25, 2024 at 10:19 AM Robert Haas wrote:
>
> On Thu, Jan 25, 2024 at 9:18 AM Melanie Plageman
> wrote:
> > > To me, the first paragraph of this one misses the mark. What I thought
> > > we should be saying here was something like "If we don't have a
> > > cleanup lock, the code above
On Thu, Jan 25, 2024 at 10:06:41AM -0500, Robert Haas wrote:
> On Wed, Jan 24, 2024 at 2:39 PM Nathan Bossart
> wrote:
>> That seems like a reasonable starting point. Even if it doesn't help
>> determine the root cause, it should at least help rule out concurrent
>> summary removal.
>
> Here
On 22.01.24 21:04, Tristan Partin wrote:
+git = find_program('git', required: false, native: true, disabler: true)
+bzip2 = find_program('bzip2', required: false, native: true,
disabler: true)
This doesn't need to be a disabler. git is fine as-is. See later
comment. Disablers only work like
"David E. Wheeler" writes:
> On Jan 24, 2024, at 16:32, Tom Lane wrote:
>> +
>> + Predicate check expressions are required in the
>> + @@ operator (and the
>> + jsonb_path_match function), and should not be
>> used
>> + with the @? operator (or the
>> +
Amit Langote writes:
> On Fri, Jan 26, 2024 at 0:15 Tom Lane wrote:
>> Amit Langote writes:
>>> Ignoring the warning was my 1st thought too, because an old discussion I
>>> found about the warning was too old (2011). The style I adopted in my
>>> “fix” is used in a few other places too, so I
On 2024-01-18 Th 09:25, Jeevan Chalke wrote:
On Thu, Jan 18, 2024 at 1:03 AM Peter Eisentraut
wrote:
On 17.01.24 10:03, Jeevan Chalke wrote:
> I added unary '+' and '-' support as well and thus thought of
having
> separate rules altogether rather than folding those in.
On Fri, Jan 26, 2024 at 0:15 Tom Lane wrote:
> Amit Langote writes:
> > On Thu, Jan 25, 2024 at 23:57 Tom Lane wrote:
> >> -1 please. We should not break that abstraction for the sake
> >> of ignorable warnings on ancient compilers.
>
> > Ignoring the warning was my 1st thought too, because
On Thu, 25 Jan 2024 at 21:43, Aleksander Alekseev
wrote:
> Hi,
>
>> I find heapam_relation_copy_data() and index_copy_data() have the following
>> code:
>>
>> dstrel = smgropen(*newrlocator, rel->rd_backend);
>>
>> ...
>>
>> RelationCreateStorage(*newrlocator,
On Thu, Jan 25, 2024 at 9:18 AM Melanie Plageman
wrote:
> > To me, the first paragraph of this one misses the mark. What I thought
> > we should be saying here was something like "If we don't have a
> > cleanup lock, the code above has already processed this page to the
> > extent that is
Amit Langote writes:
> On Thu, Jan 25, 2024 at 23:57 Tom Lane wrote:
>> -1 please. We should not break that abstraction for the sake
>> of ignorable warnings on ancient compilers.
> Ignoring the warning was my 1st thought too, because an old discussion I
> found about the warning was too old
On Thu, Jan 25, 2024 at 23:57 Tom Lane wrote:
> Amit Langote writes:
> > On Thu, Jan 25, 2024 at 2:59 PM Richard Guo
> wrote:
> >> I came across a warning when building master (a044e61f1b) on old GCC
> >> (4.8.5).
>
> > Will apply the attached, which does this:
>
> > - return
On Wed, Jan 24, 2024 at 2:39 PM Nathan Bossart wrote:
> That seems like a reasonable starting point. Even if it doesn't help
> determine the root cause, it should at least help rule out concurrent
> summary removal.
Here is a patch for that.
--
Robert Haas
EDB: http://www.enterprisedb.com
Amit Langote writes:
> On Thu, Jan 25, 2024 at 2:59 PM Richard Guo wrote:
>> I came across a warning when building master (a044e61f1b) on old GCC
>> (4.8.5).
> Will apply the attached, which does this:
> - return BoolGetDatum(!SOFT_ERROR_OCCURRED());
> + return
On Thu, Jan 25, 2024 at 7:54 PM Amit Langote wrote:
>
> >
> > The problem with returning comp_domain_with_typmod from json_value()
> > seems to be that it's using a text-to-record CoerceViaIO expression
> > picked from JsonExpr.item_coercions, which behaves differently than
> > the expression
On Thu, Jan 25, 2024 at 8:57 AM Robert Haas wrote:
>
> On Wed, Jan 24, 2024 at 9:13 PM Melanie Plageman
> wrote:
> > v12 attached has my attempt at writing better comments for this
> > section of lazy_scan_heap().
>
> + /*
> + * If we didn't get the cleanup lock and the page is not new or empty,
On Wed, Jan 24, 2024 at 9:13 PM Melanie Plageman
wrote:
> v12 attached has my attempt at writing better comments for this
> section of lazy_scan_heap().
+ /*
+ * If we didn't get the cleanup lock and the page is not new or empty,
+ * we can still collect LP_DEAD items in the dead_items array for
On Thu, 25 Jan 2024 at 08:31, Dave Cramer wrote:
>
>
> On Wed, 24 Jan 2024 at 19:03, Michael Paquier wrote:
>
>> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote:
>> > I managed to get it to build the vcvarsall arch needs to be x64. I need
>> to
>> > add some options, but the patch
Hi,
> I find heapam_relation_copy_data() and index_copy_data() have the following
> code:
>
> dstrel = smgropen(*newrlocator, rel->rd_backend);
>
> ...
>
> RelationCreateStorage(*newrlocator, rel->rd_rel->relpersistence,
> true);
>
> The smgropen() is also called by
On Wed, 24 Jan 2024 at 19:03, Michael Paquier wrote:
> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote:
> > I managed to get it to build the vcvarsall arch needs to be x64. I need
> to
> > add some options, but the patch above needs to be applied to build it.
>
> Nice. If I may ask,
Hi,
On Thu, Jan 25, 2024 at 08:56:52AM -0400, David Steele wrote:
> I would still advocate for a back patch here. It is frustrating to get logs
> from users that just say:
>
> LOG: invalid checkpoint record
> PANIC: could not locate a valid checkpoint record
>
> It would be very helpful to
Hi,
> > Here is the corrected patch.
>
> Thank you for updating the patch! I have some comments:
Thanks for the review.
> -tuple = (ReorderBufferTupleBuf *)
> +tuple = (HeapTuple)
> MemoryContextAlloc(rb->tup_context,
> -
> sizeof(ReorderBufferTupleBuf) +
> +
On 1/25/24 04:12, Michael Paquier wrote:
On Mon, Jan 22, 2024 at 04:36:27PM +0900, Michael Paquier wrote:
+ if (ControlFile->backupStartPoint != InvalidXLogRecPtr)
Nit 1: I would use XLogRecPtrIsInvalid here.
+ ereport(LOG,
+ (errmsg("completed backup recovery with
Hi,
> Andrey, many thanks for the updated patch.
>
> LGTM, cfbot is happy and I don't think we have any open items left. So
> changing CF entry status back to RfC.
PFA v14. I changed:
```
elog(ERROR, "Time argument of UUID v7 cannot exceed 6 bytes");
```
... to:
```
ereport(ERROR,
1 - 100 of 131 matches
Mail list logo
