hen we're
> making catalog changes, and it keeps these issues out of pg_dump.
Yeah, I think we just need to bite the bullet and create some
infrastructure to help folks solve the problem.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://ent
discussion.
I think the big question is whether we do anything, or just decide we
can't agree and stop.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Wed, Aug 14, 2019 at 09:19:44PM -0400, Bruce Momjian wrote:
> I think there are several directions we can go after all-cluster
> encryption, and it does matter because we would want minimal API
> breakage. The options are:
>
> 1) Allow per-table encyption control to limit encr
On Thu, Aug 15, 2019 at 06:10:24PM +0900, Masahiko Sawada wrote:
> On Thu, Aug 15, 2019 at 10:19 AM Bruce Momjian wrote:
> >
> > On Wed, Aug 14, 2019 at 04:36:35PM +0200, Antonin Houska wrote:
> > > I can work on it right away but don't know where to start.
> >
bles/indexes key and a WAL key, plus keys for
rotation. I explained why per-tablespace keys don't add much value.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Thu, Aug 15, 2019 at 09:01:05PM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > I assume you are talking about my option #1. I can see if you only need
> > a few tables encrypted, e.g., credit card numbers, it can be excessive
> > to encrypt th
On Fri, Aug 16, 2019 at 05:58:59PM +0500, Ibrar Ahmed wrote:
>
>
> On Thu, Aug 15, 2019 at 8:21 PM Bruce Momjian wrote:
>
> On Thu, Aug 15, 2019 at 11:24:46AM +0200, Antonin Houska wrote:
> > > I think there are several directions we can go after all-clus
On Fri, Aug 16, 2019 at 07:47:37PM +0200, Antonin Houska wrote:
> Bruce Momjian wrote:
>
> > I have seen no one present a clear description of how anything beyond
> > all-cluster encryption would work or be secure. Wishing that were not
> > the case doesn't change
On Fri, Aug 16, 2019 at 06:04:39PM -0400, Bruce Momjian wrote:
> I suggest we schedule a voice call and I will go over all the issues and
> explain why I came to the conclusions listed. It is hard to know what
> level of detail to explain that in an email, beyond what I have already
&g
On Sat, Aug 17, 2019 at 08:16:06AM +0200, Antonin Houska wrote:
> Bruce Momjian wrote:
>
> > On Thu, Aug 15, 2019 at 09:01:05PM -0400, Stephen Frost wrote:
> > > * Bruce Momjian (br...@momjian.us) wrote:
> > > > Why would it not be simpler to have t
tails:
>
> 1) How exactly should we report this incompatibility to a user?
> I think it's fine to leave the warnings and also write some hint for the
> user by analogy with other checks.
> "Reset ACL on the problem functions to default in the old cluster to
> cont
ures
has to be useful for our users and reasonable to implement in Postgres.
This is been the criteria for every other Postgres features I have seen
developed.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
On Fri, Aug 23, 2019 at 07:45:22AM -0400, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Sat, Aug 17, 2019 at 01:52:17PM -0400, Stephen Frost wrote:
> > > Being PostgreSQL, I would expect us to shoot for as much flexibility as
>
oes seem to be what the other
> database systems have done. Unfortunately, their documentation doesn't
> seem to really say exactly what they've done to address that.
I do like they pgcrypto key support to be per-database so pg_dump will
dump the data encrypted, and with its locked keys.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
the value of encrypting only the user rows? Better key control?
>
> Yes, better key control, and better user API, and avoiding having an
Uh, there is no user API for all-cluster encryption except for the
administrator.
--
Bruce Momjian http://momjian.us
EnterpriseDB
I am ready to update the copyright notice on HEAD for 2018. Any
objections? This shouldn't affect any pending patches since the
copyright text is normally isolated at the top of the file.
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Tue, Jan 2, 2018 at 04:49:28PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I am ready to update the copyright notice on HEAD for 2018. Any
> > objections? This shouldn't affect any pending patches since the
> > copyright text is normally isolated at the top
On Wed, Nov 1, 2017 at 11:24:03PM -0400, Peter Eisentraut wrote:
> On 10/2/17 18:34, Bruce Momjian wrote:
> > My smaller question is how will this list be generated in PG 11? From
> > the commit log when the release notes are created, or some other method?
>
> I don't
On Sat, Dec 9, 2017 at 08:45:14AM -0500, Stephen Frost wrote:
> Bruce,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Fri, Dec 8, 2017 at 12:26:55PM -0500, Stephen Frost wrote:
> > > * Bruce Momjian (br...@momjian.us) wrote:
> > > > I think the big
On Fri, Jan 5, 2018 at 02:20:59PM -0500, Robert Haas wrote:
> On Fri, Jan 5, 2018 at 2:11 PM, Bruce Momjian wrote:
> > pg_upgrade: simplify code layout in a few places
> >
> > Backpatch-through: 9.4 (9.3 didn't need improving)
>
> Hmm. We don't normally d
On Fri, Jan 5, 2018 at 02:31:51PM -0500, Robert Haas wrote:
> On Fri, Jan 5, 2018 at 2:24 PM, Bruce Momjian wrote:
> > On Fri, Jan 5, 2018 at 02:20:59PM -0500, Robert Haas wrote:
> >> On Fri, Jan 5, 2018 at 2:11 PM, Bruce Momjian wrote:
> >> > pg_upgrade: simpli
On Fri, Jan 5, 2018 at 02:37:58PM -0500, Robert Haas wrote:
> On Fri, Jan 5, 2018 at 2:32 PM, Alvaro Herrera
> wrote:
> > Bruce Momjian wrote:
> >> On Fri, Jan 5, 2018 at 02:20:59PM -0500, Robert Haas wrote:
> >> > On Fri, Jan 5, 2018 at 2:11 PM, Bruce Mo
ok
Checking for presence of required libraries ok
Checking database user is the install user ok
Checking for prepared transactions ok
*Clusters are compatible*
--
Bruce Momjian
On Fri, Jan 5, 2018 at 03:51:15PM -0800, Andres Freund wrote:
> On 2018-01-05 14:20:59 -0500, Robert Haas wrote:
> > On Fri, Jan 5, 2018 at 2:11 PM, Bruce Momjian wrote:
> > > pg_upgrade: simplify code layout in a few places
> > >
> > > Backpatch-thr
On Fri, Jan 5, 2018 at 08:39:46PM -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-01-05 18:57:55 -0500, Bruce Momjian wrote:
> >> On Fri, Jan 5, 2018 at 03:51:15PM -0800, Andres Freund wrote:
> >>> Also, leaving translatability aside, why was *any* of
On Fri, Jan 5, 2018 at 04:58:39PM -0500, Bruce Momjian wrote:
> Pg_upgrade is able to run in --check mode when the old server is still
> running. Unfortunately, all supported versions of pg_upgrade generate
> an incorrect (but harmless) "failure" message when doing thi
On Mon, Jan 8, 2018 at 10:43:00AM -0500, Robert Haas wrote:
> On Fri, Jan 5, 2018 at 9:11 PM, Bruce Momjian wrote:
> > On Fri, Jan 5, 2018 at 04:58:39PM -0500, Bruce Momjian wrote:
> >> Pg_upgrade is able to run in --check mode when the old server is still
> >> r
On Mon, Jan 8, 2018 at 06:26:21PM -0500, Bruce Momjian wrote:
> On Mon, Jan 8, 2018 at 10:43:00AM -0500, Robert Haas wrote:
> > On Fri, Jan 5, 2018 at 9:11 PM, Bruce Momjian wrote:
> > > On Fri, Jan 5, 2018 at 04:58:39PM -0500, Bruce Momjian wrote:
> > >> Pg_upg
I have removed these URLs from C comments in git head.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Mon, Oct 30, 2017 at 05:43:02PM +0100, Christoph Dreis wrote:
> Hey,
>
> please find a patch attached that fixes duplicated "the" occurrences in the
> codebase.
>
> As this is my first patch, please let me know in case I did something wrong.
Patch applied in git
On Thu, Nov 9, 2017 at 09:42:40PM +0900, Etsuro Fujita wrote:
> Hi,
>
> Attached is a patch to reorder header files in joinrels.c and pathnode.c
> in alphabetical order, removing unnecessary ones.
Applied, thanks.
--
Bruce Momjian http://momjian.us
t;;
Uh, the oid of the template1 database is 1, and I assume we would want
to preserve that too.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Sun, Jan 21, 2018 at 11:02:29AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, Jan 19, 2018 at 02:54:25PM -0500, Tom Lane wrote:
> >> Command was: DROP DATABASE "template1";
>
> > Uh, the oid of the template1 database is 1, and I assume w
Can someone confirm this so I can apply this patch?
---
On Fri, Nov 17, 2017 at 06:34:29PM +0900, Masahiko Sawada wrote:
> Hi,
>
> I found that the doc says in 19.6.4. Subscribers section that "Note
> that wal_receiver_time
On Tue, Jan 23, 2018 at 06:36:04PM -0500, Bruce Momjian wrote:
>
> Can someone confirm this so I can apply this patch?
Never mind. I see this was applied:
doc: mention wal_receiver_status_interval as GUC affecting logical rep
worker.
wal_receiver_t
ase cycle where there's very little margin for
> error.
I am coming in late here, but I am not aware of any open source
professional typesetting software that has output quality as good as
TeX.
--
Bruce Momjian http://momjian.us
EnterpriseDB ht
On Tue, Jan 23, 2018 at 05:25:30PM -0800, Joshua Drake wrote:
> On 01/23/2018 04:59 PM, Bruce Momjian wrote:
> >On Thu, Nov 23, 2017 at 03:39:24PM -0500, Tom Lane wrote:
> >>Also, we're way overdue for getting out from under the creaky TeX-based
> >>toolchain fo
7;t it be better as
> 65535 so we palloc a power of 2?
>
>
> I have no idea if this affects performance, but it did strike me as strange.
Coming in late here, but it does seem very odd.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://e
t. But I've not thought hard about
> it, nor looked for alternate tools.
For people curious about the C typedef parsing details:
http://calculist.blogspot.com/2009/02/c-typedef-parsing-problem.html
https://stackoverflow.com/questions/243383/why-cant-c-be-parsed-with-a-lr1-
On Tue, Jan 23, 2018 at 10:22:53PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Nov 23, 2017 at 03:39:24PM -0500, Tom Lane wrote:
> >> Also, we're way overdue for getting out from under the creaky TeX-based
> >> toolchain for producing PDFs.
>
>
On Wed, Jan 24, 2018 at 08:21:21AM -0500, Peter Eisentraut wrote:
> On 1/23/18 22:24, Bruce Momjian wrote:
> >> I like TeX as much as the next guy --- I wrote my thesis with it,
> >> a long time ago --- but there's no denying that (a) it's got hard
> >> limi
People are using it, so that's the end of the story. Sorry about the
> noise.
Oh, yes, people are using it, particularly LaTeX longtable, which was
added in 2013:
commit b14f81bc9a65993129e93052634e358b310b8554
Author: Bruce Momjian
Date: Thu Jan 17 11:3
ly it's fine too.
>
> And then there are the systems without glibc, or with other libc
> implementations. No idea about those.
Thanks for the analysis.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you
ndle **handle). Unlike
>RegisterBackgroundWorker, which can only be called
> from within
>the postmaster, RegisterDynamicBackgroundWorker must
> be
> - called from a regular backend.
> + called from a regular backend, possibly another background worke
say that the doc
part of this entry has been applied.
---
>
> -Chap
>
> On 01/24/2018 01:20 PM, Bruce Momjian wrote:
> > On Thu, Dec 14, 2017 at 06:12:35PM -0500, Chapman Flack wrote:
> >> On
s of two, and keep the
header in a separate location. They did this so they could combine two
free, identically-sized memory blocks into a single one that was double
the size. I have no idea how it works now.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
rol-D then \q" (or
"Use Control-C then \q" on Windows) and be done with it. By printing
the Control-D only when we are in a quoted strong, we minimize the
number of times that we are wrong due to stty changes.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
l_exec.c
> +++ b/src/pl/plpgsql/src/pl_exec.c
> @@ -3727,8 +3727,6 @@ exec_stmt_execsql(PLpgSQL_execstate *estate,
> break;
>
> case SPI_OK_REWRITTEN:
> - Assert(!stmt->mod_stmt);
> -
> /*
>* The command was rewritten into another kind of
> command. It's
>* not clear what FOUND would mean in that case (and
> SPI doesn't
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
little bit surprised when me test didn't show lost of
> updated versions.
> May be it is because of vacuum_defer_cleanup_age.
Well vacuum and single-page pruning do 3 things:
1. remove expired updated rows
2. remove deleted row
3. remove rows from aborted transactions
While time travel
* Combine BlockRecordInfos for global objects
> withs those of
> + * Combine BlockRecordInfos for global objects
> with those of
>* the database.
> */
>
ance.
Uh, I think the big question is whether we are ready to agreed that a
time-travel database will _never_ have aborted rows removed. The
aborted rows are clearly useless for time travel, so the question is
whether we ever want to remove them. I would think at some point we do.
Also, I
rnel code you might be able to verify quickly that the 4k
atomicity is not guaranteed.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Fri, Jan 26, 2018 at 11:53:33PM +0100, Tomas Vondra wrote:
>
>
> On 01/26/2018 02:56 PM, Bruce Momjian wrote:
> > Yes, that is the hard part, making sure you have 4k granularity of
> > write, and matching write alignment. pg_test_fsync and diskchecker.pl
> > (w
w an option to exit idle
connections when this happens so new users can connect?
I know we have relied on external connection poolers to solve all the
high connection problems but it seems there might be simple things we
can do to improve matters. FYI, I did write a blog entry comparing
external
can of worms, are we ever going to rename "ssl"
parameters to "tls" since TLS is the protocol used by all modern secure
communication libraries. SSL was deprecated in 2015:
https://www.globalsign.com/en/blog/ssl-vs-tls-difference/
Both SSL 2.0 and 3.0 have bee
;
> #include "utils/hashutils.h"
> #include "utils/inval.h"
> #include "utils/lsyscache.h"
> +#include "utils/memutils.h"
> #include "utils/rel.h"
> #include "utils/ruleutils.h"
> #include "utils/syscache.h"
P
On Sun, Jan 28, 2018 at 02:01:07PM -0800, Ivan Novick wrote:
> On Sat, Jan 27, 2018 at 4:40 PM, Bruce Momjian wrote:
>
> On Mon, Jan 22, 2018 at 06:51:08PM +0100, Tomas Vondra wrote:
> Right now, if you hit max_connections, we start rejecting new
> connections. Woul
On Thu, Jan 25, 2018 at 03:46:30PM -0500, Bruce Momjian wrote:
> On Mon, Jan 15, 2018 at 11:10:44AM -0500, Robert Haas wrote:
> > prompt_status does seem to be available in psql's MainLoop(), so I
> > think that could be done, but the problem is that I don't know exactly
er version.
>
>
> Oh i see its in 9.6, AWESOME!
In summary, the good news is that adding an idle-session-timeout GUC, a
max_connections limit hit cancels idle connections GUC, and a GUC for
idle connections to reduce their resource usage shouldn't be too hard to
implement and will
d not handle that cleanly. It is probably better to look into
freeing resources for idle connections instead and keep the socket open.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so onc
ut implementing the SQL Standard compliant MERGE
> command which is widely used in other databases and by various tools.
Uh, if we know we are going to get question on this, the patch had
better have an explanation of when to use it. Pushing the problem to
later doesn't seem helpful.
--
ared statements to
> be
> there. Would you deallocate server-prepared statements for those "idle"
> connections? The app would just break. There's no way (currently) for the
> application to know that the statement expired unexpectedly.
I don't know what we would dealloc
think the question is how does it handle cases it doesn't support?
Does it give wrong answers? Does it give a helpful error message? Can
you summarize that?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are,
On Sun, Jan 28, 2018 at 06:35:06PM -0500, Bruce Momjian wrote:
> I used Robert's patch and modified it to match the ideas I had above.
> Specifically no white space can be before 'help', 'exit' or 'quit' and
> prompt_status is used to adjust the sugg
On Wed, Jan 31, 2018 at 05:13:41PM -0500, Robert Haas wrote:
> On Wed, Jan 31, 2018 at 5:00 PM, Bruce Momjian wrote:
> > doc: clarify trigger behavior for inheritance
> >
> > The previous wording added in PG 10 wasn't specific enough about the
> > behavior of
On Thu, Feb 1, 2018 at 12:01:37PM +0100, Daniel Verite wrote:
> Bruce Momjian wrote:
>
> > One open issue is the existing help display is inaccurate on Windows:
> >
> > Use \\? for help or press control-C to clear the input buffer.
>
> ! #ifndef WIN
On Thu, Feb 1, 2018 at 12:01:37PM +0100, Daniel Verite wrote:
> Bruce Momjian wrote:
>
> > One open issue is the existing help display is inaccurate on Windows:
> >
> > Use \\? for help or press control-C to clear the input buffer.
>
> ! #ifndef WIN
On Wed, Jan 31, 2018 at 05:51:51PM -0500, Bruce Momjian wrote:
> On Sun, Jan 28, 2018 at 06:35:06PM -0500, Bruce Momjian wrote:
> > I used Robert's patch and modified it to match the ideas I had above.
> > Specifically no white space can be before 'help', 'exit&
we have ^C and ^D do
different things on psql, or they should do the same thing. I doubt we
would want to change ^D, so it would be changing ^C to exit, except we
use ^C to cancel a query and return you to a prompt, so I don't see how
we can change that either.
In summary, we are probabl
On Thu, Feb 1, 2018 at 07:47:14AM -0500, Bruce Momjian wrote:
> > There's also the issue that, in general, communicating different hints
> > and advice depending on the host operating system is not ideal.
> > Because people ask "how do I do such and such in psql?&quo
x27; in the same contexts.
Here is the hint for 'exit' and 'quit':
test=> SELECT '
test'> exit
--> Use control-D to quit.
but we don't hint for '\q':
test=> SELECT '
test'
On Fri, Feb 2, 2018 at 12:39:28AM -0500, Bruce Momjian wrote:
> I just thought of an inconsistency. First, we now consistently exit with
> 'exit', 'quit', and '\q' if used in an empty psql query buffer. Also, we now
> hint when 'exit
On Mon, Feb 12, 2018 at 01:28:53AM -0500, Bruce Momjian wrote:
> > Should we give the same "Use control-D to quit." hint here for '\q'?
> > I think it is logical that we should.
>
> I have applied the attached patch giving a ^D/^C hint where \q is
> ignore
On Wed, Feb 14, 2018 at 03:07:46PM +0900, Michael Paquier wrote:
> On Wed, Feb 14, 2018 at 12:56:48AM -0500, Bruce Momjian wrote:
> > On Mon, Feb 12, 2018 at 01:28:53AM -0500, Bruce Momjian wrote:
> > > > Should we give the same "Use control-D to quit." hint here
f GEQO.
I guess my big take-away is that not only can MATERIALIZE change the
quality of query plans but it can also improve the quality of query
plans if it prevents GEQO from being used.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
ill looking more into that.
Are there any bad effects of this bug on PG 12?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
much work it would take to allow that, but it seems like it
is a valid requite, and if so, I can add it to the TODO list.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+
On Sat, Nov 2, 2019 at 01:34:41PM +0100, Antonin Houska wrote:
> Robert Haas wrote:
>
> > On Tue, Aug 6, 2019 at 10:36 AM Bruce Momjian wrote:
>
> > Seems reasonable (not that I am an encryption expert).
> >
> > > For WAL, we effectively create a 16M
come
> up with. Running a shell command can already be accomplished via the
> ssl_passphrase_command setting.
What is the value of a shared library over a shell command? We had this
discussion in relation to archive_command years ago, and decided on a
shell command as the best API.
--
Bruce Mo
hing. My point is that increasing the default
autovacuum_freeze_max_age value seems like an easy way to reduce vacuum
freeze. (While, the visibility map helps avoid vacuum freeze from
reading all heap pages, and we still need to read all index pages.)
--
Bruce Momjian http://momjia
w
> > for RETURNING". Becuase, as I have described at first letter, without
> > this the RETURNING rows **does not correspond actually deleted data**
>
> > Thank you.
I have added a TODO item:
Allow DELETE triggers to modify rows, for use by RETURNING
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Thu, Nov 7, 2019 at 04:26:55PM -0500, Bruce Momjian wrote:
> On Thu, Nov 7, 2019 at 11:24:29AM +0200, Eugen Konkov wrote:
> > >> As far as allowing DELETE to modify the trigger row for RETURNING, I am
> > >> not sure how much work it would take to allow that, but i
On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus Hagander wrote:
> On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian wrote:
> We had this
> discussion in relation to archive_command years ago, and decided on a
> shell command as the best API.
>
> I don't recall t
On Mon, Nov 11, 2019 at 07:00:22PM +0300, Liudmila Mantrova wrote:
>
> > 8 нояб. 2019 г., в 0:26, Bruce Momjian написал(а):
> >
> > First, notice "only", which was missing from the later sentence:
> >
> >For INSERT and UPDATE
> >operati
gt; sslpassword to be set as user mapping options in postgres_fdw . Together all
> three patches make it possible to use SSL client certificates to manage
> authentication in postgres_fdw user mappings.
Oh, nice, greatly needed!
--
Bruce Momjian http://m
query
> ID of 0 is perhaps a utility statement, or perhaps nothing depending
> on the state of a backend entry, or even perhaps something else
> depending how on how modules make use and define such query IDs.
I thought each extension would export a function to compute the query
id, and y
On Tue, Nov 12, 2019 at 09:51:33PM -0500, Bruce Momjian wrote:
> On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus Hagander wrote:
> > On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian wrote:
> > We had this
> > discussion in relation to archive_command years
riable and there is no confusion over having two variables
and their conflicting behavior.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Thu, Nov 14, 2019 at 11:34:24AM -0500, Andrew Dunstan wrote:
>
> On 11/14/19 11:07 AM, Bruce Momjian wrote:
> > On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
> >> On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra
> >> I think it would be be
On Thu, Nov 14, 2019 at 02:07:58PM -0300, Alvaro Herrera wrote:
> On 2019-Nov-14, Bruce Momjian wrote:
>
> > I was assuming if the variable starts with a #, it is a shared object,
> > if not, it is a shell command:
> >
> > ssl_passphrase_command='#/lib/x
aining databases, then load the
dumped database. Attached is a patch that improves the wording.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Anc
On Thu, Nov 14, 2019 at 02:46:29PM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Oct-07, Bruce Momjian wrote:
> >> and the "in database" (which I have changed to capitalized "In database"
> >> in the attached patch), looks like:
>
On Thu, Nov 14, 2019 at 05:49:12PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Nov 14, 2019 at 04:06:52PM -0300, Alvaro Herrera wrote:
> >> BTW, how is one supposed to "manually upgrade databases that use
> >> contrib/isb"? This part is not v
On Fri, Nov 15, 2019 at 12:32:55AM +0100, Daniel Gustafsson wrote:
> > On 14 Nov 2019, at 23:16, Bruce Momjian wrote:
> >
> > On Thu, Nov 14, 2019 at 04:06:52PM -0300, Alvaro Herrera wrote:
> >> BTW, how is one supposed to "manually upgrade databases that use
>
On Sun, Nov 17, 2019 at 09:54:55PM +1300, Thomas Munro wrote:
> On Sat, Sep 28, 2019 at 4:20 AM Bruce Momjian wrote:
> > On Wed, Sep 4, 2019 at 06:18:31PM +1200, Thomas Munro wrote:
> > > A few years back[1] I experimented with a simple readiness API that
> > >
t; ... really hard.
I agree with Stephen's request. We have been waiting for the executor
rewrite for a while, so let's just do something simple and see how it
performs.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Thu, Dec 5, 2019 at 03:19:50PM -0500, Robert Haas wrote:
> On Thu, Dec 5, 2019 at 1:12 PM Bruce Momjian wrote:
> > I agree with Stephen's request. We have been waiting for the executor
> > rewrite for a while, so let's just do something simple and see how
with unique
> indexes.
In the past we tried to increase the number of cases where HOT updates
can happen but were unable to. Would this help with non-HOT updates?
Do we have any benchmarks where non-HOT updates cause slowdowns that we
can test on this?
--
Bruce Momjian http://momj
> degrade the index structure in order to deal with a *temporary* burst
> in versions that need to be stored. That's really bad.
Yes, I was thinking why do we need to optimize duplicates in a unique
index but then remembered is a version problem.
--
Bruce Momjian ht
hould see this too,
> but it is still a good idea to remove it for code clarity.
Agreed, patch applied.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+
601 - 700 of 2952 matches
Mail list logo
