Hi,
Since I keep forgetting the syntax and options, here is $SUBJECT.
--
Thomas Munro
https://enterprisedb.com
0001-Tab-completion-for-CREATE-TYPE.patch
Description: Binary data
On Mon, May 13, 2019 at 09:33:52PM -0700, Andres Freund wrote:
> On 2019-05-14 13:23:28 +0900, Michael Paquier wrote:
>> What's actually the reason preventing us from delaying the
>> checkpointer like the index AMs for the logging of heap init fork?
>
> I'm not following. What do you mean by
Hello.
At Sun, 12 May 2019 17:37:05 -0700, Noah Misch wrote in
<20190513003705.ga1202...@rfd.leadboat.com>
> On Sun, Mar 31, 2019 at 03:31:58PM -0700, Noah Misch wrote:
> > On Sun, Mar 10, 2019 at 07:27:08PM -0700, Noah Misch wrote:
> > > I also liked the design in the
Hi,
On 2019-05-14 13:23:28 +0900, Michael Paquier wrote:
> On Mon, May 13, 2019 at 10:37:35AM -0700, Andres Freund wrote:
> > Ugh, this is all such a mess. But, isn't this broken independently of
> > the smgrimmedsync() issue? In a basebackup case, the basebackup could
> > have included the main
On 2019/05/14 13:23, Amit Langote wrote:
> Tom
> strongly objected to that idea saying that such join paths are kind of
> silly [1], even outside the context of partitionwise join. He suggested
> that we abandon partitionwise join in such cases, because having to build
> a dummy base relation for
Hi,
On 2019-05-14 12:50:09 +0900, Michael Paquier wrote:
> On Mon, May 13, 2019 at 10:52:21AM -0700, Andres Freund wrote:
> > I was wrong here - I thought we WAL logged the main fork creation even
> > for unlogged tables. I think it's foolish that we don't, but we don't.
>
> Why? The main fork
Hi Amul, Ashutosh,
On 2019/04/24 20:26, amul sul wrote:
> Attached version is rebase atop of the latest master head(fdc7efcc30), also
> incorporates the Ashutosh's suggestion, thanks.
Reading the commit message of 0002 and after testing to confirm, I
understand that the patch doesn't handle
On Mon, May 13, 2019 at 10:37:35AM -0700, Andres Freund wrote:
> Ugh, this is all such a mess. But, isn't this broken independently of
> the smgrimmedsync() issue? In a basebackup case, the basebackup could
> have included the main fork, but not the init fork, and the reverse. WAL
> replay
On Mon, May 13, 2019 at 11:28:32AM -0400, Robert Haas wrote:
> 1. The comment added in that commit says "Recover may as well remove
> it while replaying..." but what is really meant is "Recovery may well
> remove it well replaying..." The phrase "may as well" means that
> there isn't really any
On Mon, May 13, 2019 at 8:30 PM Tom Lane wrote:
> Peter Geoghegan writes:
> > To be fair, I suppose that the code made more sense when it first went
> > in, because at the time there was a chance that there could be
> > leftover half-dead internal pages. But, that was a long time ago now.
>
> Is
Hi,
On 2019-05-14 12:37:39 +0900, Michael Paquier wrote:
> Still, I would like to understand why the bootstrap process has been
> signaled to begin with, particularly for an initdb, which is not
> really something that should happen on a server where an instance
> runs. If you have a too
On Mon, May 13, 2019 at 10:52:21AM -0700, Andres Freund wrote:
> I was wrong here - I thought we WAL logged the main fork creation even
> for unlogged tables. I think it's foolish that we don't, but we don't.
Why? The main fork is not actually necessary, and the beginning of
recovery would make
On Mon, May 13, 2019 at 11:28:51PM -0400, Tom Lane wrote:
> OK, that's fair. The SIG_DFL change I suggested will fix that problem
> for SIGINT etc (except SIGQUIT, for which you should be *expecting*
> a core file). I agree with Michael that we do not wish to change what
> happens for an
Peter Geoghegan writes:
> To be fair, I suppose that the code made more sense when it first went
> in, because at the time there was a chance that there could be
> leftover half-dead internal pages. But, that was a long time ago now.
Is there a good reason to assume there are none left anywhere?
[ please don't top-post on the PG lists ]
Thunder writes:
> At 2019-05-14 07:53:36, "Michael Paquier" wrote:
>> On Mon, May 13, 2019 at 09:37:32AM -0400, Tom Lane wrote:
>>> But ... that code's been like that for decades and nobody's complained
>>> before. Why are we worried about bootstrap's
On Tue, May 7, 2019 at 9:59 AM Peter Geoghegan wrote:
> On Tue, May 7, 2019 at 12:27 AM Heikki Linnakangas wrote:
> > I don't understand that reasoning. Yes, _bt_pagedel() will complain if
> > it finds a half-dead internal page. But how does that mean that
> > _bt_lock_branch_parent() can't
Hello.
At Mon, 13 May 2019 17:37:50 +0800, Paul Guo wrote in
> Thanks for the reply.
>
> On Tue, May 7, 2019 at 2:47 PM Kyotaro HORIGUCHI <
> horiguchi.kyot...@lab.ntt.co.jp> wrote:
>
> >
> > + if (!(stat(parent_path, ) == 0 && S_ISDIR(st.st_mode)))
> > + {
> >
> > This patch is
On Mon, May 13, 2019 at 04:34:34PM -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > On Mon, May 13, 2019 at 10:00 PM Robert Haas wrote:
> >> On Mon, May 13, 2019 at 3:54 PM Peter Eisentraut
> >> wrote:
> >>> I'm not sure doc/bug.template still serves a purpose. There is bug
> >>> reporting
On our server when process crash and core dump file generated we will receive
complaining phone call.
That's why i try to fix it.
At 2019-05-14 07:53:36, "Michael Paquier" wrote:
>On Mon, May 13, 2019 at 09:37:32AM -0400, Tom Lane wrote:
>> But ... that code's been like that for decades
On Mon, May 13, 2019 at 12:48:00PM -0500, Justin Pryzby wrote:
> On Fri, May 10, 2019 at 05:10:06PM +1200, David Rowley wrote:
> > On Fri, 10 May 2019 at 16:52, Justin Pryzby wrote:
> > > I'm rechecking my list from last month. What about these ?
> > >
> > > > c076f3d Remove
On Tue, May 14, 2019 at 01:19:30PM +1200, David Rowley wrote:
> When I wrote the code I admit that I was probably wearing my
> object-orientated programming hat. I had in mind that the whole
> function series would have made a good class. Passing the
> CopyMultiInsertInfo was sort of the non-OOP
On Tue, May 14, 2019 at 1:49 PM Thomas Munro wrote:
> ... or a named pipe that performs arbitrary magic.
(Erm, that bit might not make much sense...)
--
Thomas Munro
https://enterprisedb.com
On Mon, May 13, 2019 at 10:08:57AM +0300, Oleg Bartunov wrote:
> On Mon, May 13, 2019 at 6:52 AM Bruce Momjian wrote:
> >
> > On Sun, May 12, 2019 at 09:49:40AM -0400, Bruce Momjian wrote:
> > > On Sun, May 12, 2019 at 10:00:38AM +0300, Oleg Bartunov wrote:
> > > > Bruce,
> > > >
> > > > I
On Mon, May 13, 2019 at 08:41:25AM +0200, Fabien COELHO wrote:
>
> Hello Bruce,
>
> > I have posted a draft copy of the PG 12 release notes here:
> >
> > http://momjian.us/pgsql_docs/release-12.html
> >
> > They are committed to git. It includes links to the main docs, where
> >
Hello hackers,
Some users don't like the fact that ldapbindpasswd can leak into logs
(and now system views?). Also, some users don't like the fact that it
is in cleartext rather than some encryption scheme (though I don't
know what, since we'd presumably also need the key). I propose a new
On Tue, 14 May 2019 at 13:00, Michael Paquier wrote:
>
> On Mon, May 13, 2019 at 08:17:49PM +0530, Ashutosh Sharma wrote:
> > Thanks for the confirmation David. The patch looks good to me.
>
> It looks to me that it can be a matter a consistency with the other
> APIs dealing with multi-inserts in
On Mon, May 13, 2019 at 12:48:00PM -0500, Justin Pryzby wrote:
> I suspect c076f3d should be included, though.
bd47c4a9 has removed pg_constraint.conincluding from REL_11_STABLE as
well.
--
Michael
signature.asc
Description: PGP signature
On Mon, May 13, 2019 at 07:28:25PM +0900, Masahiko Sawada wrote:
> Thank you! I've incorporated your comment in my branch. I'll post the
> updated version patch after the above discussion got a consensus.
Fujii-san, any input about the way to move forward here? Beta1 is
planned for next week,
On Mon, May 13, 2019 at 08:17:49PM +0530, Ashutosh Sharma wrote:
> Thanks for the confirmation David. The patch looks good to me.
It looks to me that it can be a matter a consistency with the other
APIs dealing with multi-inserts in COPY. For now I have added an open
item on that.
--
Michael
On 3/5/19 5:35 PM, Nikita Glukhov wrote:
Attached 36th version of the patches rebased onto jsonpath v36.
While testing this patch a found a few issues:
[1] I was not able to apply the patch to the current HEAD. However, it
applies cleanly to commit: e988878f85 (NOTE: I did not investigate
On Mon, May 13, 2019 at 04:52:15PM -0300, Stephen Amell wrote:
> Here my first patch for postgres. Starting by an easy thing, I correct the
> duplicated "the the" strings from comments on some files.
Welcome!
> - src/backend/executor/execExpr.c
> - src/include/c.h
> -
On Mon, May 13, 2019 at 01:06:10PM -0700, legrand legrand wrote:
> that finished commited
> "pgsql: Add hooks for session start and session end"
> https://www.postgresql.org/message-id/flat/575d6fa2-78d0-4456-8600-302fc35b2591%40dunslane.net#0819e315c6e44c49a36c69080cab644d
>
> but was finally
On Mon, May 13, 2019 at 09:37:32AM -0400, Tom Lane wrote:
> But ... that code's been like that for decades and nobody's complained
> before. Why are we worried about bootstrap's response to signals at all?
Yeah, I don't think that it is something worth bothering either. As
you mentioned the
Alvaro Herrera writes:
> On 2019-May-13, Tom Lane wrote:
>> I started working on a patch to do that, and soon noticed that there
>> are pre-existing files logging.[hc] in src/bin/pg_rewind/. This seems
>> like a Bad Thing, in fact the #includes in pg_rewind/ are already a
>> little confused due
On Fri, May 10, 2019 at 10:19:44AM +0100, Dean Rasheed wrote:
While working on 1aebfbea83c, I noticed that the new multivariate MCV
stats feature suffers from the same problem, and also the original
problems that were fixed in e2d4ef8de8 and earlier --- namely that a
user can see values in the
Hi,
The Release Management Team is pleased to announce that
the release date for PostgreSQL 11 Beta 1 is set to be 2019-05-23
(wrapping [1] the release 2019-05-20).
We’re excited to make the first beta for this latest major
release of PostgreSQL available for testing, and we welcome
all
Magnus Hagander writes:
> On Mon, May 13, 2019 at 10:00 PM Robert Haas wrote:
>> On Mon, May 13, 2019 at 3:54 PM Peter Eisentraut
>> wrote:
>>> I'm not sure doc/bug.template still serves a purpose. There is bug
>>> reporting advice in the documentation, and there is a bug reporting
>>> form.
On Mon, May 13, 2019 at 10:00 PM Robert Haas wrote:
> On Mon, May 13, 2019 at 3:54 PM Peter Eisentraut
> wrote:
> > I'm not sure doc/bug.template still serves a purpose. There is bug
> > reporting advice in the documentation, and there is a bug reporting
> > form. This file just seems
Hello,
This extension https://github.com/splendiddata/login_hook
seems very interesting !
But I didn't test it myself and maybe the best place to ask
support is there
https://github.com/splendiddata/login_hook/issues
For information there is something equivalent in core
"[PATCH] A hook for
On 2019-May-13, Tom Lane wrote:
> I started working on a patch to do that, and soon noticed that there
> are pre-existing files logging.[hc] in src/bin/pg_rewind/. This seems
> like a Bad Thing, in fact the #includes in pg_rewind/ are already a
> little confused due to this. I think we should
On Mon, May 13, 2019 at 3:54 PM Peter Eisentraut
wrote:
> I'm not sure doc/bug.template still serves a purpose. There is bug
> reporting advice in the documentation, and there is a bug reporting
> form. This file just seems outdated. Should we remove it?
In my opinion, yes.
--
Robert Haas
I'm not sure doc/bug.template still serves a purpose. There is bug
reporting advice in the documentation, and there is a bug reporting
form. This file just seems outdated. Should we remove it?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
On Mon, May 13, 2019 at 12:38 PM Tom Lane wrote:
> /*
> - * Prune specified item pointer or a HOT chain originating at that item.
> + * Prune specified line pointer or a HOT chain originating at that item.
> *
> * If the item is an index-referenced tuple (i.e. not a heap-only tuple),
>
>
Hi all,
Here my first patch for postgres. Starting by an easy thing, I correct
the duplicated "the the" strings from comments on some files.
- src/backend/executor/execExpr.c
- src/include/c.h
- src/include/jit/llvmjit_emit.h
- src/include/nodes/execnodes.h
- src/include/replication/logical.h
On Fri, May 10, 2019 at 3:43 PM Ashwin Agrawal wrote:
> Meant to stick the question mark in that email, somehow missed. Yes
> not planning to spend any time on it if objections. Here is the list
> of renames I wish to perform.
>
> Lets start with low hanging ones.
>
> table_rescan ->
Peter Geoghegan writes:
> On Sun, May 5, 2019 at 1:14 PM Peter Geoghegan wrote:
>> Attached draft patch adjusts code comments and error messages where a
>> line pointer is referred to as an item pointer. It turns out that this
>> practice isn't all that prevalent. Here are some specific concerns
I wrote:
> Alvaro Herrera writes:
>> I wonder if a better solution isn't to move the file_utils stuff to
>> fe_utils. Half of it is frontend-specific. The only one that should be
>> shared to backend seems to be fsync_fname ... but instead of sharing it,
>> we have a second copy in fd.c.
> Hm,
On Sun, May 5, 2019 at 1:14 PM Peter Geoghegan wrote:
> Attached draft patch adjusts code comments and error messages where a
> line pointer is referred to as an item pointer. It turns out that this
> practice isn't all that prevalent. Here are some specific concerns
> that I had to think about
> "Tom" == Tom Lane writes:
Tom> Hmm. Oddly, you can't fix it by adding parens:
Tom> regression=# select 'foo' similar to ('f' || escape) escape escape from
(values ('oo')) v(escape);
Tom> psql: ERROR: syntax error at or near "escape"
Tom> LINE 1: select 'foo' similar to ('f' ||
I wrote:
> If we do anything at all about this, my thought would just be to change
> bootstrap_signals() so that it points all the signal handlers at
> quickdie(), or maybe something equivalent to quickdie() but printing
> a more apropos message, or even just set them all to SIGDFL since that
>
On Sun, May 12, 2019 at 2:15 AM Dilip Kumar wrote:
> I have removed some of the globals and also improved some comments.
I don't like the discard_lock very much. Perhaps it's OK, but I hope
that there are better alternatives. One problem with Thomas Munro
pointed out to me in off-list
Andrew Gierth writes:
> "Andrew" == Andrew Gierth writes:
> Andrew> The ESCAPE part could in theory be ambiguous if the SIMILAR
> Andrew> expression ends in a ... SIMILAR TO xxx operator, since then we
> Andrew> wouldn't know whether to attach the ESCAPE to that or keep it
> Andrew> as part
Hi,
On 2019-05-13 13:33:00 -0400, Alvaro Herrera wrote:
> On 2019-May-13, Andres Freund wrote:
>
> > On 2019-05-13 13:07:30 -0400, Alvaro Herrera wrote:
> > > On 2019-May-13, Andres Freund wrote:
>
> > > The first ResetUnloggedRelations call occurs before any WAL is replayed,
> > > so the data
On Fri, May 10, 2019 at 05:10:06PM +1200, David Rowley wrote:
> On Fri, 10 May 2019 at 16:52, Justin Pryzby wrote:
> > I'm rechecking my list from last month. What about these ?
> >
> > > c076f3d Remove pg_constraint.conincluding
> > > bd09503 Increase the default vacuum_cost_limit from 200 to
> "Andrew" == Andrew Gierth writes:
Andrew> The ESCAPE part could in theory be ambiguous if the SIMILAR
Andrew> expression ends in a ... SIMILAR TO xxx operator, since then we
Andrew> wouldn't know whether to attach the ESCAPE to that or keep it
Andrew> as part of the function syntax.
Hi,
On 2019-05-13 13:21:33 -0400, Alvaro Herrera wrote:
> On 2019-May-13, Robert Haas wrote:
> > If that's the scenario, I'm not sure the smgrimmedsync() call is
> > sufficient. Suppose we log_smgrcreate() but then crash before
> > smgrimmedsync()... seems like we'd need to do them in the other
On 2019-05-13 13:09:17 -0400, Robert Haas wrote:
> On Mon, May 13, 2019 at 12:50 PM Andres Freund wrote:
> > > AFAICS ResetUnloggedRelations copies the init fork after replaying WAL,
> > > so it would be sufficient to have the init fork be recovered from WAL
> > > for that to work. However, we
On 2019-May-13, Andres Freund wrote:
> On 2019-05-13 13:07:30 -0400, Alvaro Herrera wrote:
> > On 2019-May-13, Andres Freund wrote:
> > The first ResetUnloggedRelations call occurs before any WAL is replayed,
> > so the data dir certainly still in inconsistent state. At that point,
> > we need
Hi,
On 2019-05-13 13:07:30 -0400, Alvaro Herrera wrote:
> On 2019-May-13, Andres Freund wrote:
>
> > On 2019-05-13 12:24:05 -0400, Alvaro Herrera wrote:
>
> > > AFAICS ResetUnloggedRelations copies the init fork after replaying WAL,
> > > so it would be sufficient to have the init fork be
On 2019-May-13, Robert Haas wrote:
> I think I see what Alvaro is talking about, or at least I think I see
> *a* possible problem based on his remarks.
>
> Suppose we create an unlogged table and then crash. The main fork
> makes it to disk, and the init fork does not. Before WAL replay, we
>
On Fri, May 10, 2019 at 10:46 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > Yeah, I've noticed this inconsistency too. I doubt we want to change
> > the macro definition or its name, but +1 for expanding the comment.
> > Your proposed wording seems sufficient.
>
> +1
OK, committed. I assume
On Mon, May 13, 2019 at 12:50 PM Andres Freund wrote:
> > AFAICS ResetUnloggedRelations copies the init fork after replaying WAL,
> > so it would be sufficient to have the init fork be recovered from WAL
> > for that to work. However, we also do ResetUnloggedRelations *before*
> > replaying WAL
On 2019-May-13, Andres Freund wrote:
> On 2019-05-13 12:24:05 -0400, Alvaro Herrera wrote:
> > AFAICS ResetUnloggedRelations copies the init fork after replaying WAL,
> > so it would be sufficient to have the init fork be recovered from WAL
> > for that to work. However, we also do
Hi,
On 2019-05-13 12:24:05 -0400, Alvaro Herrera wrote:
> > My guess, just shooting from the hip, is that the smgrimmedsync call
> > can be removed here. If that's wrong, then we need a better
> > explanation for why it's needed, and we possibly need to add it to
> > every single place that does
I agree that the wording "recovery may as well" is incorrect and that
"may well" makes it correct.
On 2019-May-13, Robert Haas wrote:
> My guess, just shooting from the hip, is that the smgrimmedsync call
> can be removed here. If that's wrong, then we need a better
> explanation for why it's
On 3/25/19 18:13, Alexander Kuzmenkov wrote:
Please see the attached v15.
I won't be able to continue working on this because I'm changing jobs.
My colleague Arseny Sher is probably going to take over.
Here is a v16 that is a rebased v12, plus renames from v15, plus a
couple of bug fixes
On Thu, May 9, 2019 at 9:41 AM Tom Lane wrote:
> > I think we can get rid of the ability to reload the information_schema
> > after initdb. That was interesting in the early phase of its
> > development, but now it just creates complications.
>
> We've relied on that more than once to allow
On Thu, Dec 8, 2016 at 7:49 PM Michael Paquier
wrote:
> On Fri, Dec 9, 2016 at 4:54 AM, Robert Haas wrote:
> > On Wed, Dec 7, 2016 at 11:20 PM, Michael Paquier
> > wrote:
> >> OK, I rewrote a bit the patch as attached. What do you think?
> >
> > Committed and back-patched all the way back to
On Mon, May 13, 2019 at 7:16 PM David Rowley
wrote:
> On Mon, 13 May 2019 at 23:20, Ashutosh Sharma
> wrote:
> > In the latest PostgreSQL code, I could see that we are passing
> CopyMultiInsertInfo structure to CopyMultiInsertInfoNextFreeSlot() although
> it is not being used anywhere in that
On Mon, May 13, 2019 at 7:07 PM Tom Lane wrote:
> Michael Paquier writes:
> > On Mon, May 13, 2019 at 01:25:19PM +0530, Kuntal Ghosh wrote:
> >> If we fix the issue in this way, we're certainly not going to do all
> >> those portal,locks,memory,resource owner cleanups that are done
> >> inside
On Mon, 13 May 2019 at 23:20, Ashutosh Sharma wrote:
> In the latest PostgreSQL code, I could see that we are passing
> CopyMultiInsertInfo structure to CopyMultiInsertInfoNextFreeSlot() although
> it is not being used anywhere in that function. Could you please let me know
> if it has been
Michael Paquier writes:
> On Mon, May 13, 2019 at 01:25:19PM +0530, Kuntal Ghosh wrote:
>> If we fix the issue in this way, we're certainly not going to do all
>> those portal,locks,memory,resource owner cleanups that are done
>> inside AbortTransaction() for a normal transaction ID. But, I'm not
pg_stat_reset_single_table_counters/pg_stat_reset_single_function_counters
only update pg_stat_database column stats_reset.
stat_reset shuld update when all the column is reset.
sample:
drop database if exists lzzhang_db;
create database lzzhang_db;
\c lzzhang_db
create table lzzhang_tab(id
Hi Andres, Hari, David,
In the latest PostgreSQL code, I could see that we are passing
CopyMultiInsertInfo structure to CopyMultiInsertInfoNextFreeSlot() although
it is not being used anywhere in that function. Could you please let me
know if it has been done intentionally or it is just an
Hello Community,
While I was searching for logon trigger in postgres similar to that of
Oracle, I came across "login_hook", which can be installed as a Postgres
database extension to mimic a logon trigger.
But I tried to install but failed. Error is that it could not find its .so
file. Could
On Fri, May 10, 2019 at 9:03 PM Julien Rouhaud wrote:
>
> On Thu, May 9, 2019 at 1:39 PM Kyotaro HORIGUCHI
> wrote:
> >
> > At Thu, 9 May 2019 20:14:51 +0900, Masahiko Sawada
> > wrote in
> >
> > > On Thu, May 9, 2019 at 10:01 AM Michael Paquier
> > > wrote:
> > > >
> > > > On Wed, May 08,
Thanks for the reply.
On Tue, May 7, 2019 at 2:47 PM Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
>
> + if (!(stat(parent_path, ) == 0 && S_ISDIR(st.st_mode)))
> + {
>
> This patch is allowing missing source and destination directory
> even in consistent state. I don't
On Mon, May 13, 2019 at 01:25:19PM +0530, Kuntal Ghosh wrote:
> If we fix the issue in this way, we're certainly not going to do all
> those portal,locks,memory,resource owner cleanups that are done
> inside AbortTransaction() for a normal transaction ID. But, I'm not
> sure how relevant those
On Mon, May 13, 2019 at 2:09 PM Smith, Peter wrote:
>
> Hi Masahiko,
>
> > Let me briefly explain the current design I'm thinking. The design
> > employees 2-tier key architecture. That is, a database cluster has one
> > master key and per-tablespace keys which are encrypted with the master key
Hello,
On Mon, May 13, 2019 at 10:15 AM Thunder wrote:
> I try to fix this issue and check whether it's normal transaction id
> before we do abort.
>
> diff --git a/src/backend/access/transam/xact.c
> b/src/backend/access/transam/xact.c
> index 20feeec327..dbf2bf567a 100644
> ---
> "Andrew" == Andrew Gierth writes:
Tom> I am, frankly, inclined to ignore this as a bad idea. We do have
Tom> SIMILAR and ESCAPE as keywords already, but they're
Tom> type_func_name_keyword and unreserved_keyword respectively. To
Tom> support this syntax, I'm pretty sure we'd have to
On Mon, May 13, 2019 at 07:45:59AM +0500, Andrey Borodin wrote:
> I was reviewing Paul Ramsey's TOAST patch[0] and noticed that there
> is a big room for improvement in performance of pglz compression and
> decompression.
Yes, I believe so too. pglz is a huge CPU-consumer when it comes to
On Mon, May 13, 2019 at 6:52 AM Bruce Momjian wrote:
>
> On Sun, May 12, 2019 at 09:49:40AM -0400, Bruce Momjian wrote:
> > On Sun, May 12, 2019 at 10:00:38AM +0300, Oleg Bartunov wrote:
> > > Bruce,
> > >
> > > I noticed that jsonpath in your version is mentioned only in functions
> > > chapter,
Hello Bruce,
I have posted a draft copy of the PG 12 release notes here:
http://momjian.us/pgsql_docs/release-12.html
They are committed to git. It includes links to the main docs, where
appropriate. Our official developer docs will rebuild in a few hours.
Pgbench entry "Improve
> "Tom" == Tom Lane writes:
Tom> but in recent versions it's
Tom> ::=
Tom> SUBSTRING
Tom> SIMILAR
Tom> ESCAPE
Tom> I am, frankly, inclined to ignore this as a bad idea. We do have
85 matches
Mail list logo
