Japin Li writes:
> IIRC, AtSubStart_Memory, AtSubStart_ResourceOwner and
> AfterTriggerBeginSubXact don't
> use s->state.
No, they don't.
> Why should we set s->state to TRANS_START and then TRANS_INPROGRESS?
I believe it's so that if an error gets thrown somewhere in that
area, we'll recover
Hi hackers,
I found the StartSubTransaction has the following code:
static void
StartSubTransaction(void)
{
[...]
s->state = TRANS_START;
/*
* Initialize subsystems for new subtransaction
*
* must initialize resource-management
On Wed, Sep 14, 2022 at 10:46 AM Tom Lane wrote:
>
> John Naylor writes:
> > On Wed, Sep 14, 2022 at 6:47 AM Tom Lane wrote:
> >> I've just switched longfin to use built-from-source perl 5.14.0.
>
> > In that case, here is a quick update with commit message. Not yet any
> > change for MSVC, but
On Tue, Sep 13, 2022 at 10:11 PM Alvaro Herrera wrote:
>
> On 2022-Sep-07, Amit Kapila wrote:
>
> > Doc: Explain about Column List feature.
> >
> > Add a new logical replication section for "Column Lists" (analogous to the
> > Row Filters page). This explains how the feature can be used and the
>
Thanks for updating the patch!
The patch looks good to me.
- /* Not for general use --- used by SET SESSION AUTHORIZATION */
{"session_authorization", PGC_USERSET, UNGROUPED,
If we don't document session_authorization and do expect that
it's usually used by
On Wed, Sep 14, 2022 at 06:37:38AM +0200, Peter Eisentraut wrote:
> I noticed that this patch has gone around and mostly purged mentions of
> archive_command from the documentation and replaced them with
> archive_library. I don't think this is helpful, since people still use
> archive_command
Michael Paquier writes:
> And so, I have spent a couple of hours torturing the patch, applying
> it after a few tweaks and CI runs:
> ...
> The buildfarm is green so I think that we are good. I have closed the
> open item.
+1, thanks for taking care of that.
As far as my original complaint
On Monday, September 12, 2022 10:14 PM vignesh C wrote:
> On Sat, 10 Sept 2022 at 07:32, Amit Kapila wrote:
> >
> > On Fri, Sep 9, 2022 at 8:48 PM Robert Haas
> wrote:
> > >
> > > On Fri, Sep 9, 2022 at 10:29 AM houzj.f...@fujitsu.com
> > > wrote:
> > > > IIRC, the feature currently works
When I tried to apply this patch, I got the following warning, please
fix it.
Other than that, I think everything is fine.
$ git apply fix_tab_completion_merge_v4.patch
fix_tab_completion_merge_v4.patch:38: trailing whitespace.
else if (TailMatches("USING", MatchAny, "ON", MatchAny) ||
John Naylor writes:
> If we're going to go to this length, it seems more straightforward to
> just check the .c/.h files into version control, like every other
> project that I have such knowledge of.
Strong -1 on that, because then we'd have to mandate that every
committer use exactly the same
On Tue, Sep 13, 2022 at 05:38:47PM -0400, Tom Lane wrote:
> is something I tried along the way to diagnosing the problem, and
> it turns out to have exactly zero effect. The $tempdir is some
> temporary subdirectory of tmp_check that will get nuked at the end
> of the TAP test no matter what. So
I wrote:
> It kind of feels that the argument order should be pointer, oldsize, size.
> It feels even more strongly that people will get the ordering wrong,
> whichever we choose. Is there a way to make that more bulletproof?
Actually ... an even-more-terrifyingly-plausible misuse is that the
On Wed, Sep 14, 2022 at 5:24 AM Thomas Munro wrote:
>
> On Tue, Sep 6, 2022 at 9:34 AM Tom Lane wrote:
> > Peter Eisentraut writes:
> > > Why is this being proposed?
> >
> > Andres is annoyed by the long build time of ecpg, which he has to
> > wait for whether he wants to test it or not. I
I noticed that this patch has gone around and mostly purged mentions of
archive_command from the documentation and replaced them with
archive_library. I don't think this is helpful, since people still use
archive_command and will want to see what the documentation has to say
about it. I suggest
Peter Eisentraut writes:
> I have another little idea that fits well here: repalloc0 and
> repalloc0_array. These zero out the space added by repalloc. This is a
> common pattern in the backend code that is quite hairy to code by hand.
> See attached patch.
+1 in general --- you've put your
On Wed, Sep 14, 2022 at 03:08:06PM +1200, Thomas Munro wrote:
> On Wed, Sep 14, 2022 at 10:23 AM Thomas Munro wrote:
> > Given the simplicity of this case, though, I suppose we could
> > have a little not-very-general shell/python/whatever wrapper script --
> > just compute a checksum of the
On Wed, Sep 14, 2022 at 6:10 AM Andres Freund wrote:
>
> On 2022-09-12 14:49:50 +0700, John Naylor wrote:
> > CI builds fine. For v2 I only adjusted the commit message. I'll push
> > in a couple days unless there are objections.
>
> Makes sense to me. Thanks for working on it!
This is done.
--
I have another little idea that fits well here: repalloc0 and
repalloc0_array. These zero out the space added by repalloc. This is a
common pattern in the backend code that is quite hairy to code by hand.
See attached patch.
From fa611ecf7c8a7b99d37c77da66b421d2f9ebfec3 Mon Sep 17 00:00:00
On 12.09.22 15:49, Tom Lane wrote:
Peter Eisentraut writes:
On 09.09.22 22:13, Tom Lane wrote:
I think serious consideration should be given to back-patching the
0001 part (that is, addition of the macros). Otherwise we'll have
to remember not to use these macros in code intended for
At Wed, 14 Sep 2022 09:19:22 +0530, Amit Kapila wrote
in
> On Wed, Sep 14, 2022 at 9:10 AM Tom Lane wrote:
> >
> > Amit Kapila writes:
> >
> > There are basically two good reasons to back-patch comment changes:
> >
> > * fear that the comment is wrong enough to mislead people looking
> > at
At Tue, 13 Sep 2022 22:38:46 -0400, Tom Lane wrote in
> Kyotaro Horiguchi writes:
> > I saw the following message recently modified.
> >> This controls the maximum distance we can read ahead in the WAL to
> >> prefetch referenced data blocks.
> > Maybe the "we" means "PostgreSQL program and
On Wed, Sep 14, 2022 at 9:10 AM Tom Lane wrote:
>
> Amit Kapila writes:
>
> There are basically two good reasons to back-patch comment changes:
>
> * fear that the comment is wrong enough to mislead people looking
> at the older branch;
>
> * fear that leaving it alone will create a merge hazard
John Naylor writes:
> On Wed, Sep 14, 2022 at 6:47 AM Tom Lane wrote:
>> I've just switched longfin to use built-from-source perl 5.14.0.
> In that case, here is a quick update with commit message. Not yet any
> change for MSVC, but I can put together something later.
Looks reasonable just by
Amit Kapila writes:
> On Wed, Sep 14, 2022 at 8:16 AM Kyotaro Horiguchi
> wrote:
>> I found a small typo in a comment in pgbench.c of 15/master.
>> - * Return the number fo failed transactions.
>> + * Return the number of failed transactions.
> LGTM.
+1
>> While at it, I found "* lot fo
On Wed, Sep 14, 2022 at 6:47 AM Tom Lane wrote:
>
> I've just switched longfin to use built-from-source perl 5.14.0.
In that case, here is a quick update with commit message. Not yet any
change for MSVC, but I can put together something later.
Since we're much less willing to support older
On Wed, Sep 14, 2022 at 8:16 AM Kyotaro Horiguchi
wrote:
>
> I found a small typo in a comment in pgbench.c of 15/master.
>
> - * Return the number fo failed transactions.
> + * Return the number of failed transactions.
>
LGTM.
> While at it, I found "* lot fo unnecessary work." in pg13's
>
On Wed, Sep 14, 2022 at 10:23 AM Thomas Munro wrote:
> Given the simplicity of this case, though, I suppose we could
> have a little not-very-general shell/python/whatever wrapper script --
> just compute a checksum of the input and keep the output files around.
Something as dumb as this
On Tue, Sep 13, 2022 at 06:48:45PM +0900, Kyotaro Horiguchi wrote:
> Nice finding.
>
> At Tue, 13 Sep 2022 00:39:45 -0500, Jaime Casanova
> wrote in
> > and the problem seems to be that after zero'ing the stats that includes
> > the name of the replication slot, this simple patch fixes it...
On Wed, Sep 14, 2022 at 10:46 AM Kyotaro Horiguchi
wrote:
> I found a small typo in a comment in pgbench.c of 15/master.
>
> - * Return the number fo failed transactions.
> + * Return the number of failed transactions.
>
> While at it, I found "* lot fo unnecessary work." in pg13's
>
I found a small typo in a comment in pgbench.c of 15/master.
- * Return the number fo failed transactions.
+ * Return the number of failed transactions.
While at it, I found "* lot fo unnecessary work." in pg13's
procsignal.c. It has been fixed by 2a093355aa in PG14 but PG13 was
left alone at
Kyotaro Horiguchi writes:
> I saw the following message recently modified.
>> This controls the maximum distance we can read ahead in the WAL to prefetch
>> referenced data blocks.
> Maybe the "we" means "PostgreSQL program and you" but I see it
> somewhat out of place.
+1, I saw that today and
I saw the following message recently modified.
> This controls the maximum distance we can read ahead in the WAL to prefetch
> referenced data blocks.
Maybe the "we" means "PostgreSQL program and you" but I see it
somewhat out of place.
I found other three uses of "we" in backend.
> client
Em seg., 5 de set. de 2022 às 23:02, David Rowley
escreveu:
> On Tue, 6 Sept 2022 at 13:52, Ranier Vilela wrote:
> >
> > Em seg., 5 de set. de 2022 às 22:29, David Rowley
> escreveu:
> >> It feels like it would be good if we had a way to detect a few of
> >> these issues much earlier than we
John Naylor writes:
> On Sat, Sep 3, 2022 at 2:11 AM Tom Lane wrote:
>> Yeah, that seems like a reasonable new minimum for Perl. I might
>> see about setting up an animal running 5.14.0, just so we can say
>> "5.14" in the docs without fine print.
> Until such time as that happens, here is a
On 2022-09-12 14:49:50 +0700, John Naylor wrote:
> CI builds fine. For v2 I only adjusted the commit message. I'll push
> in a couple days unless there are objections.
Makes sense to me. Thanks for working on it!
On Tue, Sep 13, 2022 at 01:32:11PM +0900, Michael Paquier wrote:
> On Mon, Sep 12, 2022 at 09:13:11PM -0500, Justin Pryzby wrote:
> > Like this, maybe.
> >
> > It's similar to what I suggested to consider backpatching here:
> >
On Tue, Sep 6, 2022 at 9:34 AM Tom Lane wrote:
> Peter Eisentraut writes:
> > Why is this being proposed?
>
> Andres is annoyed by the long build time of ecpg, which he has to
> wait for whether he wants to test it or not. I could imagine that
> I might disable ecpg testing on my slowest
Michael Paquier writes:
> Attached is the patch I am finishing with, consisting of:
> - the removal of PG_COMPRESSION_OPTION_LEVEL.
> - assigning a default compression level when nothing is specified in
> the spec.
> - a couple of complifications in pg_receivewal, pg_basebackup and the
> backend
On Tue, Sep 13, 2022 at 2:01 PM Tom Lane wrote:
> > AFAICT almost all of our shell scripts contain the same mistake. I
> > propose to fix them all as in the attached demo patch, which makes
> > headerscheck exit properly (no silly noise) when interrupted.
>
> Sounds like a good idea.
Might not
Alvaro Herrera writes:
> While messing with the new guc.h stuff I happened run headerscheck and
> wanted to abort it right away, and in doing so I realized that its
> 'trap' line is incorrect: it only removes its temp dir, but it doesn't
> exit the program; so after you C-c it, it will spew a ton
On Tue, Sep 13, 2022 at 08:32:43AM +0200, Peter Eisentraut wrote:
> I notice that for column misspellings, the hint is phrased "Perhaps you
> meant X." whereas here we have "Did you mean X?". Let's make that uniform.
Good point. I attached a new version of the patch that uses the column
While messing with the new guc.h stuff I happened run headerscheck and
wanted to abort it right away, and in doing so I realized that its
'trap' line is incorrect: it only removes its temp dir, but it doesn't
exit the program; so after you C-c it, it will spew a ton of complaints
about its temp
Hi, Justin!
On Fri, Jul 29, 2022 at 1:05 PM Justin Kwan wrote:
> Not sure if this email went through previously but thank you for your
> feedback, I've incorporated your suggestions by scanning the logs produced
> from pg_rewind when asserting that certain WAL segment files were skipped
>
On Tue, 2022-09-13 at 16:13 +0200, Matthias van de Meent wrote:
> On Tue, 13 Sept 2022 at 15:45, Tom Lane wrote:
> > Laurenz Albe writes:
> > > But once they are deleted or updated, even the transaction that created
> > > them cannot
> > > see them any more, right?
> >
> > I would not trust
On Tue, Sep 13, 2022 at 7:11 AM Peter Eisentraut
wrote:
> This looks fine to me. Committed.
Thanks!
--Jacob
On Mon, Sep 12, 2022 at 11:45 PM Nikita Malakhov wrote:
> It would be more clear for complex data types like JSONB, where developers
> could
> need some additional functionality to work with internal representation of
> data type,
> and its full potential is revealed in our JSONB toaster
I wrote:
> Attached is a patch series that attempts to modernize our GUC
> infrastructure, in particular removing the performance bottlenecks
> it has when there are lots of GUC variables.
Rebased over 0a20ff54f.
regards, tom lane
commit
On 2022-09-13 15:41, Peter Eisentraut wrote:
On 13.09.22 07:34, Marina Polyakova wrote:
I agree with you that it is more comfortable and more similar to what
has already been done in initdb. IMO it would be easier to do it like
this:
diff --git a/src/bin/scripts/createdb.c
On 9/13/22 7:13 AM, Alvaro Herrera wrote:
On 2022-Sep-12, Jonathan S. Katz wrote:
+
+
+ Column-level and row-level filtering on
+ logical replication
+ publications.
+
+
-column-level filtering
+the ability to specify column lists
Adjusted to be similar to
Em ter., 13 de set. de 2022 às 11:09, Alvaro Herrera <
alvhe...@alvh.no-ip.org> escreveu:
> On 2022-Sep-13, Ranier Vilela wrote:
>
> > However, for Postgres 15 this may can cause a small memory leak.
>
> What memory leak? There's no leak here.
>
Yeah, as per Julien's answer, there is really no
Peter Eisentraut writes:
> 2) You configure and install with prefix=/usr/local/pgsql-14, and then
> symlink /usr/local/pgsql -> /usr/local/pgsql-14; hoping that you can
> then use /usr/local/pgsql as if that's where it actually is. We don't
> currently support that. (Note that it would work
On 13.09.22 01:26, Tom Lane wrote:
Andrew Dunstan writes:
I think the discussion here is a bit tangential to the original topic.
Indeed, because I just wanted to reimplement *how* we resolve the
executable path to absolute, not question whether we should do it at all.
Well, if we decided
On Tue, 13 Sept 2022 at 15:45, Tom Lane wrote:
>
> Laurenz Albe writes:
> > But once they are deleted or updated, even the transaction that created
> > them cannot
> > see them any more, right?
>
> I would not trust that claim very far. The transaction might have active
> snapshots with a
On 09.09.22 00:32, Jacob Champion wrote:
On Thu, Jul 28, 2022 at 9:19 AM Jacob Champion wrote:
On Thu, Jul 21, 2022 at 4:29 PM Jacob Champion wrote:
v4 attempts to fix this by letting the check hooks pass
MCXT_ALLOC_NO_OOM to pg_clean_ascii(). (It's ignored in the frontend,
which just
On 2022-Sep-13, Ranier Vilela wrote:
> However, for Postgres 15 this may can cause a small memory leak.
What memory leak? There's no leak here.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Bob [Floyd] used to say that he was planning to get a Ph.D. by the
On Tue, Sep 13, 2022 at 10:21:22AM -0300, Ranier Vilela wrote:
> Hi,
>
> The commit: Revert SQL/JSON features
> https://github.com/postgres/postgres/commit/2f2b18bd3f554e96a8cc885b177211be12288e4a
>
> Left a little oversight.
> I believe it will be properly corrected when it is applied again.
>
Alvaro Herrera writes:
> On 2022-Sep-12, Tom Lane wrote:
>> Yeah, I suspect people will have to manually reapply any changes in
>> the GUC tables to guc_tables.c. That'll be the same amount of work
>> for them whenever we commit this patch (unless theirs lands first,
>> in which case I have to
On Sun, 11 Sept 2022 at 21:35, Robert Treat wrote:
>
> On Wed, Sep 7, 2022 at 8:05 AM Simon Riggs
> wrote:
> >
> > On Tue, 6 Sept 2022 at 21:33, Justin Pryzby wrote:
> > >
> > > On Tue, Sep 06, 2022 at 04:16:02PM +0100, Simon Riggs wrote:
> > > > New chapter on transaction management, plus a
On 2022/09/13 17:25, bt22kawamotok wrote:
Thanks for the patch!
+
+ is_superuser (boolean)
You need to add this entry just after that of "in_hot_standby" because
the descriptions of preset parameters should be placed in alphabetical
order in the docs.
+
+
Laurenz Albe writes:
> But once they are deleted or updated, even the transaction that created them
> cannot
> see them any more, right?
I would not trust that claim very far. The transaction might have active
snapshots with a command ID between the times of insertion and deletion.
(Consider a
Hi,
The commit: Revert SQL/JSON features
https://github.com/postgres/postgres/commit/2f2b18bd3f554e96a8cc885b177211be12288e4a
Left a little oversight.
I believe it will be properly corrected when it is applied again.
However, for Postgres 15 this may can cause a small memory leak.
Attached a
On 13.09.22 07:34, Marina Polyakova wrote:
I agree with you that it is more comfortable and more similar to what
has already been done in initdb. IMO it would be easier to do it like this:
diff --git a/src/bin/scripts/createdb.c b/src/bin/scripts/createdb.c
index
On Tue, 13 Sept 2022 at 12:40, Pantelis Theodosiou wrote:
>
> Forgive me if this is not related but if there is a savepoint between
> the insertion and deletion, wouldn't it be possible for the
> transaction to recover the deleted tuples?
Savepoints result in changed TransactionIds (well,
On 2022-Sep-07, Amit Kapila wrote:
> Doc: Explain about Column List feature.
>
> Add a new logical replication section for "Column Lists" (analogous to the
> Row Filters page). This explains how the feature can be used and the
> caveats in it.
>
> Author: Peter Smith
> Reviewed-by: Shi yu,
Hi,
> > 01. filename
> > The word-ordering of filename seems not good
> > because you defined the new worker as "parallel apply worker".
> >
>
> I think in the future we may have more files for apply work (like
> applyddl.c for DDL apply work), so it seems okay to name all apply
> related files
Dear Hou-san,
> I will dig your patch more, but I send partially to keep the activity of the
> thread.
More minor comments about v28.
===
About 0002
For 015_stream.pl
14. check_parallel_log
```
+# Check the log that the streamed transaction was completed successfully
+# reported by
On 5/9/2022 12:22, Richard Guo wrote:
On Fri, Sep 2, 2022 at 7:09 PM Andrey Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
> Hmm, I'm not sure this patch works correctly in all cases. It
seems to
> me this patch pulls up the subquery without checking the constraints
>
On Tue, Sep 13, 2022 at 4:43 AM Daniel Gustafsson wrote:
>
> > On 12 Sep 2022, at 20:46, Daniel Gustafsson wrote:
> >
> >> On 12 Sep 2022, at 18:13, James Coleman wrote:
> >
> >> See attached simple patch to fix $SUBJECT; the old link generates a Not
> >> Found.
> >
> > According to
On Mon, Sep 12, 2022 at 11:41 AM Peter Eisentraut
wrote:
> I think this is because we have (erroneously) make SET ROLE to be the
> same as SET SESSION AUTHORIZATION. If those two were separate (i.e.,
> there is a current user and a separate current role, as in the SQL
> standard), then this
On Tue, 13 Sep 2022, 12:04 Laurenz Albe, wrote:
>
> On Tue, 2022-09-13 at 11:47 +0300, Nikita Malakhov wrote:
>> Please correct me if I'm wrong, despite tuples being inserted and deleted by
>> the same
>> transaction - they are visible inside the transaction and usable by it, so
>> considering
On 2022-Sep-12, Jonathan S. Katz wrote:
> +
> +
> + Column-level and row-level filtering on
> + logical replication
> + publications.
> +
> +
-column-level filtering
+the ability to specify column lists
> + Row-level filtering and the ability to specify
On Tue, Sep 13, 2022 at 5:53 PM John Naylor
wrote:
>
> Until such time as that happens, here is a draft to require 5.14.2.
As soon as I hit send, it occurred to me that we don't check the perl
version on Windows, since (I seem to recall) 5.8.3 was too old to be
an option on that platform. We'll
On Tue, 13 Sept 2022 at 11:56, Simon Riggs wrote:
>
> On Tue, 6 Sept 2022 at 13:14, Simon Riggs
> wrote:
>
> > I will update the patch, thanks for your scrutiny.
>
> I attach a diff showing what has changed between v8 and v9, and will
> reattach a full set of new patches in the next post, so
On Tue, 6 Sept 2022 at 13:14, Simon Riggs wrote:
> I will update the patch, thanks for your scrutiny.
I attach a diff showing what has changed between v8 and v9, and will
reattach a full set of new patches in the next post, so patchtester
doesn't squeal.
--
Simon Riggs
On Sat, Sep 3, 2022 at 2:11 AM Tom Lane wrote:
>
> Andres Freund writes:
> > 5.14 would be a trivial lift as far as the buildfarm is concerned.
>
> Yeah, that seems like a reasonable new minimum for Perl. I might
> see about setting up an animal running 5.14.0, just so we can say
> "5.14" in
On Mon, Sep 12, 2022 at 4:27 PM kuroda.hay...@fujitsu.com
wrote:
>
> Dear Hou-san,
>
> Thank you for updating the patch! Followings are comments for v28-0001.
> I will dig your patch more, but I send partially to keep the activity of the
> thread.
>
> ===
> For applyparallelworker.c
>
> 01.
On Tue, Sep 13, 2022 at 11:04 AM Laurenz Albe wrote:
>
> On Tue, 2022-09-13 at 11:47 +0300, Nikita Malakhov wrote:
> > On Tue, Sep 13, 2022 at 11:06 AM Laurenz Albe
> > wrote:
> > > Shouldn't such tuples be considered dead right away, even if the inserting
> > > transaction is still active?
Hi,
When I try to restore an old backup on Windows, the restore always fails with a
message that permission denied for "base/19513/21359".
Note this file name provided by postgres is random. When I check the properties
of this file, this file doesn't have any owner at all. Windows says that no
Hi!
I am trying to solve the problem of estimating the table bloat (and index
bloat, though I am mostly focusing on tables at the moment).
After searching far and wide, it seems that the choice is to be made
between two methods:
1. Slow, but very precise pgstattuple
2. Fast, but somewhat
At Tue, 13 Sep 2022 11:56:16 +0530, Bharath Rupireddy
wrote in
> On Tue, Sep 13, 2022 at 8:52 AM Noah Misch wrote:
> >
> > > > > [1] -
> > > > > https://www.postgresql.org/message-id/flat/20220909.172949.2223165886970819060.horikyota.ntt%40gmail.com
> >
> > I plan to use that message's patch,
On Fri, Sep 9, 2022 at 12:32 PM Peter Smith wrote:
>
> 29. src/backend/replication/logical/worker.c - TransactionApplyAction
>
> /*
> * What action to take for the transaction.
> *
> * TA_APPLY_IN_LEADER_WORKER means that we are in the leader apply worker and
> * changes of the transaction
On 2022-Sep-13, Thomas Munro wrote:
> I'd go for your second suggestion. 'therein' doesn't convey much (we
> already said 'in the WAL', and therein is just a slightly formal and
> somehow more Germanic way of saying 'in it' which is kinda
> duplicative; maybe 'by it' is what we want but that's
On Tue, 2022-09-13 at 11:47 +0300, Nikita Malakhov wrote:
> On Tue, Sep 13, 2022 at 11:06 AM Laurenz Albe
> wrote:
> > Shouldn't such tuples be considered dead right away, even if the inserting
> > transaction is still active? That would allow cleaning them up even before
> > the transaction is
On 2022-Sep-09, Alvaro Herrera wrote:
> Keeping 's' and removing the pstrdups better uses memory, because we
> have a single palloc'ed chunk per option rather than two.
Pushed. This is pretty much cosmetic, so no backpatch.
--
Álvaro Herrera 48°01'N 7°57'E —
Nice finding.
At Tue, 13 Sep 2022 00:39:45 -0500, Jaime Casanova
wrote in
> and the problem seems to be that after zero'ing the stats that includes
> the name of the replication slot, this simple patch fixes it... not sure
> if it's the right fix though...
That doesn't work. since what that
On Fri, Sep 9, 2022 at 2:31 PM houzj.f...@fujitsu.com
wrote:
>
> On Friday, September 9, 2022 3:02 PM Peter Smith
> wrote:
> >
>
> > 3.
> >
> > max_logical_replication_workers (integer)
> > Specifies maximum number of logical replication workers. This
> > includes apply leader workers,
út 13. 9. 2022 v 10:46 odesílatel John Naylor
napsal:
> On Mon, Sep 12, 2022 at 8:10 PM Pavel Stehule
> wrote:
> >
> > po 12. 9. 2022 v 9:59 odesílatel Daniel Gustafsson
> napsal:
> >> I don't the capabilities of the tool is all that interesting compared
> to the
> >> long term maintainability
On Thu, Sep 8, 2022 at 12:39 PM John Naylor
wrote:
>
> On Fri, Sep 2, 2022 at 3:19 PM Kyotaro Horiguchi
> wrote:
> >
> > At Fri, 2 Sep 2022 13:43:50 +0700, John Naylor
> > wrote in
> > > If there is any doubt about including all of Cf, we could also just
> > > add a branch in wchar.c to
On 2022-Sep-12, Tom Lane wrote:
> Yeah, I suspect people will have to manually reapply any changes in
> the GUC tables to guc_tables.c. That'll be the same amount of work
> for them whenever we commit this patch (unless theirs lands first,
> in which case I have to deal with it). The issue I
Hi!
Please correct me if I'm wrong, despite tuples being inserted and deleted
by the same
transaction - they are visible inside the transaction and usable by it, so
considering them
dead and cleaning up during execution is a bad idea until the
transaction is ended.
On Tue, Sep 13, 2022 at 11:06
On Mon, Sep 12, 2022 at 8:10 PM Pavel Stehule wrote:
>
> po 12. 9. 2022 v 9:59 odesílatel Daniel Gustafsson napsal:
>> I don't the capabilities of the tool is all that interesting compared to the
>> long term maintainability and readability of the source code.
With make distprep and
> On 12 Sep 2022, at 20:46, Daniel Gustafsson wrote:
>
>> On 12 Sep 2022, at 18:13, James Coleman wrote:
>
>> See attached simple patch to fix $SUBJECT; the old link generates a Not
>> Found.
>
> According to archive.org the freebsd.org site changed sometime in early 2021
> with a 301
At Tue, 13 Sep 2022 16:15:34 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Tue, 13 Sep 2022 15:45:07 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > At Mon, 12 Sep 2022 14:51:56 -0700, Andres Freund
> > wrote in
> > > This sees a tad misleading - the previous snapshot wasn't borken, right?
>
Thanks for the patch!
+
+ is_superuser (boolean)
You need to add this entry just after that of "in_hot_standby" because
the descriptions of preset parameters should be placed in alphabetical
order in the docs.
+
+Reports whether the user is superuser or not.
Isn't
On Fri, 9 Sept 2022 at 11:33, David Rowley wrote:
> I really think the Assert only form of MemoryContextContains() is the
> best move, and if it's doing Assert only, then we can do the
> loop-over-the-blocks idea as you described and I drafted in [1].
>
> If the need comes up that we're certain
Shouldn't such tuples be considered dead right away, even if the inserting
transaction is still active? That would allow cleaning them up even before
the transaction is done.
There is this code in HeapTupleSatisfiesVacuumHorizon:
else if
Sigh..
At Tue, 13 Sep 2022 16:30:06 +0900 (JST), Kyotaro Horiguchi
wrote in
> It is possible that the subxip is overrun. We need to expand the array
> somehow. Or assign the array of the size (GetMaxSnapshotXidCount() +
> GetMaxSnapshotSubxidCount()) for takenDuringRecovery snapshots.
And I
At Tue, 13 Sep 2022 16:10:59 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Tue, 13 Sep 2022 12:08:18 +0530, Dilip Kumar wrote
> in
> > On Tue, Sep 13, 2022 at 11:52 AM Kyotaro Horiguchi
> > wrote:
> > > That function is called after the SnapBuild reaches
> > > SNAPBUILD_CONSISTENT state ,or
On Tue, Sep 13, 2022 at 11:35 AM Zhang Mingli wrote:
> Param isSlice was once used to identity targetTypeId for
> transformAssignmentIndirection.
>
> In commit c7aba7c14e, the evaluation was pushed down to
> transformContainerSubscripts.
>
> No need to keep isSlice around
At Tue, 13 Sep 2022 15:45:07 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Mon, 12 Sep 2022 14:51:56 -0700, Andres Freund wrote
> in
> > This sees a tad misleading - the previous snapshot wasn't borken, right?
>
> I saw it kind of broken that ->xip contains sub transactions. But I
> didn't
1 - 100 of 111 matches
Mail list logo
