[1] https://www.postgresql.org/message-id/119497.1756892972%40localhost
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
other callers throughout the tree do.
[1]
https://www.postgresql.org/message-id/CADzfLwUgPMLiFkXRnk97ugPqkDfsNJ3TRdw9gjJM%3D8WB4_nXwQ%40mail.gmail.com
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
>From 025322cd23c05fa92bb04c8e1ce76ef40003d4cc Mon Sep 17 00:00:00 2001
From: Anto
Mihail Nikalayeu wrote:
> Antonin Houska :
> > Are you sure the test is complete? I see no occurrence of the REPACK command
> > in it.
> Oops, send invalid file. The correct one in attachment.
Thanks!
The problem was that when removing the original "preserve visibility p
if not.
Are you sure the test is complete? I see no occurrence of the REPACK command
in it.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
h bloggers
do not bother to read user documentation".
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
I don't keep track of its
issues.)
Of course, user documentation should warn about the problem, in a way it does
for other commands (typically ALTER TABLE).
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Mihail Nikalayeu wrote:
> Hello, Antonin!
>
> Antonin Houska :
> >
> > Where exactly should HeapTupleSatisfiesDirty() conclude that the tuple is
> > visible? TransactionIdIsCurrentTransactionId() will not do w/o the
> > modifications that you proposed earlier
Mihail Nikalayeu wrote:
> Antonin Houska :
>
> > Although it could work, I think it'd be confusing to consider the
> > transactions
> > being replayed as "current" from the point of view of the backend that
> > executes REPACK CONCURRENTLY.
>
Mihail Nikalayeu wrote:
> Antonin Houska :
> > I think the problem is that HeapTupleSatisfiesSelf() uses
> > TransactionIdIsInProgress() instead of checking the snapshot:
>
> Yes, some issues might be possible for SnapshotSelf.
> Possible
elieveEverythingCommitted - for that
> particular case it should work - because all xmin/xmax written into
> the new table are committed by design.
I'd prefer optimization of the logical decoding for REPACK CONCURRENTLY, and
using the MVCC snapshots.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
t could lead to weird
> side-effects. Maybe I am mis-thinking it though?
What we discuss here is how to keep visibility information of tuples (xmin,
xmax, ...) unchanged. Both CLUSTER and VACUUM FULL already do that. However
it's not trivial to ensure that REPACK with the CONCURRENTLY option does as
well.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
mmitted. In such a case, HeapTupleSatisfiesSelf() will
> > conclude the old version invisible and the we'll fail to replay the UPDATE.
>
> No, it will see it - because its xmax will be empty in the repacked
> version of the table.
You're right, it'll be empty in the new table.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
ction
may already have committed. In such a case, HeapTupleSatisfiesSelf() will
conclude the old version invisible and the we'll fail to replay the UPDATE.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Andres Freund wrote:
> Hi,
>
> On 2025-08-20 16:22:41 +0200, Antonin Houska wrote:
> > Álvaro Herrera wrote:
> >
> > > On 2025-Aug-20, Antonin Houska wrote:
> > >
> > > > There's an issue with the symlink, maybe some meson expert can hel
ww.postgresql.org/message-id/178741.1743514291%40localhost
[2] https://www.postgresql.org/message-id/97795.1744363522%40localhost
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Álvaro Herrera wrote:
> On 2025-Aug-20, Antonin Houska wrote:
>
> > There's an issue with the symlink, maybe some meson expert can help. In
> > particular, the CI on Windows ends up with the following error:
> >
> > ERROR: Tried to install symlink t
umdb' executable.
I could not find another symlink of this kind in the tree. (AFAICS, the
postmaster->postgres symlink had been removed before Meson has been
introduced.)
Does anyone happen to have a clue? Thanks.
[1] https://mesonbuild.com/Reference-manual_functions.html#install_symlink
[
Alvaro Herrera wrote:
> On 2025-Aug-16, Robert Treat wrote:
>
> > On Tue, Aug 5, 2025 at 4:59 AM Antonin Houska wrote:
>
> > > Now that we want to cover the CLUSTER/VACUUM FULL completely, I've
> > > checked the
> > > options of VACUUM FULL.
LYZE and SKIP_DATABASE_STATS. Maybe just
let's mention that in the user documentation of REPACK?
(Besides that, VACUUM FULL accepts TRUNCATE and INDEX_CLEANUP options, but I
think these have no effect.)
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
me you mean that the requirement for ABI/API stability would make it
hard to include tests for fixes like [2] in minor releases. Thanks for
explanation.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
trib" binary package than by building the whole server from source. (AFAIK
the src/modules/injection_points directory is currently not included in any
package.)
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Erik Nordström wrote:
> On Mon, Jun 30, 2025 at 1:46 PM Álvaro Herrera wrote:
>
> On 2025-Jun-30, Erik Nordström wrote:
>
> > On Mon, Jun 30, 2025 at 12:03 PM Antonin Houska wrote:
>
> > > Patch [1] is in the queue that allows both reads and writes. (
s, but that should be held for very short
time.)
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
[1] https://commitfest.postgresql.org/patch/5117/
Andres Freund wrote:
> On 2025-03-13 11:53:03 +0100, Antonin Houska wrote:
> > Attached are a few proposals for minor comment fixes.
>
> Thanks, applied.
After reading the code a bit more, I noticed that the 'cb_flags' argument of
PgAioHandleCallbackStage is not rea
nstead of CLUSTER. And while doing that, we may or may
not rename it.
[1] https://www.postgresql.org/message-id/117560.1749464355%40localhost
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
n to be revealed this way. In any case, a GUC to enable the
feature only if the DBA wants it makes sense.)
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
D and validated
-- afterwards.
alter table fk add foreign key(i) references pk not valid;
alter table fk validate constraint fk_i_fkey;
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
_COMMAND_CREATE_INDEX,
> heapId);
> pgstat_progress_update_multi_param(2, progress_cols, progress_vals);
> }
Ah, got it. So for now the REPACK CONCURRENTLY patch only needs to turn off
the progress reporting for PROGRESS_COMMAND_CREATE_INDEX properly. Thanks for
checking!
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
then not have to use
> a message like the one introduced in f1889729dd3ab0 to support parallel index
> vacuum progress 46ebdfe164c61.
I didn't know about these patches. I'm not sure though if this needs to be
removed. Even if each worker updated the progress information separately
(would users appreciate that?), it should still send the progress information
to the leader before it (i.e. the worker) exits.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
pgstat.c is designed for
frequent updates of backend-local statistics and less frequent flushes
(e.g. at command completion) to the shared memory. That's not suitable for
progress reporting.
> [2] https://commitfest.postgresql.org/patch/5282/
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
pg_stat_progress_cluster would disappear
temporarily. That might also be confusing.
Ideally we should report on all the commands in progress, but that is not
trivial to implement.
> [1] https://commitfest.postgresql.org/patch/5117/
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
s that
worth the effort?
[1] https://commitfest.postgresql.org/patch/5117/
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Matheus Alcantara wrote:
> Hi,
>
> On Tue, Apr 1, 2025 at 10:31 AM Antonin Houska wrote:
> > One more version, hopefully to make cfbot happy (I missed the bug because I
> > did not set the RELCACHE_FORCE_RELEASE macro in my environment.)
>
> Thanks for the new ver
}
> +
> + | REPACK '(' utility_option_list ')'
> + {
> + RepackStmt *n = makeNode(RepackStmt);
> +
> + n->relation = NULL;
> + n->indexname = NULL;
>
Alvaro Herrera wrote:
> On 2025-Apr-01, Antonin Houska wrote:
>
> > Besides that, it occurred to me that 0005 ("Preserve visibility
> > information of the concurrent data changes.") will probably introduce
> > significant overhead. The problem is that the ta
Alvaro Herrera wrote:
> On 2025-Mar-22, Antonin Houska wrote:
>
> > Alvaro Herrera wrote:
> >
> > > I rebased this patch series; here's v09. No substantive changes from v08.
> > > I made sure the tree still compiles after each commit.
>
> I re
Alvaro Herrera wrote:
> On 2025-Mar-22, Antonin Houska wrote:
>
> > Alvaro Herrera wrote:
> >
> > > I rebased this patch series; here's v09. No substantive changes from v08.
> > > I made sure the tree still compiles after each commit.
>
> I re
).
(I don't claim that saving and restoring the progress state is perfect, but I
don't have better idea right now.)
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Robert Haas wrote:
> On Thu, Mar 20, 2025 at 2:09 PM Antonin Houska wrote:
> > Robert Haas wrote:
> > > Is there a README or a long comment in here someplace that is a good
> > > place to read to understand the overall design of this feature?
> >
> >
Robert Haas wrote:
> Is there a README or a long comment in here someplace that is a good
> place to read to understand the overall design of this feature?
I tried to explain how it works in the commit messages. The one in 0004 is
probably the most important one.
--
Antonin Houska
Web:
ous;
Assert(ioh->state == PGAIO_HS_HANDED_OUT);
+ Assert(pgaio_my_backend->handed_out_io == ioh);
Assert(pgaio_io_has_target(ioh));
ioh->op = op;
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
diff --git a/src/backend/storage/aio/aio_io.c b/src/backend
Alvaro Herrera wrote:
> On 2025-Feb-26, Antonin Houska wrote:
>
> > @@ -403,39 +381,38 @@ cluster_rel(Relation OldHeap, Oid indexOid,
> > ClusterParams *params)
> > * would work in most respects, but the index would only get marked as
> > * indisclu
Y). I'll
incorporate it into the patch series but it'd be great if this part was a
little bit stable before I start to rebase the depending patches. Thanks.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
--
*E-Mail Disclaimer*
Der Inhalt dieser E-Mail ist ausschliesslich fuer d
Antonin Houska wrote:
> Alvaro Herrera wrote:
>
> >
> >
> > > From bf2ec8c5d753de340140839f1b061044ec4c1149 Mon Sep 17 00:00:00 2001
> > > From: Antonin Houska
> > > Date: Mon, 13 Jan 2025 14:29:54 +0100
> > > Subject: [PATC
Alvaro Herrera wrote:
>
>
> > From bf2ec8c5d753de340140839f1b061044ec4c1149 Mon Sep 17 00:00:00 2001
> > From: Antonin Houska
> > Date: Mon, 13 Jan 2025 14:29:54 +0100
> > Subject: [PATCH 4/8] Add CONCURRENTLY option to both VACUUM FULL and CLUSTER
> >
Alvaro Herrera wrote:
> On 2025-Jan-31, Antonin Houska wrote:
>
> > Matthias van de Meent wrote:
>
> > > First, due to the XLog-based change detection this feature can't work
> > > for unlogged tables without first changing them to logged (which
> >
that UPDATE needs to be moved to the stream associated with another
snapshot. But that snapshot might not see that tuple either because it was
either deleted in between, or should be found by yet another scan.
Doing the repacking in several steps might be interesting, but I admit I
haven't yet thought that far.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Alvaro Herrera wrote:
> On 2025-Jan-31, Antonin Houska wrote:
>
> Something that Robert Haas just mentioned to me is handling of row
> locks: if concurrent transactions are keeping rows in the original table
> locked (especially SELECT FOR KEY SHARE, since that's not con
abling the logical decoding transiently makes sense to me.
I also agree that tables not being REPACKed should be treated as not being
logically decoded, i.e. the logical decoding specific information should not
be written to WAL for them. Neither time nor energy should be wasted :-)
I'll try to implement these requirements the next version.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
.org/about/news/pg_squeeze-18-released-3005/
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Pavel Stehule wrote:
> Hi
>
> čt 9. 1. 2025 v 14:35 odesílatel Alvaro Herrera
> napsal:
>
> On 2024-Dec-11, Antonin Houska wrote:
>
> > Oh, it was too messy. I think I was thinking of too many things at once
> (such
> > as locking the old heap, t
Alvaro Herrera wrote:
> On 2024-Dec-11, Antonin Houska wrote:
>
> > Oh, it was too messy. I think I was thinking of too many things at once
> > (such
> > as locking the old heap, the new heap and the new heap's TOAST). Also, one
> > thing that might have c
I was curious when create_gather_path() sets single_copy, but could not find
any place in the tree where a path with num_workers==0 is added to
partial_pathlist. This patch removes the field.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
>F
hat in the new test
010_keep_recycled_wals.pl the server fails to reload the configuration
file. The line it complains about is
archive_command = '/usr/bin/perl -e 'exit(1)''
The test still succeeds for some reason.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Jacob Champion wrote:
> On Thu, Oct 17, 2024 at 10:51 PM Antonin Houska wrote:
> > * oauth_validator_library is defined as PGC_SIGHUP - is that intentional?
>
> Yes, I think it's going to be important to let DBAs migrate their
> authentication modules without a full
relacl
---+--
pg_shadow | {postgres=arwdDxtm/postgres}
pg_group | {postgres=arwdDxtm/postgres,=r/postgres}
(2 rows)
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
diff --git a/src/include/catalog/pg_authid.h b/src/include/catalog/pg_authi
Antonin Houska wrote:
> I'd like to play with the code a bit and provide some review before or during
> the next CF. That will probably generate some more questions.
This is the 1st round, based on reading the code. I'll continue paying
attention to the project and possibl
Jacob Champion wrote:
> On Mon, Sep 30, 2024 at 6:38 AM Antonin Houska wrote:
> >
> > Are you sure you can legitimately acquire the bearer token containing my
> > email
> > address?
>
> Yes. In general that's how OpenID-based "Sign in with "
>
Antonin Houska wrote:
> Jacob Champion wrote:
> > Now, the token introspection endpoint I mentioned upthread
>
> Can you please point me to the particular message?
Please ignore this dumb question. You probably referred to the email I was
responding to.
--
Antonin Ho
Jacob Champion wrote:
> On Fri, Sep 27, 2024 at 10:58 AM Antonin Houska wrote:
> > Have you considered sending the token for validation to the server, like
> > this
> >
> > curl -X GET "https://www.googleapis.com/oauth2/v3/userinfo"; -H
> > "
fo"; -H "Authorization:
Bearer $TOKEN"
and getting the userid (e.g. email address) from the response, as described in
[1]? ISTM that this is what pgadmin4 does - in paricular, see the
get_user_profile() function in web/pgadmin/authenticate/oauth2.py.
[1]
https://www.oauth.com/oaut
Antonin Houska wrote:
> Andres Freund wrote:
>
> > What I'd instead like to propose is to implement the right to set hint bits
> > as
> > a bit in each buffer's state, similar to BM_IO_IN_PROGRESS. Tentatively I
> > named this BM_SETTING_HINTS. It
in the buffer and if "some
intermediate state" of the computation was maintained for each page in shared
buffers, then the checksum update might be cheaper than the initial
computation. But I'm not sure I understand the algorithm enough.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
ssues/51
[2]
https://github.com/cybertec-postgresql/pg_squeeze/issues/21#issuecomment-514495369
[3]
http://peter.eisentraut.org/blog/2024/05/14/when-to-split-patches-for-postgresql
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
[1] https://commitfest.postgresql.org/49/5117/
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Nathan Bossart wrote:
> On Wed, Jul 10, 2024 at 05:00:13PM +0200, Antonin Houska wrote:
> > I don't quite understand why TransactionIdIsCurrentTransactionId()
> > implements
> > binary search in ParallelCurrentXids "from scratch" instead of using
> > bs
tionIdInArray() (which is effectively bsearch(..., xidComparator)) to
search for particular XID in the array.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index d119ab909d..8540e70e70 100644
--- a/s
Alvaro Herrera wrote:
> On 2024-Jul-09, Antonin Houska wrote:
>
> > Alvaro Herrera wrote:
> >
> > > > Is your plan to work on it soon or should I try to write a draft patch?
> > > > (I
> > > > assume this is for PG >= 18.)
> &g
Andy Fan wrote:
> Antonin Houska writes:
>
> >> Could you make the reason clearer for adding 'List *opfamily_lists;'
> >> into UniqueKey? You said "This is needed to create ECs in the parent
> >> query if the upper relation represents a subquery.
Antonin Houska wrote:
> Andy Fan wrote:
> > >
> > > * Combining the UKs
> > >
> > > IMO this is the most problematic part of the patch. You call
> > > populate_joinrel_uniquekeys() for the same join multiple times,
> >
> > Why
#x27;, I
> think you can use ECs.", let's see what we can improve.
> >
> > My theory is that relation is single-row if it has an UK such that each of
> > its ECs meets at least one of the following conditions:
> >
> > a) contains a constant
>
> True.
removals.
Do cases like this seem worth the effort and is the logic I use correct?
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
>From 279856bf97ce08c0c2e0c736a00831bf6324713b Mon Sep 17 00:00:00 2001
From: Antonin Houska
Date: Mon, 29 Apr 2024 11:34:30 +0200
Subject: [PATCH] Clea
001 is actually a minor fix to [1].
[1] https://www.postgresql.org/message-id/7971.1713526758%40antos
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
>From a0be4ee7698ff03d6c22398f20fd2c7efadbff45 Mon Sep 17 00:00:00 2001
From: Antonin Houska
Date: Mon, 29 Apr 2024 07:53:00 +0200
x27; is single-row, the condition b) cam be ised: the UK of
't2' should reference the EC {t1.e, t2.id}, which in turn contains the
column t1.e. And 't1' is unique because its EC meets the condition a). (Of
course you need to check em_jdomain before you use particular E
Alvaro Herrera wrote:
> This is great to hear.
>
> On 2024-Jan-31, Antonin Houska wrote:
>
> > Is your plan to work on it soon or should I try to write a draft patch? (I
> > assume this is for PG >= 18.)
>
> I don't have plans for it, so if you have
I couldn't find a reference to the 'langispl' attribute, so I removed it (see
the diff attached) and the master branch compiled cleanly. Is there yet a
reason to keep it?
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
diff --git a/src/backend/commands/proclang.
t patch? (I
assume this is for PG >= 18.)
[1] https://www.postgresql.org/docs/current/mvcc-caveats.html
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
I think that cost_incremental_sort() does not account for the limit_tuples
argument properly. Attached is my proposal to fix the problem.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c
index
Although it's not performance-critical, I think it just makes sense to break
the loop in replorigin_session_setup() as soon as we've found the origin.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
diff --git a/src/backend/replication/logical/origin.c b/src/backend/r
Thomas Munro wrote:
> On Wed, Aug 16, 2023 at 11:18 PM Antonin Houska wrote:
> > I try to understand this patch (commit 5ffb7c7750) because I use condition
> > variable in an extension. One particular problem occured to me, please
> > consider:
> >
> > Conditio
l was sent in between. Shouldn't
at least AbortTransaction() and AbortSubTransaction() check the return value
of ConditionVariableCancelSleep(), and re-send the signal if needed?
Note that I'm just thinking about such a problem, did not try to reproduce it.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Like in cost_seqscan(), I'd expect the subpath cost to be divided among
parallel workers. The patch below shows what I mean. Am I right?
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c
;a
> comprehensive description of what it is trying to do"? :)
I tried to improve the documentation and commit messages in v05. v06 (just
rebased) is attached.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
>From d4490664ec80f52d23c4345eec5771764bcdbb17 Mon Sep 17 00:00:00
James Coleman wrote:
> On Mon, Feb 6, 2023 at 11:39 AM Antonin Houska wrote:
> Attached is v9.
ok, I've changed the status to RfC
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
So I think that PATH_REQ_OUTER(cheapest_partial_path) in
generate_gather_paths() can eventually contain more relations than
required_outer, and therefore it's safer to check the first.
Similar comments might apply to generate_useful_gather_paths(). Here I also
suggest to move this test
/* We can't pass params to workers. */
if (!bms_is_subset(PATH_REQ_OUTER(subpath), rel->relids))
continue;
to the top of the loop because it's relatively cheap.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Yugo NAGATA wrote:
> On Wed, 01 Feb 2023 12:45:57 +0100
> Antonin Houska wrote:
>
> > While working on [1] I noticed that if RLS gets enabled, the COPY TO command
> > includes the contents of child table into the result, although the
> > documentation says it should
as well as fix proposal
(copy_rls_no_inh.diff).
[1] https://commitfest.postgresql.org/41/3641/
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
create table a(i int);
insert into a values (1);
create table a1() inherits(a);
insert into a1 values (1);
-- Only the parent table is copi
Antonin Houska wrote:
> I was wondering why ExecCrossPartitionUpdateForeignKey() has an unused
> argument "oldslot" and wanted to suggest its removal. However, before I did,
> it occurred to me that callers may want to pass the whole slot when the
> partition is a foreig
nstead, I'd expect it to
delete the tuple from "a1" and insert it into "a2". That looks like a bug.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
CREATE EXTENSION IF NOT EXISTS postgres_fdw WITH SCHEMA public;
CREATE SERVER s1 FOREIGN DATA WRAPPER postgres_
width=4)
If both sides should be grouped, finalization of the partial aggregates would
be more difficult, and I'm not sure it'd be worth the effort.
> [1] https://commitfest.postgresql.org/41/3764/
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Antonin Houska wrote:
> Antonin Houska wrote:
>
> > Peter Eisentraut wrote:
> >
> > > On 04.11.22 08:28, Antonin Houska wrote:
> > > > I thought about the whole concept a bit more and I doubt if the
> > > > PUBLICATION
> > &g
Peter Eisentraut wrote:
> On 12.12.22 10:44, Antonin Houska wrote:
> > Peter Eisentraut wrote:
> >
> >> On 06.12.22 09:41, Antonin Houska wrote:
> >>> Attached are my proposals for improvements. One is to avoid memory leak,
> >>> the
>
Peter Eisentraut wrote:
> On 06.12.22 09:41, Antonin Houska wrote:
> > Attached are my proposals for improvements. One is to avoid memory leak, the
> > other tries to improve readability a little bit.
>
> I added the readability improvement to my v2 patch. The pfree() cal
The attached script generates scripts to create many tablespaces as well as
the underlying directories. Fix is attached here as well.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
#!/bin/bash
TBSPDIR=/mnt/ramdisk/tbspcs
TBSPCOUNT=2048
SCRIPT_SH=create.sh
SCRIPT_SQL=create.sq
ww.postgresql.org/message-id/flat/20330.1652105397@antos
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
diff --git a/src/backend/catalog/aclchk.c b/src/backend/catalog/aclchk.c
index d3121a469f..ac4490c0b8 100644
--- a/src/backend/catalog/aclchk.c
+++ b/src/backend/catalog/aclchk.c
@@ -22
Antonin Houska wrote:
> Peter Eisentraut wrote:
>
> > On 04.11.22 08:28, Antonin Houska wrote:
> > > I thought about the whole concept a bit more and I doubt if the
> > > PUBLICATION
> > > privilege is the best approach. In particular, the user specif
Peter Eisentraut wrote:
> On 04.11.22 08:28, Antonin Houska wrote:
> > I thought about the whole concept a bit more and I doubt if the PUBLICATION
> > privilege is the best approach. In particular, the user specified in CREATE
> > SUBSCRIPTION ... CONNECTION ... (say "
to reduce the
amount of (almost) copy & pasted code. I haven't found any problem in your
patch that would be worth mentioning, except that the 0001 part does not apply
to the current master branch.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Mark Dilger wrote:
> > On Nov 4, 2022, at 12:28 AM, Antonin Houska wrote:
> >
> > I thought about the whole concept a bit more and I doubt if the PUBLICATION
> > privilege is the best approach. In particular, the user specified in CREATE
> > SUBSCRIPTION ... CON
Amit Kapila wrote:
> On Thu, Nov 3, 2022 at 11:12 AM Antonin Houska wrote:
> >
> > Peter Eisentraut wrote:
> >
> > > The CF entry is about privileges on publications. Please rebase that
> > > patch
> > > and repost it so that the CF app an
1 - 100 of 399 matches
Mail list logo
