On 2020-Jun-24, Andres Freund wrote:
> As I said before, I've utilized being able to do both over a single
> connection (among others to initialize a logical replica using a base
> backup). And I've seen at least one other codebase (developed without my
> input) doing so. I really don't
On Wed, Jun 24, 2020 at 3:41 PM Alvaro Herrera wrote:
> People (specifically the jdbc driver) *are* using this feature in this
> way, but they didn't realize they were doing it. It was an accident and
> they didn't notice.
But you don't know that that's true of everyone using this feature,
and
Hi,
On 2020-06-24 15:41:14 -0400, Alvaro Herrera wrote:
> On 2020-Jun-24, Robert Haas wrote:
>
> > So really I think this turns on #1: is it plausible
> > that people are using this feature, however inadvertent it may be, and
> > is it potentially useful? I don't see that anybody's made an
On Wed, 24 Jun 2020 at 15:41, Alvaro Herrera
wrote:
> On 2020-Jun-24, Robert Haas wrote:
>
> > So really I think this turns on #1: is it plausible
> > that people are using this feature, however inadvertent it may be, and
> > is it potentially useful? I don't see that anybody's made an argument
On 2020-Jun-24, Robert Haas wrote:
> So really I think this turns on #1: is it plausible
> that people are using this feature, however inadvertent it may be, and
> is it potentially useful? I don't see that anybody's made an argument
> against either of those things. Unless someone can do so, I
On Wed, Jun 24, 2020 at 1:06 PM Alvaro Herrera wrote:
> On 2020-Jun-24, Stephen Frost wrote:
> > Doesn't mean it makes sense or that we should be supporting that. What
> > we should have is a way to allow administrators to configure a system
> > for exactly what they want to allow, and it
On 2020-Jun-24, Stephen Frost wrote:
> Doesn't mean it makes sense or that we should be supporting that. What
> we should have is a way to allow administrators to configure a system
> for exactly what they want to allow, and it doesn't seem like we're
> doing that today and therefore we should
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2020-Jun-24, Kyotaro Horiguchi wrote:
>
> > In logical replication, a replication role is intended to be
> > accessible only to the GRANTed databases. On the other hand the same
> > role can create a dead copy of the whole
On 2020-Jun-24, Kyotaro Horiguchi wrote:
> In logical replication, a replication role is intended to be
> accessible only to the GRANTed databases. On the other hand the same
> role can create a dead copy of the whole cluster, including
> non-granted databases.
In other words -- essentially, if
On 2020/06/24 11:56, Kyotaro Horiguchi wrote:
At Tue, 23 Jun 2020 10:51:40 +0900, Michael Paquier wrote
in
On Sun, Jun 21, 2020 at 01:02:34PM -0700, Andres Freund wrote:
I still maintain that adding restrictions here is a bad idea. Even
disregarding the discussion of running normal
At Tue, 23 Jun 2020 10:51:40 +0900, Michael Paquier wrote
in
> On Sun, Jun 21, 2020 at 01:02:34PM -0700, Andres Freund wrote:
> > I still maintain that adding restrictions here is a bad idea. Even
> > disregarding the discussion of running normal queries interspersed, it's
> > useful to be able
On Sun, Jun 21, 2020 at 01:02:34PM -0700, Andres Freund wrote:
> I still maintain that adding restrictions here is a bad idea. Even
> disregarding the discussion of running normal queries interspersed, it's
> useful to be able to both request WAL and receive logical changes over
> the same
Hi,
On 2020-06-21 13:45:36 -0400, Jonathan S. Katz wrote:
> The PG13 RMT had a discussion about this thread, and while the initial
> crash has been fixed, we decided to re-open the Open Item around whether
> we should allow physical replication to be initiated in a logical
> replication session.
Hi,
On 6/5/20 11:51 AM, Alvaro Herrera wrote:
> On 2020-Jun-05, Dave Cramer wrote:
>
>> On Thu, 4 Jun 2020 at 19:46, Alvaro Herrera
>> wrote:
>
>>> Ouch ... so they made IDENT in the replication grammar be a trigger to
>>> enter the regular grammar. Crazy. No way to put those worms back in
On Thu, Jun 04, 2020 at 11:07:29AM +0900, Michael Paquier wrote:
> Are there any objections in fixing the issue first then? As far as I
> can see there is no objection to this part, like here:
> https://www.postgresql.org/message-id/20200603214448.GA901@alvherre.pgsql
Hearing nothing, I have
On 2020-Jun-05, Dave Cramer wrote:
> On Thu, 4 Jun 2020 at 19:46, Alvaro Herrera
> wrote:
> > Ouch ... so they made IDENT in the replication grammar be a trigger to
> > enter the regular grammar. Crazy. No way to put those worms back in
> > the tin now, I guess.
>
> Is that documented ?
I
On Thu, 4 Jun 2020 at 19:46, Alvaro Herrera
wrote:
> On 2020-Jun-04, Andres Freund wrote:
>
> > postgres[52656][1]=# SELECT 1;
> > ┌──┐
> > │ ?column? │
> > ├──┤
> > │1 │
> > └──┘
> > (1 row)
> >
> >
> > I am very much not in love with the way that was
On 2020-Jun-04, Andres Freund wrote:
> postgres[52656][1]=# SELECT 1;
> ┌──┐
> │ ?column? │
> ├──┤
> │1 │
> └──┘
> (1 row)
>
>
> I am very much not in love with the way that was implemented, but it's
> there, and it's used as far as I know (cf tablesync.c).
Ouch
Hi,
On 2020-06-04 16:44:53 -0400, Alvaro Herrera wrote:
> A logical replication connection cannot run SQL anyway, can it?
You can:
andres@awork3:~/src/postgresql$ psql 'replication=database'
postgres[52656][1]=# IDENTIFY_SYSTEM;
┌─┬──┬┬──┐
│
On 2020-Jun-04, Michael Paquier wrote:
> On Wed, Jun 03, 2020 at 06:33:11PM -0700, Andres Freund wrote:
> >> I don't think having a physical replication connection access catalog
> >> data directly is a great idea. We already have gadgets like
> >> IDENTIFY_SYSTEM for physical replication that
On 2020-Jun-03, Andres Freund wrote:
> On 2020-06-03 18:27:12 -0400, Alvaro Herrera wrote:
> > On 2020-Jun-03, Andres Freund wrote:
> > > I don't think we should prohibit this. For one, it'd probably break some
> > > clients, without a meaningful need.
> >
> > There *is* a need, namely to keep
On Wed, Jun 03, 2020 at 06:33:11PM -0700, Andres Freund wrote:
> On 2020-06-03 18:27:12 -0400, Alvaro Herrera wrote:
>> There *is* a need, namely to keep complexity down. This is quite
>> convoluted, it's got a lot of historical baggage because of the way it
>> was implemented, and it's very
Hi,
On 2020-06-03 18:27:12 -0400, Alvaro Herrera wrote:
> On 2020-Jun-03, Andres Freund wrote:
> > I don't think we should prohibit this. For one, it'd probably break some
> > clients, without a meaningful need.
>
> There *is* a need, namely to keep complexity down. This is quite
> convoluted,
On 2020-Jun-02, Michael Paquier wrote:
> I can note as well that StartLogicalReplication() moves in this sense
> by setting xlogreader to be the one from logical_decoding_ctx once the
> decoding context has been created.
>
> This results in the attached. The extra test from upthread to check
>
On 2020-Jun-03, Andres Freund wrote:
> I don't think we should prohibit this. For one, it'd probably break some
> clients, without a meaningful need.
There *is* a need, namely to keep complexity down. This is quite
convoluted, it's got a lot of historical baggage because of the way it
was
Hi,
On 2020-06-02 14:23:50 +0900, Fujii Masao wrote:
> On 2020/06/02 13:24, Michael Paquier wrote:
> > On Fri, May 29, 2020 at 06:09:06PM +0900, Masahiko Sawada wrote:
> > > Yes. Conversely, if we start logical replication in a physical
> > > replication connection (i.g. replication=true) we got
On 2020/06/03 20:33, Dave Cramer wrote:
On Wed, 3 Jun 2020 at 01:19, Michael Paquier mailto:mich...@paquier.xyz>> wrote:
On Tue, Jun 02, 2020 at 02:23:50PM +0900, Fujii Masao wrote:
> On 2020/06/02 13:24, Michael Paquier wrote:
>> Still unconvinced as this restriction stands
On Wed, 3 Jun 2020 at 01:19, Michael Paquier wrote:
> On Tue, Jun 02, 2020 at 02:23:50PM +0900, Fujii Masao wrote:
> > On 2020/06/02 13:24, Michael Paquier wrote:
> >> Still unconvinced as this restriction stands for logical decoding
> >> requiring a database connection but it is not necessarily
On Tue, Jun 02, 2020 at 02:23:50PM +0900, Fujii Masao wrote:
> On 2020/06/02 13:24, Michael Paquier wrote:
>> Still unconvinced as this restriction stands for logical decoding
>> requiring a database connection but it is not necessarily true now as
>> physical replication has less restrictions
At Tue, 2 Jun 2020 13:24:56 +0900, Michael Paquier wrote
in
> On Fri, May 29, 2020 at 06:09:06PM +0900, Masahiko Sawada wrote:
> > Yes. Conversely, if we start logical replication in a physical
> > replication connection (i.g. replication=true) we got an error before
> > staring replication:
>
On 2020/06/02 13:24, Michael Paquier wrote:
On Fri, May 29, 2020 at 06:09:06PM +0900, Masahiko Sawada wrote:
Yes. Conversely, if we start logical replication in a physical
replication connection (i.g. replication=true) we got an error before
staring replication:
ERROR: logical decoding
On Fri, May 29, 2020 at 06:09:06PM +0900, Masahiko Sawada wrote:
> Yes. Conversely, if we start logical replication in a physical
> replication connection (i.g. replication=true) we got an error before
> staring replication:
>
> ERROR: logical decoding requires a database connection
>
> I think
On Fri, 29 May 2020 at 17:57, Kyotaro Horiguchi wrote:
>
> At Fri, 29 May 2020 16:21:38 +0900, Michael Paquier
> wrote in
> > On Thu, May 28, 2020 at 06:11:39PM +0900, Kyotaro Horiguchi wrote:
> > > Mmm. It is not the proper way to use physical replication and it's
> > > totally accidental that
At Fri, 29 May 2020 16:21:38 +0900, Michael Paquier wrote
in
> On Thu, May 28, 2020 at 06:11:39PM +0900, Kyotaro Horiguchi wrote:
> > Mmm. It is not the proper way to use physical replication and it's
> > totally accidental that that worked (or even it might be a bug). The
> > documentation is
On Thu, May 28, 2020 at 06:11:39PM +0900, Kyotaro Horiguchi wrote:
> Mmm. It is not the proper way to use physical replication and it's
> totally accidental that that worked (or even it might be a bug). The
> documentation is saying as the follows, as more-or-less the same for
> all versions since
At Thu, 28 May 2020 09:08:19 -0400, Dave Cramer
wrote in
> On Thu, 28 May 2020 at 05:11, Kyotaro Horiguchi
> wrote:
> > Mmm. It is not the proper way to use physical replication and it's
> > totally accidental that that worked (or even it might be a bug). The
> > documentation is saying as the
On Thu, 28 May 2020 at 05:11, Kyotaro Horiguchi
wrote:
> Hello, Vladimir.
>
> At Thu, 28 May 2020 11:57:23 +0300, Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote in
> > Kyotaro>It seems to me that that crash means Pgjdbc is initiating a
> logical
> > Kyotaro>replication connection to
Hello, Vladimir.
At Thu, 28 May 2020 11:57:23 +0300, Vladimir Sitnikov
wrote in
> Kyotaro>It seems to me that that crash means Pgjdbc is initiating a logical
> Kyotaro>replication connection to start physical replication.
>
> Well, it used to work previously, so it might be a breaking change
Kyotaro>It seems to me that that crash means Pgjdbc is initiating a logical
Kyotaro>replication connection to start physical replication.
Well, it used to work previously, so it might be a breaking change from the
client/application point of view.
Vladimir
At Thu, 28 May 2020 09:07:04 +0300, Vladimir Sitnikov
wrote in
> Pgjdbc test suite identified a SIGSEGV in the recent HEAD builds of
> PostgreSQL, Ubuntu 14.04.5 LTS
>
> Here's a call stack:
> https://travis-ci.org/github/pgjdbc/pgjdbc/jobs/691794110#L7484
> The crash is consistent, and it
On Thu, May 28, 2020 at 04:32:22PM +0900, Kyotaro Horiguchi wrote:
> I think that's not the case. I think I cause this crash with the
> HEAD. I'll post a fix soon.
>
> Pgjdbc seems initiating physical replication on a logical replication
> session.
Let me see... Indeed:
$ psql
At Thu, 28 May 2020 16:22:33 +0900, Michael Paquier wrote
in
> On Thu, May 28, 2020 at 09:07:04AM +0300, Vladimir Sitnikov wrote:
> > The CI history shows that HEAD was good at 11 May 13:27 UTC, and it became
> > bad by 19 May 14:00 UTC,
> > so the regression was introduced somewhere
On Thu, May 28, 2020 at 09:07:04AM +0300, Vladimir Sitnikov wrote:
> The CI history shows that HEAD was good at 11 May 13:27 UTC, and it became
> bad by 19 May 14:00 UTC,
> so the regression was introduced somewhere in-between.
>
> Does that ring any bells?
It does, thanks! This would map with
43 matches
Mail list logo
