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
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
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
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:
>
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:
>>> >
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.
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
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
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
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
> >
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
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
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
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?
"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
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);
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
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
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
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:
> >
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
21 matches
Mail list logo
