Mark Dilger writes:
>> On Feb 20, 2020, at 8:30 PM, Tom Lane wrote:
>> This idea doesn't fix every possible problem. For instance, if you
>> have a plperlu function that wants to open a bunch of files, I don't
>> see any easy way to ensure we release VFDs to make that possible.
>> But it's sure
On 24/02/2020 18:37, David Fetter wrote:
> If we'd done this from a clean sheet of paper, it would have been the
> right decision. We're not there, and haven't been for decades.
OTOH, it's never too late to do the right thing.
--
Vik Fearing
On Sun, Feb 23, 2020 at 7:59 PM Dave Cramer wrote:
>
> 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
čt 20. 2. 2020 v 20:15 odesílatel Pavel Stehule
napsal:
>
>
> st 19. 2. 2020 v 8:09 odesílatel Amit Langote
> napsal:
>
>> On Wed, Feb 19, 2020 at 3:56 PM Amit Langote
>> wrote:
>> > On Wed, Feb 19, 2020 at 3:38 PM Pavel Stehule
>> wrote:
>> > > st 19. 2. 2020 v 7:30 odesílatel Pavel Stehule
> On Feb 20, 2020, at 8:30 PM, Tom Lane wrote:
>
> This idea doesn't fix every possible problem. For instance, if you
> have a plperlu function that wants to open a bunch of files, I don't
> see any easy way to ensure we release VFDs to make that possible.
> But it's sure an improvement on
Hi,
On 2020-02-24 10:29:51 -0800, Mark Dilger wrote:
> > On Feb 20, 2020, at 8:30 PM, Tom Lane wrote:
> >
> > This idea doesn't fix every possible problem. For instance, if you
> > have a plperlu function that wants to open a bunch of files, I don't
> > see any easy way to ensure we release
On 2020-Feb-21, Peter Eisentraut wrote:
> Allow running src/tools/msvc/mkvcbuild.pl under not Windows
>
> This to allow verifying the MSVC build file generation without having
> to have Windows.
I suggest that src/tools/msvc/README should indicate how to use this; I
don't think it's completely
Alvaro Herrera writes:
> On 2020-Feb-24, Tom Lane wrote:
>> We could also consider a HINT, along the lines of "Raise the server's
>> max_files_per_process and/or \"ulimit -n\" limits." This again has
>> the ambiguity about which server, and it also seems dangerously
>> platform-specific.
>
po 24. 2. 2020 v 18:56 odesílatel Pavel Stehule
napsal:
>
>
> po 24. 2. 2020 v 18:47 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> čt 20. 2. 2020 v 20:15 odesílatel Pavel Stehule
>> napsal:
>>
>>>
>>>
>>> st 19. 2. 2020 v 8:09 odesílatel Amit Langote
>>> napsal:
>>>
On Wed, Feb 19, 2020
I wrote:
> Alvaro Herrera writes:
>> As for the platform dependencies, I see two main options: make the hint
>> platform-specific (i.e have #ifdef branches per platform) or make it
>> even more generic, such as "file descriptor limits".
> I thought about platform-specific messages, but it's not
On 2020-Feb-24, Tom Lane wrote:
> I wrote:
> > I thought about platform-specific messages, but it's not clear to me
> > whether our translation infrastructure will find messages that are
> > inside #ifdefs ... anyone know?
>
> Oh, but of course it does. So let's do
>
>
On Mon, Feb 24, 2020 at 06:04:28PM +0530, Robert Haas wrote:
> On Mon, Feb 24, 2020 at 1:56 PM Shay Rojansky wrote:
> > As Dave wrote, the problem here isn't with the driver, but with framework
> > or user-code which swallows the initial exception and allows code to
> > continue to the commit.
On Sat, Feb 22, 2020 at 9:09 PM Michail Nikolaev
wrote:
>
> I am not sure it is good idea to mix both patches because it adds some
> confusion and makes it harder to merge each.
> Maybe is it better to update current patch the way to reuse some
> function later in [1]?
>
The patch was originaly
po 24. 2. 2020 v 18:47 odesílatel Pavel Stehule
napsal:
>
>
> čt 20. 2. 2020 v 20:15 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> st 19. 2. 2020 v 8:09 odesílatel Amit Langote
>> napsal:
>>
>>> On Wed, Feb 19, 2020 at 3:56 PM Amit Langote
>>> wrote:
>>> > On Wed, Feb 19, 2020 at 3:38 PM
Hi,
On 2020-02-24 16:14:53 -0300, Alvaro Herrera wrote:
> But the C runtime does:
> https://docs.microsoft.com/en-us/cpp/c-runtime-library/file-handling?view=vs-2019
> I suppose we do use the C runtime. There's a reference to
> _setmaxstdio() being able to raise the limit from the default of 512
Andres Freund writes:
> On 2020-02-24 16:14:53 -0300, Alvaro Herrera wrote:
>> I suppose we do use the C runtime. There's a reference to
>> _setmaxstdio() being able to raise the limit from the default of 512 to
>> up to 8192 open files. We don't currently invoke that.
>>
On Mon, Feb 24, 2020 at 06:40:16PM +0100, Vik Fearing wrote:
> On 24/02/2020 18:37, David Fetter wrote:
>
> > If we'd done this from a clean sheet of paper, it would have been the
> > right decision. We're not there, and haven't been for decades.
>
> OTOH, it's never too late to do the right
On 2020-Feb-19, Amit Langote wrote:
> Or:
>
> * However, if our parent is a partition itself, there might be
> * internal triggers that must not be skipped. For example, triggers
> * on the parent that were in turn cloned from its own parent are
> * marked
Alvaro Herrera writes:
> On 2020-Feb-24, Tom Lane wrote:
>> I don't think there's much point in telling Windows users about
>> _setmaxstdio() here.
> Yeah, telling users to _setmaxstdio() themselves is useless, because
> they can't do it; that's something *we* should do. I think the 512
> limit
I wrote:
> [ unicode-escapes-with-other-server-encodings-2.patch ]
I see this patch got sideswiped by the recent refactoring of JSON
lexing. Here's an attempt at fixing it up. Since the frontend
code isn't going to have access to encoding conversion facilities,
this creates a difference between
On 2020-Feb-24, Tom Lane wrote:
> We could also consider a HINT, along the lines of "Raise the server's
> max_files_per_process and/or \"ulimit -n\" limits." This again has
> the ambiguity about which server, and it also seems dangerously
> platform-specific.
Maybe talk about "the local server"
On 2020-Feb-24, Tom Lane wrote:
> Alvaro Herrera writes:
> > Then again, that would be akin to setrlimit() on Linux. Maybe we can
> > consider that a separate GUC, in a separate patch, with a
> > platform-specific default value that just corresponds to the OS's
> > default, and the user can
At Fri, 21 Feb 2020 14:02:40 +0100, Juan José Santamaría Flecha
wrote in
> After commit 9573384 this patch no longer applies, but with a trivial
> rebase it fixes the issue.
Thanks! This is the rebased version. I'll register this to the next CF.
regards.
--
Kyotaro Horiguchi
NTT Open Source
On Mon, Feb 24, 2020 at 03:29:03PM -0800, Andres Freund wrote:
> I do find it a bit odd that you essentially duplicated the existing
> comment in a different phrasing. What's the point?
A direct reference to catalog tuples is added for each code path
calling log_heap_new_cid(), so that was more
Hi!
Thank you for your review. The revised version is attached.
On Wed, Feb 19, 2020 at 1:16 AM Peter Geoghegan wrote:
> On Tue, Feb 18, 2020 at 2:16 AM Alexander Korotkov
> wrote:
> > > Don't need the "!P_ISLEAF()" here.
> >
> > Why don't I need. bt_downlink_connectivity_check() checks one
Hi Michael,
On 2/24/20 7:26 AM, Michael Paquier wrote:
On Sun, Feb 23, 2020 at 04:08:58PM +0900, Michael Paquier wrote:
Good idea. Let's do things as you suggest.
Applied and back-patched this one down to 11.
FWIW, we took a slightly narrower approach to this issue in the
pgBackRest
On Thu, 20 Feb 2020 at 16:16, Masahiko Sawada
wrote:
>
> On Wed, 19 Feb 2020 at 09:29, Cary Huang wrote:
> >
> > Hi
> >
> > I have tried the attached kms_v3 patch and have some comments:
> >
> > 1) In the comments, I think you meant hmac + iv + encrypted data instead of
> > iv + hmac +
Merlin>My biggest sense of alarm with the proposed change is that it could
Merlin>leave applications in a state where the transaction is hanging there
How come?
The spec says commit ends the transaction.
Can you please clarify where the proposed change leaves a hanging
transaction?
Just in case,
On Mon, Feb 24, 2020 at 4:06 PM Vladimir Sitnikov
wrote:
>
> Merlin>My biggest sense of alarm with the proposed change is that it could
> Merlin>leave applications in a state where the transaction is hanging there
>
> How come?
> The spec says commit ends the transaction.
> Can you please clarify
> On 23 Feb 2020, at 08:27, Michael Paquier wrote:
>
> On Sat, Feb 22, 2020 at 10:22:27PM +0100, Daniel Gustafsson wrote:
>> Turns out that we in heap_multi_insert missed to call log_heap_new_cid for
>> the
>> first tuple inserted, we only do it in the loop body for the subsequent ones.
>> With
On Mon, 24 Feb 2020 at 17:59, Merlin Moncure wrote:
> On Mon, Feb 24, 2020 at 4:06 PM Vladimir Sitnikov
> wrote:
> >
> > Merlin>My biggest sense of alarm with the proposed change is that it
> could
> > Merlin>leave applications in a state where the transaction is hanging
> there
> >
> > How
Hi Alvaro,
On Tue, Feb 25, 2020 at 3:58 AM Alvaro Herrera wrote:
> On 2020-Feb-19, Amit Langote wrote:
>
> > Or:
> >
> > * However, if our parent is a partition itself, there might be
> > * internal triggers that must not be skipped. For example,
> > triggers
> > *
Alvaro Herrera writes:
> On 2020-Feb-24, Tom Lane wrote:
>> Why not just drive it off max_files_per_process? On Unix, that
>> largely exists to override the ulimit setting anyway. With no
>> comparable knob on a Windows system, we might as well just say
>> that's what you set.
> That makes
At Sat, 22 Feb 2020 21:12:20 -0800, Noah Misch wrote in
> On Fri, Feb 21, 2020 at 04:49:59PM +0900, Kyotaro Horiguchi wrote:
> > At Wed, 19 Feb 2020 17:29:08 +0900 (JST), Kyotaro Horiguchi
> > wrote in
> > > At Tue, 18 Feb 2020 23:44:52 -0800, Noah Misch wrote
> > > in
> > > > - When
On 12/02/2020 00:27, Tom Lane wrote:
> Vik Fearing writes:
>> On 11/02/2020 23:35, Tom Lane wrote:
>>> So I assume you're imagining that that would leave us still in
>>> transaction-aborted state, and the session is basically dead in
>>> the water until the user thinks to issue ROLLBACK instead?
On 2020-02-22 11:02:16 -0800, Jeff Davis wrote:
> On Sat, 2020-02-22 at 10:00 -0800, Andres Freund wrote:
> > Both patches, or just 0013? Seems the earlier one might make the
> > addition of the opcodes you add less verbose?
>
> Just 0013, thank you. 0008 looks like it will simplify things.
Hi,
On 2020-02-23 16:27:57 +0900, Michael Paquier wrote:
> On Sat, Feb 22, 2020 at 10:22:27PM +0100, Daniel Gustafsson wrote:
> > Turns out that we in heap_multi_insert missed to call log_heap_new_cid for
> > the
> > first tuple inserted, we only do it in the loop body for the subsequent
> >
On Mon, Feb 24, 2020 at 05:03:07PM +0100, Peter Eisentraut wrote:
> committed
Thanks!
--
Michael
signature.asc
Description: PGP signature
On Mon, Feb 24, 2020 at 01:11:10PM +0100, Bernd Helmle wrote:
> The other makes scan_directories() complicated to read and special
> cases just a single directory in an otherwise more or less generic
> function. E.g. it makes me uncomfortable if we get a pg_tblspc
> somewhere else than PGDATA (if
Robert>Now, of course, it's also true that if what the server does makes
Robert>users sad, maybe the server should do something different
The server makes users sad as it reports the same end result (=="commit
failed") differently.
Sometimes the server produces ERROR, and sometimes the server
I'm trying to figure out what's specific about RS_EPHEMERAL and RS_TEMPORARY
slot kinds. The following comment (see definition of the
ReplicationSlotPersistency enumeration) tells when each kind is dropped
* Slots marked as PERSISTENT are crash-safe and will not be dropped when
* released.
On Tue, Feb 25, 2020 at 12:47 PM Vladimir Sitnikov
wrote:
> Noone suggested that "commit leaves the session in a transaction state".
> Of course, every commit should terminate the transaction.
> However, if a commit fails (for any reason), it should produce the relevant
> ERROR that explains
On Fri, Feb 14, 2020 at 11:59 AM, 王胜利 wrote:
>I am glad to know you are working on PG accumulated statistics
> feature, and I am interested on it.
>I see these two patch file you made, can you let me know which branch
> of PG code based?
>
>when I use this:
On Sat, Feb 22, 2020 at 10:53:35PM +0100, Tomas Vondra wrote:
> 1) explain.c API
>
> The functions in explain.c (even the static ones) follow the convention
> that the last parameter is (ExplainState *es). I think we should stick
> to this, so the new parameters should be added before it.
I
On 2020-02-24 12:21, Kuntal Ghosh wrote:
I've reproduced the issue on head. And, the patch seems to solve the
problem. The patch looks good to me. But, I've a small doubt regarding
the changes in test_decoding regression file.
diff --git a/contrib/test_decoding/sql/toast.sql
On Mon, Feb 24, 2020 at 11:19 PM Tom Lane wrote:
> I see this patch got sideswiped by the recent refactoring of JSON
> lexing. Here's an attempt at fixing it up. Since the frontend
> code isn't going to have access to encoding conversion facilities,
> this creates a difference between frontend
On Sat, Feb 22, 2020 at 10:31 PM Tom Lane wrote:
> I'm still going to object to it, on the grounds that
>
> (1) it's exposing an implementation detail that clients should not be
> concerned with, and that we might change in future. The name isn't
> even well chosen --- if the argument is that
On Tue, Feb 25, 2020 at 10:14:10AM +0900, Kyotaro Horiguchi wrote:
> At Fri, 21 Feb 2020 14:02:40 +0100, Juan José Santamaría Flecha
> wrote in
> > After commit 9573384 this patch no longer applies, but with a trivial
> > rebase it fixes the issue.
>
> Thanks! This is the rebased version. I'll
At Tue, 25 Feb 2020 14:02:04 +0900, Michael Paquier wrote
in
> On Tue, Feb 25, 2020 at 10:14:10AM +0900, Kyotaro Horiguchi wrote:
> > At Fri, 21 Feb 2020 14:02:40 +0100, Juan José Santamaría Flecha
> > wrote in
> > > After commit 9573384 this patch no longer applies, but with a trivial
> > >
> First, to repeat what I said before, the COMMIT only returns a ROLLBACK
command tag if there's been a previous ERROR. So, if you haven't ignored
the prior ERROR, you should be fine. [...]
> I am really struggling to see why this is anything but a bug in the JDBC
driver
As Dave wrote, the
This removes another relic from the old nmake-based Windows build.
version_stamp.pl put version number information into win32ver.rc. But
win32ver.rc already gets other version number information from the
preprocessor at build time, so it would make more sense if all version
number information
On 24/02/2020 02:31, Robert Haas wrote:
> I am really struggling to see why this is anything but a bug in the
> JDBC driver.
I can follow your logic for it being a bug in the JDBC driver, but
"anything but"? No, this is (also) an undocumented violation of SQL.
--
Vik Fearing
Hi Thomas!
Thanks for looking into this! I’ll fix your notices asap.
> On 24 февр. 2020 г., at 01:58, Thomas Munro wrote:
>
> On Thu, Feb 20, 2020 at 10:14 AM Thomas Munro wrote:
>> 1. We expect floats to be in IEEE format, and the sort order of IEEE
>> floats is mostly correlated to the
On Sat, Feb 22, 2020 at 4:05 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Fri, Feb 21, 2020 at 6:21 PM Michael Leonhard
> wrote:
>
>> How about making the Java client library accept the same connection
>> strings as psql and other command-line tools? [...]
>>
>
> That falls
On Mon, Feb 24, 2020 at 8:20 PM Tom Lane wrote:
> Aditya Toshniwal writes:
> > On Mon, Feb 24, 2020 at 12:46 PM Andres Freund
> wrote:
> >> This isn't reproducible here. Are you sure that you're running on a
> >> clean installation?
>
> > Yes I did a fresh installation using installer provided
Hi
I added this patch to a commitfest
https://commitfest.postgresql.org/27/2467/
It is very interesting speedup and it is in good direction to JIT
expressions
Pavel
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. It
seems clear enough that the driver not only should not change the
semantics of the
On Mon, Feb 24, 2020 at 7:01 AM Justin Pryzby wrote:
> This links to a long thread, from which I've tried to quote some of the
> most important mails, below.
> https://wiki.postgresql.org/wiki/PostgreSQL_12_Open_Items#Won.27t_Fix
>
> I wondered if there's an effort to pursue a resolution for v13
On Mon, 24 Feb 2020 at 07:34, Robert Haas wrote:
> On Mon, Feb 24, 2020 at 1:56 PM Shay Rojansky wrote:
> > As Dave wrote, the problem here isn't with the driver, but with
> framework or user-code which swallows the initial exception and allows code
> to continue to the commit. Npgsql (and I'm
If we did change the server behavior, it seems unlikely that
> every driver would adjust their behavior to the new server behavior
> all at once and that they would all get it right while also all
> preserving backward compatibility with current releases in case a
> newer driver is used with an
Hi All,
I observe a different behavior in "temporary table" and "global temporary
table".
Not sure if it is expected?
postgres=# create global temporary table parent1(a int) on commit delete
rows;
CREATE TABLE
postgres=# create global temporary table child1() inherits (parent1);
CREATE TABLE
On 24.02.2020 05:08, Hubert Zhang wrote:
Hi
On Sat, Feb 22, 2020 at 12:58 AM Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
On 12.02.2020 13:12, Hubert Zhang wrote:
On Tue, Feb 11, 2020 at 1:20 AM Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
On Fri, Feb 14, 2020 at 9:03 PM Robert Haas wrote:
> On Thu, Feb 13, 2020 at 11:26 AM Mark Dilger
> wrote:
> > I have made these changes and rebased Robert’s patches but otherwise
> > changed nothing. Here they are:
>
> Thanks. Anyone else have comments? I think this is pretty
>
On Fri, 2020-02-21 at 15:36 +0900, Michael Paquier wrote:
> We don't do that for the normal directory scan path, so it does not
> strike me as a good idea on consistency ground. As a whole, I don't
> see much point in having a separate routine which is just roughly a
> duplicate of
On Mon, Feb 24, 2020 at 1:31 PM Vik Fearing wrote:
> On 24/02/2020 02:31, Robert Haas wrote:
> > I am really struggling to see why this is anything but a bug in the
> > JDBC driver.
>
> I can follow your logic for it being a bug in the JDBC driver, but
> "anything but"? No, this is (also) an
Hi All:
Here is the updated patch. It used some functions from
query_is_distinct_for.
I check the query's distinctness in create_distinct_paths, if it is
distinct already,
it will not generate the paths for that. so at last the query tree is not
untouched.
Please see if you have any comments.
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. It
> seems clear enough that the
On Sun, Feb 23, 2020 at 04:08:58PM +0900, Michael Paquier wrote:
> Good idea. Let's do things as you suggest.
Applied and back-patched this one down to 11.
--
Michael
signature.asc
Description: PGP signature
On Mon, Feb 24, 2020 at 1:56 PM Shay Rojansky wrote:
> As Dave wrote, the problem here isn't with the driver, but with framework or
> user-code which swallows the initial exception and allows code to continue to
> the commit. Npgsql (and I'm sure the JDBC driver too) does surface PostgreSQL
>
On Wed, Feb 12, 2020 at 12:36 AM Ashutosh Bapat <
ashutosh.bapat@gmail.com> wrote:
>
>
> On Tue, Feb 11, 2020 at 8:27 AM Andy Fan wrote:
>
>>
>>
>> On Tue, Feb 11, 2020 at 12:22 AM Ashutosh Bapat <
>> ashutosh.bapat@gmail.com> wrote:
>>
>>>
>>>
[PATCH] Erase the distinctClause
Hi Konstantin,
I have added you as a collaborator on github. Please accepted and try again.
I think non collaborator could also open pull requests.
On Mon, Feb 24, 2020 at 8:02 PM Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
>
>
> On 24.02.2020 05:08, Hubert Zhang wrote:
>
> Hi
>
> On
>> If we think the current *user-visible* behavior is problematic (commit
on failed transaction completes without throwing), then the only remaining
question is where this behavior should be fixed - at the server or at the
driver. As I wrote above, from the user's perspective it makes no
This is a change to make the bitmap of updated columns available to a
trigger in TriggerData. This is the same idea as was recently done to
generated columns [0]: Generic triggers such as tsvector_update_trigger
can use this information to skip work if the columns they are interested
in
Hello Peter,
On Mon, Feb 24, 2020 at 12:59 PM Peter Eisentraut
wrote:
>
> On 2020-01-06 13:32, Peter Eisentraut wrote:
> > Attached is a patch that attempts to fix this by propagating the storage
> > change to existing indexes. This triggers a few regression test
> > failures (going from no
On Thu, Feb 20, 2020 at 8:06 AM Andres Freund wrote:
>
> Hi,
>
> On 2020-02-19 11:12:18 +0530, Amit Kapila wrote:
> > I think till we know the real need for changing group locking, going
> > in the direction of what Tom suggested to use an array of LWLocks [1]
> > to address the problems in hand
On Fri, Feb 21, 2020 at 9:10 PM 曾文旌(义从) wrote:
> Hi,
> I have started testing the "Global temporary table" feature,
> That's great, I see hope.
> from "gtt_v11-pg13.patch". Below is my findings:
>
> -- session 1:
> postgres=# create global temporary table gtt1(a int);
> CREATE TABLE
>
> --
To summarize the current state of parallel grouping sets, we now have
two available implementations for it.
1) Each worker performs an aggregation step, producing a partial result
for each group of which that process is aware. Then the partial results
are gathered to the leader, which then
po 24. 2. 2020 v 14:34 odesílatel Prabhat Sahu <
prabhat.s...@enterprisedb.com> napsal:
> Hi All,
>
> I observe a different behavior in "temporary table" and "global temporary
> table".
> Not sure if it is expected?
>
> postgres=# create global temporary table parent1(a int) on commit delete
>
Thomas Munro writes:
> I suppose there may be users who have set ulimit -n high enough to
> support an FDW workload that connects to very many hosts, who will now
> need to set max_files_per_process higher to avoid the new error now
> that we're doing this accounting. That doesn't seem to be a
> 2020年2月24日 下午9:34，Prabhat Sahu 写道：
>
> Hi All,
>
> I observe a different behavior in "temporary table" and "global temporary
> table".
> Not sure if it is expected?
>
> postgres=# create global temporary table parent1(a int) on commit delete
> rows;
> CREATE TABLE
> postgres=# create
Aditya Toshniwal writes:
> On Mon, Feb 24, 2020 at 12:46 PM Andres Freund wrote:
>> This isn't reproducible here. Are you sure that you're running on a
>> clean installation?
> Yes I did a fresh installation using installer provided here -
> https://www.enterprisedb.com/downloads/postgresql
On 2020-02-21 05:18, Michael Paquier wrote:
On Thu, Feb 20, 2020 at 10:10:11AM +0100, Peter Eisentraut wrote:
OK, added in new patch.
Thanks, that looks good.
committed
The frontends do neither right now, or at least the error handling is very
inconsistent and inscrutable. It would be
>do you think most common connection poolers would continue to
>work after making this change?
Of course, they should.
There are existing cases when commit responds with an error: deferrable
constraints.
There's nothing new except it is suggested to make the behavior of
commit/prepare failure
On Mon, Feb 24, 2020 at 6:40 PM Dave Cramer wrote:
> Fair enough. What I meant to say was that the driver isn't in the business of
> providing different semantics than the server provides.
Still don't agree. The server doesn't make any decision about what
semantics the driver has to provide.
84 matches
Mail list logo
