> The following review has been posted through the commitfest application:
> make installcheck-world: tested, failed
> Implements feature: tested, failed
> Spec compliant: tested, failed
> Documentation:tested, failed
Sorry, I thought I checked with the commitfest App,
On Tue, Jan 28, 2025 at 07:24:38AM +, keisuke kuroda wrote:
> I have confirmed that the coverage improves
> to the expected value（69.7%->83.0%)
>
> source: commit 75eb9766ec201b62f264554019757716093e2a2f(HEAD)
> ## add with-openssl option for ssltest
> ./configure --enable-coverage --enable-t
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
Thank you for your patch!
I have confirmed that the coverage
On Tue, Jan 28, 2025 at 3:58 AM Peter Smith wrote:
>
> On Fri, Jan 24, 2025 at 7:28 PM Ashutosh Bapat
> wrote:
> >
> > On Fri, Jan 24, 2025 at 8:14 AM Peter Smith wrote:
> > >
> > > On Thu, Jan 23, 2025 at 10:33 PM Ashutosh Bapat
> > > wrote:
> > > >
> > > > On Wed, Jan 22, 2025 at 7:29 PM Shub
On Tue, 28 Jan 2025 at 10:19, Srinath Reddy wrote:
>
>
> Hi mahendra,
>
> I have reviewed the code in the v11 patch and it looks good to me.
>
> But in common_dumpall_restore.c there's parseDumpFormat which is common
> between pg_dumpall and pg_restore ,as per the discussion in [1] thread i
> d
make check-world fails,i think we don't need $port and $filename instead we
can use something like 'xxx'.so fixed it in the below patch.
Regards,
Srinath Reddy Sadipiralla,
EDB: http://www.enterprisedb.com
v1-fix-make-check-world.patch
Description: Binary data
On Wed, Jan 22, 2025 at 03:45:30PM +0300, Vitaly Davydov wrote:
> I hope you may find this patch worth to consider. You may consider
> this patch as one more step to a complete migration to
> FullTransactionId in twophase.c for 17+ versions.
Heavy refactorings are only going to be something for 18
On Sat, Jan 25, 2025 at 6:45 AM Jim Jones wrote:
> On 25.01.25 11:50, Pavel Stehule wrote:
> > you still forces detoasting (inside PG_GETARG_XML_P)
>
>
> Ah, ok .. I overlooked it. You meant _DATUM instead of _XML_P
>
> Fixed in v8.
>
Was playing around with the patch and was thinking about this
Hi mahendra,
I have reviewed the code in the v11 patch and it looks good to me.
But in common_dumpall_restore.c there's parseDumpFormat which is common
between pg_dumpall and pg_restore ,as per the discussion in [1] thread i
don't think we should create a common api ,as discussed in the thread t
On 1/27/25 16:50, Alexander Korotkov wrote:
I expressed my point on this in [1]. We generally greedy about index
quals and there is no logic which prevent us from using a clause and
index qual because of its cost. And there are many cases when this
causes regressions before d4378c0005. One o
On Mon, Jan 27, 2025 at 05:13:39PM +0300, Nazir Bilal Yavuz wrote:
> On Mon, 27 Jan 2025 at 16:59, Nazir Bilal Yavuz wrote:
>>
>> On Mon, 27 Jan 2025 at 03:52, Michael Paquier wrote:
>> We use PendingWalStats.wal_[ write | sync ]_time only to show timings
>> on the pg_stat_wal view, right? And no
On Sun, Jan 26, 2025 at 10:08 PM Álvaro Herrera wrote:
>
> On 2025-Jan-25, Álvaro Herrera wrote:
>
> > On Sat, Jan 25, 2025, at 6:00 AM, Alexander Lakhin wrote:
> > > Hello Álvaro,
> > >
> > > Please look at the script that produces an error starting from b663b9436:
> >
> > Ah yes, this is my bug:
On Tue, Jan 28, 2025 at 4:31 AM Masahiko Sawada wrote:
>
> On Sun, Jan 26, 2025 at 10:26 PM Amit Kapila wrote:
> >
> > On Fri, Jan 24, 2025 at 12:38 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Jan 22, 2025 at 7:35 PM Peter Smith wrote:
> > > >
> > > > On Thu, Jan 23, 2025 at 2:17 PM Amit
On Fri, Jan 24, 2025 at 5:28 PM Zhijie Hou (Fujitsu)
wrote:
> Hi,
>
> I think the proposed feature is interesting, and after reviewing the
> original discussion thread, I'd like to help move it forward. To that end,
> I've
> summarized the key points of the discussion so far, including the
> chal
On 28.01.2025 02:00, Sami Imseih wrote:
Hi,
I have a few comments about the patch.
1/
tests are missing for pg_stat_statements.track=all and with a sample
rate < 1 applied.
Can we add tests for this case?
I think I’ve come up with a good idea for implementing this. We can
create a new file
On Mon, Jan 6, 2025 at 5:34 PM jian he wrote:
>
> hi.
>
> about this issue,
> last email in 2012 (https://postgr.es/m/8967.1353167...@sss.pgh.pa.us)
> """
> Even if it happens to be trivial in the current patch, it's an added
> functional requirement that we might later regret having cavalierly
>
On Mon, Jan 27, 2025 at 11:22:16AM -0600, Sami Imseih wrote:
>> I have put my hands on this patch, and at the end I think that we
>> should just do the attached, which is simpler and addresses your
>> use-case. Note also that the end time is acquired while the entries
>> are not locked in the repo
On Mon, Jan 27, 2025 at 07:45:55AM +0900, Michael Paquier wrote:
> Yep. config_sspi_auth() would fill into hba.conf a new HBA entry for
> all the roles given by --create-role under the --config-auth switch,
> which is wnat we want here.
>
> Will go fix in a bit using Dagfinn's patch.
Worth a not
On Fri, Jan 24, 2025 at 6:38 PM vignesh C wrote:
>
> On Fri, 24 Jan 2025 at 10:36, vignesh C wrote:
> >
> > On Fri, 24 Jan 2025 at 09:51, Tom Lane wrote:
> > >
> > > Amit Kapila writes:
> > > > On Fri, Jan 24, 2025 at 8:39 AM Tom Lane wrote:
> > > >> I think the problem is not so much the unde
Hi,
I have a few comments about the patch.
1/
tests are missing for pg_stat_statements.track=all and with a sample
rate < 1 applied.
Can we add tests for this case?
2/
This declaration:
+static bool current_query_sampled = false;
should be moved near the declaration of nesting_level,
the othe
Our pg_stat_wal view currently doesn't expose the number of WAL segments
recycled, although this information is already logged by the checkpointer
in the database log. For example,
LOG: checkpoint complete: wrote 317 buffers (1.9%); 0 WAL file(s) added, 0
removed, 3 recycled; write=0.003 s, sync=
> On 21 Jan 2025, at 17:46, Jacob Champion
> wrote:
> Done that way in v43.
I've spent some time staring at, and testing, 0001, 0002 and 0003 with the
intent of getting them in to pave the way for the end goal of getting 0004 in.
In general I would say they are ready, I only have a small nitpic
On Fri, Jan 24, 2025 at 7:28 PM Ashutosh Bapat
wrote:
>
> On Fri, Jan 24, 2025 at 8:14 AM Peter Smith wrote:
> >
> > On Thu, Jan 23, 2025 at 10:33 PM Ashutosh Bapat
> > wrote:
> > >
> > > On Wed, Jan 22, 2025 at 7:29 PM Shubham Khanna
> > > wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I am wr
Only patches v34-0001 and 2 has been tested.
Patch v34-0003-Refactor-createPartitionTable-to-remove-ProcessU.patch do not
apply anymore on src/backend/catalog/heap.c
The new status of this patch is: Waiting on Author
On Thu, Jan 23, 2025 at 7:57 AM Jelte Fennema-Nio wrote:
>
> (Resent because sending to both -hackers and -www gets emails put in
> the moderation queue, and I don't want to introduce that delay to all
> replies. If you received the previous version because you're in the CC
> please only reply to
On Mon, Jan 27, 2025 at 12:52 PM Masahiko Sawada wrote:
>
> Thank you for updating the patch. I was reviewing the v10 patch and
> had some comments. I believe these comments are still valid for v11,
> but please ignore them if outdated.
Thanks so much for the review!
> + if (TransactionIdI
On Mon, Jan 27, 2025 at 4:55 AM Laurenz Albe wrote:
> My suggestion for the parameter name is "autovacuum_disable_truncate".
Then it would have a different name than the reloption, and the
opposite sense. In most cases, we've been able to keep those matching
-- autovacuum vs. autovacuum_enabled b
On Wed, Jan 22, 2025 at 01:54:32AM +0300, Melih Mutlu wrote:
> I confirm that the patch introduces some improvement in simple cases like
> the one you shared. I looked around a bit to understand whether there is an
> obvious reason why copying from a partitioned table is not allowed, but
> couldn't
Hello.
How can I build Postgres Pro on FreeBSD? Must build it from source?
Where can I manual if it exists?
Thank you.
--
С уважением,
Владимир Василенко,
Telegram: https://t.me/sailorsamoor,
+7 962 267 3934, http://shumbely.com.
On Mon, 27 Jan 2025 at 11:21, Laurenz Albe wrote:
> > He reported to our team, that he did a test with two indexes on the same
> > data. They had the same density but one had no fragmentation while the
> > other had 100%. He got an execution time of ~90ms (0 frag) vs ~340ms
> > 100% frag).
> >
> >
>
> I'd like to merge these down to 3 patches again, but I'm keeping them
> separate for this patchset to isolate the attnum-checking code for this
> go-round.
>
These are mock-ups of the to/from JSON functions, but building from/to text
rather than the not-yet-committed pg_ndistinct and pg_depend
On Wed, Jan 15, 2025 at 02:11:05AM +0900, Yugo Nagata wrote:
> I have a minor comment.
>
> + "LEFT JOIN
> pg_catalog.pg_available_extensions() ae(name, default_version, comment) ON
> ae.name=e.extname "
>
> For consistency with around codes, it seems bette
On Fri, Jan 10, 2025 at 03:56:31PM +0100, Michael Banck wrote:
> On Fri, Jan 10, 2025 at 01:04:14PM +0100, Magnus Hagander wrote:
>> In an effort to make at least a couple of more people realize they have to
>> run ALTER EXTENSION UPDATE after they've upgraded an extension, as well as
>> make it a
On Mon, Jan 27, 2025 at 9:45 AM Melanie Plageman
wrote:
>
> On Fri, Jan 24, 2025 at 3:43 PM Robert Haas wrote:
> >
> > On Fri, Jan 24, 2025 at 3:02 PM Melanie Plageman
> > wrote:
> > > I think you're right. I would go with a percentage. I don't see many
> > > other GUCs that are percents. What w
Hi!
On 27.01.2025 11:05, Richard Guo wrote:
(This was briefly discussed in [1], which primarily focuses on the
incremental sort regression. So start a new thread for this topic.)
In set_append_rel_size(), we currently set rel->tuples to rel->rows
for an appendrel. Generally, rel->tuples is th
On Fri, Jan 24, 2025 at 3:43 PM Robert Haas wrote:
>
> On Fri, Jan 24, 2025 at 3:02 PM Melanie Plageman
> wrote:
> > I think you're right. I would go with a percentage. I don't see many
> > other GUCs that are percents. What would you call it? Perhaps
> > vacuum_eager_scan_fail_threshold? The % o
On Sun, Jan 26, 2025 at 10:26 PM Amit Kapila wrote:
>
> On Fri, Jan 24, 2025 at 12:38 AM Masahiko Sawada
> wrote:
> >
> > On Wed, Jan 22, 2025 at 7:35 PM Peter Smith wrote:
> > >
> > > On Thu, Jan 23, 2025 at 2:17 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Wed, Jan 22, 2025 at 9:21 AM Pet
> I think that this is hiding a behavior change while adding new
> counters, and both changes are independent.
That's a fair point.
> Another thing that is
> slightly incorrect to do if we take the argument of only adding the
> counters is moving around the call of pgstat_progress_end_command(),
On Sun, Jan 26, 2025 at 3:11 PM Robert Treat wrote:
> Hmm... isn't "don't try" really more logically equivalent to "stop
> after zero failures", with "try until zero failures" more of the
> inverse... more like "never stop never stopping"?
No. Or at least, I don't think that's how English works.
On Mon, Jan 27, 2025 at 11:51 AM Tatsuo Ishii wrote:
> I have looked through the v5 patch. Here are review comments.
New version attached.
> @@ -69,6 +69,10 @@ typedef struct WindowObjectData
> int readptr;/* tuplestore read
> pointer for this fn */
>
On Mon, Jan 27, 2025 at 9:05 AM jian he wrote:
> On Tue, Jan 21, 2025 at 7:31 AM Jeff Davis wrote:
> >
> > On Mon, 2025-01-20 at 16:45 -0500, Corey Huinker wrote:
> > >
> > > What I struggle to understand is how that purpose isn't served better
> > > by statistics being in SECTION_NONE like COMM
On 24.01.25 00:20, Paul Jungwirth wrote:
What about caching the FK's query plan? Could the RESTRICT test ever
reuse the constraint oid from the NO ACTION tests just above it? I'm
pretty sure that's not supposed to happen, but if it used a plan
generated from the NO ACTION SQL, it would exhibit
On 24.01.25 03:55, Tom Lane wrote:
Paul Jungwirth writes:
On 1/23/25 15:28, Tom Lane wrote:
I've only noticed the two, but I did not mount an aggressive search.
It's possible that there were failures before 1772d554b0, since I
now see that the diff is in a test case that is older than that.
Hi,
On Mon, Jan 27, 2025 at 09:28:57AM -0500, Tom Lane wrote:
> Bertrand Drouvot writes:
> > On Fri, Jan 24, 2025 at 11:42:15AM -0500, Tom Lane wrote:
> >> PS: FTR, the hits I got on this in the past 90 days were
> >>
> >> sysname |branch | snapshot | stage |
On Mon, Jan 27, 2025 at 09:47:22AM -0500, Tom Lane wrote:
> Nitin Jadhav writes:
>> I noticed that the corruption issue related to two hardlinks pointing
>> to the same WAL file has been fixed in the master branch up to version
>> 16 in commit [1]. As a result, the function durable_rename_excl()
>
So, patch looks good to me. Implements described functionality. Test case
also provided.
I think it's ready to be viewed by a committer.
--
Best regards,
Maxim Orlov.
On Sun, Jan 26, 2025 at 10:24 PM Srinath Reddy
wrote:
>
> as there was repeated code between BufferIsExclusiveLocked and
> BufferIsDirty to check if buffer is pinned and its locked exclusively,i
> thought it would be nice to move that repeated code into
> BufferIsExclusiveLocked and as we need bu
Hi,
On Fri, Jan 24, 2025 at 03:06:17PM -0500, Andres Freund wrote:
> On 2025-01-15 08:38:33 +, Bertrand Drouvot wrote:
> > Fair enough. I'll look at the remaining pieces once this stuff goes in.
>
> Cool. I did try writing the change, but it does indeed seem better as a
> separate patch. Besi
Nitin Jadhav writes:
> I noticed that the corruption issue related to two hardlinks pointing
> to the same WAL file has been fixed in the master branch up to version
> 16 in commit [1]. As a result, the function durable_rename_excl()
> became unused and was removed in commit [2]. Since this corrup
Bertrand Drouvot writes:
> On Fri, Jan 24, 2025 at 11:42:15AM -0500, Tom Lane wrote:
>> PS: FTR, the hits I got on this in the past 90 days were
>>
>> sysname |branch | snapshot | stage |
>>l
po 27. 1. 2025 v 14:57 odesílatel Umar Hayat
napsal:
> Pavel and Jim,
> If that's the case, it looks good to me.
> Just wanted to highlight potential issues and implementation
> differences compared to other databases.
>
It is correct.
Every Time there will be some differences - DB2 has an abs
On Mon, 27 Jan 2025 at 09:46, Alexander Pyhalov
wrote:
> Unfortunately, it's not so simple. We can't just ship type casts to
> remote server if we are not sure that local and remote types match. For
> example,
>
Yeah, my fault. I've overlooked an "elemexpr" member in "ArrayCoerceExpr"
and errone
Hi,
On Mon, 27 Jan 2025 at 16:59, Nazir Bilal Yavuz wrote:
>
> On Mon, 27 Jan 2025 at 03:52, Michael Paquier wrote:
> >
> > In 0002, you are removing PendingWalStats.wal_write_time, which does
> > not seem OK to me because we should still aggregate this data for
> > track_wal_io_timing, no?
>
>
On Wed, 6 Nov 2024 at 11:50, Peter Eisentraut wrote:
>
> Seeing no further comments (or any easy alternatives), I have committed
> this last patch as is.
I just noticed that the #define for MaxArraySize in utils/array.h uses
MaxAllocSize without including the utils/memutils.h header. Is that on
p
On Tue, Jan 21, 2025 at 7:31 AM Jeff Davis wrote:
>
> On Mon, 2025-01-20 at 16:45 -0500, Corey Huinker wrote:
> >
> > What I struggle to understand is how that purpose isn't served better
> > by statistics being in SECTION_NONE like COMMENTs are, so that they
> > are imported immediately after the
Hi,
On Mon, 27 Jan 2025 at 03:52, Michael Paquier wrote:
>
> On Fri, Jan 24, 2025 at 06:29:46PM +0300, Nazir Bilal Yavuz wrote:
> > By saying that, this does not solve the problem; there is still a
> > difference although you omit WAL initialization stats from the
> > pg_stat_io.
>
> Reattaching
On Fri, 24 Jan 2025 at 22:20, Tom Lane wrote:
>
> What I am realizing is that "JSON null becomes SQL NULL" is a rule
> that is adapted to use-case #2 but not so much to use-case #1.
>
OK, I think I've got it.
> So here's the patch, just because I promised it, but I'm now
> thinking about withdr
Pavel and Jim,
If that's the case, it looks good to me.
Just wanted to highlight potential issues and implementation
differences compared to other databases.
Regards
Umar Hayat
Richard Guo 于2025年1月27日周一 16:06写道：
> (This was briefly discussed in [1], which primarily focuses on the
> incremental sort regression. So start a new thread for this topic.)
>
> In set_append_rel_size(), we currently set rel->tuples to rel->rows
> for an appendrel. Generally, rel->tuples is the
Hi,
On Mon, Jan 27, 2025 at 09:30:16AM +0900, Michael Paquier wrote:
> The addition of the extra GetCurrentTimestamp() in the report path
> does not stress me much,
Reading at the previous messages I see how you reached this state. I also think
that makes sense and that's not an issue as we are
Hi,
I noticed that the corruption issue related to two hardlinks pointing
to the same WAL file has been fixed in the master branch up to version
16 in commit [1]. As a result, the function durable_rename_excl()
became unused and was removed in commit [2]. Since this corruption
issue is occurring i
On Mon, 27 Jan 2025 at 09:59, Peter Eisentraut wrote:
>
> Here is an updated patch that integrates the above changes and also
> makes some adjustments now that the logical replication configuration
> questions are resolved. I think this is complete now.
>
In struct ResultRelInfo, the following f
> The attached patch should fix both of these. I've added extra tests
> with a PARTITION BY in the window clause to test for multiple
> partitions.
I have looked through the v5 patch. Here are review comments.
>From 5268754b33103fefc511b57ec546103899f70dbe Mon Sep 17 00:00:00 2001
From: Oliver Fo
Hi,
Postgres allows us to pass BufferManagerRelation structure to
functions in two ways : BMR_REL and BMR_SMGR.
In case we use BMR_REL, the "smgr" field of structure initialized this way :
***
if (bmr.smgr == NULL)
{
bmr.smgr = RelationGetSmgr(bmr.rel);
bmr.relpersistence = bmr.rel->rd_rel-
On 05.08.24 15:48, Aleksander Alekseev wrote:
Hi,
Agreed. I've pushed your patch for that:
Here are corresponding patches.
The ID is new in v17, so I also renamed it like
s/installation-notes-visual/installation-notes-visual-studio/.
(I didn't examine or push your other patch, which was
On Mon, Jan 27, 2025 at 11:00 AM Nisha Moond wrote:
>
> I discussed the above comments further with Peter off-list, and here
> are the v63 patches with the following changes:
> patch-001: The Assert and related comments have been updated for clarity.
>
The 0001 patch should be discussed in a sep
On 21.01.25 11:48, Umar Hayat wrote:
> For XMLAttributes attribute it should have ColumnRef/Expr because
> that's the data/content we want to generate. But namespaces and xml
> tags, IMO they should be considered as part of the structure/schema of
> XML. Allowing namespaces (default or otherwise)
On Thu, 2025-01-23 at 22:33 -0800, Gurjeet Singh wrote:
> > > I am also wondering if having an autovacuum setting to control it would be
> > > a good idea for a feature.
> >
> > I'm all for that.
>
> Please see attached an initial patch to disable truncation behaviour in
> autovacuum. This patch
Hi, Andrei!
On Mon, Jan 27, 2025 at 10:52 AM Andrei Lepikhov wrote:
> On 1/25/25 12:04, Alexander Korotkov wrote:
> > On Wed, Jan 15, 2025 at 10:24 AM Andrei Lepikhov
wrote:
> >> causes SEGFAULT during index keys evaluation. I haven't dived into it
> >> yet, but it seems quite a typical misstep
On Wed, Jan 15, 2025 at 5:59 PM Ashutosh Bapat
wrote:
>
> On Tue, Dec 31, 2024 at 5:24 PM Ashutosh Bapat
> wrote:
> >
> > On Fri, Dec 27, 2024 at 6:17 PM Daniel Gustafsson wrote:
> > >
> > > > On 20 Dec 2024, at 11:01, Ashutosh Bapat
> > > > wrote:
> > > > On Wed, Dec 18, 2024 at 7:39 PM Danie
On 1/26/2025 10:59 PM, Yura Sokolov wrote:
24.01.2025 12:07, Japin Li пишет:
On Thu, 23 Jan 2025 at 21:44, Japin Li wrote:
On Thu, 23 Jan 2025 at 15:03, Yura Sokolov
wrote:
23.01.2025 11:46, Japin Li пишет:
On Wed, 22 Jan 2025 at 22:44, Japin Li wrote:
On Wed, 22 Jan 2025 at 17:02, Yura
On Mon, 27 Jan 2025 at 05:38, Umar Hayat wrote:
> +1 in github you can enforce a minimum number of reviewers. IMO there
> should be a minimum of two reviewers and one of the reviewers should
> be from the security group/role.
In a perfect world I'd agree, but I don't think there are currently
eno
On Mon, 2025-01-27 at 10:13 +0100, Benoit Lobréau wrote:
> On 1/25/25 7:07 PM, Laurenz Albe wrote:
> > Looks good to me. I have one question left: the explanation for the
> > performance
> > penalty of a high leaf fragmentation sounds like it would only be relevant
> > for
> > disks where sequen
On 1/25/25 7:07 PM, Laurenz Albe wrote:
Looks good to me. I have one question left: the explanation for the performance
penalty of a high leaf fragmentation sounds like it would only be relevant for
disks where sequential reads are faster. If that is correct, perhaps it would
be
worth mentioni
On Sat, 25 Jan 2025 at 06:29, Akshat Jaimini
wrote:
> I'll be happy to submit a PR with some basic tests on the repository.
Sounds good, what basic tests do you have in mind?
I have this auto-formatting PR open that also adds some github
actions: https://github.com/JelteF/commitfest/pull/1
Hi,
On Tue, Jan 7, 2025 at 5:09 AM Jelte Fennema-Nio
wrote:
The core functionality works well in my opinion. I think it makes sense
to spend the effort to move this from PoC quality to something
committable. Below some of the things that are necessary to do that
after an initial pass over the
On Fri, Jan 24, 2025 at 5:43 PM Sergey Tatarintsev
wrote:
>
> I think there is another problem - publisher can modify publication
> during the execution of "CREATE SUBSCRIPTION" (Rarely, this situation
> occurred in my tests.)
>
> I.e.:
>
> 1. Publisher: CREATE PUBLICATION ... FOR TABLE t1;
>
> 2.
On Sun, 26 Jan 2025 at 19:09, Yura Sokolov wrote:
> Given history of libxz backdoor, I'd fear to give "commit access" for
> anything critical to rather fresh member of community.
That's definitely a valid concern in the general case, but I wouldn't
call myself a fresh member of the community. I'v
On 1/25/25 12:04, Alexander Korotkov wrote:
On Wed, Jan 15, 2025 at 10:24 AM Andrei Lepikhov wrote:
causes SEGFAULT during index keys evaluation. I haven't dived into it
yet, but it seems quite a typical misstep and is not difficult to fix.
Segfault appears to be caused by a typo. Patch used
hi.
There are two ways we can use to represent the new copy format: json.
1.
typedef struct CopyFormatOptions
{
boolbinary;/* binary format? */
boolfreeze;/* freeze rows on loading? */
boolcsv_mode;/* Comma Separated Value format?
(This was briefly discussed in [1], which primarily focuses on the
incremental sort regression. So start a new thread for this topic.)
In set_append_rel_size(), we currently set rel->tuples to rel->rows
for an appendrel. Generally, rel->tuples is the raw number of tuples
in the relation and rel-
81 matches
Mail list logo
