partition key to provide “pretty
> > good” pruning. The net result is that you get 2-3x the IO due to the
> > lack of global index (same workaround as first story above).
>
> Is that basically like a global BRIN index with granularity at the
> partition level?
Exac
t; -
> itemid = PageGetItemId(page, topoff);
> itup = (IndexTuple) PageGetItem(page, itemid);
> BTreeInnerTupleSetDownLink(itup, rightsib);
>
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprised
ctions = none # none, pl, all
> -#track_activity_query_size = 1024# (change requires restart)
> +#track_activity_query_size = 1024# range 100B - 1MB (change requires
> restart)
> #stats_temp_directory = 'pg_stat_tmp'
>
>
--
Bruce Momjian
On Thu, Dec 19, 2019 at 10:55:42AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Nov 26, 2019 at 01:45:10PM +, Ranier Vilela wrote:
> >> Same case on nbtpage.c at line 1637, with var opaque.
> >> make check, passed all 195 tests here with all commits.
On Thu, Dec 19, 2019 at 09:48:40AM +0100, Jose Luis Tallon wrote:
> On 19/12/19 4:03, Bruce Momjian wrote:
> > On Mon, Nov 25, 2019 at 03:44:39PM -0800, Jeremy Schneider wrote:
> > > On 11/25/19 15:05, Jeremy Schneider wrote:
> > > > ... the cost of doing the indiv
On Thu, Dec 19, 2019 at 11:28:55AM -0800, Jeremy Schneider wrote:
> On 12/19/19 08:12, Bruce Momjian wrote:
> > I don't see lossy BRIN indexes helping with the uniqueness use-case, and
> > I am not sure they would help with the rare case either. They would
> > help for r
On Fri, Dec 20, 2019 at 02:35:37PM +0300, Alexey Kondratov wrote:
> On 19.12.2019 20:52, Robert Haas wrote:
> > On Thu, Dec 19, 2019 at 10:59 AM Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Good question. I am in favor of allowing a larger value if no one
&
ort GSSAPI, or this only happens if
libpq asks for GSSAPI?
--
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, Dec 20, 2019 at 06:14:09PM +, Andrew Gierth wrote:
> >>>>> "Bruce" == Bruce Momjian writes:
>
> >> This came up recently on IRC, not sure if the report there was
> >> passed on at all.
> >>
> >> ProcessStartupP
oefully limited and
> something we need to prioritize more.
Uh, how much does the new field get us near the CPU cache line max size
for a single PGPROC entry?
--
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 +
but comments were
confusing
regarding which one is processed where.
Author: Julien Rouhaud
Reviewed-by: Daniel Gustafsson
Discussion:
https://postgr.es/m/caobau_a2ivitg7fe10yo_gcw+zqchnfhra_ndiktf3ur65b...@mail.gmail.com
--
Bruce Momjian
t;
> https://www.postgresql.org/message-id/20180125204630.GA27619%40momjian.us
>
> If you want to reverse that decision you need to present cogent arguments
> why, not just send in a patch.
Do we need a C comment to document why no whitespace is allowed
before it?
--
Bruce Momj
nch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/8729fa72483f8a9acf299508bb2cbae1aa9a29b8
Modified Files
--
src/backend/utils/misc/pg_controldata.c | 2 +-
1 file changed, 1 insertion(+), 1 d
On Sat, Dec 21, 2019 at 03:42:21PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Do we need a C comment to document why no whitespace is allowed
> > before it?
>
> Probably, else we may not remember next time somebody wants to
> change it.
Done, applied to master on
t without guaranteeing the client
knows, but in the second case, we tell the client success with a warning
that the synchronous standby didn't get the commit. Are clients even
checking warning messages? You see it in psql, but what about
applications that use Postgres. Do they even check fo
BC, and -1
* is 11 BC thru 2 BC...
FYI, these two URLs suggest the inconsistency is OK:
https://www.timeanddate.com/calendar/decade.html
https://en.wikipedia.org/wiki/Decade
--
Bruce Momjian http://momjian.us
EnterpriseDB http:/
ient. This means other
clients are acting on data that is durable on the local machine, but not
on the replicated machine, even if synchronous_standby_names is set.
I feel this topic needs a lot more thought before we consider changing
anything.
--
Bruce Momjian http://momjian.us
E
resistance by breaking such lines to avoid the ugliness:
>
> if (IsA(leftop, Var) &&
> IsA(rightop, Const))
In the past I would use a post-processing step after BSD indent to fix
up these problems.
--
Bruce Momjian http://momjian.us
EnterpriseDB
e parent can only
> sequennly process the data from data nodes.
>
> Providing there is no performance degrdation for non FDW append queries,
> I would recomend to consider this patch as an interim soluton while we are
> waiting for parallel FDW scan.
Wow, these are very impressive re
on 20X0 that we
don't need to document that Postgres does that.
--
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 +
r as using tab-delimited data, I know this usage was compared to
postgresql.conf and pg_hba.conf, which don't change much. However,
those files are not usually written, and do not contain user data, while
the backup file might contain user-specified paths if they are not just
relative to
system tables GUC settings are less likely to be
renamed than postgresql.conf.auto settings. FYI, we are more inclined
to allow postgresql.conf-only changes than others because there is less
impact on applications.
--
Bruce Momjian http://momjian.us
Enterpri
l silently truncates
> the password specified in the prompt into 99B if its length is
> more than 99B. I think that psql should emit a warning in this case
> so that users can notice that.
I think we should be using a macro to define the maximum length, rather
than have 100 used in various
On Tue, Jan 21, 2020 at 04:19:13PM +0100, David Fetter wrote:
> On Tue, Jan 21, 2020 at 10:12:52AM -0500, Bruce Momjian wrote:
> > I think we should be using a macro to define the maximum length, rather
> > than have 100 used in various places.
>
> It's not just 100 in s
ed
> XA managers.
I think the big question is whether we want to make active prepared
transactions more visible to administrators, either during server start
or idle duration.
--
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 +
--- we
just need to check for non-ASCII, which is much easier. Another
problem, though, is how do you _flag_ file names as being
base64-encoded? Use another JSON field to specify that?
--
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 +
as to
> call the field either 'path' or 'path_base64' depending on whether
> base-64 escaping was used. That seems better to me than having a field
> called 'path' and a separate field called 'is_path_base64' or
> whatever.
Hmm, so the JSON key
On Thu, Jan 23, 2020 at 03:20:27PM -0300, Alvaro Herrera wrote:
> On 2020-Jan-23, Bruce Momjian wrote:
>
> > On Thu, Jan 23, 2020 at 01:05:50PM -0500, Robert Haas wrote:
> > > > Another
> > > > problem, though, is how do you _flag_ file names as being
>
http://beets.io/blog/paths.html
Is there any danger of assuming a non-UTF8 sequence to be UTF8 even when
it isn't, except that it displays oddly? I am thinking of a non-UTF8
sequence that is value UTF8.
--
Bruce Momjian http://momjian.us
EnterpriseDB http
Use correct connection name variable in ecpglib.
Fixed-by: Kuroda-san
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ An
mal. From the modes table below, we see
> - * that it means that the codeword encodes three 12-bit integers. In
> decimal,
> + * that it means that the codeword encodes three 20-bit integers. In
> decimal,
> * those integers are 18, 50 and 20. Because we encode deltas rat
On Thu, Mar 14, 2019 at 12:53:02AM -0700, Mitar wrote:
> Hi!
>
> On Fri, Jan 25, 2019 at 2:32 PM Bruce Momjian wrote:
> > I wrote a blog entry about this:
> >
> > https://momjian.us/main/blogs/pgblog/2017.html#June_2_2017
> >
> > This is certain
but that ship sailed *years*
> ago.
Uh, did we consider keeping hostgss and changing the auth part at the
end to "gssauth"?
--
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 +
t;users" specify their needs, we will see ;o)
Why can't we just explose the hash computation as an SQL function and
let people call it with pg_stat_activity.query or wherever they want the
value? We can install multiple functions if needed.
--
Bruce Momjian http://momjia
ave pre-images (GUC
full_page_writes) stored in WAL so they are protected from partial
writes, hence are less likely to need checksum protection to detect
corruption.
--
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 +
ut we
don't have code to do that yet, and most people use link anyway.
--
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 +
g from bloat due to
> auto-vacuum not knowing how many dead tuples there are in the tables.
OK, let me step back. Why are people resetting the statistics
regularly? Based on that purpose, does it make sense to clear the
stats that effect autovacuum?
--
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 +
and overhead of
implementing it.
I do think the Pluggable storage API is the right approach, and, if you
are going to go that route, adding #4 compression seems very worthwhile.
--
Bruce Momjian http://momjian.us
EnterpriseDB http:
dex AMs. As opposed to the proposed undo and SLRU
> SMGRs that provide layouts specialised for different life cycles.
A bigger issue is that our documention often refers to "disk" as storage
when including SSD storage, which clearly have no disks. They are
"solid state drives",
greed. Requirement #2 is not needed for WAL:
https://en.wikipedia.org/wiki/Disk_encryption_theory#Problem_definition
2. Data retrieval and storage should both be fast operations, no
matter where on the disk the data is stored.
because you are not writing into random p
o propagate into the wild. A year is not too much; IMO it's
> barely enough.
It would be nice to address channel binding as part of this.
--
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 +
he
> existing external tools to leverage.
I think there is some interesting complexity brought up in this thread.
Which options are going to minimize storage I/O, network I/O, have only
background overhead, allow parallel operation, integrate with
pg_basebackup. Eventually we will need to evalu
ng tools could retain modblock files along with WAL, could
pull full-page-writes from WAL, or from PGDATA. It avoids the need to
scan 16MB WAL files, and the WAL files and modblock files could be
expired independently.
--
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, Apr 15, 2019 at 09:04:13PM -0400, Robert Haas wrote:
> On Mon, Apr 15, 2019 at 4:31 PM Bruce Momjian wrote:
> > Can I throw out a simple idea? What if, when we finish writing a WAL
> > file, we create a new file 00010001.modblock which
> > lists all
EXPLAIN ANALYZE VERBOSE EXECUTE e ('pg_class');
EXPLAIN ANALYZE VERBOSE EXECUTE e ('pg_class');
--> EXPLAIN ANALYZE VERBOSE EXECUTE e ('pg_class');
The last explain will _not_ show any log_planner_stats duration, though
it does show an EXPLAIN planning time:
On Wed, Apr 17, 2019 at 12:04:35AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I have found that log_planner_stats only outputs stats until the generic
> > plan is chosen. For example, if you run the following commands:
>
> Uh, well, the planner doesn't get run
oring the file name and block number in the modblock
file, using the database oid, relfilenode, and block number (3 int32
values) should be sufficient.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I a
$ ls --
file1 file2
FYI, 'gcc --' (using Debian 6.3.0-18+deb9u1) does throw an error, so it
is inconsistent.
--
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 +
sed for non-\x
display? What do people want the non-pspg pager to do?
--
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, Apr 18, 2019 at 05:32:57PM +0200, David Fetter wrote:
> On Wed, Apr 17, 2019 at 11:57:35AM -0400, Bruce Momjian wrote:
> > Also, instead of storing the file name and block number in the modblock
> > file, using the database oid, relfilenode, and block number (3 int32
> &
On Thu, Apr 18, 2019 at 05:45:24PM +0200, Pavel Stehule wrote:
> čt 18. 4. 2019 v 15:51 odesílatel Bruce Momjian napsal:
> In testing pspg, it seems to work fine with tabular and \x-non-tabular
> data. Are you asking for a pager option that is only used for non-\x
> displ
On Thu, Apr 18, 2019 at 06:06:40PM +0200, Pavel Stehule wrote:
>
>
> čt 18. 4. 2019 v 17:58 odesílatel Bruce Momjian napsal:
>
> On Thu, Apr 18, 2019 at 05:45:24PM +0200, Pavel Stehule wrote:
> > čt 18. 4. 2019 v 15:51 odesílatel Bruce Momjian
> napsal:
>
ery second, they would probably still be happy to have a new
> modified block file only, say, every 10 seconds.
Agreed.
--
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, Apr 18, 2019 at 04:25:24PM -0400, Robert Haas wrote:
> On Thu, Apr 18, 2019 at 3:51 PM Bruce Momjian wrote:
> > How would you choose the STARTLSN/ENDLSN? If you could do it per
> > checkpoint, rather than per-WAL, I think that would be great.
>
> I thought o
pact will be about the same as having one additional
> standby, give or take.
Good point.
--
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 Sat, Apr 20, 2019 at 12:09:42AM -0400, Robert Haas wrote:
> On Thu, Apr 18, 2019 at 5:47 PM Bruce Momjian wrote:
> > How would the modblock file record all the modified blocks across
> > restarts and crashes? I assume that 1G of WAL would not be available
> > for scan
On Sat, Apr 20, 2019 at 04:17:08PM -0400, Robert Haas wrote:
> On Sat, Apr 20, 2019 at 9:18 AM Bruce Momjian wrote:
> > > I think you've got to prevent the WAL from being removed until a
> > > .modblock file has been written. In more detail, you should (a) scan
>
On Sun, Apr 21, 2019 at 06:24:50PM -0400, Robert Haas wrote:
> On Sat, Apr 20, 2019 at 5:54 PM Bruce Momjian wrote:
> > Good point. You mentioned:
> >
> > It seems better to me to give the files names like
> > ${TLI}.${STARTL
nning to do such operations when a segment finishes being
> written, which would be much better.
I think your point is that the 16MB is more likely to be in memory,
while the 1GB is less likely.
--
Bruce Momjian http://momjian.us
EnterpriseDB h
On Mon, Apr 22, 2019 at 12:15:32PM -0400, Robert Haas wrote:
> On Mon, Apr 22, 2019 at 11:48 AM Bruce Momjian wrote:
> > My point is that you would normally only remove the modblock file when 4
> > is removed because this modblock files is useful for incremental backups
> > f
here and we can discuss it.
--
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, Apr 22, 2019 at 01:11:22PM -0400, Robert Haas wrote:
> On Mon, Apr 22, 2019 at 12:35 PM Bruce Momjian wrote:
> > I assumed the modblock files would be stored in the WAL archive so some
> > external tools could generate incremental backups using just the WAL
> > f
is infrastructure, we
> need to write the .modfiles kinda "raw" and do this processing in some
> later step.
>
> Now, maybe the incremental backup use case is so much more important the
> right thing to do is ignore this other use case, and I'm OK with that -
>
at take
us to meeing incremental backup needs? I can imagine db/relfilenode oid
volatility could be a problem, but might be fixable.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you
On Mon, Apr 22, 2019 at 08:52:11PM -0400, Bruce Momjian wrote:
> Well, the interesting question is whether the server will generate a
> single modblock file for all WAL in pg_wal only right before we are
> ready to expire some WAL, or whether modblock files will be generated
> offl
ey are hard to explain
I see the argument as wanting vague warm and fuzzy feelings that we are
improving the optimizer, which we are. I will see what I can do to get
those ideas into the PG 12 release notes in as concrete a way as
possible.
--
Bruce Momjian http://momjian.us
On Sat, Apr 27, 2019 at 02:04:33PM +1200, David Rowley wrote:
> On Sat, 27 Apr 2019 at 11:49, Bruce Momjian wrote:
> >
> > On Wed, Apr 24, 2019 at 02:46:15PM -0400, Adam Brusselback wrote:
> > > As a user, I am interested in the optimizer changes for sure, and I
> &
On Sat, Apr 27, 2019 at 02:47:44PM +1200, David Rowley wrote:
> On Sat, 27 Apr 2019 at 14:22, Bruce Momjian wrote:
> > > > * They are hard to explain
> > >
> > > That can be true, but we generally get there if not the first time
> > > then after a few
#x27;,'_');
to_timestamp
1976-01-01 00:00:00-05
Proposed patch attached.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, s
On Wed, May 1, 2019 at 10:01:50AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I don't think the changes made in PG 12 are documented accurately.
>
> That code is swapped out of my head at the moment, but it looks
> to me like the para before the one you changed is
n surprised by the churn caused by
this change, and have therefore questioned the value of it. Frankly,
there has been so much churn I am unclear if it can be easily reverted.
--
Bruce Momjian http://momjian.us
EnterpriseDB h
On Wed, May 1, 2019 at 09:08:54AM -0700, Andres Freund wrote:
> So sure, there's a few typo fixes, one bugfix, and one buildfarm test
> stability issue. Doesn't seem crazy for a nontrivial improvement.
OK, my ignorant opinion was just based on the length of discussion
threa
On Wed, May 1, 2019 at 11:20:05PM +0300, Arthur Zakirov wrote:
> Hello,
>
> On Wed, May 1, 2019 at 6:05 PM Bruce Momjian wrote:
> > Thanks. I think I see the sentence you are thinking of:
> >
> >to_timestamp and to_date
> >skip multiple bla
; for "MON"
> > DETAIL: The given value did not match any of the allowed values for this
> > field.
>
> Actually, FX takes effect on subsequent format patterns. This is not
> documented, but it copycats Oracle behavior. Sure, normally FX should
> be
ords, but only physical block-level redo records.
My blog entry covers some of this:
https://momjian.us/main/blogs/pgblog/2019.html#March_6_2019
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are,
Is there a reason pg_checksums is plural and not singular, i.e.,
pg_checksum? I know it is being renamed for PG 12. It might have
needed to be plural when it was pg_verify_checksums.
--
Bruce Momjian http://momjian.us
EnterpriseDB http
by
version number. pgcryptokey does this by allowing specification of a
encrypted data key by name or key_id.
It might be necessary to allow decryption to try several versions of a
key to see which one decrypts the data. While this is possible with PGP
because there is a checksum payload, it isn
ion and WAL. I don't think it
is very valuable to use these options so reencryption will be easier.
In many cases, taking any object offline might cause the application to
fail, and having multiple encrypted data keys active will allow key
replacement to be done on an as-needed basis.
--
B
se notes that it was odd we could
control this via a CREATE TABLE option but not VACUUM. I have updated
the release notes.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As
On Wed, May 8, 2019 at 03:32:04PM -0500, Justin Pryzby wrote:
> I noticed you added release notes at bdf595adbca195fa54a909c74a5233ebc30641a1,
> thanks for writing them.
> -This improve optimization for columns with non-uniform distributions that
> often appear in WHERE clauses.
> +This improves
es that are implementation-behavior in the release notes? Usually
we don't.
Applied patch attached, docs updated:
http://momjian.us/pgsql_docs/release-12.html
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you a
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/bin/pg_upgrade/pg_upgrade.c;h=0b304bbd56ab0204396838618e86dfad757c2812;hb=HEAD
It doesn't mention extensions.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so
cause
> > conflicts (Surafel Temesgen)
> > +
>
> restore *using* INSERT statements ?
> cause "unique index" conflicts ?
I am not sure "unique index" helps since most people think of ON
CONFLICT and not its implementation.
Applied patch attached, URL updated:
On Thu, May 9, 2019 at 07:13:35PM -0500, Justin Pryzby wrote:
> On Thu, May 09, 2019 at 07:35:18PM -0400, Bruce Momjian wrote:
> > I have made your other changes, with adjustment, patch attached.
> >
> > The results are here:
> >
> > http://momjian.us/pgsql
On Thu, May 9, 2019 at 08:34:49PM -0500, Justin Pryzby wrote:
> On Thu, May 09, 2019 at 09:02:51PM -0400, Bruce Momjian wrote:
> > These were all very helpful. I adjusted your changes to create the
> > attached applied patch. URL updated:
>
> Thanks.
>
> >
On Thu, May 9, 2019 at 07:10:43PM -0700, Peter Geoghegan wrote:
> On Thu, May 9, 2019 at 6:03 PM Bruce Momjian wrote:
> > These were all very helpful. I adjusted your changes to create the
> > attached applied patch. URL updated:
>
> I noticed that the compatibility not
On Fri, May 10, 2019 at 03:34:15PM +1200, David Rowley wrote:
> On Fri, 10 May 2019 at 13:03, Bruce Momjian wrote:
> >
> > On Thu, May 9, 2019 at 07:13:35PM -0500, Justin Pryzby wrote:
> > > On Thu, May 09, 2019 at 07:35:18PM -0400, Bruce Momjian wrote:
> > >
On Fri, May 10, 2019 at 06:53:55PM -0700, Peter Geoghegan wrote:
> On Fri, May 10, 2019 at 6:02 PM Bruce Momjian wrote:
> > Have new btree indexes sort duplicate index entries in heap-storage
> > order (Peter Geoghegan)
> >
> > This slightly
On Sat, May 11, 2019 at 03:06:40AM +0100, Andrew Gierth wrote:
> >>>>> "Bruce" == Bruce Momjian writes:
> Bruce> Do I need more?
>
> That isn't quite how I'd have worded it, but I'm not sure what the best
> wording is. Something like:
&
On Fri, May 10, 2019 at 07:31:21PM -0700, Peter Geoghegan wrote:
> On Fri, May 10, 2019 at 7:11 PM Bruce Momjian wrote:
> > > Whether or not you include more details is not what I care about here
> > > -- I *agree* that this is insignificant.
>
> > Well, we can
On Sat, May 11, 2019 at 10:36:13AM -0400, Bruce Momjian wrote:
> On Fri, May 10, 2019 at 07:31:21PM -0700, Peter Geoghegan wrote:
> > > I think I have understood the nuances, as listed above --- I just don't
> > > agree with the solution.
> >
> > To be clear
On Sat, May 11, 2019 at 10:28:08AM -0700, Peter Geoghegan wrote:
> On Sat, May 11, 2019 at 7:40 AM Bruce Momjian wrote:
> > > > > I think I have understood the nuances, as listed above --- I just
> > > > > don't
> > > > > agree with the solu
On Sat, May 11, 2019 at 11:47:42AM -0700, Peter Geoghegan wrote:
> On Sat, May 11, 2019 at 11:02 AM Bruce Momjian wrote:
> > OK, commit removed.
>
> You're mistaken -- nothing has been pushed to master in the last 3 hours.
I am not mistaken. I have removed it from my loca
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.
--
Bruce Momjian http
a new path syntax. Is it a new storage format for JSON, or something
else? I need help on this.
--
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, May 12, 2019 at 10:49:07AM -0400, Jonathan Katz wrote:
> Hi Bruce,
>
> On 5/11/19 4:33 PM, Bruce Momjian wrote:
> > I have posted a draft copy of the PG 12 release notes here:
> >
> > http://momjian.us/pgsql_docs/release-12.html
> >
> > They a
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, but commit
> > 72b6460336e86ad5
On Mon, May 13, 2019 at 01:37:25PM +1200, David Rowley wrote:
> On Sun, 12 May 2019 at 08:33, Bruce Momjian wrote:
> >
> > I have posted a draft copy of the PG 12 release notes here:
> >
> > http://momjian.us/pgsql_docs/release-12.html
>
> I noticed a
includes links to the main docs, where
> > appropriate. Our official developer docs will rebuild in a few hours.
>
> Pgbench entry "Improve pgbench error reporting with clearer messages and
> return codes" is by Peter Eisentraut, not me. I just reviewed it.
Thanks, fixed
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:
> >
701 - 800 of 2669 matches
Mail list logo
