Hi Kyotaro, I'm glad you are still into this
> I didn't register for some reasons.
Right now in v8 there's a typo in ./src/backend/catalog/storage.c :
storage.c: In function 'RelationDropInitFork':
storage.c:385:44: error: expected statement before ')' token
pending->unlink_forknum !=
At Mon, 20 Dec 2021 15:28:23 +0900 (JST), Kyotaro Horiguchi
wrote in
>
> 4. Including the reasons above, this is not fully functionally.
>For example, if we execute the following commands on primary,
>replica dones't work correctly. (boom!)
>
>=# CREATE UNLOGGED TABLE t (a int);
>
Hi,
When reviewing some replica identity related patches, I found that when adding
primary key using an existing unique index on not null columns, the
target table's relcache won't be invalidated.
This would cause an error When REPLICA IDENTITY is default and we are
UPDATE/DELETE a published
Hello, Jakub.
At Fri, 17 Dec 2021 09:10:30 +, Jakub Wartak
wrote in
> the patch didn't apply clean (it's from March; some hunks were failing), so
> I've fixed it and the combined git format-patch is attached. It did conflict
> with the following:
Thanks for looking this. Also thanks for
On Mon, Dec 20, 2021 at 2:00 PM Corey Huinker wrote:
> Sorry for the delay. This patch no longer applies, it has some conflict with
> d6f96ed94e73052f99a2e545ed17a8b2fdc1fb8a
Thanks Corey for the heads up. Rebased with some cosmetic adjustments.
--
Amit Langote
EDB:
On Mon, Dec 20, 2021 at 4:13 PM Amit Kapila wrote:
>
> On Wed, Nov 24, 2021 at 3:22 PM vignesh C wrote:
> >
> > On Tue, Nov 23, 2021 at 4:58 PM Ajin Cherian wrote:
> > >
> >
> > 3) Should we include row filter condition in pg_publication_tables
> > view like in describe publication(\dRp+) ,
On Wed, Nov 24, 2021 at 3:22 PM vignesh C wrote:
>
> On Tue, Nov 23, 2021 at 4:58 PM Ajin Cherian wrote:
> >
>
> 3) Should we include row filter condition in pg_publication_tables
> view like in describe publication(\dRp+) , since the prqual is not
> easily readable in pg_publication_rel table:
On Mon, Dec 20, 2021 at 11:19 AM Peter Smith wrote:
>
> For some reason the current HEAD PublicationActions is a struct of
> boolean representing combinations of the 4 different "publication
> actions".
>
> I felt it is more natural to implement boolean flag combinations using
> a bitmask instead
>
>
>
> I wasn't able to make much inroads into how we might be able to get
> rid of the DETACH-related partition descriptor hacks, the item (3),
> though I made some progress on items (1) and (2).
>
> For (1), the attached 0001 patch adds a new isolation suite
> fk-snapshot.spec to exercise
On Thu, Dec 2, 2021 at 7:40 PM vignesh C wrote:
>
...
> Thanks for the updated patch, few comments:
> 1) Both testpub5a and testpub5c publication are same, one of them can be
> removed
> +SET client_min_messages = 'ERROR';
> +CREATE PUBLICATION testpub5a FOR TABLE testpub_rf_tbl1 WHERE (a > 1)
On Sun, Dec 19, 2021 at 7:00 PM Tom Lane wrote:
> Corey Huinker writes:
> > Which brings up a tangential question, is there value in having something
> > that brings in one or more env vars as psql vars directly. I'm thinking
> > something like:
>
> > \importenv pattern [prefix]
>
> Meh ...
On Mon, Dec 20, 2021 at 8:33 AM Masahiko Sawada wrote:
>
> On Sat, Dec 18, 2021 at 3:38 PM Amit Kapila wrote:
> >
> > Few comments:
> > =
> > 1.
> > + * dead_items stores TIDs whose index tuples are deleted by index
> > vacuuming.
> > + * Each TID points to an LP_DEAD line pointer
On Tue, Dec 16, 2021 at 10:27AM, Michael Paquier wrote:
> On Tue, Dec 16, 2021 at 06:40AM, Michael Paquier wrote:
> > Would you like to write a patch to address all that?
>
> OK, I will push it soon.
Here is a patch to correct wrong comment about REPLICA_IDENTITY_INDEX, And
improve the pg-doc.
On Mon, Dec 20, 2021 at 12:51 PM houzj.f...@fujitsu.com
wrote:
>
> I think it might not be hard to predict the current behavior. User only need
> to be
> aware of that:
> 1) pubaction and row filter on different publications are combined with 'OR'.
> 2) FOR UPDATE, we execute the fiter for both
On Mon, Dec 20, 2021 at 6:07 AM Greg Nancarrow wrote:
>
> On Sat, Dec 18, 2021 at 1:33 PM Amit Kapila wrote:
> >
> > >
> > > I think it's a concern, for such a basic example with only one row,
> > > getting unpredictable (and even wrong) replication results, depending
> > > upon the order of
On Wednesday, December 8, 2021 2:29 PM Amit Kapila
wrote:
>
> On Mon, Dec 6, 2021 at 6:04 PM Euler Taveira wrote:
> >
> > On Mon, Dec 6, 2021, at 3:35 AM, Dilip Kumar wrote:
> >
> > On Mon, Dec 6, 2021 at 6:49 AM Euler Taveira wrote:
> > >
> > > On Fri, Dec 3, 2021, at 8:12 PM, Euler Taveira
Dear Gunnar,
> postgres=# CREATE TABLE test (i int, lz4 text COMPRESSION lz4, std text);
> postgres=# INSERT INTO test SELECT
> i,repeat(md5(i::text),100),repeat(md5(i::text),100) FROM
> generate_series(0,10) x(i);
> postgres=# SELECT * FROM pg_stat_toast WHERE schemaname = 'public';
> -[
On Sat, Dec 18, 2021 at 3:38 PM Amit Kapila wrote:
>
> On Fri, Dec 17, 2021 at 10:51 AM Masahiko Sawada
> wrote:
> >
> > I've attached updated patches. The first patch just moves common
> > function for index bulk-deletion and cleanup to vacuum.c. And the
> > second patch moves parallel vacuum
> -Original Message-
> From: Amit Kapila
On Saturday, December 18, 2021 10:33 AM
> On Fri, Dec 17, 2021 at 5:29 PM Greg Nancarrow
> wrote:
> >
> > On Fri, Dec 17, 2021 at 7:20 PM Ajin Cherian wrote:
> > >
> > > On Fri, Dec 17, 2021 at 5:46 PM Greg Nancarrow
> wrote:
> > >
> > > > So
On Sat, Dec 18, 2021 at 1:33 PM Amit Kapila wrote:
>
> >
> > I think it's a concern, for such a basic example with only one row,
> > getting unpredictable (and even wrong) replication results, depending
> > upon the order of operations.
> >
>
> I am not sure how we can deduce that. The results
For some reason the current HEAD PublicationActions is a struct of
boolean representing combinations of the 4 different "publication
actions".
I felt it is more natural to implement boolean flag combinations using
a bitmask instead of a struct of bools. IMO using the bitmask also
simplifies
Corey Huinker writes:
> Which brings up a tangential question, is there value in having something
> that brings in one or more env vars as psql vars directly. I'm thinking
> something like:
> \importenv pattern [prefix]
Meh ... considering we've gone this long without any getenv capability
in
On Sun, Dec 19, 2021 at 5:48 PM Tom Lane wrote:
> Corey Huinker writes:
> > I have a nitpick about the \getenv FOO FOO lines.
> > It's a new function to everyone, and to anyone who hasn't seen the
> > documentation it won't be immediately obvious which one is the ENV var
> and
> > which one is
On Sat, Dec 18, 2021 at 1:33 PM Amit Kapila wrote:
>
> On Fri, Dec 17, 2021 at 5:29 PM Greg Nancarrow wrote:
> >
> > On Fri, Dec 17, 2021 at 7:20 PM Ajin Cherian wrote:
> > >
> > > On Fri, Dec 17, 2021 at 5:46 PM Greg Nancarrow
> > > wrote:
> > >
> > > > So using the v47 patch-set, I still
Corey Huinker writes:
> I have a nitpick about the \getenv FOO FOO lines.
> It's a new function to everyone, and to anyone who hasn't seen the
> documentation it won't be immediately obvious which one is the ENV var and
> which one is the local var. Lowercasing the local var would be a way to
>
>
>
> 0001 adds the \getenv command to psql; now with documentation
> and a simple regression test.
>
+1. Wish I had added this years ago when I had a need for it.
>
> 0002 tweaks pg_regress to export the needed values as environment
> variables, and modifies the test scripts to use those
Justin Pryzby writes:
> I reduced the problematic query to this.
> SELECT 1 FROM pg_rewrite WHERE
> pg_get_function_arg_default(ev_class, 1) !~~
> pg_get_expr(ev_qual, ev_class, false);
Or more simply,
regression=# select pg_get_expr(ev_qual, ev_class, false) from pg_rewrite where
rulename =
I wrote:
> This led me to wonder why we couldn't get rid of that entire
> mechanism in favor of some less-painful way of getting that
> information into the scripts. If we had the desired values in
> psql variables, we could do what we need easily, for example ...
Here's some fleshed-out patches
I reduced the problematic query to this.
SELECT 1 FROM pg_rewrite WHERE
pg_get_function_arg_default(ev_class, 1) !~~
pg_get_expr(ev_qual, ev_class, false);
#0 pg_re_throw () at elog.c:1800
#1 0x563f5d027932 in errfinish () at elog.c:593
#2 0x563f5cb874ee in resolve_special_varno
Hi,
While working on [1], I noticed $SUBJECT: postgres_fdw resets the
per-connection states of connections, which store async requests sent
to remote servers in async_capable mode, during post-abort
(pgfdw_xact_callback()), but it fails to do so during post-subabort
(pgfdw_subxact_callback()).
> [0001-schema-variables-20211219-2.patch]
> [0002-schema-variables-20211219-2.patch]
Hi Pavel,
You said earlier
> 1. The schema variables were renamed to session variable
But I still see:
$ grep -Eic 'schema variable' postgres.html
15
(postgres.html from 'make postgres.html')
So th
31 matches
Mail list logo
