I wrote:
> vignesh C writes:
>> Conchuela is failing because of:
>> ok 17 - connect to node standby_1 if mode "standby" and standby_1,primary
>> listed
>> ack Broken pipe: write( 13, 'SHOW port;' ) at
>> /usr/local/lib/perl5/site_perl/IPC/Run/IO.pm line 549.
> It didn't fail on the next run, so
vignesh C writes:
> Conchuela is failing because of:
> ok 17 - connect to node standby_1 if mode "standby" and standby_1,primary
> listed
> ack Broken pipe: write( 13, 'SHOW port;' ) at
> /usr/local/lib/perl5/site_perl/IPC/Run/IO.pm line 549.
It didn't fail on the next run, so this might just be
On Wed, Mar 3, 2021 at 2:49 PM vignesh C wrote:
>
>
>
> On Wed, Mar 3, 2021 at 7:37 AM Tom Lane wrote:
> >
> > Greg Nancarrow writes:
> > > I've marked this as "Ready for Committer".
> >
> > I've pushed this after whacking it around a fair amount. A lot of
> > that was cosmetic, but one thing
On Wed, Mar 3, 2021 at 7:37 AM Tom Lane wrote:
>
> Greg Nancarrow writes:
> > I've marked this as "Ready for Committer".
>
> I've pushed this after whacking it around a fair amount. A lot of
> that was cosmetic, but one thing that wasn't is that I got rid of the
> proposed "which_primary_host"
Greg Nancarrow writes:
> I've marked this as "Ready for Committer".
I've pushed this after whacking it around a fair amount. A lot of
that was cosmetic, but one thing that wasn't is that I got rid of the
proposed "which_primary_host" variable. I thought the logic around
that was way too messy
On Fri, Feb 12, 2021 at 2:42 PM vignesh C wrote:
> > Thanks, just one minor thing I missed in doc/src/sgml/libpq.sgml.
> >
> > +The support of read-write transactions is determined by the
> > value of the
> > +default_transaction_read_only and
> > +in_hot_standby
On Fri, Feb 12, 2021 at 7:07 AM Greg Nancarrow wrote:
>
> On Wed, Feb 10, 2021 at 5:09 PM vignesh C wrote:
> >
> > Modified.
> > These comments are handled in v22 patch posted in my earlier mail.
> >
>
> Thanks, just one minor thing I missed in doc/src/sgml/libpq.sgml.
>
> +The support
On Wed, Feb 10, 2021 at 5:09 PM vignesh C wrote:
>
> Modified.
> These comments are handled in v22 patch posted in my earlier mail.
>
Thanks, just one minor thing I missed in doc/src/sgml/libpq.sgml.
+The support of read-write transactions is determined by the
value of the
+
Thanks for the comments Greg, please find my comments inline below.
On Tue, Feb 9, 2021 at 2:27 PM Greg Nancarrow wrote:
>
> On Mon, Feb 8, 2021 at 8:17 PM vignesh C wrote:
> >
> > >
> > > I think what we want to do is mark default_transaction_read_only as
> > > GUC_REPORT, instead. That will
On Tue, Feb 9, 2021 at 5:47 AM Greg Nancarrow wrote:
>
> On Mon, Feb 8, 2021 at 8:17 PM vignesh C wrote:
> >
> > >
> > > I think what we want to do is mark default_transaction_read_only as
> > > GUC_REPORT, instead. That will give a reliable report of what the
> > > state of its GUC is, and you
On Mon, Feb 8, 2021 at 8:17 PM vignesh C wrote:
>
> >
> > I think what we want to do is mark default_transaction_read_only as
> > GUC_REPORT, instead. That will give a reliable report of what the
> > state of its GUC is, and you can combine it with is_hot_standby
> > to decide whether the
On Mon, Feb 8, 2021 at 8:17 PM vignesh C wrote:
>
> >
> > I think what we want to do is mark default_transaction_read_only as
> > GUC_REPORT, instead. That will give a reliable report of what the
> > state of its GUC is, and you can combine it with is_hot_standby
> > to decide whether the
On Wed, Jan 6, 2021 at 3:05 AM Tom Lane wrote:
>
> Greg Nancarrow writes:
> > Posting an updated set of patches.
>
> I've reviewed and pushed most of v20-0001, with the following changes:
>
> * I realized that we had more moving parts than necessary for
> in_hot_standby. We don't really need
Greg Nancarrow writes:
> Posting an updated set of patches.
I've reviewed and pushed most of v20-0001, with the following changes:
* I realized that we had more moving parts than necessary for
in_hot_standby. We don't really need two static variables, one is
sufficient --- and we shouldn't
On Thu, Nov 26, 2020 at 11:07 AM Greg Nancarrow wrote:
>
> On Thu, Nov 26, 2020 at 3:43 AM Tom Lane wrote:
> >
> > Thanks for looking! Pushed.
> >
> > At this point the cfbot is going to start complaining that the last-posted
> > patch in this thread no longer applies. Unless you have a new
On Thu, Nov 26, 2020 at 3:43 AM Tom Lane wrote:
>
> Thanks for looking! Pushed.
>
> At this point the cfbot is going to start complaining that the last-posted
> patch in this thread no longer applies. Unless you have a new patch set
> nearly ready to post, I think we should close the CF entry
Greg Nancarrow writes:
> On Wed, Nov 25, 2020 at 12:07 PM Tom Lane wrote:
>> Here's a v2 that does it like that.
> Looks OK to me.
Thanks for looking! Pushed.
At this point the cfbot is going to start complaining that the last-posted
patch in this thread no longer applies. Unless you have a
On Wed, Nov 25, 2020 at 12:07 PM Tom Lane wrote:
>
>
> Here's a v2 that does it like that.
>
Looks OK to me.
Regards,
Greg Nancarrow
Fujitsu Australia
I wrote:
> Alvaro Herrera writes:
>> Agreed. If this is just a few hundred bytes of server-side local memory
>> per backend, it seems definitely worth it.
> Yeah, given the current set of GUC_REPORT variables, it's hard to see
> the storage for their last-reported values amounting to much. The
Alvaro Herrera writes:
> On 2020-Nov-24, Tom Lane wrote:
>>> As it stands, 0001 reduces the ParameterStatus message traffic to
>>> at most one per GUC per query, but it doesn't attempt to eliminate
>>> duplicate ParameterStatus messages altogether. We could do that
>>> as a pretty simple
On 2020-Nov-24, Tom Lane wrote:
> I'm inclined to go ahead and commit the 0001 patch I posted at [1]
> (ie, change the implementation of GUC_REPORT to avoid intra-query
> reports), since that addresses a performance problem that's
> independent of the goal here. The rest of this seems to still
>
Anastasia Lubennikova writes:
> Hi, this entry is "Waiting on Author" and the thread was inactive for a
> while. As far as I see, the patch needs some further work.
> Are you going to continue working on it, or should I mark it as
> "returned with feedback" until a better time?
I'm inclined to
On 30.09.2020 10:57, Greg Nancarrow wrote:
Thanks for your thoughts, patches and all the pointers.
I'll be looking at all of them.
(And yes, the comma instead of bitwise OR is of course an error,
somehow made and gone unnoticed; the next field in the struct is an
enum, so accepts any int value).
On Sun, Sep 27, 2020 at 4:34 AM Tom Lane wrote:
>
>
> Thoughts?
>
Thanks for your thoughts, patches and all the pointers.
I'll be looking at all of them.
(And yes, the comma instead of bitwise OR is of course an error,
somehow made and gone unnoticed; the next field in the struct is an
enum, so
I wrote:
> BTW, I think it would be worth splitting this into separate server-side
> and libpq patches. It looked to me like the server side is pretty
> nearly committable, modulo bikeshedding about the new GUC name.
Actually ... I looked that over again and got a bit more queasy about
all the
Greg Nancarrow writes:
> [ v19-0001-Enhance-libpq-target_session_attrs-and-add-target_se.patch ]
I started to look through this, and I find that I'm really pretty
disappointed in the direction the patch has gone of late. I think
there is no defensible reason for the choices that have been made
Hi Greg,
> Thanks for the further review, an updated patch is attached. Please
> see my responses to your comments below:
>
Thanks for addressing all of my previous review comments in your new v19 patch.
Everything looks good to me now, so I am marking this as "ready for committer".
Kind
Hi Peter,
Thanks for the further review, an updated patch is attached. Please
see my responses to your comments below:
On Thu, Aug 20, 2020 at 11:36 AM Peter Smith wrote:
>
>
> COMMENT (help text)
>
> The help text is probably accurate but it does seem a bit confusing still.
>
> ...
>
> IMO
On Thu, Aug 20, 2020 at 10:26 AM Greg Nancarrow wrote:
> I have updated the patch (attached) based on your comments, with
> adjustments made for additional changes based on feedback (which I
> tend to agree with) from Robert Haas and Tsunakawa san, who suggested
> read-write/read-only should be
Hi Peter,
I have updated the patch (attached) based on your comments, with
adjustments made for additional changes based on feedback (which I
tend to agree with) from Robert Haas and Tsunakawa san, who suggested
read-write/read-only should be functionally different to
primary/standby, and not
From: Robert Haas
> I think it would be better to have read-write and read-only check
> trnasaction_read_only, and primary and standby can check the new
> thing. There can never be any real advantage in having synonyms for
> the same thing, but there can be an advantage to letting users choose
>
On Fri, Dec 27, 2019 at 8:08 AM Alvaro Herrera wrote:
> So, we can know whether server is primary/standby by checking
> in_recovery, as opposed to knowing whether read-write which is done by
> checking transaction_read_only. So we can keep read-write as a synonym
> for "primary", and check
Hi Greg,
I was able to successfully execute all the tests of the v17-0001 patch.
But I do have a couple of additional review comments about the test code.
COMMENT - missing "any" tests
In my earlier code review (previous email) I suggested that "any" should be
added as valid option to
Hi Greg,
I have spent some time reading this discussion thread, and doing a code review
of the latest (v17-0001) patch.
Below are my review comments; some are trivial, others not so much.
GENERAL COMMENT 1 ("any")
"any" should be included as valid option for target_server_type.
IIUC
>
> Thanks, but now the tests no longer work as the nodes in the test suite are
> renamed. While simple enough for a committer to fix, it's always good to see
> the tests pass in the CFBot to make sure the variable name error isn't hiding
> an actual test error.
>
Rebased patch attached, all
> On 6 Jul 2020, at 14:19, Greg Nancarrow wrote:
>
>> This patch no longer applies, can you please submit a rebased version? I've
>> marked the entry as Waiting on Author in the meantime.
>>
>
> Here's a rebased version of the patch.
Thanks, but now the tests no longer work as the nodes in
> This patch no longer applies, can you please submit a rebased version? I've
> marked the entry as Waiting on Author in the meantime.
>
Here's a rebased version of the patch.
Regards,
Greg
v16-0001-Enhance-libpq-target_session_attrs-and-add-target_se.patch
Description: Binary data
> On 18 May 2020, at 09:33, Greg Nancarrow wrote:
> I'd like to submit a new version of a patch that I'd previously
> submitted but was eventually Returned with Feedback (closed in
> commitfest 2020-03).
This patch no longer applies, can you please submit a rebased version? I've
marked the
Hi Hackers,
I'd like to submit a new version of a patch that I'd previously
submitted but was eventually Returned with Feedback (closed in
commitfest 2020-03).
The patch enhances the libpq "target_session_attrs" connection
parameter by supporting primary/standby/prefer-standby, and I've
attempted
On 2/28/20 11:05 AM, Alvaro Herrera wrote:
MauMau, Greg, is any of you submitting a new patch for this?
This patch has not had any updates in months and now we are halfway
through the CF so I have marked it Returned with Feedback.
If a patch arrives soon I'll be happy to revive the entry,
MauMau, Greg, is any of you submitting a new patch for this?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-Jan-06, tsunakawa.ta...@fujitsu.com wrote:
> Let me check my understanding. Are you proposing these?
>
> * The canonical libpq connection parameter is target_session_attr = {primary
> | standby | prefer-standby}. Leave and document read-write as a synonym for
> primary.
>
> * When
From: Alvaro Herrera
> So, we can know whether server is primary/standby by checking
> in_recovery, as opposed to knowing whether read-write which is done by
> checking transaction_read_only. So we can keep read-write as a synonym
> for "primary", and check in_recovery when used in servers that
On 2019-Dec-27, tsunakawa.ta...@fujitsu.com wrote:
> From: Alvaro Herrera
> > I'm not sure I understand why we end up with "prefer-read" in addition
> > to "prefer-standby" (and similar seeming redundancy between "primary"
> > and "read-write"). Do we really need more than one way to identify
>
From: Alvaro Herrera
> I'm not sure I understand why we end up with "prefer-read" in addition
> to "prefer-standby" (and similar seeming redundancy between "primary"
> and "read-write"). Do we really need more than one way to identify
> hosts' roles? It seems 0001 adds the "prefer-read" modes
On 2019-Dec-26, Dave Cramer wrote:
> On Thu, 26 Dec 2019 at 15:07, Alvaro Herrera
> wrote:
> > There were other comments that I think went largely unaddressed,
> > such as the point that the JDBC driver seems to offer a different
> > syntax for the configuration, and should we offer a
On Thu, 26 Dec 2019 at 15:07, Alvaro Herrera
wrote:
> On 2019-Oct-01, Greg Nancarrow wrote:
>
> > On Wed, Sep 11, 2019 at 10:17 AM Alvaro Herrera from 2ndQuadrant
> > wrote:
> > >
> > > Oh, oops. Here they are then.
> >
> > With the permission of the original patch author, Haribabu Kommi, I’ve
On 2019-Dec-26, Alvaro Herrera wrote:
> The name of the label "consume_checked_write_connection" is not very
> descriptive. I propose "conn_succeeded" instead.
(I realized later that I should have removed this paragraph -- other
goto labels are added in 0002 that would make such renaming more
On 2019-Oct-01, Greg Nancarrow wrote:
> On Wed, Sep 11, 2019 at 10:17 AM Alvaro Herrera from 2ndQuadrant
> wrote:
> >
> > Oh, oops. Here they are then.
>
> With the permission of the original patch author, Haribabu Kommi, I’ve
> rationalized the existing 8 patches into 3 patches, merging
From: Greg Nancarrow
> With the permission of the original patch author, Haribabu Kommi, I’ve
> rationalized the existing 8 patches into 3 patches, merging patches
> 1-5 and 6-7, and tidying up some documentation and code comments. I
> also rebased them to the latest PG12 source code (as of
On Wed, Sep 11, 2019 at 10:17 AM Alvaro Herrera from 2ndQuadrant
wrote:
>
>
> Oh, oops. Here they are then.
>
With the permission of the original patch author, Haribabu Kommi, I’ve
rationalized the existing 8 patches into 3 patches, merging patches
1-5 and 6-7, and tidying up some documentation
On Wed, Sep 11, 2019 at 10:17 AM Alvaro Herrera from 2ndQuadrant
wrote:
>
> Oh, oops. Here they are then.
>
With the permission of the original patch author, Haribabu Kommi, I’ve
rationalized the existing 8 patches into 3 patches, merging patches
1-5 and 6-7, and tidying up some documentation
On 2019-Sep-11, Tsunakawa, Takayuki wrote:
> From: Alvaro Herrera from 2ndQuadrant [mailto:alvhe...@alvh.no-ip.org]
> > Remaining patchset attached (per my count it's v13 of your patchset.
>
> I'm afraid those weren't attached.
Oh, oops. Here they are then.
--
Álvaro Herrera
From: Alvaro Herrera from 2ndQuadrant [mailto:alvhe...@alvh.no-ip.org]
> Testing protocol version 2 is difficult! Almost every single test fails
> because of error messages being reported differently; and streaming
> replication (incl. pg_basebackup) doesn't work at all because it's not
>
On 2019-Sep-09, Alvaro Herrera from 2ndQuadrant wrote:
> Question about 0001. In the CONNECTION_SETENV state, you end by falling
> through to the CONNECTION_CHECK_TARGET case; but in that switch it seems
> a bit unnatural to do that. I think doing "goto keep_trying" is another
> way of doing
Question about 0001. In the CONNECTION_SETENV state, you end by falling
through to the CONNECTION_CHECK_TARGET case; but in that switch it seems
a bit unnatural to do that. I think doing "goto keep_trying" is another
way of doing the same thing, but more in line with what every other
piece of
On Mon, 3 Jun 2019 at 16:32, Haribabu Kommi
wrote:
>
>
> On Thu, Apr 11, 2019 at 9:13 AM Haribabu Kommi
> wrote:
>
>> I fixed all the comments that you have raised above and attached the
>> updated
>> patches.
>>
>
> Rebased patches are attached.
>
Rebased patches are attached.
Regards,
On Thu, Apr 11, 2019 at 9:13 AM Haribabu Kommi
wrote:
> I fixed all the comments that you have raised above and attached the
> updated
> patches.
>
Rebased patches are attached.
Regards,
Haribabu Kommi
Fujitsu Australia
0001-New-pg_basebackup-g-option-to-control-the-group-acce.patch
On Fri, Mar 29, 2019 at 7:06 PM Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> Hi Hari-san,
>
> I've reviewed all the files. The patch would be OK when the following
> have been fixed, except for the complexity of fe-connect.c (which probably
> cannot be improved.)
>
>
Hi Hari-san,
I've reviewed all the files. The patch would be OK when the following have
been fixed, except for the complexity of fe-connect.c (which probably cannot be
improved.)
Unfortunately, I'll be absent next week. The earliest date I can do the test
will be April 8 or 9. I hope
On Wed, Mar 27, 2019 at 5:17 PM Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> I've looked through 0004-0007. I've only found the following:
>
> (5) 0005
> With this read-only option type, application can connect to
> connecting to a read-only server in the list of hosts, in case
I've looked through 0004-0007. I've only found the following:
(5) 0005
With this read-only option type, application can connect to
connecting to a read-only server in the list of hosts, in case
if there is any read-only servers available, the connection
attempt fails.
"connecting to" can be
From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
> while going through the old patch where the GUC_REPORT is implemented, Tom
> has commented the logic of sending the signal to all backends to process
> the hot standby exit with SIGHUP, if we add the logic of updating the GUC
> variable
On Fri, Mar 22, 2019 at 6:07 PM Haribabu Kommi
wrote:
>
> On Fri, Mar 22, 2019 at 7:32 AM Haribabu Kommi
> wrote:
>
>>
>> On Fri, Mar 22, 2019 at 6:57 AM Robert Haas
>> wrote:
>>
>>> On Thu, Mar 21, 2019 at 2:26 AM Haribabu Kommi
>>> wrote:
>>> > Based on the above new options that can be
On Fri, Mar 22, 2019 at 7:32 AM Haribabu Kommi
wrote:
>
> On Fri, Mar 22, 2019 at 6:57 AM Robert Haas wrote:
>
>> On Thu, Mar 21, 2019 at 2:26 AM Haribabu Kommi
>> wrote:
>> > Based on the above new options that can be added to
>> target_session_attrs,
>> >
>> > primary - it is just an alias
On Fri, Mar 22, 2019 at 6:57 AM Robert Haas wrote:
> On Thu, Mar 21, 2019 at 2:26 AM Haribabu Kommi
> wrote:
> > Based on the above new options that can be added to target_session_attrs,
> >
> > primary - it is just an alias to the read-write option.
> > standby, prefer-standby - These options
On Thu, Mar 21, 2019 at 2:26 AM Haribabu Kommi wrote:
> Based on the above new options that can be added to target_session_attrs,
>
> primary - it is just an alias to the read-write option.
> standby, prefer-standby - These options should check whether server is
> running in recovery mode or not
On Wed, Mar 20, 2019 at 5:01 PM Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Robert Haas [mailto:robertmh...@gmail.com]
> > I really dislike having both target_sesion_attrs and
> > target_server_type. It doesn't solve any actual problem. master,
> > slave, prefer-save,
From: Robert Haas [mailto:robertmh...@gmail.com]
> I really dislike having both target_sesion_attrs and
> target_server_type. It doesn't solve any actual problem. master,
> slave, prefer-save, or whatever you like could be put in
> target_session_attrs just as easily, and then we wouldn't end up
On Mon, Mar 18, 2019 at 9:33 PM Haribabu Kommi wrote:
> While working on implementation of target_server_type new connection option
> for the libpq
> to specify master, slave and etc, there is no problem when the newly added
> target_server_type
> option is used separate, but when it is
From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
> Target_session_attrs Target_server_type
>
> read-write prefer-slave, slave
>
> prefer-read master, slave
> read-onlymaster, prefer-slave
>
> I know that some of the
On Thu, Feb 28, 2019 at 1:00 PM Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
> > Attached are the updated patches.
>
> Thanks, all look fixed.
>
>
> > The target_server_type option yet to be implemented.
>
> Please let me
> Now I will add the another parameter target_server_type to choose the
> primary, standby or prefer-standby
> as discussed in the upthreads with a new GUC variable.
>
So just to further confuse things here is a use case for "preferPrimary"
This is from the pgjdbc list.
"if the master instance
From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
> Attached are the updated patches.
Thanks, all look fixed.
> The target_server_type option yet to be implemented.
Please let me review once more and proceed to testing when the above is added,
to make sure the final code looks good. I'd
On Mon, Feb 25, 2019 at 11:38 AM Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> Hi Hari-san,
>
> I've reviewed all files. I think I'll proceed to testing when I've
> reviewed the revised patch and the patch for target_server_type.
>
>
Thanks for the review.
>
> (1) patch 0001
>
Hi Hari-san,
I've reviewed all files. I think I'll proceed to testing when I've reviewed
the revised patch and the patch for target_server_type.
(1) patch 0001
CONNECTION_CHECK_WRITABLE, /* Check if we could make a writable
On Fri, Feb 22, 2019 at 5:47 PM Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
> Here I attached first set of patches that implemented the prefer-read
> option
> > after reporting the transaction_read_only GUC to client. Along
From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
Here I attached first set of patches that implemented the prefer-read option
> after reporting the transaction_read_only GUC to client. Along the lines
> of adding prefer-read option patch,
Great, thank you! I'll review and test it.
> 3.
On Thu, Feb 14, 2019 at 1:04 PM Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
> > No. It's not good if the user has to be bothered by
> > default_transaction_read_only when he simply wants to a standby.
> >
> >
> >
> >
From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
> No. It's not good if the user has to be bothered by
> default_transaction_read_only when he simply wants to a standby.
>
>
>
> OK. Understood.
> so if we are going to differentiate between readonly and standby types,
> then I still
On Fri, Feb 8, 2019 at 8:16 PM Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
> > target_session_attrs checks for the default_transaction_readonly or not?
>
> PG 11 uses transaction_read_only, not default_transaction_readonly.
From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
> target_session_attrs checks for the default_transaction_readonly or not?
PG 11 uses transaction_read_only, not default_transaction_readonly. That's
fine, because its purpose is to get a read-only session as the name suggests,
not to
On Mon, Jan 21, 2019 at 5:48 PM Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
> > Thanks for finding out the problem, how about the following way of
> checking
> > for prefer-read/prefer-standby.
> >
> > 1.
On Mon, Jan 21, 2019 at 06:48:14AM +, Tsunakawa, Takayuki wrote:
> That would be fine. But as I mentioned in another mail, I think
> "get read-only session" and "connect to standby" differ. So I find
> it better to separate parameters for those request;
> target_session_attr and
From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
> Thanks for finding out the problem, how about the following way of checking
> for prefer-read/prefer-standby.
>
> 1. (default_transaction_read_only = true and recovery = true)
>
> 2. If none of the host satisfies the above scenario, then
From: Laurenz Albe [mailto:laurenz.a...@cybertec.at]
> Tsunakawa, Takayuki wrote:
> > I'm sorry to repeat myself, but anyway, I think we need a method to connect
> to a standby
> > as the original desire, because the primary instance may be read only
> by default while
> > only limited users
On Fri, Jan 18, 2019 at 5:33 PM Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Tsunakawa, Takayuki [mailto:tsunakawa.ta...@jp.fujitsu.com]
> > As for prefer-standby/prefer-read, if host parameter specifies
> host1,host2
> > in this order, and host1 is the primary with
> >
Tsunakawa, Takayuki wrote:
> From: Laurenz Albe [mailto:laurenz.a...@cybertec.at]
> > I think that transaction_read_only is good.
> >
> > If it is set to false, we are sure to be on a replication primary or
> > stand-alone server, which is enough to know for the load balancing use case.
>
> As
From: Tsunakawa, Takayuki [mailto:tsunakawa.ta...@jp.fujitsu.com]
> As for prefer-standby/prefer-read, if host parameter specifies host1,host2
> in this order, and host1 is the primary with
> default_transaction_read_only=true, does the app get a connection to host1?
> I want to connect to host2
>> If you need some input from me regarding finding a primary node,
>> please say so. While working on Pgpool-II project, I learned the
>> necessity in a hard way.
>>
>>
> I would really like to have a consistent way of doing this, and consistent
> terms for the connection parameters.
>
> that
From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
> IMO, if we try to use only pg_is_in_recovery() only to decide to connect,
> we may not
> support all the target_session_attrs that are possible. how about using
> both to decide?
I favor adding a new parameter like target_server_type whose
On Fri, Jan 18, 2019 at 2:34 PM Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Laurenz Albe [mailto:laurenz.a...@cybertec.at]
> > I think that transaction_read_only is good.
> >
> > If it is set to false, we are sure to be on a replication primary or
> > stand-alone server,
From: Laurenz Albe [mailto:laurenz.a...@cybertec.at]
> I think that transaction_read_only is good.
>
> If it is set to false, we are sure to be on a replication primary or
> stand-alone server, which is enough to know for the load balancing use case.
As Tatsuo-san said, setting
On Thu, 17 Jan 2019 at 19:56, Tatsuo Ishii wrote:
> >> > I'm curious; under what circumstances would the above occur?
> >>
> >> Former primary goes down and one of standbys is promoting but it is
> >> not promoted to new primary yet.
> >>
> >
> > seems like JDBC might have some work to
>> > I'm curious; under what circumstances would the above occur?
>>
>> Former primary goes down and one of standbys is promoting but it is
>> not promoted to new primary yet.
>>
>
> seems like JDBC might have some work to do...Thanks
>
> I'm going to wait to implement until we resolve this
On Thu, 17 Jan 2019 at 19:38, Tatsuo Ishii wrote:
> >> >> >> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
> >> >> >> >> But pg_is_in_recovery() returns true even for a promoting
> >> standby. So
> >> >> >> >> you have to wait and retry to send pg_is_in_recovery() until it
> >> >> >> >>
>> >> >> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
>> >> >> >> But pg_is_in_recovery() returns true even for a promoting
>> standby. So
>> >> >> >> you have to wait and retry to send pg_is_in_recovery() until it
>> >> >> >> finishes the promotion to find out it is now a primary. I am not
>>
On Thu, 17 Jan 2019 at 19:09, Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Dave Cramer [mailto:p...@fastcrypt.com]
> > >> 2) If there's no node on which pg_is_in_recovery() returns
> false,
> > then
> > >>we need to retry until we find it. To not retry
On Thu, 17 Jan 2019 at 19:15, Tatsuo Ishii wrote:
> > On Thu, 17 Jan 2019 at 18:03, Tatsuo Ishii wrote:
> >
> >> > On Wed, 16 Jan 2019 at 01:02, Tatsuo Ishii
> wrote:
> >> >
> >> >> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
> >> >> >> But pg_is_in_recovery() returns true even for a
> On Thu, 17 Jan 2019 at 18:03, Tatsuo Ishii wrote:
>
>> > On Wed, 16 Jan 2019 at 01:02, Tatsuo Ishii wrote:
>> >
>> >> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
>> >> >> But pg_is_in_recovery() returns true even for a promoting standby. So
>> >> >> you have to wait and retry to send
1 - 100 of 147 matches
Mail list logo
