On Sat, Dec 23, 2023 at 09:52:59AM +1300, Thomas Munro wrote:
> As it happens I was just thinking about this particular patch because
> I suddenly had a strong urge to teach pg_combinebackup to use
> copy_file_range. I wonder if you had the same idea...
Yeah, +1. That would make copy_file_blocks
On Tue, Dec 19, 2023 at 03:15:42PM -0500, Robert Haas wrote:
> I don't think this is a good commit message. It's totally unclear what
> it means, and when I opened up the diff to try to see what was
> changed, it looked nothing like what I expected.
(Not my intention to ignore you here, my head ha
On Mon, Nov 13, 2023 at 07:06:15PM -0500, Melanie Plageman wrote:
> As best I can tell, our best case scenario is Thomas' streaming read API
> goes in, we add vacuum as a user, and we can likely remove the skip
> range logic.
This does not prevent the work you've been doing in 0001 and 0002
posted
>
>
> I think you're overthinking it.
>
*Moi*? Never happens ;-)
Fantastic answer, thanks very much for giving me all of these details.
Coming from you, I'll take it as authoritative and run with it.
On Sat, Dec 23, 2023 at 03:18:01PM +0100, Peter Eisentraut wrote:
> +/* LCOV_EXCL_START */
> +PG_FUNCTION_INFO_V1(pg_stat_statements);
> PG_FUNCTION_INFO_V1(pg_stat_statements_1_2);
> +/* LCOV_EXCL_STOP */
The only reason why I've seen this used at the C level was to bump up
the coverage requirem
On Sat, Dec 23, 2023 at 08:52:38AM +0530, vignesh C wrote:
> I didn't see anyone volunteering for the January Commitfest, so I'll
> volunteer to be CF manager for January 2024 Commitfest.
(Adding Magnus in CC.)
That would be really helpful. Thanks for helping! Do you have the
admin rights on th
On Fri, Dec 22, 2023 at 09:07:21AM -0500, Andrew Dunstan wrote:
> I've done it a bit differently, but the same idea. I have tested that what I
> committed passes checks on Unix and works on Windows.
Sounds fine by me. Thanks for the quick turnaround!
--
Michael
signature.asc
Description: PGP si
On Sat, Dec 23, 2023 at 03:37:33PM +0800, Japin Li wrote:
> Thanks for you confirmation! Please consider the v2 patch to review.
This oversight is from me via commit e35cc3b3f2d0. I'll take care of
it. Thanks for the report!
--
Michael
signature.asc
Description: PGP signature
Morris de Oryx writes:
> I've got a small question about marking functions working with decimal
> number types as either IMMUTABLE or STABLE. Below are a pair of trivial
> functions that show what I'm guessing. An int8/int8[] seems like it's going
> to be immutable forever. However, decimal types
date_bin has big problem with DST.
In example, if you put origin in winter zone, then generated bin will be
incorrect for summer input date.
date_trunc is resistant for this problem.
My version of date_trunc is additionally more flexible, you can select
more granular interval, 12h, 8h, 6h, 15m
My compiler has the following complaint:
../postgresql/src/backend/postmaster/walsummarizer.c: In function
‘GetOldestUnsummarizedLSN’:
../postgresql/src/backend/postmaster/walsummarizer.c:540:32: error:
‘unsummarized_lsn’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
Hi
pá 22. 12. 2023 v 0:17 odesílatel Jeff Davis napsal:
> On Wed, 2023-12-20 at 17:48 -0800, Jeff Davis wrote:
> > Attached.
>
> It appears to increase the coverage. I committed it and I'll see how
> the buildfarm reacts.
>
I tested it locally ( LANG=cs_CZ.UTF-8 ) without problems
Regards
Pav
I've got a small question about marking functions working with decimal
number types as either IMMUTABLE or STABLE. Below are a pair of trivial
functions that show what I'm guessing. An int8/int8[] seems like it's going
to be immutable forever. However, decimal types aren't quite so crisp and
consis
so 23. 12. 2023 v 19:18 odesílatel Tom Lane napsal:
> I happened to notice that information_schema._pg_expandarray(),
> which has the nigh-unreadable definition
>
> AS 'select $1[s],
> s operator(pg_catalog.-) pg_catalog.array_lower($1,1)
> operator(pg_catalog.+) 1
> from pg_c
I happened to notice that information_schema._pg_expandarray(),
which has the nigh-unreadable definition
AS 'select $1[s],
s operator(pg_catalog.-) pg_catalog.array_lower($1,1)
operator(pg_catalog.+) 1
from pg_catalog.generate_series(pg_catalog.array_lower($1,1),
> On 23 Dec 2023, at 17:52, Tom Lane wrote:
>
> Andrew Dunstan writes:
>> On 2023-12-22 Fr 17:11, Tom Lane wrote:
>>> After studying this some more, my conclusion is that BackgroundPsql.pm
>>> failed to borrow as much as it should have from 010_tab_completion.pl.
>>> Specifically, we want all
> On 22 Dec 2023, at 10:39, Japin Li wrote:
>
>
> I try to split the test for transaction timeout, and all passed on my CI [1].
I like the refactoring you did in timeout.spec. I thought it is impossible,
because permutations would try to reinitialize FATALed sessions. But,
obviously, tests
Andrew Dunstan writes:
> On 2023-12-22 Fr 17:11, Tom Lane wrote:
>> After studying this some more, my conclusion is that BackgroundPsql.pm
>> failed to borrow as much as it should have from 010_tab_completion.pl.
>> Specifically, we want all the environment-variable changes that that
>> script per
Joe Conway writes:
> The attached patch set moves the guts of \password from psql into the
> libpq client side -- PQchangePassword() (patch 0001).
Haven't really read the patch, just looked at the docs, but here's
a bit of bikeshedding:
* This seems way too eager to promote the use of md5. Sur
I have recently, once again for the umpteenth time, been involved in
discussions around (paraphrasing) "why does Postgres leak the passwords
into the logs when they are changed". I know well that the canonical
advice is something like "use psql with \password if you care about that".
And while
pg_stat_statements has some significant gaps in test coverage,
especially around the serialization of data around server restarts, so I
wrote a test for that and also made some other smaller tweaks to
increase the coverage a bit. These patches are all independent of each
other.
After that, t
On 2023-12-22 Fr 17:11, Tom Lane wrote:
I wrote:
I happened to notice this stuff getting added to my .psql_history:
\echo background_psql: ready
SET password_encryption='scram-sha-256';
;
\echo background_psql: QUERY_SEPARATOR
SET scram_iterations=42;
;
\echo background_psql: QUERY_SEPARATOR
\
Here is an updated patch rebased over 3e2e0d5ad7.
The 0001 patch stands on its own, but I also tacked on two additional
WIP patches that simplify some pg_attribute handling and make these
kinds of refactorings simpler in the future. See description in the
patches.
On 05.12.23 13:52, Peter
so 23. 12. 2023 v 13:33 odesílatel Pavel Stehule
napsal:
> Hi
>
> pá 22. 12. 2023 v 23:25 odesílatel Przemysław Sztoch
> napsal:
>
>> In my opinion date_trunc is very good name.
>> Truncated data is timestamp type, not interval.
>> First parameter has same meaning in original date_trunc and in m
Hi
pá 22. 12. 2023 v 23:25 odesílatel Przemysław Sztoch
napsal:
> In my opinion date_trunc is very good name.
> Truncated data is timestamp type, not interval.
> First parameter has same meaning in original date_trunc and in my new
> version.
> New version provides only more granularity.
>
ok,
I meant to add that the example in the doc is adapted from Marco
Slot's blog post linked earlier:
https://www.citusdata.com/blog/2018/06/14/scalable-incremental-data-aggregation/
On Sun, Sep 3, 2023 at 11:16 PM Will Mortensen wrote:
> I realized that for our use case, we'd ideally wait for holders of
> RowExclusiveLock only, and not e.g. VACUUM holding
> ShareUpdateExclusiveLock. Waiting for lockers in a specific mode seems
> possible by generalizing/duplicating WaitForLoc
27 matches
Mail list logo
