Hi Andres,
On Mon, Feb 24, 2020 at 12:46 PM Andres Freund wrote:
>
> Hi,
>
> On 2020-02-24 12:16:08 +0530, Aditya Toshniwal wrote:
> > The PG 12.2 server is crashing on setting the jit_above_cost param. Below
> > is the output.
>
> > postgres=# SELECT count(*) FROM pg_class;
> >
> > server
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 error to error), which I attempted to fix up,
but I haven't analyzed what the tests were
Hi,
On 2020-02-24 12:16:08 +0530, Aditya Toshniwal wrote:
> The PG 12.2 server is crashing on setting the jit_above_cost param. Below
> is the output.
> postgres=# SELECT count(*) FROM pg_class;
>
> server closed the connection unexpectedly
>
> This probably means the server terminated
++hackers.
On Mon, Feb 24, 2020 at 12:16 PM Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:
> Hi Team,
>
> The PG 12.2 server is crashing on setting the jit_above_cost param. Below
> is the output.
>
> postgres=# select version();
>
>
On Mon, Feb 24, 2020 at 7:42 PM Thomas Munro wrote:
> On Mon, Feb 24, 2020 at 12:24 PM Tom Lane wrote:
> > On reflection, trying to make ReserveExternalFD serve two different
> > use-cases was pretty messy. Here's a version that splits it into two
> > functions. I also took the trouble to fix
On Mon, Feb 24, 2020 at 12:24 PM Tom Lane wrote:
> On reflection, trying to make ReserveExternalFD serve two different
> use-cases was pretty messy. Here's a version that splits it into two
> functions. I also took the trouble to fix dblink.
+/*
+ * We don't want more than max_safe_fds
On Mon, Feb 24, 2020 at 4:49 PM Thomas Munro wrote:
> While working on a patch to reuse a common WaitEventSet for latch
> waits, I noticed that be-secure-gssapi.c and be-secure-openssl.c don't
> use FeBeWaitSet. They probably should, for consistency with
> be-secure.c, because that surely holds
Hi,
While working on a patch to reuse a common WaitEventSet for latch
waits, I noticed that be-secure-gssapi.c and be-secure-openssl.c don't
use FeBeWaitSet. They probably should, for consistency with
be-secure.c, because that surely holds the socket they want, no? The
attached patch passes the
Hi
On Sat, Feb 22, 2020 at 12:58 AM Konstantin Knizhnik <
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 <
> k.knizh...@postgrespro.ru> wrote:
>
>>
>> So looks like PG-13 provides significant advantages in
On Sun, 23 Feb 2020 at 20:31, Robert Haas wrote:
> On Sun, Feb 23, 2020 at 11:11 AM Shay Rojansky wrote:
> > I'd like to second Dave on this, from the .NET perspective - actual
> client access is done via standard drivers in almost all cases, and these
> drivers generally adhere to database API
On Sun, Feb 23, 2020 at 11:11 AM Shay Rojansky wrote:
> I'd like to second Dave on this, from the .NET perspective - actual client
> access is done via standard drivers in almost all cases, and these drivers
> generally adhere to database API abstractions (JDBC for Java, ADO.NET for
> .NET,
Hi,
On 2020-02-19 11:38:45 +0100, Tomas Vondra wrote:
> I generally agree with the impression that parsing CSV is tricky and
> unlikely to benefit from parallelism in general. There may be cases with
> restrictions making it easier (e.g. restrictions on the format) but that
> might be a bit too
On Tue, Feb 18, 2020 at 6:51 PM Amit Kapila wrote:
> I am talking about access to shared memory instead of the process
> local memory. I understand that an extra copy won't be required.
You make it sound like there is some performance penalty for accessing
shared memory, but I don't think
Tom Lane writes:
> OK, got that. But that doesn't directly answer the question of whether
> it's wrong to use a phony target as an order-only prerequisite of
> another phony target. Grepping around for other possible issues,
> I see that you recently added
>
> update-unicode: |
I wrote:
> Here's a draft patch that does it like that.
On reflection, trying to make ReserveExternalFD serve two different
use-cases was pretty messy. Here's a version that splits it into two
functions. I also took the trouble to fix dblink.
regards, tom lane
diff
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 Fri, Apr 12, 2019 at 11:42:24AM -0400, Tom Lane wrote in
Chapman Flack writes:
> ISO seems to allow spaces among the digits of a binary literal, so as
> to group them for readability, as in X'00ba b10c'. We seem not to.
Hmm. SQL99 did not allow noise spaces in and
related productions, but it does look like they added that in SQL:2008.
> (The B'...'
I wrote:
>> Clearly, we gotta do something about that too. Maybe bumping up
>> NUM_RESERVED_FDS would be a good idea, but I feel like more-honest
>> accounting for permanently-eaten FDs would be a better idea. And
>> in any case we can't suppose that there's a fixed upper limit on
>> the number
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 binary sort order of the bits
> reinterpreted as an int. It isn't in some special cases, but for this
> use case we don't really care
Hi,
ISO seems to allow spaces among the digits of a binary literal, so as
to group them for readability, as in X'00ba b10c'. We seem not to.
(The B'...' form appears to be a PostgreSQL extension, but I imagine
if ISO had it, it would allow spaces too.)
Is it worthwhile to allow that? Or to add a
Shay> Asking drivers to do this at the client have the exact same breakage
impact as the server change, since the user-visible behavior changes in the
same way
+1
Dave>While we can certainly code around this in the client drivers I don't
believe they should be responsible for fixing the failings
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
>>> different way than the server which is not what
22 matches
Mail list logo
