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,
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
compila
> "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 mak
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
> --- a/src/backend/a
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
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 step
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, &st) == 0 && S_ISDIR(st.st_mode)))
> + {
>
> This patch is allowing missing source and destination directory
> even in consistent state. I don't
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,
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 yo
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 overloo
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 int);
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
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 don
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 A
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 fu
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 9.2
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 minor
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
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 ne
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
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 ResetUnlogged
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 i
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 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
> re
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 recove
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 t
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 al
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 o
> "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. But
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 20
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 d
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 o
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 discussio
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
> mea
> "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' || escap
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 wh
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,
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
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 -> table_scan_re
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 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),
>
> Shou
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, Re
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
En
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 ei
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 sessi
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 outdated
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. T
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 feedback.
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 MC
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 t
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 data
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 rol
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
> - src/include/jit/llvmjit_emit
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 whic
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
si
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, hen
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 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
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
optio
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
> > appropriat
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 noticed
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 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 e
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 pg_constraint.conincl
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 a
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
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, &st) == 0 && S_ISDIR(st.st_mode)))
> > + {
> >
> > This patch is
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 encou
[ 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
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?
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 internal
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 s
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 aggressi
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
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 re
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 *solely*
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 OUTER
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 is
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 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 f
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 https://postgr.es/m/559fa0
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 "dela
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 Tue, Apr 30, 2019 at 11:26 AM nickb wrote:
> Hello, hackers
>
> we witnessed this slightly misleading error in production and it took us a
> while to figure out what was taking place.
> Below are reproduction steps:
>
>
> -- setup
> create table trun(cate int4);
>
> -- session 1
> begin;
> tru
Hello.
At Tue, 14 May 2019 17:50:58 +1200, Thomas Munro wrote
in
> Hi,
>
> Since I keep forgetting the syntax and options, here is $SUBJECT.
I played with this a bit and found that "... (attr=[tab]" (no
space between "r" and "=") complets with '='. Isn't it annoying?
Only "UPDATE hoge SET a=
Hi,
On 2019-05-14 14:22:15 +0900, Michael Paquier wrote:
> 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
On Mon, 1 Apr 2019 12:11:22 +0900
Yugo Nagata wrote:
> On Thu, 27 Dec 2018 21:57:26 +0900
> Yugo Nagata wrote:
>
> > Hi,
> >
> > I would like to implement Incremental View Maintenance (IVM) on PostgreSQL.
> >
>
> I am now working on an initial patch for implementing IVM on PostgreSQL.
> Th
On Tue, Apr 30, 2019 at 02:20:27PM +1200, David Rowley wrote:
> The options seem to be:
> 1. Make the lower limit of toast_tuple_target the same as
> TOAST_TUPLE_THRESHOLD; or
> 2. Require an AccessExclusiveLock when setting toast_tuple_target and
> call create_toast_table() to ensure we get a toa
On Tue, May 14, 2019 at 6:18 PM Kyotaro HORIGUCHI
wrote:
> I played with this a bit and found that "... (attr=[tab]" (no
> space between "r" and "=") complets with '='. Isn't it annoying?
>
> Only "UPDATE hoge SET a=[tab]" behaves the same way among
> existing completions.
Hmm. True. Here's one
89 matches
Mail list logo
