> On 7. 4. 2022, at 17:19, Robert Haas wrote:
>
> On Tue, Apr 5, 2022 at 10:17 AM Tom Lane wrote:
>> What I think you need to do is:
>>
>> 1. In the back branches, revert delayChkpt to its previous type and
>> semantics. Squeeze a separate delayChkptEnd bool in somewhere
>> (you can't change
> On 23. 3. 2022, at 12:50, Amit Kapila wrote:
>
> On Tue, Mar 22, 2022 at 5:41 PM Petr Jelinek
> mailto:petr.jeli...@enterprisedb.com>> wrote:
>>
>>> On 22. 3. 2022, at 13:09, Amit Kapila wrote:
>>>
>>> On Mon, Mar 21, 202
> On 22. 3. 2022, at 13:09, Amit Kapila wrote:
>
> On Mon, Mar 21, 2022 at 4:25 AM Tomas Vondra
> wrote:
>>
>> Hi,
>>
>> Attached is a rebased patch, addressing most of the remaining issues.
>>
>
> It appears that on the apply side, the patch always creates a new
> relfilenode irrespective
I would not remove it altogether, there is plenty of consumers of this
extension's output in the wild (even if I think it's unfortunate) that might
not be interested in sequences, but changing it to off by default certainly
makes sense.
--
Petr Jelinek
> On 26. 1. 2022, at
I note that a lot of additional
> code had to be added around several areas of the code, whereas the original
> patch really just touched the logical decoding code, as it should. This
> doesn't prevent anyone from attempting to optimize things somehow in the
> future, bu
On 26 May 2021, at 05:04, Amit Kapila wrote:
>
> On Tue, May 25, 2021 at 12:40 PM Michael Paquier wrote:
>>
>> On Mon, May 24, 2021 at 10:03:01AM +0530, Amit Kapila wrote:
>>> So, this appears to be an existing caveat of synchronous replication.
>>> If that is the case, I am not sure if it is a
> On 12 Apr 2021, at 08:58, Amit Kapila wrote:
>
> On Mon, Apr 12, 2021 at 10:03 AM osumi.takami...@fujitsu.com
> wrote:
>>
>>> I checked the PG-DOC, found it says that “Replication of TRUNCATE
>>> commands is supported”[1], so maybe TRUNCATE is not supported in
>>> synchronous logical replic
>
> On 13 Feb 2021, at 17:32, Andres Freund wrote:
>
> Hi,
>
> On 2021-02-10 08:02:17 +0530, Amit Kapila wrote:
>> On Wed, Feb 10, 2021 at 12:08 AM Robert Haas wrote:
>>>
>> If by successfully confirmed, you mean that once the subscriber node
>> has received, it won't be sent again then as fa
On 11 Feb 2021, at 10:56, Amit Kapila wrote:
>
> On Thu, Feb 11, 2021 at 3:20 PM Petr Jelinek
> wrote:
>>
>> On 11 Feb 2021, at 10:42, Amit Kapila wrote:
>>>
>>> On Thu, Feb 11, 2021 at 1:51 PM Petr Jelinek
>>> wrote:
>>>>
>&g
On 11 Feb 2021, at 10:42, Amit Kapila wrote:
>
> On Thu, Feb 11, 2021 at 1:51 PM Petr Jelinek
> wrote:
>>
>> On 10 Feb 2021, at 06:32, Amit Kapila wrote:
>>>
>>> On Wed, Feb 10, 2021 at 7:41 AM Peter Smith wrote:
>>>>
>
On 10 Feb 2021, at 06:32, Amit Kapila wrote:
>
> On Wed, Feb 10, 2021 at 7:41 AM Peter Smith wrote:
>>
>> On Tue, Feb 9, 2021 at 10:38 AM Peter Smith wrote:
>>>
>>
>> PSA v2 of this WalRcvExceResult patch (it is same as v1 but includes
>> some PG doc updates).
>> This applies OK on top of v3
On 06/02/2021 07:29, Amit Kapila wrote:
On Fri, Feb 5, 2021 at 6:45 PM Euler Taveira wrote:
On Fri, Feb 5, 2021, at 4:01 AM, Amit Kapila wrote:
I am not completely whether we should retire replorigin_drop or just
keep it for backward compatibility? What do you think? Anybody else
has any opini
On 06/02/2021 06:07, Amit Kapila wrote:
On Sat, Feb 6, 2021 at 6:22 AM Peter Smith wrote:
On Sat, Feb 6, 2021 at 2:10 AM Petr Jelinek
wrote:
+ReplicationSlotNameForTablesync(Oid suboid, Oid relid, char
syncslotname[NAMEDATALEN])
+{
+ if (syncslotname)
+ sprintf
Hi,
We had a bit high-level discussion about this patches with Amit
off-list, so I decided to also take a look at the actual code.
My main concern originally was the potential for left-over slots on
publisher, but I think the state now is relatively okay, with couple of
corner cases that are
toric snapshot. So the output plugin simply does not see the real value.
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
On 14/07/2020 11:36, Dilip Kumar wrote:
On Tue, Jul 14, 2020 at 2:47 PM Petr Jelinek wrote:
Hi,
On 14/07/2020 10:29, Amit Kapila wrote:
On Tue, Jul 14, 2020 at 12:05 PM Dilip Kumar wrote:
On Tue, Jul 14, 2020 at 11:14 AM Amit Kapila wrote:
On Tue, Jul 14, 2020 at 11:00 AM Dilip Kumar
Petr Jelinek wrote:
If we were to support the origin forwarding, then strictly speaking we
need everything only at commit time from correctness perspective,
Okay. Anyway streaming mode is optional, so in such cases, we can keep it 'off'
but
ideally origin_id would be best sent
s matters, but for network binary
format they do not matter as Tom says.
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
Hi,
On 09/07/2020 14:34, Amit Kapila wrote:
On Thu, Jul 9, 2020 at 5:16 PM Petr Jelinek wrote:
On 09/07/2020 13:10, Amit Kapila wrote:
On Thu, Feb 6, 2020 at 2:40 PM Amit Kapila wrote:
During logical decoding, we send replication_origin and
replication_origin_lsn when we decode commit
e, C interface does not require that and I don't
think we need to do that. The existing apply code sets the
replorigin_session_origin_lsn only when processing commit message IIRC.
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
I also (I suspect like Álvaro) parsed your original message as wanting
to remove origin from the record completely.
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
On 04/04/2020 07:25, Tom Lane wrote:
Petr Jelinek writes:
On 03/04/2020 17:51, Tom Lane wrote:
But the forked-off children have to write the gcov files independently,
don't they?
Hmm that's very good point. I did see these missing coverage issue when
running tests that explic
On 03/04/2020 17:51, Tom Lane wrote:
Petr Jelinek writes:
On 03/04/2020 16:59, Tom Lane wrote:
Petr Jelinek writes:
AFAIK gcov can't handle multiple instances of same process being started
as it just overwrites the coverage files. So for TAP test it will report
bogus info (as in some
quot;tap_sub_16390_sync_16384"
already exists
2020-04-04 02:08:57.300 CEST [5e87d018.50689:7] LOG: background worker "logical replication worker" (PID 329408) exited with exit code
Looks like we are simply retrying so fast that upstream will not have
finished cleanup after
On 03/04/2020 16:59, Tom Lane wrote:
Petr Jelinek writes:
AFAIK gcov can't handle multiple instances of same process being started
as it just overwrites the coverage files. So for TAP test it will report
bogus info (as in some code that's executed will look as not executed).
Hm,
P
framework and merge (gcov/lcov can do that AFAIK) the resulting files to
get accurate coverage info. But that's beyond this patch IMHO.
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
chema". How
about naming it "publish_via_partition_root", which also matches the
name of the analogous option in pg_dump.
+1 (disclaimer: I was one of the people who discussed this offline)
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
Hi,
On 08/03/2020 00:18, Dave Cramer wrote:
On Fri, 6 Mar 2020 at 08:54, Petr Jelinek <mailto:p...@2ndquadrant.com>> wrote:
Hi Dave,
On 29/02/2020 18:44, Dave Cramer wrote:
>
>
> rebased and removed the catversion bump.
Looked into this and it ge
h StringInfoData
array, that seems generally both simpler and should have smaller memory
footprint too, no?
We could also merge the binary and changed arrays into single char array
named something like format (as data can be either unchanged, binary or
text) and just reuse same identifiers
TABLE foo DETACH PARTITION bar ...;
This will end up with bar not being in any publication even though it
was explicitly added. That might be acceptable caveat but it at least
should be clearly documented (IMHO with warning).
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
Hi,
On 05/08/2019 09:26, Andres Freund wrote:
Hi,
On 2019-08-05 00:19:28 +0200, Petr Jelinek wrote:
It carries that information inside the compressed value, like I said in the
other reply, that's why the extra byte.
I'm not convinced that that is a good plan - imo the refere
We should at least offer HINT though.
However, I'd be in favor of removing this restriction once the patch
which limits how much wal a slot can retain gets in.
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
Hi,
On 05/08/2019 00:15, Andres Freund wrote:
Hi,
On 2019-08-04 17:53:26 +0200, Petr Jelinek wrote:
5) I wonder why compression_algorithm is defined as PGC_SIGHUP. Why not
to allow users to set it per session? I suppose we might have a separate
option for WAL compression_algorithm.
Yeah I
Hi,
On 04/08/2019 21:20, Andres Freund wrote:
On 2019-08-04 02:41:24 +0200, Petr Jelinek wrote:
Same here.
Just so that we don't idly talk, what do you think about the attached?
Cool!
It:
- adds new GUC compression_algorithm with possible values of pglz (default)
and lz4 (if l
If lz4 is compiled in
we can even offer in-system training, just make sure that trained prefixes will make
their way to standbys.
I definitely don't plan to work on common prefix. But don't see why that
could not be added later.
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
Hi,
On 04/08/2019 13:52, Tomas Vondra wrote:
On Sun, Aug 04, 2019 at 02:41:24AM +0200, Petr Jelinek wrote:
Hi,
On 02/08/2019 21:48, Tomas Vondra wrote:
On Fri, Aug 02, 2019 at 11:20:03AM -0700, Andres Freund wrote:
Another question is whether we'd actually want to include the co
any automated test for reading old TOAST format,
no idea how to do that
- I expect my changes to configure.in are not the greatest as I don't
have pretty much zero experience with autoconf
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
&g
embarassing demonstrations...
Yeah, pg_list.h is one file I never close.
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
besides
XLOG_HEAP2_MULTI_INSERT and XLOG_HEAP2_NEW_CID, it seems like simplest
fix is to just remove the first check for fast forward and keep the one
in XLOG_HEAP2_MULTI_INSERT.
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
just have the request for binary data as
an option for the pgoutput and have it chosen dynamically? Then it's the
subscriber who asks for binary output via option(s) to START_REPLICATION.
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions
https://www.2ndQuadrant.com/
goutput) so if you look for example at the
write_tuple/read_tuple/decide_datum_transfer in
https://github.com/2ndQuadrant/pglogical/blob/REL2_x_STABLE/pglogical_proto_native.c
that can help you give some ideas on how to approach this.
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions
https://www.2ndQuadrant.com/
ing what's part of system and
what's user created in general. The FirstNormalObjectId seems somewhat
okay approximation, but then we have plenty of other ways for checking,
maybe it's time to consolidate it into some extra column in pg_class?
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions
https://www.2ndQuadrant.com/
ned
> how it is supposed to work; please double-check to ensure I got it
> right.
>
Besides the "We regards it" typo it looks fine to me.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 27/03/2019 20:55, Tomas Vondra wrote:
> Hi,
>
> I've now committed the MCV part, after addressing the last two issues
> raised by Dean:
>
Congrats!
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
sr/bin/createuser
/usr/share/postgresql-common/pg_wrapper
Centos (PGDG package):
readlink -f /usr/bin/createdb
/usr/pgsql-11/bin/createdb
This also means that the idea about symlinks is something packages
already do.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 23/03/2019 02:38, Michael Paquier wrote:
> On Fri, Mar 22, 2019 at 08:41:06PM +0800, Andrey Borodin wrote:
>> 22 марта 2019 г., в 19:17, Petr Jelinek
>> написал(а):
>>> I still don't like that we are running the subscription workers as
>>> superuser eve
te triggers, index expressions etc, in that worker).
> Do we have any objection on these points?
>
> If not, it is RFC, it should not be returned.
>
Regardless of my complain above, patch with this big security
implications that has arrived in middle of last CF should not be merged
in that last CF IMHO.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
the tablesample one.
>
The SYSTEM table sampling is basically per-page sampling so it depends
heavily on which rows are on which page.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ier to do but rather easier to spot
(vs normal type casting) which is IMO a good thing from patch review
perspective.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Hi,
On 15/01/2019 02:56, Masahiko Sawada wrote:
> On Tue, Nov 27, 2018 at 3:46 AM Petr Jelinek
> wrote:
>>> +
>>> + /*
>>> +* The requested wal lsn is no longer available. We don't
>>> want to ret
yot...@lab.ntt.co.jp>> wrote:
>>
>> Thank you for the review.I took a liberty to address it with v9.
>
>
> So, given there are no further feedback or suggestions, can we set it to
> RFC?
I vote yes.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 29/01/2019 17:14, Andres Freund wrote:
> Hi
>
> On January 29, 2019 8:04:55 AM PST, Petr Jelinek
> wrote:
>> On 29/01/2019 16:28, Andres Freund wrote:
>>> Hi,
>>>
>>> On January 29, 2019 4:19:52 AM PST, Petr Jelinek
>> wrote:
>>
On 29/01/2019 16:28, Andres Freund wrote:
> Hi,
>
> On January 29, 2019 4:19:52 AM PST, Petr Jelinek
> wrote:
>> Hi,
>>
>> On 20/01/2019 21:03, Andres Freund wrote:
>>> Hi,
>>>
>>> Currently RelationFindReplTupleByIndex(), RelationFindR
patched manageable size-wise. As things stand
now we could remove that and use normal heap_update instead of simple
variant. It'll be likely be needed again if we add conflict handling in
the future, but perhaps we could be smarter about it then (i.e. I can
imagine that it will be per tab
_prepare_cb callback and potentially others.
+1
> I also don't see much
> value in checking that exactly 0 or 3 callbacks were registred.
>
I think that check makes sense, if you support 2pc you need to register
all callbacks.
>
> Nitpicking:
>
> First patch: I still don't think that these flags need a bitmask.
Since we are discussing this, I personally prefer the bitmask here.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
(ERROR,
> + (errcode(ERRCODE_INVALID_TRANSACTION_STATE),
> + errmsg("improper heap_getnext call")));
> +
I think we should log the relation oid as well so that plugin developers
have easier time debugging this (for all variants of this).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Hi,
On 02/01/2019 10:21, Oleksii Kliukin wrote:
> On Mon, Dec 17, 2018, at 14:10, Alexander Kukushkin wrote:
>> Hi,
>>
>> On Thu, 6 Dec 2018 at 00:55, Petr Jelinek
>> wrote:
>>>> Does excluding WAL senders from the max_connections limit and including
&
zation can be left for later.
Also (these are pretty pointless until we agree that this is the right
approach):
- there is no documentation update yet
- there are no TAP tests yet
- the recheck timer might need GUC
[1]
https://www.postgresql.org/message-id/20181212204154.nsxf3gzqv3ges...@al
On 30/12/2018 20:27, Petr Jelinek wrote:
> Hi,
>
> while messing around with slot code I noticed that the SQL functions for
> consuming/moving logical replication slots only move restart_lsn up to
> previously consumed position and not to currently consumed position. The
> reaso
pg_replication_slot_advance.
Attached patch improves things by adding call to move the slot's
restart_lsn and catalog_xmin to the last serialized snapshot position
right after we update the confirmed_lsn.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development,
On 27/12/2018 20:19, Stephen Frost wrote:
> Greetings,
>
> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
>> On 14/12/2018 16:56, Stephen Frost wrote:
>>> * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
>>>> On 11/23/18 8:03 PM, Stephen Frost wr
Hi,
On 27/12/2018 20:05, Stephen Frost wrote:
> Greetings,
>
> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
>> On 14/12/2018 16:38, Stephen Frost wrote:
>>> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
>>>> I do see the appeal here, if you
on catalog xmin
advance when there is lagging logical replication on primary? It might
not be too big deal as in that use-case it should only happen if
hs_feedback was off at some point, but just wanted to point out this
potential problem.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 14/12/2018 16:56, Stephen Frost wrote:
> Greetings,
>
> * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
>> On 11/23/18 8:03 PM, Stephen Frost wrote:
>>> * Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote:
>>>> On Fri, Nov 23, 2018 at 4:13 PM
On 14/12/2018 16:38, Stephen Frost wrote:
> Greetings,
>
> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
>> On 23/11/2018 03:02, Stephen Frost wrote:
>>> * Euler Taveira (eu...@timbira.com.br) wrote:
>>>> 2018-02-28 21:54 GMT-03:00 Craig Ringer :
>
ed the proc slots for walsenders on the standby
same way we do for normal backends.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
optimization, but from what I've seen the problems
arising from this can easily prevent logical replication from working
altogether as reorder buffer hits OOM on bigger tables. So ISTM that it
does warrant backpatch.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Hi,
On 26/11/2018 01:29, Masahiko Sawada wrote:
> On Sun, Nov 25, 2018 at 12:27 AM Petr Jelinek
> wrote:
>>
>> The more serious thing is:
>>
>>> + if (MyReplicationSlot)
>>> + ReplicationSlotRelease();
>>> +
>>> +
ed by ALTER SYSTEM, doing overwrites
there is not as straightforward proposition (behaviorally) as doing it
in another included file.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
nSlot)
This won't work as intended as the ReplicationSlotRelease() will set
MyReplicationSlot to NULL, you might need to set aside MyReplicationSlot
to yet another temp variable inside this function prior to releasing it.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 23/11/2018 19:29, Fabrízio de Royes Mello wrote:
>
> On Fri, Nov 23, 2018 at 4:13 PM Petr Jelinek
> mailto:petr.jeli...@2ndquadrant.com>> wrote:
>>
>> >
>> > If carefully documented I see no problem with it... we already have an
>> > anal
On 23/11/2018 19:05, Fabrízio de Royes Mello wrote:
> On Fri, Nov 23, 2018 at 3:55 PM Petr Jelinek
> mailto:petr.jeli...@2ndquadrant.com>> wrote:
>>
>> On 23/11/2018 17:15, Euler Taveira wrote:
>> > Em qui, 22 de nov de 2018 às 20:03, Petr Jelinek
>>
On 23/11/2018 17:15, Euler Taveira wrote:
> Em qui, 22 de nov de 2018 às 20:03, Petr Jelinek
> escreveu:
>> Firstly, I am not sure if it's wise to allow UDFs in the filter clause
>> for the table. The reason for that is that we can't record all necessary
>&
On 23/11/2018 17:39, David Fetter wrote:
> On Fri, Nov 23, 2018 at 12:03:27AM +0100, Petr Jelinek wrote:
>> On 01/11/2018 01:29, Euler Taveira wrote:
>>> Em qua, 28 de fev de 2018 às 20:03, Euler Taveira
>>> escreveu:
>>>> The attached patches add supp
at has zero effect on this as everything here is happening on
different server than where subscription lives (we already allow
creation of publications with just CREATE privilege on database and
ownership of the table).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
re that the expression is run with the
session environment of the replication connection (so that it's more
obvious that things like CURRENT_USER will not return user which changed
tuple but the replication user).
It would be nice if 0006 had regression test and 0007 TAP test.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
l_level < logical"
>> and:
>> "physical replication slot \"%s\" exists, but wal_level < replica"
>
> Darnit. Fixed. Thanks.
>
Since we are fixing this message, shouldn't the hint for logical slot
say "Change wal_level to be logical or
e functions
should return void.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From 6ca65097d08244308c264975db4b7b843751d40f Mon Sep 17 00:00:00 2001
From: Petr Jelinek
Date: Mon, 1 Oct 2018 15:19:26 +0200
Subject
replication origin, which could be used to
>>> filter local changes in the replication slot?
>>>
>>> In other words, I'm curious that what's the default replication
>>> origin? Because normal DML locally does not set any origin explicitly,
>>&
t; AFTER:
> Provider - 9.6.10-1.pgdg16.04+1, pglogical 2.2.0-3.xenial+1
> Subscriber - 9.6.10-1.pgdg16.04+1, pglogical 2.2.0-3.xenial+1
>
I finally managed to reproduce this and it's indeed fixed in the 9.6.10
by the commit da10d6a. It was caused by the issue with subtransaction
and S
e_* scan APIs.
>
They can be, but currently they might not be. So this requires at least
big fat warning in docs and description on how to access user catalogs
from plugins correctly (ie to always use systable_* API on them). It
would be nice if we could check for it in Assert builds at least.
--
> CreateInitDecodingContext() passes true for fast_forward? Dave, could
> you confirm this is the case? If so, this'll end up actually being an
> open items entry...
>
Indeed.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ther interfaces and not by move). So I think what Michael
has here is correct.
>> It seems to me that we still want to have the slot forwarding finish in
>> this case even if this is interrupted. Petr, isn't that the intention
>> here?
>
Well, it seems wasteful to just
On 06/06/18 04:04, Michael Paquier wrote:
> On Tue, Jun 05, 2018 at 01:00:30PM +0200, Petr Jelinek wrote:
>> I didn't say anything about CreateDecodingContext though. I am talking
>> about the fact that we then use the same variable as input to
>> XLogReadRecord late
On 05/06/18 06:28, Michael Paquier wrote:
> On Mon, Jun 04, 2018 at 11:51:35AM +0200, Petr Jelinek wrote:
>> On 01/06/18 21:13, Michael Paquier wrote:
>>> -startlsn =3D MyReplicationSlot->data.confirmed_flush;
>>> +if (OidIsValid(MyReplicationSlot->data.dat
er using the confirmed_flush (via startlsn) as start
point of logical decoding (XLogReadRecord parameter in
pg_logical_replication_slot_advance) which is not correct. The
restart_lsn should be used for that. I think it would make sense to fix
that as part of this patch as well.
--
Petr Jelinek
n, if we detect abort in the write callback, set something in the
context which will make all the future writes noop until it's reset
again after we yield back to the logical decoding?
That's not the most beautiful design I've seen, but I'd be okay with
that, it seems like it
On 30/03/18 19:36, Andres Freund wrote:
>
>
> On March 30, 2018 10:27:18 AM PDT, Petr Jelinek
> wrote:
>> . Locking
>> around plugin callbacks can hold he lock for longer periods of time
>> since plugins usually end up writing to network. I think for most
&g
he issues around reading aborted
catalog changes, but that does seem like rather large project on its
own. And if we do locking around plugin callbacks now then we can easily
switch to that solution if it ever happens without anybody having to
rewrite the plugins.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 30/03/18 00:30, Petr Jelinek wrote:
> On 29/03/18 23:58, Andres Freund wrote:
>> On 2018-03-29 23:52:18 +0200, Tomas Vondra wrote:
>>>> I have added details about this in src/backend/storage/lmgr/README as
>>>> suggested by you.
>>>>
>>>
nd of property to Snapshot
which would indicate this fact - logical decoding is using it's own
snapshots it could inject the information about being inside the 2PC
decoding.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 07/03/18 17:55, Stephen Frost wrote:
> Greetings Petr, all,
>
> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
>> On 07/03/18 13:14, Stephen Frost wrote:
>>> * Noah Misch (n...@leadboat.com) wrote:
>>>> On Tue, Mar 06, 2018 at 09:28:21PM -0500, Step
uld be a role attribute. If an
> administrator doesn't wish for that role to have a schema created
> on-demand at login time, they would set the 'SCHEMA_CREATE' (or whatever
> we name it) role attribute to false.
>
Yeah I think role attribute makes se
On 07/03/18 16:26, Stephen Frost wrote:
> Greeting Petr, all,
>
> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
>> On 07/03/18 13:18, Stephen Frost wrote:
>>> Greetings,
>>>
>>> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
>>>>
On 07/03/18 13:18, Stephen Frost wrote:
> Greetings,
>
> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
>> Certain "market leader" database behaves this way as well. I just hope
>> we won't go as far as them and also create users for schemas (so that
&g
about tweaking the roles a
bit which can be easily scripted.
TBH I would personally prefer if we got rid of search_path as GUC
completely because it makes certain aspects of DDL logical replication
and connection pooling much more complex, but that does not seem to be a
realistic change.
> opportunity to do so. I do think it would be too weird to create the schema
> in one database only. Creating it on demand might work. What would be the
> procedure, if any, for database owners who want to deny object creation in
> their databases?
>
Well, REVOKE CREATE ON DATABASE already exists.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
You mean because PG_exception_stack is not initialized for startup
process? That deserves comment I think.
Other than that if I am very nitpicky, I'd call the new function
ReorderBufferCleanupSerializedTXNs.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ry, it's running sum on the new
fast default column.
He uses create and create-alter names as comparison between when the
table was created with the columns and when the columns were added using
fast default.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 16/02/18 12:38, tushar wrote:
> On 02/16/2018 04:02 PM, Petr Jelinek wrote:
>> It's because you are creating temporary slot. Temporary slots are
>> removed on error, that's a documented behavior.
>
> Thanks for pointing out but It looks weird behavior - even a s
from pg_replication_slots;
> slot_name | plugin | slot_type | datoid | database | temporary | active
> | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn
> ---++---++--+---+++--+------+
1 - 100 of 138 matches
Mail list logo
