_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
Peter Eisentraut wrote:
> On 03.11.22 01:43, 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 and the CF bot are up to date.
> > T
subscription. I haven't
added a note about this problem to the documentation yet, in case someone has
better idea how to approach the problem.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 03c0193709..d510220a07 1006
to develop a framework that'd be
useful for both.
[1]
https://www.postgresql.org/message-id/CA%2BTgmoZWP8UtkNVLd75Qqoh9VGOVy_0xBK%2BSHZAdNvnfaikKsQ%40mail.gmail.com
> From: Robert Haas
> Date: Wednesday, September 21, 2022 at 11:54 AM
> To: Antonin Houska
> Cc: PostgreSQL Hacker
ystem call, I assume that zero is a valid result, isn't it?
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Robert Haas wrote:
> On Fri, Jul 29, 2022 at 11:36 AM Antonin Houska wrote:
> > Attached is a new version. It allows the user to set "elevel" (i.e. ERROR is
> > not necessarily thrown on I/O failure, if the user prefers to check the
> > number
> > of b
Antonin Houska wrote:
> Peter Eisentraut wrote:
>
> > On 04.07.22 18:35, Antonin Houska wrote:
> > >> Attached is a new version of the patch, to evaluate what the API use in
> > >> the
> > >> backend could look like. I haven't touched plac
Thus I think that the query in
check_memberships() only needs an outer JOIN for the pg_database table,
while the other joins can be inner.
* In this part
SET SESSION AUTHORIZATION role_read_12_noinherit;
SELECT * FROM data; -- error
SET ROLE role_read_12; -- error
SELECT * FROM data; -- error
I think you don't need to query the table again if the SET ROLE statement
failed and the same query had been executed before the SET ROLE.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Richard Guo wrote:
> On Fri, Jul 15, 2022 at 5:00 PM Richard Guo wrote:
>
> On Fri, Jul 15, 2022 at 4:03 PM Richard Guo wrote:
>
> On Thu, Jul 14, 2022 at 10:02 PM Antonin Houska wrote:
>
> I'd prefer a test that demonstrates that the Gather node at the top
d by parallel workers. If the parallel
"Hash Full Join" gets implemented (I've noticed but not checked in detail
[1]), it might break this test.
I'd prefer a test that demonstrates that the Gather node at the top of the
"subproblem plan" is useful purely from the *cost* perspective, rather than
due to executor limitation.
[1] https://commitfest.postgresql.org/38/2903/
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
at if you run that benchmark with a single user you don't see
> any regression. I don't see how rebuilding an extra hashtable in
> entry_dealloc(), so when holding an exclusive lwlock, while not saving any
> other work elsewhere could be free?
>
> Looking at the script, you have:
> echo "log_min_messages=debug1" >> $PGDATA/postgresql.conf; \
>
> Is that really necessary? Couldn't you upgrade the gc message to a higher
> level for your benchmark need, or expose some new counter in
> pg_stat_statements_info maybe? Have you done the benchmark using a debug
> build
> or normal build?
>
>
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Peter Eisentraut wrote:
> On 04.07.22 18:35, Antonin Houska wrote:
> >> Attached is a new version of the patch, to evaluate what the API use in the
> >> backend could look like. I haven't touched places where the file is
> >> accessed
> >> in
Antonin Houska wrote:
> Robert Haas wrote:
>
> > On Tue, Apr 12, 2022 at 5:30 AM Antonin Houska wrote:
> > > Robert Haas wrote:
> > > > On Mon, Apr 11, 2022 at 4:05 AM Antonin Houska wrote:
> > > > > There are't really that many
permissions of "B" (e.g. "pg_write_all_data"), then I
think the roles hierarchy is poorly designed.
A counter-example might help me to understand.
* Why do you think that "unsafe_tests" is the appropriate name for the
directory that contains regression tests?
I can spend more time on the review if the patch gets rebased.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Euler Taveira wrote:
> --eeab359ad6094efd84562cddd7fb9e89
> Content-Type: text/plain
>
> On Wed, May 18, 2022, at 6:44 AM, Antonin Houska wrote:
> > ok, please see the next version.
> The new paragraph looks good to me. I'm not sure if the CREATE PUBLICATION is
> th
Euler Taveira wrote:
> On Wed, May 18, 2022, at 6:16 AM, Antonin Houska wrote:
>
> The patch is attached to this message.
>
> Great. Add it to the next CF. I'll review it when I have some spare time.
https://commitfest.postgresql.org/38/3641/
Thanks!
--
Anton
Euler Taveira wrote:
> On Fri, May 13, 2022, at 3:36 AM, Antonin Houska wrote:
>
> Attached is my proposal. It tries to be more specific and does not mention
> the
> absence of the privileges explicitly.
>
> You explained the current issue but say nothing about
Antonin Houska wrote:
> Euler Taveira wrote:
>
> > On Tue, May 10, 2022, at 5:37 AM, Antonin Houska wrote:
> >
> > My understanding is that the rows/columns filtering is a way for the
> > *publisher* to control which data is available to particular replica. Fro
Peter Eisentraut wrote:
> On 10.05.22 10:37, Antonin Houska wrote:
> > My understanding is that the rows/columns filtering is a way for the
> > *publisher* to control which data is available to particular replica. From
> > this point of view, the publication privilege
Euler Taveira wrote:
> On Tue, May 10, 2022, at 5:37 AM, Antonin Houska wrote:
>
> My understanding is that the rows/columns filtering is a way for the
> *publisher* to control which data is available to particular replica. From
> this point of view, the publication privil
Amit Kapila wrote:
> On Tue, May 10, 2022 at 12:16 AM Euler Taveira wrote:
> >
> > On Mon, May 9, 2022, at 11:09 AM, Antonin Houska wrote:
> >
> > Now that the user can specify rows and columns to be omitted from the
> > logical
> > replication [1], I s
Euler Taveira wrote:
> On Mon, May 9, 2022, at 11:09 AM, Antonin Houska wrote:
>
> Now that the user can specify rows and columns to be omitted from the logical
> replication [1], I suppose hiding rows and columns from the subscriber is an
> important use case. How
?
[1] https://www.postgresql.org/docs/devel/sql-createpublication.html
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Robert Haas wrote:
> On Tue, Apr 12, 2022 at 5:30 AM Antonin Houska wrote:
> > Robert Haas wrote:
> > > On Mon, Apr 11, 2022 at 4:05 AM Antonin Houska wrote:
> > > > There are't really that many kinds of files to encrypt:
> > >
Matthias van de Meent wrote:
> On Mon, 11 Apr 2022 at 10:05, Antonin Houska wrote:
> >
> > There are't really that many kinds of files to encrypt:
> >
> > https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#List_of_the_files_that_contain_user_data
> &
Robert Haas wrote:
> On Mon, Apr 11, 2022 at 4:05 AM Antonin Houska wrote:
> > There are't really that many kinds of files to encrypt:
> >
> > https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#List_of_the_files_that_contain_user_data
> >
> >
zG4ZouZyQQ9h%3DoRiy%3DZQV5%2BxHQXxMWmep4Ygg8Dg%40mail.gmail.com
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Robert Haas wrote:
> On Fri, Apr 8, 2022 at 4:54 AM Antonin Houska wrote:
> > Do you think that the use of a system call is a problem itself (e.g. because
> > the code looks less simple if read/write is used somewhere and fread/fwrite
> > elsewhere; of course of read/
1 - 100 of 372 matches
Mail list logo
