> On 24 Feb 2023, at 08:40, Kyotaro Horiguchi wrote:
> Mmm. The following changes of e9960732a9 seem like reverting the
> previous commit 35ce24c333...
Fixed in 94851e4b90, thanks for the report!
--
Daniel Gustafsson
At Fri, 24 Feb 2023 16:31:27 +0900 (JST), Kyotaro Horiguchi
wrote in
> I noticed that the commit e9960732a9 introduced the following message.
>
> + if (EndCompressFileHandle(ctx->dataFH) != 0)
> + pg_fatal("could not close blob data file: %m");
>
> It seems that we have
> On 24 Feb 2023, at 08:31, Kyotaro Horiguchi wrote:
> Shouldn't we use "large object" instead of "blob" in the message?
Nice catch, it should be "large object" as per the linked discussion. There
are also a few more like:
- if (cfclose(ctx->LOsTocFH) != 0)
-
I noticed that the commit e9960732a9 introduced the following message.
+ if (EndCompressFileHandle(ctx->dataFH) != 0)
+ pg_fatal("could not close blob data file: %m");
It seems that we have removed the terminology "blob(s)" from
user-facing messages by the commit 35ce24c333
On Thu, Feb 23, 2023 at 8:42 PM Kirk Wolak wrote:
> I love that my proposal for %T in the prompt, triggered some great
> conversations.
>
> This is not instead of that. That lets me run a query and come back HOURS
> later, and know it finished before 7PM like it was supposed to!
Neat! I
On Tue, Feb 21, 2023 at 1:48 AM Imseih (AWS), Sami wrote:
>
> Thanks!
>
> > I think PROGRESS_VACUUM_INDEXES_TOTAL and
> > PROGRESS_VACUUM_INDEXES_PROCESSED are better for consistency. The rest
> > looks good to me.
>
> Took care of that in v25.
Thanks! It looks good to me so I've marked it
Attached is a patch fixing a few doc omissions for MERGE.
I don't think that it's necessary to update every place that could
possibly apply to MERGE, but there are a few places where we give a
list of commands that may be used in a particular context, and I think
those should mention MERGE, if it
On Wed, Feb 22, 2023 at 6:55 PM John Naylor
wrote:
>
>
> On Wed, Feb 22, 2023 at 3:29 PM Masahiko Sawada wrote:
> >
> > On Wed, Feb 22, 2023 at 4:35 PM John Naylor
> > wrote:
> > >
> > > I don't think any vacuum calls in regression tests would stress any of
> > > this code very much, so it's
On Tue, 7 Feb 2023 at 10:56, Dean Rasheed wrote:
>
> Attached is a more complete patch
>
Rebased version attached.
Regards,
Dean
diff --git a/doc/src/sgml/dml.sgml b/doc/src/sgml/dml.sgml
new file mode 100644
index cbbc5e2..ff2a827
--- a/doc/src/sgml/dml.sgml
+++ b/doc/src/sgml/dml.sgml
@@
On Wed, Nov 16, 2022 at 11:39 AM Bharath Rupireddy
wrote:
>
> I'm attaching the v10 patch for further review.
Needed a rebase. I'm attaching the v11 patch for further review.
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
On Thu, Feb 23, 2023 at 07:51:16PM -0600, Justin Pryzby wrote:
> On Thu, Feb 23, 2023 at 09:24:46PM +0100, Tomas Vondra wrote:
>> I've now pushed 0002 and 0003, after minor tweaks (a couple typos etc.),
>> and marked the CF entry as committed. Thanks for the patch!
>
> A big thanks from me to
On Fri, Feb 24, 2023 at 01:25:01PM +1300, Thomas Munro wrote:
> I think you should have a trailing \n when writing to stderr.
Oops. I added that in v7.
> Here's that reproducer I speculated about (sorry I confused SIGQUIT
> and SIGTERM in my earlier email, ENOCOFFEE). Seems to do the job, and
Here is my summary of this thread so far, plus some other thoughts.
(I wrote this mostly for my own internal notes/understanding, but
maybe it is a helpful summary for others so I am posting it here too).
~~
1. Initial Goal
--
Currently, the CREATE SUBSCRIPTION ...
On Thu, Feb 23, 2023 at 09:24:46PM +0100, Tomas Vondra wrote:
> I've now pushed 0002 and 0003, after minor tweaks (a couple typos etc.),
> and marked the CF entry as committed. Thanks for the patch!
A big thanks from me to everyone involved.
> I wonder how difficult would it be to add the zstd
On Fri, Feb 24, 2023 at 1:25 PM Thomas Munro wrote:
> ENOCOFFEE
Erm, I realised after sending that I'd accidentally sent a version
that uses fork() anyway, and now if I change it back to vfork() it
doesn't fail the way I wanted to demonstrate, at least on Linux. I
don't have time or desire to
On Fri, Feb 24, 2023 at 01:56:05PM +1300, Thomas Munro wrote:
> On Fri, Feb 24, 2023 at 1:20 PM Justin Pryzby wrote:
> > These patches cause warnings under MSVC.
> >
> > Of course my patch to improve CI by warning about compiler warnings is
> > the only one to notice.
> >
> >
On Fri, Feb 24, 2023 at 1:20 PM Justin Pryzby wrote:
> These patches cause warnings under MSVC.
>
> Of course my patch to improve CI by warning about compiler warnings is
> the only one to notice.
>
> https://cirrus-ci.com/task/6199582053367808
It's a shame that it fails the whole Windows task,
On Fri, Feb 24, 2023 at 12:15 PM Nathan Bossart
wrote:
> Thoughts?
I think you should have a trailing \n when writing to stderr.
Here's that reproducer I speculated about (sorry I confused SIGQUIT
and SIGTERM in my earlier email, ENOCOFFEE). Seems to do the job, and
I tested on a Linux box for
These patches cause warnings under MSVC.
Of course my patch to improve CI by warning about compiler warnings is
the only one to notice.
https://cirrus-ci.com/task/6199582053367808
--
Justin
On Wed, 2023-02-22 at 20:49 +0100, Peter Eisentraut wrote:
> > On 14.02.23 00:45, Jeff Davis wrote:
> > > > Now the patches are:
> > > >
> > > > 0001: pg_strcoll/pg_strxfrm
> > > > 0002: pg_locale_deterministic()
> > > > 0003: cleanup a USE_ICU special case
> > > > 0004: GUCs
On Wed, Feb 22, 2023 at 09:48:10PM +1300, Thomas Munro wrote:
> On Tue, Feb 21, 2023 at 5:50 PM Nathan Bossart
> wrote:
>> On Tue, Feb 21, 2023 at 09:03:27AM +0900, Michael Paquier wrote:
>> > Perhaps beginning a new thread with a patch and a summary would be
>> > better at this stage? Another
On Wed, Feb 22, 2023 at 09:48:10PM +1300, Thomas Munro wrote:
> On Tue, Feb 21, 2023 at 5:50 PM Nathan Bossart
> wrote:
>> I'm happy to create a new thread if needed, but I can't tell if there is
>> any interest in this stopgap/back-branch fix. Perhaps we should just jump
>> straight to the
> This really doesn't feel like a great area to try and do hooks or
> similar in, not the least because that approach has been tried and tried
> again (PAM, GSSAPI, SASL would all be examples..) and frankly none of
> them has turned out great (which is why we can't just tell people "well,
>
The patch v19 LGTM.
- v19 applies cleanly for me
- Full clean build OK
- HTML docs build and render OK
- The 'make check' tests all pass for me
- Also cfbot reports latest patch has no errors -- http://cfbot.cputube.org/
So, I marked it a "Ready for Committer" in the CF --
On Mon, Feb 8, 2021 at 9:49 AM Mead, Scott wrote:
> Initially, my goal was to determine feasibility for making this dynamic. I
> added debug code to vacuum.c:vacuum_delay_point(void) and found that changes
> to cost_delay and cost_limit are already processed by a running vacuum.
> There
Hi,
Users may wish to speed up long-running vacuum of a large table by
decreasing autovacuum_vacuum_cost_delay/vacuum_cost_delay, however the
config file is only reloaded between tables (for autovacuum) or after
the statement (for explicit vacuum). This has been brought up for
autovacuum in [1].
On Thu, Feb 23, 2023 at 11:30:38AM -0800, Nathan Bossart wrote:
> Will post a new version shortly.
As promised...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From b284ba24f771b6ccbf599839bdc813af718b91a1 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 23 Feb 2023
On 2023-02-23 Th 10:58, Andres Freund wrote:
On a Windows instance, fairly similar to what's running drongo, I can get a
successful build with meson+VS2019, but I'm getting an error in the
regression tests, which don't like setting lc_time to 'de_DE'. Not sure
what's going on there.
Huh,
Peter Smith writes:
> Should the 'relation_callback_registered' variable name be plural?
Yeah, plural seems better to me too. I fixed that and did a little
comment-editing and pushed it.
regards, tom lane
On 2/23/23 16:26, Tomas Vondra wrote:
> Thanks for v30 with the updated commit messages. I've pushed 0001 after
> fixing a comment typo and removing (I think) an unnecessary change in an
> error message.
>
> I'll give the buildfarm a bit of time before pushing 0002 and 0003.
>
I've now pushed
Everyone,
I love that my proposal for %T in the prompt, triggered some great
conversations.
This is not instead of that. That lets me run a query and come back
HOURS later, and know it finished before 7PM like it was supposed to!
This feature is simple. We forget to set \timing on...
We
Hi,
On 2023-02-23 13:56:56 -0500, Tom Lane wrote:
> Corey Huinker writes:
> > My not-ready-for-16 work on CAST( ... ON DEFAULT ... ) involved making
> > FuncExpr/IoCoerceExpr/ArrayCoerceExpr have a safe_mode flag, and that
> > necessitates adding a reserror boolean to ExprEvalStep for subsequent
Hi,
On 2023-02-23 13:39:14 -0500, Corey Huinker wrote:
> My not-ready-for-16 work on CAST( ... ON DEFAULT ... ) involved making
> FuncExpr/IoCoerceExpr/ArrayCoerceExpr have a safe_mode flag, and that
> necessitates adding a reserror boolean to ExprEvalStep for subsequent steps
> to test if the
On Thu, Feb 23, 2023 at 10:40:48AM -0800, Nathan Bossart wrote:
> On Tue, Jan 10, 2023 at 03:41:12PM -0800, Nathan Bossart wrote:
>> My vote would be to redefine the existing pg_input_error_message() function
>> to return a record, but I recognize that this would inflate the patch quite
>> a bit
On Thu, Feb 23, 2023 at 9:52 AM Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 23/02/2023 13:20, Peter Eisentraut wrote:
> >> If you don't have \timing turned on before the query starts, psql won't
> >> record what the time was before the query, so you can't compute the run
> >> time
Corey Huinker writes:
> My not-ready-for-16 work on CAST( ... ON DEFAULT ... ) involved making
> FuncExpr/IoCoerceExpr/ArrayCoerceExpr have a safe_mode flag, and that
> necessitates adding a reserror boolean to ExprEvalStep for subsequent steps
> to test if the error happened.
Why do you want it
On Thu, Feb 23, 2023 at 1:16 PM Maciek Sakrejda
wrote:
> On Thu, Feb 23, 2023, 09:55 Nikolay Samokhvalov
> wrote:
>
>> On Thu, Feb 23, 2023 at 9:05 AM Maciek Sakrejda
>> wrote:
>>
>>> I think Heikki's solution is probably more practical since (1) ..
>>
>>
>> Note that these ideas target two
On 2/23/23 17:44, Matthias van de Meent wrote:
> On Thu, 23 Feb 2023 at 16:22, Tomas Vondra
> wrote:
>>
>> On 2/23/23 15:19, Matthias van de Meent wrote:
>>> Comments on 0001, mostly comments and patch design:
>
> One more comment:
>
+ range->min_value = bval->bv_values[0];
+
Greetings,
* Jacob Champion (jchamp...@timescale.com) wrote:
> On Mon, Feb 20, 2023 at 2:35 PM Stephen Frost wrote:
> > Having skimmed back through this thread again, I still feel that the
> > direction that was originally being taken (actually support something in
> > libpq and the backend, be
čt 23. 2. 2023 v 19:16 odesílatel Maciek Sakrejda
napsal:
> On Thu, Feb 23, 2023, 09:55 Nikolay Samokhvalov
> wrote:
>
>> On Thu, Feb 23, 2023 at 9:05 AM Maciek Sakrejda
>> wrote:
>>
>>> I think Heikki's solution is probably more practical since (1) ..
>>
>>
>> Note that these ideas target two
On Tue, Jan 10, 2023 at 03:41:12PM -0800, Nathan Bossart wrote:
> My vote would be to redefine the existing pg_input_error_message() function
> to return a record, but I recognize that this would inflate the patch quite
> a bit due to all the existing uses in the tests. If this is the only
>
On Mon, Feb 06, 2023 at 05:19:39AM -0500, Regina Obe wrote:
>
> Attached is a revised version of the original patch. It is revised to
> prevent
>
> ALTER EXTENSION .. SET SCHEMA if there is a dependent extension that
> references the extension in their scripts using @extschema:extensionname@
On Wed, Feb 22, 2023 at 5:47 PM Andres Freund wrote:
> Hi,
>
> On 2023-02-22 16:34:44 -0500, Tom Lane wrote:
> > I wrote:
> > > Andres Freund writes:
> > >> Maybe it's worth sticking a StaticAssert() for the struct size
> > >> somewhere.
> >
> > > Indeed. I thought we had one already.
> >
> >
On Thu, Feb 23, 2023, 09:55 Nikolay Samokhvalov
wrote:
> On Thu, Feb 23, 2023 at 9:05 AM Maciek Sakrejda
> wrote:
>
>> I think Heikki's solution is probably more practical since (1) ..
>
>
> Note that these ideas target two *different* problems:
> - what was the duration of the last query
> -
Hi,
Thanks for the review.
On Mon, 20 Feb 2023 at 21:44, Peter Eisentraut
wrote:
>
> I tested this a bit. It works fine. The approach makes sense to me.
>
> The install_additional_files script could be simplified a bit. You
> could use os.makedirs(dest, exist_ok=True) and avoid the error
On Thu, Feb 23, 2023 at 9:05 AM Maciek Sakrejda
wrote:
> I think Heikki's solution is probably more practical since (1) ..
Note that these ideas target two *different* problems:
- what was the duration of the last query
- when was the last query executed
So, having both solved would be ideal.
+1 on solving the general problem of "I forgot to set \timing--how
long did this run?". I could have used that more than once in the
past, and I'm sure it will come up again.
I think Heikki's solution is probably more practical since (1) even if
we add the prompt parameter originally proposed, I
On Thu, 23 Feb 2023 at 16:22, Tomas Vondra
wrote:
>
> On 2/23/23 15:19, Matthias van de Meent wrote:
>> Comments on 0001, mostly comments and patch design:
One more comment:
>>> + range->min_value = bval->bv_values[0];
>>> + range->max_value = bval->bv_values[1];
This produces dangling
Richard Guo writes:
> On Thu, Feb 23, 2023 at 4:50 AM Tom Lane wrote:
>> Less-hasty v2 patch attached.
> I think the patch is in good shape now.
Pushed, thanks for reviewing!
regards, tom lane
On 2023-02-23 06:27:23 -0500, Andrew Dunstan wrote:
>
> On 2023-02-22 We 20:20, Andres Freund wrote:
> >
> > > There is work to do to make sure we pick up the right log files, and maybe
> > > adjust a module or two. I have adopted a design where instead of trying to
> > > know a lot about the
Thanks for v30 with the updated commit messages. I've pushed 0001 after
fixing a comment typo and removing (I think) an unnecessary change in an
error message.
I'll give the buildfarm a bit of time before pushing 0002 and 0003.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
On 2/23/23 15:19, Matthias van de Meent wrote:
> On Sat, 18 Feb 2023 at 16:55, Tomas Vondra
> wrote:
>>
>> cfbot complained there's one more place triggering a compiler warning on
>> 32-bit systems, so here's a version fixing that.
>>
>> I've also added a copy of the regression tests but using
Heikki Linnakangas writes:
> On 23/02/2023 13:20, Peter Eisentraut wrote:
>> If you don't have \timing turned on before the query starts, psql won't
>> record what the time was before the query, so you can't compute the run
>> time afterwards. This kind of feature would only work if you always
On Sat, 18 Feb 2023 at 16:55, Tomas Vondra
wrote:
>
> cfbot complained there's one more place triggering a compiler warning on
> 32-bit systems, so here's a version fixing that.
>
> I've also added a copy of the regression tests but using the indexam
> stats added in 0001. This is just a copy of
> On 22 Feb 2023, at 20:20, Nathan Bossart wrote:
> One thing I noticed is that the
> "failed check" log is only printed once, even if multiple data type checks
> failed. I believe this is because this message uses PG_STATUS. If I
> change it to PG_REPORT, all of the "failed check" messages
> On 22 Feb 2023, at 18:21, Jonathan S. Katz wrote:
> On 2/22/23 8:39 AM, Daniel Gustafsson wrote:
>> The attached is a rebase on top of master with no other additional hacking
>> done
>> on top of the above review comments.
>
> Generally LGTM. I read through earlier comments (sorry I missed
On 22/02/2023 16:00, Heikki Linnakangas wrote:
On 11/12/2022 02:01, Ian Lawrence Barwick wrote:
2021年11月9日(火) 20:31 Daniel Gustafsson :
On 14 Jul 2021, at 14:03, Aleksander Alekseev wrote:
The following review has been posted through the commitfest application:
make installcheck-world:
On 2/22/23 23:03, Tom Lane wrote:
Andres Freund writes:
We could just do something like printing __. So
something like avg(reltuples / relpages) would end up as
avg_reltuples_float48div_relpages.
Whether that's worth it, or whether column name lengths would be too painful,
IDK.
I think you'd
On 2/22/23 18:04, Jonathan S. Katz wrote:
> On 2/22/23 5:02 AM, Tomas Vondra wrote:
>>
>> On 2/22/23 03:28, Jonathan S. Katz wrote:
>
>>> Thanks for continuing to work on this patch! I tested the latest version
>>> and have some feedback/clarifications.
>>>
>>
>> Thanks!
>
> Also I should
> This is because copy_data is not something stored in pg_subscription
> or another catalog. But this is not an issue for copy_fornat since its
> value will be stored in the catalog. This can allow users to set the
> format even if copy_data=false and no initial sync is needed at that
> moment.
Dear Shi,
Thank you for reviewing! PSA new version.
> + elog(DEBUG2, "time-delayed replication for txid %u, delay_time
> = %d ms, remaining wait time: %ld ms",
> + ctx->write_xid, (int) ctx->min_send_delay,
> + remaining_wait_time_ms);
>
> I
On 23/02/2023 13:20, Peter Eisentraut wrote:
On 22.02.23 19:14, Heikki Linnakangas wrote:
How about a new backslash command or psql variable to show how long the
previous statement took? Something like:
If you don't have \timing turned on before the query starts, psql won't
record what the
shiy.f...@fujitsu.com , 23 Şub 2023 Per, 12:29
tarihinde şunu yazdı:
> On Thu, Feb 23, 2023 12:40 PM Kuroda, Hayato/黒田 隼人 <
> kuroda.hay...@fujitsu.com> wrote:
> >
> > > > I'm not sure the combination of "copy_format = binary" and
> "copy_data =
> > false"
> > > > should be accepted or not. How
On 2023-02-22 We 23:48, Tom Lane wrote:
For my own taste, I really don't have any objection to // in isolation --
the problem with it is just that we've got megabytes of code in the other
style. I fear it'd look really ugly to have an intermixture of // and /*
comment styles.
Maybe, I've
On 20.12.22 23:08, Eric Radman wrote:
This patch is a new function based on the implementation of to_hex(int).
Since support for octal integer literals was added, to_oct(int) allows
octal values to be easily stored and returned in query results.
to_oct(0o755) = '755'
This is probably most
On 2023-02-22 We 20:20, Andres Freund wrote:
There is work to do to make sure we pick up the right log files, and maybe
adjust a module or two. I have adopted a design where instead of trying to
know a lot about the testing regime the client needs to know a lot less.
Instead, it gets meson to
On 22.02.23 19:14, Heikki Linnakangas wrote:
How about a new backslash command or psql variable to show how long the
previous statement took? Something like:
If you don't have \timing turned on before the query starts, psql won't
record what the time was before the query, so you can't compute
On 20.02.23 15:03, Peter Eisentraut wrote:
On 15.02.23 19:04, Alvaro Herrera wrote:
That said, I think most of this code is invoked for DDL, where
performance is not so critical; probably just fixing
get_object_property_data to not be so naïve would suffice.
Ok, I'll look into that.
I did a
Hey,
It depnends on scenario, but there is many use cases that hack data
change from somebody with admin privileges could be disaster.
That is the place where data history could come with help. Some basic
solution would be trigger which writes previous version of record
to some other table.
Dear Wang,
Thank you for making the patch. IIUC your patch basically can achieve that
output plugin
does not have to call UpdateProgress.
I think the basic approach is as follows, is it right?
1. In *_cb_wrapper, set ctx->did_write to false
2. In OutputPluginWrite() set ctx->did_write to true.
On 2023-02-22 We 19:23, Michael Paquier wrote:
On a Windows instance, fairly similar to what's running drongo, I can get a
successful build with meson+VS2019, but I'm getting an error in the
regression tests, which don't like setting lc_time to 'de_DE'. Not sure
what's going on there.
What's
I ran a couple "in situ" tests on server hardware using UUID columns, since
they are common in the real world and have bad correlation to heap
order, so are a challenge for index vacuum.
=== test 1, delete everything from a small table, with very small
maintenance_work_mem:
alter system set
On Thu, Feb 23, 2023 at 4:50 AM Tom Lane wrote:
> I thought about this and decided that it's not really a problem.
> have_relevant_joinclause is just a heuristic, and I don't think we
> need to prioritize forming a join if the only relevant clauses look
> like this. We won't be able to use such
On Thu, Feb 23, 2023 12:40 PM Kuroda, Hayato/黒田 隼人
wrote:
>
> > > I'm not sure the combination of "copy_format = binary" and "copy_data =
> false"
> > > should be accepted or not. How do you think?
> >
> > It seems quite useless indeed to specify the format of a copy that won't
> happen.
>
> I
On Wed, Feb 22, 2023 9:48 PM Kuroda, Hayato/黒田 隼人
wrote:
>
> Thank you for reviewing! PSA new version.
>
Thanks for your patch. Here is a comment.
+ elog(DEBUG2, "time-delayed replication for txid %u, delay_time
= %d ms, remaining wait time: %ld ms",
+
> On 22 Feb 2023, at 21:55, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 22 Feb 2023, at 21:33, Andres Freund wrote:
>>> On 2023-02-22 15:10:11 +0100, Daniel Gustafsson wrote:
Rebased patch to handle breakage of v2 due to bd8d453e9b.
>
>>> I think we probably should just apply
Hi,
Seems like supporting only constants is a good starting
point. The only thing that is likely confusing for users is that NUMERICs
(and potentially constants of other types) are unsupported. Wouldn't it be
fairly simple to support them via something like the following?
> On 23 Feb 2023, at 05:48, Tom Lane wrote:
> For my own taste, I really don't have any objection to // in isolation --
> the problem with it is just that we've got megabytes of code in the other
> style. I fear it'd look really ugly to have an intermixture of // and /*
> comment styles.
We
On 23.02.23 08:51, Peter Eisentraut wrote:
In kwlist.h you have
PG_KEYWORD("indent", INDENT, UNRESERVED_KEYWORD, AS_LABEL)
but you can actually make it BARE_LABEL, which is preferable.
More importantly, you need to add the new keyword to the
bare_label_keyword production in gram.y. I
79 matches
Mail list logo
