> 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
> 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 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
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
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
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 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 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 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 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
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
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 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.
>>>>
>>>
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 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
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
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 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
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/
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
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
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 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
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/
embarassing demonstrations...
Yeah, pg_list.h is one file I never close.
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
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
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
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
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
On 08/01/18 08:02, Simon Riggs wrote:
> On 31 December 2017 at 10:44, Petr Jelinek
> wrote:
>
>> Attached is patch which adds ability to do fast-forwarding while
>> decoding. That means wal is consumed as fast as possible and changes are
>> not given to out
le to see any difference according to the code or the
> documentation, so I'm wondering if we should document that they are the
> same.
>
It's for use by 3rd party tools (afaik both londiste and slony use it)
to differentiate between replicated and not replicated changes.
--
ateGuts should track
which relations it opened and only close those and the rest should be
closed by caller? That should also remove the other ugly part which is
that the ExecuteTruncateGuts modifies the input list. What if caller
wanted to use those relations it sent as parameter later?
--
Petr
twork write, this would really mean locking the transaction for
and unbounded period of time. That does not strike me as something we
want to do, decoding should not interact with frontend transaction
management, definitely not this badly.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 19/01/18 12:41, Marco Nenciarini wrote:
> Hi Peter,
>
> Il 18/01/18 17:30, Peter Eisentraut ha scritto:
>> On 1/17/18 11:33, Petr Jelinek wrote:
>>>> P.S: I'm struggling to understand why we have two possible values of
>>>> session_replication_role
On 19/01/18 12:37, Marco Nenciarini wrote:
> Hi All,
>
> Il 18/01/18 17:48, Simon Riggs ha scritto:
>> On 17 January 2018 at 17:07, Petr Jelinek
>> wrote:
>>
>>> Things I am less convinced about:
>>>
>>> The patch will cascade trunca
On 22/01/18 20:21, Robert Haas wrote:
> On Mon, Jan 22, 2018 at 10:40 AM, Petr Jelinek
> wrote:
>> I think this is the only real problem from your list for logical
>> decoding catalog snapshots. But it's indeed quite a bad one. Is there
>> something preventing us to r
On 22/01/18 19:45, Petr Jelinek wrote:
> On 19/01/18 12:37, Marco Nenciarini wrote:
>> Hi All,
>>>>> + /* logicalrep_rel_close call not needed, because ExecuteTruncateGuts
>>>>> + * already closes the relations. Setting localrel to NULL in the
On 23/01/18 13:34, Marco Nenciarini wrote:
> Il 22/01/18 19:41, Petr Jelinek ha scritto:
>> On 19/01/18 12:41, Marco Nenciarini wrote:
>>> Hi Peter,
>>>
>>> Il 18/01/18 17:30, Peter Eisentraut ha scritto:
>>>> On 1/17/18 11:33, Petr Jelinek wrote:
Hi,
On 23/01/18 15:38, Marco Nenciarini wrote:
> Il 22/01/18 23:18, Petr Jelinek ha scritto:
>> On 22/01/18 19:45, Petr Jelinek wrote:
>>
>> Actually on second look, I don't like the new boolean parameter much.
>> I'd rather we didn't touch the input list
On 23/01/18 18:19, Marco Nenciarini wrote:
> Il 23/01/18 18:13, Petr Jelinek ha scritto:
>> Hi,
>>
>> On 23/01/18 15:38, Marco Nenciarini wrote:
>>> Il 22/01/18 23:18, Petr Jelinek ha scritto:
>>>> On 22/01/18 19:45, Petr Jelinek wrote:
>>>&
Hi,
On 23/01/18 18:47, Marco Nenciarini wrote:
> Il 23/01/18 18:25, Petr Jelinek ha scritto:
>> On 23/01/18 18:19, Marco Nenciarini wrote:
>>> Il 23/01/18 18:13, Petr Jelinek ha scritto:
>>>> Hi,
>>>>
>>>> On 23/01/18 15:38, Marco Nenciarini w
transaction didn't do any catalog modifications
(we already have that info easily accessible as bool).
That would mean we'd never do any kind of heavy locking for prolonged
periods of time (ie network calls) but only during catalog access and
only when needed. It would also solv
e
> problem gracefully? Don't know if we ever got to doing that but seems not.
We didn't find clean way of detecting this (being sure this is the case
involves a lot of shmem gymnastics and process interlocking, not to
mention the code layering does not really work for it).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
.
OTOH, if we'll want to add option in the future to propagate cascade (to
any additional tables on downstream), it may need to reset sequences
which are not even present upstream and as such would not be handled by
sequence replication.
--
Petr Jelinek http://www.2ndQuadr
ld break cascading.
I expect Marco to send new version shortly with both of these fixed.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 26/01/18 02:34, Robert Haas wrote:
> On Wed, Jan 17, 2018 at 12:07 PM, Petr Jelinek
> wrote:
>> The patch will cascade truncation on downstream if cascade was specified
>> on the upstream, that can potentially be dangerous and we either should
>> not do it and only t
On 26/01/18 03:44, Peter Eisentraut wrote:
> On 1/24/18 07:53, Petr Jelinek wrote:
>> That depends on if we consider this to be part of sequence handling or
>> truncate statement replication handling. It's true that if we had
>> sequence replication, the restart wou
a few days ago. I'm on it.
>>
>
>
> Here's a version that fixes the above issue and also the issue with
> VACUUM that Tomas Vondra reported. I'm still working on the issue with
> aggregates that Tomas also reported.
>
I see the patch does not update the ALTE
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
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/
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
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
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
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
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 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 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
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
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
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();
>>> +
>>> +
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
(uint32)
>> (MyReplicationSlot->data.confirmed_flush >> 32),
>> 484 (uint32)
>> (MyReplicationSlot->data.confirmed_flush;
>> 485 }
>> 486
>>
Yeah, of course we can't use MyReplicationSlot after calling
ReplicationSlotRelease().
>
> Attached patch proposes a required fix.
>
Looks correct to me.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
from pg_replication_slots;
> slot_name | plugin | slot_type | datoid | database | temporary | active
> | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn
> ---++---++--+---+++--+------+
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
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
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
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
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
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:
>>>>
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 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
> 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
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
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/
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/
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,
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 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
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
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
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
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/
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/
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
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/
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
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
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/
(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
_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
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
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
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:
>>
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
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
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
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
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
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 :
>
1 - 100 of 138 matches
Mail list logo
