> 1. The solution based on background workers looks too fragile - it
can be easy to exhaust all background workers, and because this feature
is proposed mainly for logging, then it is a little bit dangerous,
because it means loss of possibility of logging.
1. We could add types for background
> Is anyone else using backgroud connections?
Don't know at the current time. Maybe EnterpriseDB uses bgworkers as
Peter Eisentraut works there currently (LinkedIn says =)) And in 2016
he has proposed a patch with autonomous transactions with bgworkers.
https://www.postgresql.org/message-id/f
Hi!
On Mon, Dec 11, 2023 at 3:25 PM Ashutosh Bapat
wrote:
> On Fri, Dec 8, 2023 at 11:24 PM Alexander Korotkov
> wrote:
> > On Fri, Dec 8, 2023 at 3:28 PM Ashutosh Bapat
> > wrote:
> > > I did some analysis of memory consumption by bitmapsets in such cases.
> > > [1] contains slides with the r
Dave Cramer
www.postgres.rocks
On Sat, 23 Dec 2023 at 11:00, Tom Lane wrote:
> 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
Hi
ne 24. 12. 2023 v 12:27 odesílatel Ivan Kush
napsal:
> > 1. The solution based on background workers looks too fragile - it
> can be easy to exhaust all background workers, and because this feature
> is proposed mainly for logging, then it is a little bit dangerous,
> because it means loss o
On Sun, 24 Dec 2023 at 07:16, Michael Paquier wrote:
>
> 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 real
On 12/23/23 11:00, Tom Lane wrote:
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:
Thanks!
* This seems
On 12/24/23 10:14 AM, Joe Conway wrote:
On 12/23/23 11:00, Tom Lane wrote:
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 o
"Jonathan S. Katz" writes:
> I think this is a good start and adds something that's better than what
> we have today. However, it seems like we also need something for "CREATE
> ROLE", otherwise we're either asking users to set passwords in two
> steps, or allowing for the unencrypted password
Joe Conway writes:
> Completely unrelated process bikeshedding:
> I changed the naming scheme I used for the split patch-set this time. I
> don't know if we have a settled/documented pattern for such naming, but
> the original pattern which I borrowed from someone else's patches was
> "vX--
On 12/24/23 12:22, Tom Lane wrote:
Joe Conway writes:
Completely unrelated process bikeshedding:
I changed the naming scheme I used for the split patch-set this time. I
don't know if we have a settled/documented pattern for such naming, but
the original pattern which I borrowed from someone e
Coverity whinged this morning about the following bit in
the new pg_combinebackup code:
644 unsignedrb;
645
646 /* Read the block from the correct source, except if
dry-run. */
647 rb = pg_pread(s->fd, buffer, BLCKSZ, offsetmap[i]);
648
Joe Conway writes:
> Oh well, I guess I will get with the program and put every patch-set
> into its own directory.
Yeah, that's what I've started doing too. It does have some
advantages, in that you can squirrel away other related files
in the same subdirectory.
regard
On Tue, Dec 12, 2023 at 3:22 PM Alexander Korotkov wrote:
>
> On Mon, Dec 11, 2023 at 6:16 PM Peter Geoghegan wrote:
> > Will you be in Prague this week? If not this might have to wait.
>
> Sorry, I wouldn't be in Prague this week. Due to my current
> immigration status, I can't travel.
> I wish
On Sat, Dec 23, 2023 at 12:04 AM Alexander Korotkov
wrote:
> On Mon, Dec 4, 2023 at 3:50 AM Anton A. Melnikov
> wrote:
>>
>> Thanks for remarks!
>>
>> On 28.11.2023 21:34, Alexander Korotkov wrote:
>> > After examining the second patch
>> > ("v2-0001-Add-restartpoint-stats.patch"), it appears th
Hi Alexander,
On Sun, Dec 24, 2023 at 5:32 PM Alexander Korotkov wrote:
>
>
> Thank you Ashutosh for your work on this matter. With a large number of
> partitions, it definitely makes sense to reduce both Bitmapset's size as well
> as the number of Bitmapsets.
>
> I've checked the patchset [1]
On Mon, Dec 25, 2023 at 2:56 AM Ashutosh Bapat
wrote:
> On Sun, Dec 24, 2023 at 5:32 PM Alexander Korotkov
> wrote:
> >
> >
> > Thank you Ashutosh for your work on this matter. With a large number of
> > partitions, it definitely makes sense to reduce both Bitmapset's size as
> > well as the
Hi Andrey,
On Sun, Dec 24, 2023 at 1:14 AM Andrey M. Borodin wrote:
>
>
>
> > 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,
On Sun, 24 Dec 2023 at 01:14, Andrey M. Borodin wrote:
>> 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 wo
I came across the 'missing braces' warning again when building master
(0a93f803f4) on old GCC (4.8.5).
blkreftable.c: In function ‘BlockRefTableSetLimitBlock’:
blkreftable.c:268:2: warning: missing braces around initializer
[-Wmissing-braces]
BlockRefTableKey key = {0}; /* make sure any padding
On Mon, 25 Dec 2023 at 10:42, Richard Guo wrote:
> I came across the 'missing braces' warning again when building master
> (0a93f803f4) on old GCC (4.8.5).
>
> blkreftable.c: In function ‘BlockRefTableSetLimitBlock’:
> blkreftable.c:268:2: warning: missing braces around initializer
> [-Wmissing-
Richard Guo writes:
> I came across the 'missing braces' warning again when building master
> (0a93f803f4) on old GCC (4.8.5).
On the one hand, it's probably pointless to worry about buggy
warnings from ancient compilers ...
> This has popped up a few times in the past, and it seems to be GCC bu
I wrote:
> Richard Guo writes:
>> I came across the 'missing braces' warning again when building master
>> (0a93f803f4) on old GCC (4.8.5).
> On the one hand, it's probably pointless to worry about buggy
> warnings from ancient compilers ...
Actually, after checking the buildfarm, I see that
ar
Hello.
pg_basebackup.c: got the following message lines:
> printf(_(" -i, --incremental=OLDMANIFEST\n"));
> printf(_(" take incremental backup\n"));
I'd suggest merging these lines as follows (and the attached patch).
> + printf(_(" -i, --incremental=OL
Hi.
+/*
+ * JsonTableFetchRow
+ * Prepare the next "current" tuple for upcoming GetValue calls.
+ * Returns FALSE if the row-filter expression returned no more rows.
+ */
+static bool
+JsonTableFetchRow(TableFuncScanState *state)
+{
+ JsonTableExecContext *cxt =
+ GetJsonTableExecContext(state, "J
> > printf(_(" -i, --incremental=OLDMANIFEST\n"));
> > printf(_(" take incremental backup\n"));
>
> I'd suggest merging these lines as follows (and the attached patch).
>
> > + printf(_(" -i, --incremental=OLDMANIFEST\n"
> > +"
A new function check_control_file() in pg_combinebackup.c has the
following message.
> pg_fatal("%s: crc is incorrect", controlpath);
I think "crc" should be in all uppercase in general and a brief
grep'ing told me that it is almost always or consistently used in
uppercase i
On Sat, Dec 16, 2023 at 08:20:57PM +0100, Michael Paquier wrote:
> One thing that 0001 missed is an update of the header where the
> function is declared. I've edited a few things, and applied it to
> start on this stuff. The rest will have to wait a bit more..
I have been reviewing the whole, a
On Mon, Dec 25, 2023 at 03:20:58PM +0900, Michael Paquier wrote:
> pgstat_tracks_io_bktype() does not look correct to me. Why is the WAL
> receiver considered as something correct in the list of backend types,
> while the intention is to *not* add it to pg_stat_io? I have tried to
> switche to th
On Mon, Dec 25, 2023 at 02:39:16PM +0900, Kyotaro Horiguchi wrote:
> The attached patch contains both of the above fixes.
Good catches, let's fix them. You have noticed that while translating
these new messages, I guess?
--
Michael
signature.asc
Description: PGP signature
On Thu, Jul 13, 2023 at 3:12 PM Richard Guo wrote:
> So I'm wondering if it'd be better that we move all this logic of
> computing additional lateral references within PHVs to get_memoize_path,
> where we can examine only PHVs that are evaluated at innerrel. And
> considering that these lateral
31 matches
Mail list logo
