pá 12. 5. 2023 v 6:50 odesílatel Kirk Wolak napsal:
> On Fri, May 12, 2023 at 12:14 AM Tom Lane wrote:
>
>> Kirk Wolak writes:
>> > Did you try the print statement that Andrey asked Pavel to try?
>>
>> Yeah, and I get exactly the results I expect:
>>
>> Your results MATCHED Pavels (Hmm).
Thanks for clarifying!
At Mon, 8 May 2023 14:46:43 -0700, Andres Freund wrote in
> Hi,
>
> On 2023-04-26 18:47:14 +0900, Kyotaro Horiguchi wrote:
> > I see four issues here.
> >
> > 1. The current database stats omits buffer fetches that don't
> > originate from a relation.
> >
> > In this
On Fri, May 12, 2023 at 10:33 AM Amit Kapila wrote:
>
> On Fri, May 12, 2023 at 7:38 AM Masahiko Sawada wrote:
> >
> > On Thu, May 11, 2023 at 2:04 PM Amit Kapila wrote:
> > >
> > > On Fri, Apr 28, 2023 at 2:35 PM Hayato Kuroda (Fujitsu)
> > > wrote:
> > > >
> > > > Dear hackers,
> > > >
> > >
On Fri, May 12, 2023 at 7:38 AM Masahiko Sawada wrote:
>
> On Thu, May 11, 2023 at 2:04 PM Amit Kapila wrote:
> >
> > On Fri, Apr 28, 2023 at 2:35 PM Hayato Kuroda (Fujitsu)
> > wrote:
> > >
> > > Dear hackers,
> > >
> > > I rebased and refined my PoC. Followings are the changes:
> > >
> >
> >
On Fri, May 12, 2023 at 12:14 AM Tom Lane wrote:
> Kirk Wolak writes:
> > Did you try the print statement that Andrey asked Pavel to try?
>
> Yeah, and I get exactly the results I expect:
>
> Your results MATCHED Pavels (Hmm). Piping ONE of those into psql should
fail, and the other one
On Fri, May 12, 2023 at 12:48 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > > Overall, I think such an approach can address comments by Sawada-San
> > > [1] but not sure if Sawada-San or others have any better ideas to
> > > achieve this feature. It would be good to see what others think of
> > > this
Kirk Wolak writes:
> Did you try the print statement that Andrey asked Pavel to try?
Yeah, and I get exactly the results I expect:
$ cat test.pl
use locale;
my $result = sprintf('SELECT 1 \watch c=3 i=%g', 0.01);
print ">>$result<<\n";
$ LANG=cs_CZ.utf8 perl test.pl
>>SELECT 1 \watch c=3
On Thu, May 11, 2023 at 8:08 PM Tom Lane wrote:
> Kirk Wolak writes:
> > Can you change the 0.01 to just 1 or 0?
> > I assume it will work then! (and better than a full removal)?
>
> IMO the point of that test is largely to exercise this locale-dependent
> behavior, so I'm very unwilling to
On Fri, May 12, 2023 at 9:10 AM Masahiko Sawada wrote:
>
> On Fri, May 12, 2023 at 1:12 AM Robert Haas wrote:
> >
> > On Thu, May 11, 2023 at 7:38 AM Amit Kapila wrote:
> > > Do we want the initial sync to also respect 'run_as_owner' option? I
> > > might be missing something but I don't see
Dear Amit, Sawada-san,
Thank you for replying!
> On Thu, May 11, 2023 at 2:04 PM Amit Kapila wrote:
> >
> > On Fri, Apr 28, 2023 at 2:35 PM Hayato Kuroda (Fujitsu)
> > wrote:
> > >
> > > Dear hackers,
> > >
> > > I rebased and refined my PoC. Followings are the changes:
> > >
> >
> > 1. Is my
On Fri, May 12, 2023 at 1:12 AM Robert Haas wrote:
>
> On Thu, May 11, 2023 at 7:38 AM Amit Kapila wrote:
> > Do we want the initial sync to also respect 'run_as_owner' option? I
> > might be missing something but I don't see anything in the docs about
> > initial sync interaction with this
On Thu, May 11, 2023 at 2:04 PM Amit Kapila wrote:
>
> On Fri, Apr 28, 2023 at 2:35 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Dear hackers,
> >
> > I rebased and refined my PoC. Followings are the changes:
> >
>
> 1. Is my understanding correct that this patch creates the delay files
> for
On Thu, May 11, 2023 at 11:56 AM Michael Paquier wrote:
>
> On Wed, May 10, 2023 at 09:04:47PM +0900, Michael Paquier wrote:
> > It took me some time, but I have been able to deploy a big box to see
> > the effect of this patch at a rather large scale (64 vCPU, 512G of
> > memory), with the
Hi Kuroda-san. Here are some comments for patch v12-0001.
==
src/bin/pg_upgrade/check.c
1. check_new_cluster
+ if (user_opts.include_logical_slots)
+ {
+ get_logical_slot_infos(_cluster);
+ check_for_parameter_settings(_cluster);
+ }
+
check_new_cluster_is_empty();
~
The code is OK, but
On Tue, Aug 31, 2021 at 10:02 AM Gurjeet Singh wrote:
> On Tue, Aug 31, 2021 at 8:04 AM Alvaro Herrera
> wrote:
>
> > You know what I've heard? That your index advisor module languishes
> > unmaintained and that there's no shortage of people wishing to use it.
>
> Now there's a masterclass in
Kirk Wolak writes:
> Can you change the 0.01 to just 1 or 0?
> I assume it will work then! (and better than a full removal)?
IMO the point of that test is largely to exercise this locale-dependent
behavior, so I'm very unwilling to dumb it down to that extent.
What seems to be happening is that
On Fri, May 12, 2023 at 8:16 AM Jim Mlodgenski wrote:
> On Mon, May 1, 2023 at 9:29 PM Thomas Munro wrote:
>> I am not aware of any modern/non-historic filesystem[2] that can't do
>> large files with ease. Anyone know of anything to worry about on that
>> front?
>
> There is some trouble in the
New patch series attached.
=== 0001: fix bug that allows creating hidden collations
Bug:
https://www.postgresql.org/message-id/051c9395cf880307865ee8b17acdbf7f838c1e39.ca...@j-davis.com
=== 0002: handle some kinds of libc-stlye locale strings
ICU used to handle libc locale strings like
On Thu, May 11, 2023 at 1:40 PM Peter Geoghegan wrote:
> Just to be clear, I am not proposing changing the name of
> anti-wraparound autovacuum at all. What I'd like to do is use a term
> like "XID exhaustion" to refer to the state that we internally refer
> to as xidStopLimit. My motivation is
On Thu, May 11, 2023 at 1:04 PM Greg Stark wrote:
> Fwiw while "wraparound" has pitfalls I think changing it for a new
> word isn't really helpful. Especially if it's a mostly meaningless
> word like "overload" or "exhaustion". It suddenly makes every existing
> doc hard to find and confusing to
On Wed, May 10, 2023 at 12:59 AM Pavel Stehule
wrote:
> Hi
>
> When I remove this test, then all tests passed
>
> diff --git a/src/bin/psql/t/001_basic.pl b/src/bin/psql/t/001_basic.pl
> index 596746de17..631a1a7335 100644
> --- a/src/bin/psql/t/001_basic.pl
> +++ b/src/bin/psql/t/001_basic.pl
>
On Mon, May 1, 2023 at 9:29 PM Thomas Munro wrote:
>
> I am not aware of any modern/non-historic filesystem[2] that can't do
> large files with ease. Anyone know of anything to worry about on that
> front?
There is some trouble in the ambiguity of what we mean by "modern" and
"large files".
On Thu, May 11, 2023 at 11:50 AM Robert Haas wrote:
> On Thu, May 11, 2023 at 10:14 AM Robert Haas
> wrote:
> > Ouch, so we've had a known queries-returning-wrong-answers bug for
> > more than two months. That's not great. I'll try to find time today to
> > check whether the patches on that
On Wed, 3 May 2023 at 18:50, Peter Geoghegan wrote:
>
> What about "XID allocation overload"? The implication that I'm going
> for here is that the system was misconfigured, or there was otherwise
> some kind of imbalance between XID supply and demand.
Fwiw while "wraparound" has pitfalls I
On Wed, May 10, 2023 at 1:33 PM Tom Lane wrote:
> I wrote:
> > Hmm, I wonder how useful that's really going to be, considering
> > that trigger names aren't unique across tables. Wouldn't it
> > need to be more like "\et table-name trigger-name"?
>
> Different line of thought: \et seems awfully
Pavel Stehule writes:
>> Stranger things, but is LANG case sensitive, or formatted differently?
> I don't think so encoding is case sensitive - I am not sure, but minimally
> ncurses applications works without any problems, and ncurses is very locale
> sensitive
> $ LANG=cs_CZ.utf8 make check
>
Hi
>
>
> Stranger things, but is LANG case sensitive, or formatted differently?
>
> tom> $ LANG=cs_CZ.utf8 make installcheck
> you> LANG=cs_CZ.*UTF-8*
>
>
I don't think so encoding is case sensitive - I am not sure, but minimally
ncurses applications works without any problems, and ncurses is
On Thu, May 11, 2023 at 3:06 PM Pavel Stehule
wrote:
>
>
> čt 11. 5. 2023 v 20:44 odesílatel Tom Lane napsal:
>
>> Pavel Stehule writes:
>> > When I remove this test, then all tests passed
>>
>> This works fine for me on Fedora 37:
>>
>
> I have Fedora 38
>
>>
>> $ cd src/bin/psql
>> $
čt 11. 5. 2023 v 20:44 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > When I remove this test, then all tests passed
>
> This works fine for me on Fedora 37:
>
I have Fedora 38
>
> $ cd src/bin/psql
> $ LANG=cs_CZ.utf8 make installcheck
> make -C ../../../src/backend
Greetings,
* Greg Stark (st...@mit.edu) wrote:
> Including the pre-truncation length in the wal record is the obviously
> solid approach and I none of the below is a good substitution for it.
I tend to agree with the items mentioned in Andres's recent email on
this thread too in terms of
Pavel Stehule writes:
> When I remove this test, then all tests passed
This works fine for me on Fedora 37:
$ cd src/bin/psql
$ LANG=cs_CZ.utf8 make installcheck
make -C ../../../src/backend generated-headers
make[1]: Vstupuje se do adresáře „/home/tgl/pgsql/src/backend“
...
# +++ tap
On Thu, May 11, 2023 at 1:46 PM Tom Lane wrote:
> > What I'm inclined to do about it is just revert this particular
> > change. But I'd better run around and see where else I did that,
> > because the idea is evidently not ready for prime time.
>
> Looks like that was the only such change in
I wrote:
> Yeah, I've just traced the problem to remove_rel_from_query() deciding
> that it can drop the qual of interest :-(. I'd done this:
> - if (RINFO_IS_PUSHED_DOWN(rinfo, joinrelids))
> + if (bms_is_member(ojrelid, rinfo->required_relids))
> as part of an unfinished effort at
Robert Haas writes:
> On Thu, May 11, 2023 at 10:14 AM Robert Haas wrote:
>> Ouch, so we've had a known queries-returning-wrong-answers bug for
>> more than two months. That's not great. I'll try to find time today to
>> check whether the patches on that thread resolve this issue.
> I tried out
On Tue, May 9, 2023 at 5:14 AM Aleksander Alekseev
wrote:
> > I admit I haven't done the legwork to nail down a test
> > case where everything comes together just right to show user-visible
> > breakage, but your success in finding one where it doesn't is no proof
> > of anything.
>
>
On Thu, May 11, 2023 at 7:38 AM Amit Kapila wrote:
> Do we want the initial sync to also respect 'run_as_owner' option? I
> might be missing something but I don't see anything in the docs about
> initial sync interaction with this option. In the commit a2ab9c06ea,
> we did the permission checking
On Thu, May 11, 2023 at 10:14 AM Robert Haas wrote:
> Ouch, so we've had a known queries-returning-wrong-answers bug for
> more than two months. That's not great. I'll try to find time today to
> check whether the patches on that thread resolve this issue.
I tried out the v3 patches from that
čt 11. 5. 2023 v 16:04 odesílatel Joel Jacobson napsal:
> Hi hackers,
>
> I've come across an unexpected behavior in our CSV parser that I'd like to
> bring up for discussion.
>
> % cat example.csv
> id,rating,review
> 1,5,"Great product, will buy again."
> 2,3,"I bought this for my 6" laptop
On Thu, May 11, 2023 at 9:57 AM Tom Lane wrote:
> Robert Haas writes:
> > While merging commits from c9f7f926484d69e2806e35343af7e472fadfede7
> > through 3db72ebcbe20debc6552500ee9ccb4b2007f12f8 into a fork, my
> > colleague Rushabh Lathia and I noticed that the merge caused certain
> > queries
On Wed, May 10, 2023 at 1:33 PM Bruce Momjian wrote:
> This seems like it will be forever confusing to people. I frankly don't
> know why --role matching CREATE ROLE ... ROLE IN was not already
> confusing in pre-PG 16. Any new ideas for improvement?
Yeah, it's a bad situation. I think --role
Hi hackers,
I've come across an unexpected behavior in our CSV parser that I'd like to
bring up for discussion.
% cat example.csv
id,rating,review
1,5,"Great product, will buy again."
2,3,"I bought this for my 6" laptop but it didn't fit my 8" tablet"
% psql
CREATE TABLE reviews (id int, rating
Robert Haas writes:
> While merging commits from c9f7f926484d69e2806e35343af7e472fadfede7
> through 3db72ebcbe20debc6552500ee9ccb4b2007f12f8 into a fork, my
> colleague Rushabh Lathia and I noticed that the merge caused certain
> queries to return wrong answers.
I believe this is a variant of
On 02.04.23 19:46, Tomas Vondra wrote:
OK, I took a stab at this, see the attached 0007 patch which bumps the
protocol version, and allows the subscriber to specify "sequences" when
starting the replication, similar to what we do for the two-phase stuff.
The patch essentially adds 'sequences'
On Thu, May 11, 2023 at 02:21:22PM +0200, Daniel Gustafsson wrote:
> > On 10 May 2023, at 19:33, Bruce Momjian wrote:
>
> > I frankly don't
> > know why --role matching CREATE ROLE ... ROLE IN was not already
> > confusing in pre-PG 16. Any new ideas for improvement?
>
> IIRC there were a
While merging commits from c9f7f926484d69e2806e35343af7e472fadfede7
through 3db72ebcbe20debc6552500ee9ccb4b2007f12f8 into a fork, my
colleague Rushabh Lathia and I noticed that the merge caused certain
queries to return wrong answers. Rushabh then discovered that this
also happens in unmodified
Hi
čt 11. 5. 2023 v 11:36 odesílatel Andrey M. Borodin
napsal:
>
>
> > On 10 May 2023, at 09:58, Pavel Stehule wrote:
> >
> > When I remove this test, then all tests passed
>
> Hi Pavel!
>
> Can you plz share how sprintf('SELECT 1 \watch c=3 i=%g', 0.01) is
> formatting 0.01 on your system?
>
11.05.2023 01:27, David Rowley wrote:
On Thu, 11 May 2023 at 01:00, Alexander Lakhin wrote:
This time `git bisect` pointed at 3c6fc5820. Having compared execution plans
(both attached), I see the following differences (3c6fc5820~1 vs 3c6fc5820):
Based on what you've sent, I'm uninspired to
> On 10 May 2023, at 19:33, Bruce Momjian wrote:
> I frankly don't
> know why --role matching CREATE ROLE ... ROLE IN was not already
> confusing in pre-PG 16. Any new ideas for improvement?
IIRC there were a number of ideas presented in that thread but backwards
compatibility with --role
On Tue, Apr 4, 2023 at 9:40 PM Robert Haas wrote:
>
> On Mon, Apr 3, 2023 at 10:09 PM Noah Misch wrote:
> > I gather we agree on what to do for v16, which is good.
>
> I have committed the patches.
>
Do we want the initial sync to also respect 'run_as_owner' option? I
might be missing something
On Thu, May 11, 2023 at 10:36 AM Alvaro Herrera
wrote:
> On 2023-May-11, Yurii Rashkovskii wrote:
>
> > ```
> > 127.0.0.1=5432 ::1=54321
> > ```
> >
> > Basically, a space-delimited set of address/port pairs (delimited by `=`
> to
> > allow IPv6 addresses to use a colon).
>
> This seems a bit
On 09.05.23 17:09, Jeff Davis wrote:
It's awkward for a user to read pg_database.datlocprovider, then
depending on that, either look in datcollate or daticulocale. (It's
awkward in the code, too.)
Maybe some built-in function that returns a tuple of the default
provider, the locale, and the
On 09.05.23 10:25, Alvaro Herrera wrote:
On 2023-Apr-24, Peter Eisentraut wrote:
The GUC settings lc_collate and lc_ctype are from a time when those locale
settings were cluster-global. When we made those locale settings
per-database (PG 8.4), we kept them as read-only. As of PG 15, you can
> On 10 May 2023, at 19:54, Alvaro Herrera wrote:
> ..as I understand, this cannot happen merely because of a full
> disk, because that should fail during _write_ of the file, not read.
> And no other user-caused causes should exist.
>
> Therefore, I propose to turn these messages into
> On 11 May 2023, at 06:24, Michael Paquier wrote:
>
> On Thu, May 11, 2023 at 01:06:42PM +1000, Peter Smith wrote:
>> While reviewing another patch to the file info.c, I noticed there seem
>> to be some unnecessary calls to strlen(query) in get_rel_infos()
>> function.
>>
>> i.e. The query is
On Wednesday, May 10, 2023 3:03 AM Andres Freund wrote:
> Hi,
>
> Unfortunately I have found the following commit to have caused a
> performance
> regression:
>
> commit e101dfac3a53c20bfbf1ca85d30a368c2954facf
> Author: Andres Freund
> Date: 2023-04-08 00:24:24 -0700
>
> For cascading
On 10.05.23 20:10, Andres Freund wrote:
Moreover, the text "except the relation can be extended by multiple blocks
at once and the added blocks will be filled with zeroes" doesn't make much
sense as a differentiation, because smgrextend() does that as well.
Hm? smgrextend() writes a single
> On 10 May 2023, at 09:58, Pavel Stehule wrote:
>
> When I remove this test, then all tests passed
Hi Pavel!
Can you plz share how sprintf('SELECT 1 \watch c=3 i=%g', 0.01) is formatting
0.01 on your system?
And try to run that string against psql.
As an alternative I propose to use
On Thu, May 11, 2023 at 6:30 PM Daniel Gustafsson wrote:
>
> > On 11 May 2023, at 07:41, Peter Smith wrote:
>
> > While reviewing another patch for the file info.c, I noticed some
> > misplaced colon (':') in the verbose logs for print_rel_infos().
>
> That spelling was introduced in
Dear Peter,
Thanks for reviewing! New patch can be available at [1].
> 1. help
>
> printf(_(" --insertsdump data as INSERT
> commands, rather than COPY\n"));
> printf(_(" --load-via-partition-rootload partitions via the
> root table\n"));
> + printf(_("
Dear Wang,
Thank you for reviewing! PSA new version.
> 1. In the function getLogicalReplicationSlots
> ```
> + /*
> + * Note: Currently we do not have any options to include/exclude
> slots
> + * in dumping, so all the slots must be selected.
> +
On 2023-May-11, Yurii Rashkovskii wrote:
> Relying on a variable number of lines may be counter-productive here if we
> want postmaster.pid to be easily readable by shell scripts.
Oh, I was thinking in Peter E's proposal to list the interface/port
number pairs in a separate file named 'ports' or
> On 11 May 2023, at 07:41, Peter Smith wrote:
> While reviewing another patch for the file info.c, I noticed some
> misplaced colon (':') in the verbose logs for print_rel_infos().
That spelling was introduced in c2e9b2f28818 which was the initial import of
pg_upgrade into contrib/ for the 9.0
On Wed, May 10, 2023 at 8:58 PM Melih Mutlu wrote:
>
> Hi,
>
> Masahiko Sawada , 8 May 2023 Pzt, 10:24 tarihinde şunu
> yazdı:
>>
>> I've attached the patch. Feedback is very welcome.
>
>
> Thanks for the patch, nice catch.
> I can confirm that the issue exists on HEAD and gets resolved by this
On 11/05/2023 00:34, Michael Paquier wrote:
On Wed, May 10, 2023 at 09:24:39AM -0400, Andrew Dunstan wrote:
We will definitely want buildfarm support. I don't have such a machine and
am not likely to have one any time soon. I do run drongo and fairywren on an
EC2 instance, but AWS doesn't seem
Tom Lane 于2023年5月11日周四 00:32写道：
> Bharath Rupireddy writes:
> > And, the /* do not unlock till end of xact */, it looks like it's been
> > there from day 1. It may be indicating that the ref count fo the new
> > relation created in heap_create_with_catalog() will be decremented at
> > the end
On 5/10/23 12:41 PM, Amit Kapila wrote:
On Tue, May 9, 2023 at 12:44 PM Drouvot, Bertrand
Pushed this yesterday.
Thanks!
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Alvaro, Tom,
On Mon, May 8, 2023 at 4:49 PM Tom Lane wrote:
> Alvaro Herrera writes:
> > This made me wonder if storing the unadorned port number is really the
> > best way. Suppose we did extend things so that we listen on different
> > ports on different interfaces; how would this scheme
Hi Denis,
Great catch. I've amended the patch to fix this issue with the
documentation (V3).
On Tue, May 9, 2023 at 2:25 PM Denis Laxalde
wrote:
> The documentation fails to build for me:
>
> $ ninja docs
> [1/2] Generating doc/src/sgml/postgres-full.xml with a custom command
> FAILED:
Dear Wang,
> I'm not sure if there is any reason to not expose this new option? Do we have
> concerns that users who use this new option by mistake may cause data
> inconsistencies?
>
> BTW, I think that all options of pg_dump (please see the array of long_options
> in the main function of the
On Wed, May 10, 2023 at 09:04:47PM +0900, Michael Paquier wrote:
> It took me some time, but I have been able to deploy a big box to see
> the effect of this patch at a rather large scale (64 vCPU, 512G of
> memory), with the following test characteristics for HEAD and v6:
> - TPS comparison with
70 matches
Mail list logo
