Yes, when did it become a good idea to put a connection pooler in the
backend???
Dave Cramer
www.postgres.rocks
ack to
> expecting the community to maintain things for the benefit of
> third-party forks.
>
if this proposal brought us the ability stream results that would be a huge
plus!
Dave Cramer
www.postgres.rocks
>
>
On Tue, 26 Jan 2021 at 12:46, Laurenz Albe wrote:
> On Tue, 2021-01-26 at 12:25 -0500, Dave Cramer wrote:
> > > After thinking some more about it, I think that COMMIT AND CHAIN would
> have
> > > to change behavior: if COMMIT throws an error (because the transaction
>
On Tue, 26 Jan 2021 at 12:20, Laurenz Albe wrote:
> On Tue, 2021-01-26 at 11:09 -0500, Dave Cramer wrote:
> > On Tue, 26 Jan 2021 at 05:05, Laurenz Albe
> wrote:
> >
> > > I wonder about the introduction of the new USER_ERROR level:
> > >
> > > #def
On Tue, 26 Jan 2021 at 05:05, Laurenz Albe wrote:
> On Mon, 2021-01-25 at 11:29 -0500, Dave Cramer wrote:
> > Rebased against head
> >
> > Here's my summary of the long thread above.
> >
> > This change is in keeping with the SQL spec.
> >
> > T
On Tue, 26 Jan 2021 at 06:59, Masahiko Sawada wrote:
> On Tue, Jan 26, 2021 at 7:06 PM Laurenz Albe
> wrote:
> >
> > On Mon, 2021-01-25 at 11:29 -0500, Dave Cramer wrote:
> > > Rebased against head
> > >
> > > Here's my summary of the long t
Apologies, I should have checked again to make sure the patch applied.
This one does and passes tests.
Dave Cramer
www.postgres.rocks
On Mon, 25 Jan 2021 at 09:09, Dave Cramer wrote:
> Rebased against head
>
> Here's my summary of the long thread above.
>
> This change is
async drivers that would also benefit
from not having to keep state in the session.
Regards,
Dave Cramer
www.postgres.rocks
On Tue, 10 Nov 2020 at 11:53, Dave Cramer wrote:
>
>
> On Mon, 9 Nov 2020 at 16:26, Dave Cramer
> wrote:
>
>>
>>
>> On Wed, 30 Sep 2020 at
I could if someone wants to commit to reviewing it.
I've updated it a number of times but it seems nobody wants to review it.
Dave Cramer
www.postgres.rocks
On Thu, 7 Jan 2021 at 09:27, Masahiko Sawada wrote:
> Hi Dave,
>
> On Tue, Dec 1, 2020 at 6:49 PM Georgios Koko
On Mon, 9 Nov 2020 at 16:26, Dave Cramer wrote:
>
>
> On Wed, 30 Sep 2020 at 18:14, Andrew Dunstan <
> andrew.duns...@2ndquadrant.com> wrote:
>
>>
>> On 8/4/20 12:19 PM, Dave Cramer wrote:
>> > Attached is the rebased patch for consideration.
>&
On Wed, 30 Sep 2020 at 18:14, Andrew Dunstan
wrote:
>
> On 8/4/20 12:19 PM, Dave Cramer wrote:
> > Attached is the rebased patch for consideration.
> >
> >
>
>
> It's a bit sad this has been hanging around so long without attention.
>
>
> The prev
On Wed, 4 Nov 2020 at 10:50, Shay Rojansky wrote:
> Hi all.
>
> Back in 2016 I started a thread about making cancellations safer[1], I'd
> like to try to pick this up again. Here a summary of the previous
> conversation:
>
> The main ask here is to allow clients to specify which command to cancel
On Tue, 3 Nov 2020 at 08:42, Alvaro Herrera wrote:
> Hi Dave,
>
> On 2020-Nov-03, Dave Cramer wrote:
>
> > On Mon, 2 Nov 2020 at 10:57, Alvaro Herrera
> wrote:
> >
> > > On 2020-Nov-02, Alvaro Herrera wrote:
> > >
> > > > In v23 I&
for looking at this.
What else does it need to get it in shape to apply?
Dave Cramer
www.postgres.rocks
tch needs a rebase as it visibly fails to apply,
> per the CF bot.
> --
> Michael
>
Where are you with this? Are you able to work on it ?
Dave Cramer
On Mon, 2 Nov 2020 at 14:47, Andres Freund wrote:
> Hi,
>
> On 2020-11-02 11:18:03 -0500, Dave Cramer wrote:
> > On Sun, 1 Nov 2020 at 18:15, Tom Lane wrote:
> >
> > > Dave Cramer writes:
> > > > OK, checked and I definitely have the changes. I don&#
On Sun, 1 Nov 2020 at 18:15, Tom Lane wrote:
> Dave Cramer writes:
> > OK, checked and I definitely have the changes. I don't think the
> isolation
> > test is running. Is there some configuration that enables it?
>
> No, top-level "check-world" shou
On Sun, 1 Nov 2020 at 13:46, Dave Cramer wrote:
>
>
> On Sun., Nov. 1, 2020, 1:41 p.m. Thomas Munro,
> wrote:
>
>> On Mon, Nov 2, 2020 at 1:58 AM Dave Cramer wrote:
>> > For my patch https://commitfest.postgresql.org/30/2522/
>> >
>> > When I
On Sun., Nov. 1, 2020, 1:41 p.m. Thomas Munro,
wrote:
> On Mon, Nov 2, 2020 at 1:58 AM Dave Cramer wrote:
> > For my patch https://commitfest.postgresql.org/30/2522/
> >
> > When I run
> >
> > make -j4 all contrib && make check-world
> > locally
&
For my patch https://commitfest.postgresql.org/30/2522/
When I run
make -j4 all contrib && make check-world
locally
I see 2 errors.
When cf-bot runs this it sees
35 out of 93 failed.
How can I see the same errors?
Dave Cramer
On Tue, 20 Oct 2020 at 20:09, Andres Freund wrote:
> Hi,
>
> On 2020-10-20 18:55:41 -0500, Jack Christensen wrote:
> > Upthread someone posted a page pgjdbc detailing desired changes to the
> > backend protocol (
> >
> https://github.com/pgjdbc/pgjdbc/blob/master/backend_protocol_v4_wanted_featur
On Tue, 20 Oct 2020 at 05:57, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-10-09 21:02, Dave Cramer wrote:
> > For the most part we know exactly which types we want in binary for 99%
> > of queries.
> >
> > The hard part around this
On Fri, 9 Oct 2020 at 14:59, Andres Freund wrote:
> Hi,
>
> On 2020-10-09 14:49:11 -0400, Dave Cramer wrote:
> > On Fri, 9 Oct 2020 at 14:46, Andres Freund wrote:
> > > > (I suspect what would be more useful in practice is to designate
> > > > output
Hi,
On Fri, 9 Oct 2020 at 14:46, Andres Freund wrote:
> Hi,
>
> On 2020-10-08 09:46:38 +0200, Peter Eisentraut wrote:
> > New would be that the server would now also respond with a new message,
> say,
> >
> > S: DynamicResultInfo
>
> > Now, if the client has seen DynamicResultInfo earlier, it s
On Fri, 9 Oct 2020 at 13:33, Andrew Dunstan wrote:
>
> On 10/8/20 3:46 AM, Peter Eisentraut wrote:
> > I want to progress work on stored procedures returning multiple result
> > sets. Examples of how this could work on the SQL side have previously
> > been shown [0]. We also have ongoing work t
On Tue, 29 Sep 2020 at 14:33, Andrew Dunstan
wrote:
>
> On 9/29/20 10:26 AM, Peter Eisentraut wrote:
> > On 2020-09-28 15:46, Vladimir Sitnikov wrote:
> >> The concerns to avoid "Clob maps to text" could be:
> >> a) Once the behavior is implemented, it is hard to change. That is
> >> applications
On Mon, 28 Sep 2020 at 20:08, Andy Fan wrote:
>
>
> On Tue, Sep 29, 2020 at 5:22 AM Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
>> >100% compatible with the MySQL
>>
>> It is hardly a justification for a feature or for a change request.
>>
>> Vladimir
>>
>
I would have to agree. T
On Mon, 21 Sep 2020 at 09:21, Matthieu Garrigues <
matthieu.garrig...@gmail.com> wrote:
> Matthieu Garrigues
>
> On Mon, Sep 21, 2020 at 3:09 PM Dave Cramer
> wrote:
> >>
> > There was a comment upthread a while back that people should look at the
> comments
Dave Cramer
www.postgres.rocks
On Mon, 31 Aug 2020 at 11:46, Matthieu Garrigues <
matthieu.garrig...@gmail.com> wrote:
> Hi,
>
> It seems like this patch is nearly finished. I fixed all the remaining
> issues. I'm also asking
> a confirmation of the test scenarios y
certainly
> not a newcomer.)
>
I am looking for this in the commitfest and can't find it. However there is
an old commitfest entry
https://commitfest.postgresql.org/13/1024/
Do you have the link for the new one ?
Dave Cramer
www.postgres.rocks
>
>
>
On Wed, 12 Aug 2020 at 08:14, Andy Fan wrote:
>
>
> On Wed, Aug 12, 2020 at 8:11 PM Andy Fan wrote:
>
>>
>>
>> On Wed, Aug 12, 2020 at 5:54 PM Dave Cramer
>> wrote:
>>
>>>
>>>
>>>
>>> On Tue, 11 Aug 2020 at 22:33,
d the data one by one.
>
> The above user case looks reasonable to me IMO, I would say it is kind of
> "tech debt"
> in postgres. To support this completely, looks we have to decouple the
> snapshot/locking
> management with transaction? If so, it looks like a huge change. I wonder
> if anybody
> tried to resolve this issue and where do we get to that point?
>
> --
> Best Regards
> Andy Fan
>
I think if you set the fetch size the driver will use a named cursor and
this should work
Dave Cramer
www.postgres.rocks
Attached is the rebased patch for consideration.
Dave Cramer
www.postgres.rocks
>
>
0001-Throw-error-and-rollback-on-a-failed-transaction-ins.patch
Description: Binary data
facility
that is not easily replicated.
Thoughts ?
Dave Cramer
On Fri, 17 Jul 2020 at 11:17, David G. Johnston
wrote:
> On Fri, Jul 17, 2020 at 8:10 AM Dave Cramer wrote:
>
>> This started out with just fixing
>>
>> "One option do deal" to " One option to deal"
>>
>> But after reading the rest I
This started out with just fixing
"One option do deal" to " One option to deal"
But after reading the rest I'd propose the following patch.
Dave Cramer
reorderdoc.patch
Description: Binary data
ll of the types.
AFAICT we don't have that information since the publication determines what
is sent?
This code line 482 in proto.c attempts to limit what is sent in binary. We
could certainly be more restrictive here.
*if* (binary &&
OidIsValid(typclass->typreceive) &&
(att->atttypid < FirstNormalObjectId || typclass->typtype != 'c') &&
(att->atttypid < FirstNormalObjectId || typclass->typelem == InvalidOid))
Dave Cramer
On Tue, 14 Jul 2020 at 12:59, Tom Lane wrote:
> So I started looking through this seriously, and my first question
> is why do the docs and code keep saying that "base types" are sent
> in binary? Why not just "data"? Are there any cases where we
> don't use binary format, if the subscription r
On Tue, 14 Jul 2020 at 09:26, Daniel Gustafsson wrote:
> > On 13 Jul 2020, at 15:11, Dave Cramer wrote:
>
> I took another look at the updated version today. Since there now were
> some
> unused variables and (I believe) unnecessary checks (int size and
> endianness
&g
On Sat, 11 Jul 2020 at 10:20, Tom Lane wrote:
> Petr Jelinek writes:
> > On 11/07/2020 14:14, Dave Cramer wrote:
> >> So is there any point in having them as options then ?
>
> > I am guessing this is copied from pglogical, right? We have them there
> > becau
ctions.
>
will do
>
>
> BTW, while it's not the job of this patch to fix it, I find it quite
> distressing that we're apparently repeating the lookups of the type
> I/O functions for every row transferred.
>
> I'll set this back to WoA, but I concur with Daniel's opinion that
> it doesn't seem that far from committability.
>
Thanks for looking at this
Dave Cramer
On Tue, 7 Jul 2020 at 10:01, Daniel Gustafsson wrote:
> > On 7 Jul 2020, at 02:16, Dave Cramer wrote:
>
> > OK, rebased it down to 2 patches, attached.
>
> I took a look at this patchset today. The feature clearly seems like
> something
> which we'd benefit from
On Mon, 6 Jul 2020 at 09:35, Dave Cramer wrote:
>
>
> On Mon, 6 Jul 2020 at 09:03, Daniel Gustafsson wrote:
>
>> > On 6 Jul 2020, at 14:58, Dave Cramer wrote:
>>
>> > as far as rebase -i do what is advised here for squashing them. Just
>> one patch no
On Mon, 6 Jul 2020 at 09:03, Daniel Gustafsson wrote:
> > On 6 Jul 2020, at 14:58, Dave Cramer wrote:
>
> > as far as rebase -i do what is advised here for squashing them. Just one
> patch now ?
>
> One patch per logical change, if there are two disjoint changes in th
On Sun, 5 Jul 2020 at 17:28, Daniel Gustafsson wrote:
> > On 5 Jul 2020, at 23:11, Alvaro Herrera
> wrote:
> >
> > On 2020-Jul-05, Daniel Gustafsson wrote:
> >
> >>> On 2 Jul 2020, at 18:41, Dave Cramer wrote:
> >>>
> >>> rebased
rebased
Thanks,
Dave Cramer
On Wed, 1 Jul 2020 at 06:43, Dave Cramer wrote:
> Honestly I'm getting a little weary of fixing this up only to have the
> patch not get reviewed.
>
> Apparently it has no value so unless someone is willing to review it and
> get it committed I
This seems pretty strange:
create publication pub1 for all tables;
WARNING: wal_level is insufficient to publish logical changes
HINT: Set wal_level to logical before creating subscriptions.
Dave Cramer
Honestly I'm getting a little weary of fixing this up only to have the
patch not get reviewed.
Apparently it has no value so unless someone is willing to review it and
get it committed I'm just going to let it go.
Thanks,
Dave Cramer
On Wed, 1 Jul 2020 at 04:53, Daniel Gustafs
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
>
hackers who are used to the standard git convention.
>
While it is the default I expect that will change soon. Github is planning
on making main the default.
https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/
Many projects are moving from master to main.
I expect it will be less confusing than you think.
Dave Cramer
www.postgres.rocks
ms back in
> the tin now, I guess.
>
Is that documented ?
>
> It is still my opinion that we should prohibit a logical replication
> connection from being used to do physical replication. Horiguchi-san,
> Sawada-san and Masao-san are all of the same opinion. Dave Cramer (of
>
ications relying on the
> existing behavior, and that's also the point of Vladimir upthread.
>
I don't see this is a valid reason to keep doing something. If it is broken
then fix it.
Clients can deal with the change.
Dave Cramer
https://www.postgres.rocks
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 sta
On Fri, 3 Apr 2020 at 16:44, Dave Cramer wrote:
>
>
> On Fri, 3 Apr 2020 at 03:43, Petr Jelinek wrote:
>
>> Hi,
>>
>> On 08/03/2020 00:18, Dave Cramer wrote:
>> > On Fri, 6 Mar 2020 at 08:54, Petr Jelinek > > <mailto:p...@2ndquadrant.com>>
On Fri, 3 Apr 2020 at 03:43, Petr Jelinek wrote:
> 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 Tue, 17 Mar 2020 at 19:32, Dave Cramer wrote:
>
>
> On Tue, 17 Mar 2020 at 19:23, Bruce Momjian wrote:
>
>> On Tue, Mar 17, 2020 at 07:15:05PM -0400, Dave Cramer wrote:
>> > On Tue, 17 Mar 2020 at 16:47, Bruce Momjian wrote:
>> > Third, the idea t
is by altering the client_encoding setting. The JDBC
team considers this a failing of the COPY command and hopes to provide an
alternate means of specifying the encoding in the future, but for now there
is this URL parameter. Enable this only if you need to override the client
encoding when doing a copy.*
Dave Cramer
www.postgres.rocks
On Tue, 17 Mar 2020 at 19:23, Bruce Momjian wrote:
> On Tue, Mar 17, 2020 at 07:15:05PM -0400, Dave Cramer wrote:
> > On Tue, 17 Mar 2020 at 16:47, Bruce Momjian wrote:
> > Third, the idea that individual interfaces, e.g. JDBC, should throw
> an
> > error in th
On Tue, 17 Mar 2020 at 16:47, Bruce Momjian wrote:
> On Fri, Mar 6, 2020 at 01:12:10PM -0500, Robert Haas wrote:
> > On Fri, Mar 6, 2020 at 11:55 AM Dave Cramer
> wrote:
> > > There have been some arguments that the client can fix this easily.
> > >
> >
On Fri, 6 Mar 2020 at 08:54, Petr Jelinek wrote:
> Hi Dave,
>
> On 29/02/2020 18:44, Dave Cramer wrote:
> >
> >
> > rebased and removed the catversion bump.
>
> Looked into this and it generally seems okay, but I do have one gripe here:
>
> > +
On Thu, 27 Feb 2020 at 08:30, Dave Cramer wrote:
>
>
> On Thu, 27 Feb 2020 at 07:44, Dave Cramer
> wrote:
>
>>
>>
>>
>> On Wed, 26 Feb 2020 at 16:57, Vik Fearing
>> wrote:
>>
>>> On 26/02/2020 22:22, Tom Lane wrote:
>>> &g
On Fri, 28 Feb 2020 at 18:34, Tom Lane wrote:
> Dave Cramer writes:
> > Rebased against head
>
> The cfbot's failing to apply this [1]. It looks like the reason is only
> that you included a catversion bump in what you submitted. Protocol is to
> *not* do that in s
On Thu, 27 Feb 2020 at 07:44, Dave Cramer wrote:
>
>
>
> On Wed, 26 Feb 2020 at 16:57, Vik Fearing wrote:
>
>> On 26/02/2020 22:22, Tom Lane wrote:
>> > Dave Cramer writes:
>> >> OK, here is a patch that actually doesn't leave the transaction in
On Wed, 26 Feb 2020 at 16:57, Vik Fearing wrote:
> On 26/02/2020 22:22, Tom Lane wrote:
> > Dave Cramer writes:
> >> OK, here is a patch that actually doesn't leave the transaction in a
> failed
> >> state but emits the error and rolls back the transaction.
&g
On Wed, 26 Feb 2020 at 16:57, Vik Fearing wrote:
> On 26/02/2020 22:22, Tom Lane wrote:
> > Dave Cramer writes:
> >> OK, here is a patch that actually doesn't leave the transaction in a
> failed
> >> state but emits the error and rolls back the transaction.
&g
On Wed, 26 Feb 2020 at 13:46, Vik Fearing wrote:
> On 25/02/2020 12:11, Laurenz Albe wrote:
> > On Tue, 2020-02-25 at 13:25 +0530, Robert Haas wrote:
> >> On Tue, Feb 25, 2020 at 12:47 PM Vladimir Sitnikov
> >> wrote:
> >>> Noone suggested that "commit leaves the session in a transaction
> state
oint in that it's not nearly as bad as
> I thought you were suggesting (to treat commit as bad statement) but
> the transaction would still terminate. Still, this is very sensitive
> stuff, do you think most common connection poolers would continue to
> work after making this change?
>
Don't see why not. All that happens is that an error message is emitted by
the server on commit instead of silently rolling back
Dave Cramer
https://www.postgres.rocks
//ignore this exception
}
conn.commit();
} catch ( SQLException ex ) {
ex.printStackTrace();
conn.rollback();
}
conn.close();
Dave Cramer
http://www.postgres.rocks
>
eded to be repaired. Seems to me it would be much easier if
everything failed.
> You may think that
> nobody is doing this sort of thing, but I think people are, and that
> they will come after us with pitchforks if we break it.
>
So the argument here is that we don't want to annoy some percentage of the
population by doing the right thing ?
Dave Cramer
www.postgres.rocks
On Mon, 24 Feb 2020 at 07:25, Robert Haas wrote:
> On Mon, Feb 24, 2020 at 7:29 AM Dave Cramer
> wrote:
> > Well the driver really isn't in the business of changing the semantics
> of the server.
>
> I mean, I just can't agree with that way of characterizing it. I
rspective, is not that the driver behavior in the face of errors
> can't be made correct with the existing semantics, but that the driver
> would find it more convenient if PostgreSQL reported those errors in a
> somewhat different way. I think that's a fair criticism, but I don't
> think it's a sufficient reason to change the behavior.
>
I think the fact that this is a violation of the SQL SPEC lends
considerable credence to the argument for changing the behaviour.
Since this can lead to losing a transaction I think there is even more
reason to look at changing the behaviour.
Dave Cramer
www.postgres.rocks
On Sun, 23 Feb 2020 at 00:41, Shay Rojansky wrote:
>
>
> On Fri, 14 Feb 2020 at 14:37, Robert Haas wrote:
>>
>>> On Fri, Feb 14, 2020 at 2:08 PM Dave Cramer
>>> wrote:
>>> > Well now you are asking the driver to re-interpret the results in a
>&g
On Mon, 17 Feb 2020 at 13:02, Haumacher, Bernhard wrote:
> Am 14.02.2020 um 20:36 schrieb Robert Haas:
> > On Fri, Feb 14, 2020 at 2:08 PM Dave Cramer
> wrote:
> >> Well now you are asking the driver to re-interpret the results in a
> different way than the server whic
Hi,
Feel free to send out the email blast.
There are a number of other channels. postgres slack, postgres mailing
lists, @PostgreSQL Hackers , twitter
with Postgres tag
Cheers,
Dave Cramer
On Sat, 15 Feb 2020 at 19:44, 'Meetup Messages' via Meetup <
mee...@postgre
On Fri, 14 Feb 2020 at 15:19, Alvaro Herrera
wrote:
> On 2020-Feb-14, Dave Cramer wrote:
>
> > I offered to make the behaviour in the JDBC driver dependent on a
> > configuration parameter
>
> Do you mean "if con.commit() results in a rollback, then an exception is
&
On Fri, 14 Feb 2020 at 15:07, Tom Lane wrote:
> Dave Cramer writes:
> > On Fri, 14 Feb 2020 at 14:37, Robert Haas wrote:
> >> I'm not trying to deny that you might find some other server behavior
> >> more convenient. You might. And, to Vik's original p
On Fri, 14 Feb 2020 at 14:37, Robert Haas wrote:
> On Fri, Feb 14, 2020 at 2:08 PM Dave Cramer
> wrote:
> > Well now you are asking the driver to re-interpret the results in a
> different way than the server which is not what we tend to do.
> >
> > The server throws
On Fri, 14 Feb 2020 at 13:29, Robert Haas wrote:
> On Fri, Feb 14, 2020 at 1:04 PM Dave Cramer
> wrote:
> > Thing is that con.commit() DOESN'T return a status code, nor does it
> throw an exception as we silently ROLLBACK here.
>
> Why not? There's nothing keepi
as depending on how the transaction
failed we seem to do different things
In Tom's example we do issue a warning and say there is no transaction
running. I would guess we silently rolled back earlier.
In my example we don't issue the warning we just roll back.
I do agree with Tom that changing this behaviour at this point would make
things worse for more people than it would help so I am not advocating
throwing an error here.
I would however advocate for consistently doing the same thing with failed
transactions
Dave Cramer
www.postgres.rocks
On Tue, 11 Feb 2020 at 17:35, Tom Lane wrote:
> Vik Fearing writes:
> > There is a current discussion off-list about what should happen when a
> > COMMIT is issued for a transaction that cannot be committed for whatever
> > reason. PostgreSQL returns ROLLBACK as command tag but otherwise
> succ
On Mon, 2 Dec 2019 at 14:35, Dave Cramer wrote:
> Rebased against head
>
> Dave Cramer
>
>
> On Sat, 30 Nov 2019 at 20:48, Michael Paquier wrote:
>
>> Hi,
>>
>> On Mon, Nov 11, 2019 at 03:24:59PM -0500, Dave Cramer wrote:
>> > Attached,
>
ose two things, then it's possible
> to create a sandbox which the end client cannot escape but which the
> pooler can escape easily.
>
So where are we on this patch ? AFAICT using _pq is a protocol level option.
Dave Cramer
da...@postgresintl.com
www.postgresintl.com
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 Thu, 19 Dec 2019 at 11:59, Dave Cramer wrote:
> The publication exists but for some reason the function can't find it
>
> SELECT * FROM pg_logical_slot_get_binary_changes('debezium', NULL,
> NULL,'proto_version','1','publicat
x27;publication_names','dbz_publication');
ERROR: publication "dbz_publication" does not exist
CONTEXT: slot "debezium", output plugin "pgoutput", in the change
callback, associated LSN 0/307D8E8
Dave Cramer
> Then, URLs pointing to that page (such as Dave evidently has bookmarked)
> would break entirely, which doesn't seem like an improvement.
>
it was linked to in a bug report.
Dave Cramer
On Tue, 17 Dec 2019 at 06:53, Magnus Hagander wrote:
> On Tue, Dec 17, 2019 at 12:43 PM Dave Cramer wrote:
>
>> While following an old link to
>> https://www.postgresql.org/docs/10/auth-methods.html
>>
>> I see a list of links to authentication methods. However
While following an old link to
https://www.postgresql.org/docs/10/auth-methods.html
I see a list of links to authentication methods. However:
When I hit the current version
https://www.postgresql.org/docs/current/auth-methods.html
There are absolutely no links...
Dave Cramer
Rebased against head
Dave Cramer
On Sat, 30 Nov 2019 at 20:48, Michael Paquier wrote:
> Hi,
>
> On Mon, Nov 11, 2019 at 03:24:59PM -0500, Dave Cramer wrote:
> > Attached,
>
> The latest patch set does not apply correctly. Could you send a
> rebase please? I am mov
On Mon, 11 Nov 2019 at 15:17, Alvaro Herrera
wrote:
> On 2019-Nov-11, Dave Cramer wrote:
>
> > Following 2 patches address Dmitry's concern and check for compatibility.
>
> Please resend the whole patchset, so that the patch tester can verify
> the series. (
On Mon, 11 Nov 2019 at 12:07, Dave Cramer wrote:
>
>
> On Mon, 11 Nov 2019 at 12:04, Alvaro Herrera
> wrote:
>
>> On 2019-Nov-11, Dave Cramer wrote:
>>
>> > Previously someone mentioned that we need to confirm whether the two
>> > servers are compat
On Mon, 11 Nov 2019 at 12:04, Alvaro Herrera
wrote:
> On 2019-Nov-11, Dave Cramer wrote:
>
> > Previously someone mentioned that we need to confirm whether the two
> > servers are compatible for binary or not.
> >
> > Checking to make sure the two servers have th
On Fri, 8 Nov 2019 at 11:20, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Tue, Nov 05, 2019 at 07:16:10AM -0500, Dave Cramer wrote:
> >
> > See attached
>
> --- a/src/backend/replication/logical/worker.c
> +++ b/src/backend/replication/logical/
On Sun, 3 Nov 2019 at 19:40, Thomas Munro wrote:
> On Wed, Oct 16, 2019 at 6:49 PM Dave Cramer wrote:
> > Here's an updated patch that addresses some of Andres' concerns
> specifically does not use strtok.
>
> Hi Dave,
>
> I think you need to s/strncasecmp/pg_
On Sun, 3 Nov 2019 at 21:47, Thomas Munro wrote:
> On Thu, Oct 31, 2019 at 3:03 AM Dave Cramer wrote:
> > Ok, I've rebased and reverted logicalrep_read_insert
>
> Hi Dave,
>
> From the code style police (actually just from cfbot, which is set up
> to complain about
On Sun, 27 Oct 2019 at 11:00, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Mon, Jun 17, 2019 at 10:29:26AM -0400, Dave Cramer wrote:
> > > Which is what I have done. Thanks
> > >
> > > I've attached both patches for comments.
> > >
On Sat, 12 Oct 2019 at 05:05, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-10-11 16:30:17 -0400, Robert Haas wrote:
> >> But, if it does need to be changed, it seems like a terrible idea to
> >> allow it to be done via SQL. Otherwise, the user can break the driver
> >> by using SQL to set
On Fri, 11 Oct 2019 at 16:41, Chapman Flack wrote:
> On 10/11/19 4:30 PM, Robert Haas wrote:
>
> > But, if it does need to be changed, it seems like a terrible idea to
> > allow it to be done via SQL. Otherwise, the user can break the driver
> > by using SQL to set the list to something that the
On Thu, 10 Oct 2019 at 12:05, Andres Freund wrote:
> Hi,
>
> On 2019-10-09 16:29:07 -0400, Dave Cramer wrote:
> > I've added functionality into libpq to be able to set this STARTUP
> > parameter as well as changed it to _pq_.report.
> > Still need to document th
On Wed, 9 Oct 2019 at 08:15, Dave Cramer wrote:
>
>
> On Tue, 8 Oct 2019 at 11:57, Craig Ringer wrote:
>
>> On Thu, 11 Jul 2019 at 04:34, Tom Lane wrote:
>>
>>> Robert Haas writes:
>>> > On Wed, Jul 10, 2019 at 9:59 AM Dave Cramer wrote:
>&
201 - 300 of 392 matches
Mail list logo
