Thank all of you for your great insight!
On Sat, Nov 21, 2020 at 9:04 AM Peter Geoghegan wrote:
> On Fri, Nov 20, 2020 at 3:04 PM Andreas Karlsson
> wrote:
> > I am sadly not familiar enough with Oracle or have access to any Oracle
> > license so I cannot comment on how Oracle have implemented
Fixed patch attached, after new introduced conflicts.
Vik, can you add it to the next commitfest, to be able to test it.
Also, all tests from Oliver Ford's old patch also passed successfully.
На пт, 13.11.2020 г. в 0:44 ч. Vik Fearing написа:
> On 11/12/20 11:35 PM, Krasiyan Andreev wrote:
> > H
On Fri, Nov 20, 2020 at 03:04:57PM +0530, Bharath Rupireddy wrote:
> Thanks! Attaching the patch. Please review it.
Thanks. I have removed the references to the INSERT check in the
comments and the docs, because that would be confusing as it refers
to something we don't do anymore now with this p
I figured out that my TLS version was too low in the libpq call and increased
it to TLS v1.1
Should I go to 1.2? I am wondering because I do not want to limit
compatibility.
Once I got past that hurdle, I am getting the error "ssl error: the certificate
verify failed"
Since I built the certifi
so 21. 11. 2020 v 9:59 odesílatel Andy Fan
napsal:
> Thank all of you for your great insight!
>
> On Sat, Nov 21, 2020 at 9:04 AM Peter Geoghegan wrote:
>
>> On Fri, Nov 20, 2020 at 3:04 PM Andreas Karlsson
>> wrote:
>> > I am sadly not familiar enough with Oracle or have access to any Oracle
>
On Sat, Nov 21, 2020 at 08:39:11AM +0100, Peter Eisentraut wrote:
> On 2020-11-20 17:16, Justin Pryzby wrote:
> > It matters if it was planned with jit but executed without jit.
> >
> > postgres=# DEALLOCATE p; SET jit=on; SET jit_above_cost=0; prepare p as
> > select from generate_series(1,9); e
"Corbit, Dann" writes:
> I figured out that my TLS version was too low in the libpq call and increased
> it to TLS v1.1
> Should I go to 1.2? I am wondering because I do not want to limit
> compatibility.
PG 13 and up consider that 1.2 is the *minimum* secure version.
Quoting from the commit l
Michael Paquier writes:
> Indeed, this could go. There is a recursive call for views, but in
> order to maintain compatibility with that we can just remove one
> function and move the second to use a regclass as argument, like the
> attached, while removing setLastTid(). Any thoughts?
Consideri
Hi,
+1 for getting rid of whatever we can without too much trouble.
On 2020-11-21 13:13:35 -0500, Tom Lane wrote:
> Michael Paquier writes:
> > Indeed, this could go. There is a recursive call for views, but in
> > order to maintain compatibility with that we can just remove one
> > function an
On 11/20/20 4:54 PM, Corbit, Dann wrote:
>
> I would like to have all my certificates and keys on the same machine
> (localhost for local connections and dcorbit for tcp/ip).
> I found a couple tutorials and tried them but it failed.
> I saw one document that said the common name should be the po
If you have a sufficiently broken data page, pageinspect throws an
error when trying to examine the page:
ERROR: invalid memory alloc request size 18446744073709551451
This is pretty unhelpful; it would be better not to try to print the
data instead of dying. With that, at least you can know wh
On Fri, Nov 20, 2020 at 05:26:54PM +0100, Peter Eisentraut wrote:
> On 2020-10-29 03:44, Justin Pryzby wrote:
> > diff --git a/doc/src/sgml/contrib.sgml b/doc/src/sgml/contrib.sgml
> > index 4e833d79ef..be4292ec33 100644
> > --- a/doc/src/sgml/contrib.sgml
> > +++ b/doc/src/sgml/contrib.sgml
> > @@
On Sat, Nov 21, 2020 at 12:58 AM Andy Fan wrote:
> I don't mean we need to be the same as Oracle, but to support a
> customer who comes from Oracle, it would be good to know the
> difference.
Actually, it is documented here:
https://www.postgresql.org/docs/devel/transaction-iso.html
The descript
I went ahead and pushed 0001 and 0003 (the latter in two parts), since
they didn't seem particularly controversial to me. Just to keep the
cfbot from whining, here's a rebased version of 0002.
regards, tom lane
diff --git a/src/backend/utils/adt/geo_ops.c b/src/backend/ut
Pavel Borisov writes:
> The way that seems acceptable to me is to add (optional) nulls mask into
> the end of existing style SpGistLeafTuple header and use indextuple
> routines to attach attributes after it. In this case, we can reduce the
> amount of code at the cost of adding one extra MAXALIGN
On Sat, Nov 21, 2020 at 01:13:35PM -0500, Tom Lane wrote:
> Considering that we're preserving this only for backwards compatibility,
> I doubt that changing the signature is a good idea. It maybe risks
> breaking something, and the ODBC driver is hardly going to notice
> any improved ease-of-use.
On Sat, Nov 21, 2020 at 11:27 PM Pavel Stehule
wrote:
>
>
> so 21. 11. 2020 v 9:59 odesílatel Andy Fan
> napsal:
>
>> Thank all of you for your great insight!
>>
>> On Sat, Nov 21, 2020 at 9:04 AM Peter Geoghegan wrote:
>>
>>> On Fri, Nov 20, 2020 at 3:04 PM Andreas Karlsson
>>> wrote:
>>> > I
On Sun, Nov 22, 2020 at 5:56 AM Peter Geoghegan wrote:
> On Sat, Nov 21, 2020 at 12:58 AM Andy Fan
> wrote:
> > I don't mean we need to be the same as Oracle, but to support a
> > customer who comes from Oracle, it would be good to know the
> > difference.
>
> Actually, it is documented here:
>
Michael Paquier writes:
> So, what you are basically saying is to switch currtid_byreloid() to
> become a function local to tid.c. And then have just
> currtid_byrelname() and currtid_for_view() call that, right?
Yeah, that sounds about right.
regards, tom lane
Hi,
I would like to propose getting the callstack of the postgres process
by connecting to the server. This helps us in diagnosing the problems
from a customer environment in case of hung process or in case of long
running process.
The idea here is to implement & expose pg_print_callstack function
vignesh C writes:
> The idea here is to implement & expose pg_print_callstack function,
> internally what this function does is, the connected backend will send
> SIGUSR1 signal by setting PMSIGNAL_BACKTRACE_EMIT to the postmaster
> process. Postmaster process will send a SIGUSR1 signal to the pro
21 matches
Mail list logo