> I'm happy with this now, so barring objections or complaints from CI,
> I plan to commit it soon.
Great, thank you!
> I don't think it does, because I think those options are anyway
> blocked on Windows. See the comment block that says /* Check that the
> platform supports the requested copy method. */
Yeah, you are right. I could swear I ran `pg_combinebackup --clone` on
a Windows VM, and instead of erroring o
> With regard to the second question, why does this test need to create
> three tables with a million rows each instead of some small number of
> rows? If you need to fill multiple blocks, consider making the rows
> wider instead of inserting such a large number.
Makes sense! Changed that to use t
Thanks for the new round of reviews!
> 1) The new file 010_links.pl added should be included to meson.build also
Added 010_links.pl to src/bin/pg_combinebackup/meson.build.
> 2) Since it is a new file, "Copyright (c) 2021-2025" should be
> "Copyright (c) 2025"
Done!
> 3) Since it is a single s
Thanks for the review, Robert!
I applied all of your suggestions.
> I'm still not a fan of the changes to 010_links.pl; let's drop those.
As discussed through a side chat, 010_links.pl is the new test file
which ensures the hard links are created as expected in the output
directory.
I've removed
Hello Robert,
> In general, +1, although I think that the patch needs polishing in a
> bunch of areas.
Thanks for your review!
> Originally, I thought what we wanted was something like a --in-place
> option to pg_combinebackup, allowing the output directory to be the
> same as one of the input d
One concern that I have about this --link mode, which Euler Taveira
also got concerned about: the fact that it can invalidate the original
backups if the user modifies or starts the synthetic backup without
moving it to another file system or machine.
At the moment, pg_combinebackup issues a warni
Hello all,
With the current implementation of pg_combinebackup, we have a few
copy methods: --clone, --copy and --copy-file-range. By using either of
them, it implicates an actual file copy in the file system, i.e. among
other things, disk usage.
While discussing with some people, e.g. Robert Haa
> Yeah, this is a bug. It seems that the WAL summarizer process, when
> restarted, wants to restart from wherever it was previously
> summarizing WAL, which is correct if that WAL is still around, but if
> summarize_wal has been turned off in the meanwhile, it might not be
> correct. Here's a patch
I'm attaching the files which I missed in the original email.
>
19:34:17.437626 epoll_wait(5, [], 1, 8161) = 0 <8.171542>
19:34:25.610176 rt_sigprocmask(SIG_SETMASK, [URG], NULL, 8) = 0 <0.000334>
19:34:25.611012 openat(AT_FDCWD, "pg_wal/0001000200B3", O_RDONLY) =
-1 ENOENT (No such f
Hello,
Hope you are doing well.
I've been playing a bit with the incremental backup feature which might
come as
part of the 17 release, and I think I hit a possible bug in the WAL
summarizer
process.
The issue that I face refers to the summarizer process getting into a hung
state.
When the issue
n. de 2023 às 14:09, Jacob Champion <
jchamp...@timescale.com> escreveu:
> On Wed, Jan 25, 2023 at 7:47 AM Israel Barth Rubio
> wrote:
> > I imagine more people might have already hit a similar situation too.
> While the
> > workaround can seem a bit weird, in my very humb
Hello Jim/Jacob,
> > I do not think it is worth it to change the current behavior of
> PostgreSQL
> > in that sense.
>
> Well, I am not suggesting to change the current behavior of PostgreSQL in
> that matter. Quite the contrary, I find this feature very convenient,
> specially when you need to de
Hello Jim,
> Hi Jelte, thanks for the message. You're right, an invalid cert path
> does solve the issue - I even use it for tests. Although it solves the
> authentication issue it still looks in my eyes like a non intuitive
> workaround/hack. Perhaps a new sslmode isn't the right place for this
>
m sex., 7 de out. de 2022 às 17:54, Israel Barth Rubio <
barthisr...@gmail.com> escreveu:
> Hello Zhihong,
>
> > For the last question, please take a look at:
> >
> > #define MemSetAligned(start, val, len) \
> >
> > which is called by palloc0().
>
&g
> Attached is a draft patch along the lines I speculated about above.
> It breaks backwards compatibility in that PreventInTransactionBlock
> commands will now be rejected if they're a non-first command in a
> pipeline. I think that's okay, and arguably desirable, for HEAD
> but I'm pretty uncomfo
Hello Zhihong,
> For the last question, please take a look at:
>
> #define MemSetAligned(start, val, len) \
>
> which is called by palloc0().
Oh, I totally missed that. Thanks for the heads up!
I'm attaching the new patch version, which contains both the fix
to the problem reported by Andres, an
Hello Andres,
> cfbot shows that tests started failing with this version:
>
https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/39/3822
> A full backtrace is at
https://api.cirrus-ci.com/v1/task/5354378189078528/logs/cores.log
Thanks for pointing this out. I had initially missed t
Hello Zhihong,
> + /* attribute is NOT to be copied from input */
>
> I think saying `is NOT copied from input` should suffice.
>
> + /* fieldno is 0-index and attnum is 1-index */
>
> 0-index -> 0-indexed
I have applied both suggestions, thanks! I'll submit a 4th version
Hello Andrew,
> . There needs to be a check that this is being used with COPY FROM, and
> the restriction needs to be stated in the docs and tested for. c.f.
> FORCE NULL.
>
> . There needs to be support for this in psql's tab_complete.c, and
> appropriate tests added
>
> . There needs to be suppo
>
> > On 2022-08-16 Tu 14:12, Israel Barth Rubio wrote:
> >> Hello all,
> >>
> >> With the current implementation of COPY FROM in PostgreSQL we are
> >> able to load the DEFAULT value/expression of a column if the column
> >> is absent in the li
Hello,
Thanks for your review. I submitted the patch to the next commit fest
(https://commitfest.postgresql.org/39/3822/).
Regards,
Israel.
Em qua., 17 de ago. de 2022 às 18:56, Andrew Dunstan
escreveu:
>
> On 2022-08-17 We 17:12, Israel Barth Rubio wrote:
> >
> >
> >
on a line by itself, or an EOF signal.
>> 1,\D
>> 2,\\D
>> 3,"\D"
>> \.
COPY 3
postgres=# TABLE copy ;
id | value
+---
1 | \D
2 | \\D
3 | \D
(3 rows)
Does that address your concerns?
I am attaching the new patch, containing the above test in the r
Hello all,
With the current implementation of COPY FROM in PostgreSQL we are able to
load the DEFAULT value/expression of a column if the column is absent in the
list of specified columns. We are not able to explicitly ask that
PostgreSQL uses
the DEFAULT value/expression in a column that is being
24 matches
Mail list logo
