ot clear about this.
>
> Indeed.
>
> > Can you fix it?
>
> Sure. Attached patch adds an explicit sentence about it, as it was only
> hinted about in the default initialization command string, and removes a
> spurious empty paragraph found nearby.
Thanks,
On Wed, May 6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote:
>
>
> > 5 мая 2020 г., в 08:16, Bruce Momjian написал(а):
> >
> > I have committed the first draft of the PG 13 release notes. You can
> > see them here:
> >
> > htt
On Wed, May 6, 2020 at 03:18:54PM +0300, Alexander Korotkov wrote:
> On Tue, May 5, 2020 at 6:16 AM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 13 release notes. You can
> > see them here:
> >
> > https://momjian.us/pgsq
On Tue, May 5, 2020 at 01:45:37PM -0500, Justin Pryzby wrote:
> On Tue, May 05, 2020 at 02:10:24PM -0400, Bruce Momjian wrote:
> > > > > | This is controlled by GUC wal_skip_threshold.
> > > > > I think you should say that's a size threshold which det
On Tue, May 5, 2020 at 04:39:58PM -0500, Justin Pryzby wrote:
> On Tue, May 05, 2020 at 05:34:26PM -0400, Bruce Momjian wrote:
> > On Tue, May 5, 2020 at 02:37:16PM -0400, Bruce Momjian wrote:
> > > On Tue, May 5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote:
> > > &
On Tue, May 5, 2020 at 11:44:33AM -0700, Jeff Davis wrote:
> On Mon, 2020-05-04 at 23:16 -0400, Bruce Momjian wrote:
> > I have committed the first draft of the PG 13 release notes. You can
> > see them here:
> >
> > https://momjian.us/pgsql_docs/release-13.h
On Tue, May 5, 2020 at 05:31:26PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2020-May-05, Bruce Momjian wrote:
> >> I tried a few approaches but ended up with this:
> >>
> >> Improve control of prepared statement parameter logging (
On Tue, May 5, 2020 at 02:37:16PM -0400, Bruce Momjian wrote:
> On Tue, May 5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote:
> > Do you want to include any of these?
> >
> > 5823677acc Provide pgbench --show-script to dump built-in scripts.
I have added the above entry
On Tue, May 5, 2020 at 03:21:00PM -0400, Alvaro Herrera wrote:
> On 2020-May-05, Bruce Momjian wrote:
>
> > > |Allow incremental sorting (James Coleman, Alexander Korotkov)
> > > s/Allow/Implement/ ?
> >
> > Agreed.
>
> FWIW I think T
On Tue, May 5, 2020 at 03:44:37PM -0400, Alvaro Herrera wrote:
> On 2020-May-05, Bruce Momjian wrote:
>
> > On Tue, May 5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote:
> > > Do you want to include any of these?
> > >
> > > 5823677acc Provide pgbench
On Thu, May 7, 2020 at 08:12:30PM +0300, Alexander Korotkov wrote:
> On Thu, May 7, 2020 at 2:46 AM Bruce Momjian wrote:
> >
> > Allow CREATE INDEX to specify the GiST signature length and maximum
> > number of integer ranges (Nikita Glukhov)
> >
On Fri, May 15, 2020 at 03:55:19PM +0900, Fujii Masao wrote:
>
>
> On 2020/05/05 12:16, Bruce Momjian wrote:
> > I have committed the first draft of the PG 13 release notes. You can
> > see them here:
> >
> > https://momjian.us/pgsql_docs/release-13.ht
xref links. Release notes
> > updated.
>
> Thanks!
>
> > Odd I got no warning for this on 'make check'.
>
> I'm not sure why, but btw I got the message when I compiled the document on
> Mac.
I don't think I looked at the HTML build output, only the check one, so
that mi
On Thu, May 14, 2020 at 09:51:41AM +0900, Kyotaro Horiguchi wrote:
> At Wed, 13 May 2020 11:15:18 -0400, Bruce Momjian wrote in
> > On Wed, May 13, 2020 at 11:56:33AM +0900, Kyotaro Horiguchi wrote:
> It is just an more accurate (not an detailed) version of the
> previously propo
Thanks, applied.
---
On Mon, May 18, 2020 at 11:18:51AM +0200, Daniel Gustafsson wrote:
> > On 5 May 2020, at 05:16, Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 13 relea
;
> > What are the thoughts about then marking the postfix operator deprecated
> > and eventually removing it?
>
> I am greatly in favor of removing postfix operators as soon as possible.
Agreed.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
ly for COPY
> operations and always using fsync, but the implementation had a bug
> that could cause data loss during crash recovery.
That is too much detail for the release notes. We already will link to
the docs. Why put it here?
--
Bruce Momjian https://momjian.us
EnterpriseDB
gt;
> > Again, this is the first hash you gave.
>
> Possibly, but as the "THIS WAS NOT DOCUMENTED BEFORE?" question seemed to
> still be in the release notes, I gathered that the information had not
> reached its destination, hence the possible repetition. But maybe the is
d to
> > > still be in the release notes, I gathered that the information had not
> > > reached its destination, hence the possible repetition. But maybe the
> > > issue
> > > is that this answer is not satisfactory. Sorry for the inconvenience.
> >
> >
On Wed, May 6, 2020 at 10:20:57PM -0700, Noah Misch wrote:
> On Wed, May 06, 2020 at 07:40:25PM -0400, Bruce Momjian wrote:
> > On Tue, May 5, 2020 at 11:39:10PM -0700, Noah Misch wrote:
> > > On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
> > > >
On Wed, May 6, 2020 at 04:01:44PM -0400, Chapman Flack wrote:
> On 05/05/20 10:31, Bruce Momjian wrote:
> > On Tue, May 5, 2020 at 09:20:39PM +0800, John Naylor wrote:
> >> ... This patch is
> >> about the server encoding, which formerly needed to be utf-8 for
> >
On Thu, May 7, 2020 at 08:48:49AM -0400, Bruce Momjian wrote:
> I think trying to put this all into one item is too complex, but I did
> merge two of the items together, so we have two items now:
I ended up adjusting the wording again, so please review the commit or
the website:
On Wed, May 6, 2020 at 07:31:14PM -0500, Justin Pryzby wrote:
> On Wed, May 06, 2020 at 07:35:34PM -0400, Bruce Momjian wrote:
> > On Wed, May 6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote:
> > > I'm not sure, but probably it worth mentioning in "General perf
or
un-fun an item is should be used as criteria.
> About pgbench, ISTM that d37ddb745be07502814635585cbf935363c8a33d is worth
> mentionning because it is a user-visible change.
Uh, that is not usually something I mention because, like error message
changes, it is nice, but few people need to kno
On Thu, May 7, 2020 at 11:25:47AM +0500, Andrey M. Borodin wrote:
>
>
> > 7 мая 2020 г., в 04:35, Bruce Momjian написал(а):
> >
> > On Wed, May 6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote:
> >>
> >>
> >>> 5 мая 2020 г., в
On Thu, May 7, 2020 at 12:06:33AM +0900, Amit Langote wrote:
> Hi Bruce,
>
> On Tue, May 5, 2020 at 12:16 PM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 13 release notes. You can
> > see them here:
> >
> > https:
On Mon, May 11, 2020 at 11:38:33PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, May 11, 2020 at 11:08:35PM -0400, Chapman Flack wrote:
> >> 'specify' ?
>
> > I like that word if Tom prefers it.
>
> 'specify' works for me.
Sure, done.
-
On Tue, Mar 17, 2020 at 10:58:54PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I have implemented the ideas above in the attached patch. I have
> > synchronized the syntax to match SELECT, and synchronized the paragraphs
> > describing the item.
>
> I thi
h loop iteration.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
fferent encryption key for block
> encryption. Therefore we will end up with having two encryption keys
> inside database. Maybe we can discuss this after the key manager has
> been introduced.
I know Sehrope liked derived keys so let's get his feedback on this. We
might want to have two keys
On Thu, Mar 19, 2020 at 11:42:36PM +0900, Masahiko Sawada wrote:
> On Thu, 19 Mar 2020 at 22:00, Bruce Momjian wrote:
> >
> > On Thu, Mar 19, 2020 at 06:32:57PM +0900, Masahiko Sawada wrote:
> > > On Thu, 19 Mar 2020 at 15:59, Masahiko Sawada
> > > > I und
On Fri, Mar 20, 2020 at 12:50:27AM +0900, Masahiko Sawada wrote:
> On Fri, Mar 20, 2020 at 0:35 Bruce Momjian wrote:
> Well, the issue is if the user can control the user key, there is might be
> a way to make the user key do nothing.
>
> Well I meant ‘USER_KEY:’ is a fixe
On Mon, Mar 16, 2020 at 05:55:26PM -0400, Bruce Momjian wrote:
> Report bugs mailto:pgsql-b...@lists.postgresql.org
> PostgreSQL home page https://www.postgresql.org/
>
> I kind of prefer the last one since the can both be pasted directly into
> a browser.
Act
On Tue, Mar 17, 2020 at 07:15:05PM -0400, Dave Cramer wrote:
> On Tue, 17 Mar 2020 at 16:47, Bruce Momjian wrote:
> Third, the idea that individual interfaces, e.g. JDBC, should throw an
> error in this case while the server just changes the COMMIT return tag
>
same as
> it is in SELECT.
>
> (Compare the handling of with_query, which has pretty much the
> same problem of being way too complex to document three times.)
I have implemented the ideas above in the attached patch. I have
synchronized the syntax to match SELECT, and synchroniz
tions that track statement
errors and issue rollbacks will be fine. So, we are left with
applications that issue COMMIT and expect success after a transaction
block has failed. Do we know how other database systems handle this?
--
Bruce Momjian https://momjian.us
Enterprise
ved quoting. This patch
backpatches the "could not open" cause to PG 12, where it was
first widely used, and backpatches the quoting fix in that patch
to all supported releases.
Because some of the branches are different, I am atta
port PG_COLORS='error=01;34:locus=01;33'
>
> Having to dig into the code to find out that stuff is not a good user
> experience. And I found out about that only because I worked on a
> patch touching this area yesterday.
I can confirm there is still no mention of PG_COLORS in our
docu
bOn Mon, Mar 16, 2020 at 09:10:25PM -0300, Alvaro Herrera wrote:
> On 2020-Mar-16, Bruce Momjian wrote:
>
> > On Mon, Mar 16, 2020 at 05:55:26PM -0400, Bruce Momjian wrote:
> > > Report bugs mailto:pgsql-b...@lists.postgresql.org
> > > PostgreSQL home p
ss phrase.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Fri, Mar 20, 2020 at 11:15:07PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> >> I can confirm there is still no mention of PG_COLORS in our
> >> documentation.
>
> > My mistake, PG_COLOR (not PG_COLORS) is documented properly.
>
> Yeah, but the poi
On Thu, Mar 19, 2020 at 10:15:57PM -0400, Bruce Momjian wrote:
> On Tue, Mar 3, 2020 at 02:31:01PM +0900, Michael Paquier wrote:
> > On Mon, Mar 02, 2020 at 01:00:44PM +0100, Juan José Santamaría Flecha wrote:
> > > - The new entry in the documentation, specially as the P
On Sat, Mar 21, 2020 at 02:12:46PM +0900, Masahiko Sawada wrote:
> On Sat, 21 Mar 2020 at 05:30, Bruce Momjian wrote:
> > We should create an SQL-level master key that is different from the
> > block-level master key. By using separate keys, and not deriving them
> > from a
On Sat, Mar 21, 2020 at 10:01:02AM -0400, Bruce Momjian wrote:
> On Sat, Mar 21, 2020 at 02:12:46PM +0900, Masahiko Sawada wrote:
> > On Sat, 21 Mar 2020 at 05:30, Bruce Momjian wrote:
> > > We should create an SQL-level master key that is different from the
> >
this is a new bug in PG 12. The attached
patch fixes PG 12 and master.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
diff
On Sat, Mar 21, 2020 at 02:14:44PM -0400, Bruce Momjian wrote:
> On Tue, Mar 10, 2020 at 01:47:14PM +0100, Filip Janus wrote:
> > Hello,
> > After upgrade from 11.2 to 12.2 I found, that build of ecpg component
> > depends
> > on pgcommon_shlib and pgport_shlib. But bu
On Sat, Mar 21, 2020 at 07:30:48PM +, Dagfinn Ilmari Mannsåker wrote:
> Bruce Momjian writes:
>
> > On Sat, Mar 21, 2020 at 02:14:44PM -0400, Bruce Momjian wrote:
> >> On Tue, Mar 10, 2020 at 01:47:14PM +0100, Filip Janus wrote:
> >> > Hello,
> >>
with 018_wal_optimize.pl.
> > > (0004-Add-TAP-test-for-WAL-skipping-feature.patch)
> >
> > That is a good idea. Rather than make it specific to this test, I would
> > like
> > to back-patch all applicable test files from 9.6 src/test/recovery. I'll
> > plan
On Mon, Mar 23, 2020 at 03:55:34PM +0900, Masahiko Sawada wrote:
> On Sat, 21 Mar 2020 at 23:50, Bruce Momjian wrote:
> > Actually, I think we need three files:
> >
> > * TDE WAL key file
> > * TDE block key file
> > * SQL-level file
> >
> > Primar
On Mon, Mar 23, 2020 at 01:00:24PM -0300, Alvaro Herrera wrote:
> On 2020-Mar-18, Bruce Momjian wrote:
>
> > On Tue, Feb 25, 2020 at 09:35:52AM +0100, Antonin Houska wrote:
> > > I've noticed that two variables in RelationCopyStorage() are defined in a
> > > scope
> + application_name text,
> + backend_type text
> ) SERVER pglog
> OPTIONS ( filename '/home/josh/data/log/pglog.csv', format 'csv' );
>
Patch applied to master, thanks.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterp
l update the patch and post.
Yes, that makes sense to me.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
t was last written to the file system, and
flush is the last time is was flushed to storage.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
scovered to be sub-optimal in August/September. While a relesae
team might have gotten the release out before January, that isn't
certain.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
actually have never seen URLs in <>, only email addresses. I think
using <> for URLs and emails is confusing because they usually have
different actions, unless we want to add mailto:
Report bugs <mailto:pgsql-b...@lists.postgresql.org>
PostgreSQ
On Mon, May 4, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
> I have committed the first draft of the PG 13 release notes. You can
> see them here:
>
> https://momjian.us/pgsql_docs/release-13.html
>
> It still needs markup, word wrap, and indenting. The community
On Fri, May 8, 2020 at 12:32:16AM +0900, Amit Langote wrote:
> On Thu, May 7, 2020 at 9:48 PM Bruce Momjian wrote:
> > On Thu, May 7, 2020 at 12:06:33AM +0900, Amit Langote wrote:
> > > +Author: Etsuro Fujita
> > > +2020-04-08 [c8434d64c] Allow partitionwise joins i
On Thu, May 7, 2020 at 09:49:49AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > OK, I have moved her name to be first. FYI, this commit was backpatched
> > back through PG 11, though the commit message doesn't mention that.
>
> If it was back-patched, it should not be
On Thu, May 7, 2020 at 11:30:40PM +0900, Amit Langote wrote:
> On Thu, May 7, 2020 at 11:12 PM Bruce Momjian wrote:
> > Well, her name was there already for a later commit that was not
> > backpatched, so I just moved her name earlier. The fact that her name
> > was
_date() is
supposed to match, making -1 as 1 BC.
Because we already have the to_date/make_date inconsistency, and the -1
to -2 BC mapping is confusing, and doesn't match Oracle, I think the
clean solution is to change PG 14 to treat -1 as 1 BC, and document the
incompatibility in the rel
On Wed, Apr 1, 2020 at 08:57:18AM -0300, Ranier Vilela wrote:
> Hi,
> New patch with yours suggestions.
Patch applied to head, thanks.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is
On Wed, Sep 2, 2020 at 10:45:30AM +0900, Kyotaro Horiguchi wrote:
> At Tue, 1 Sep 2020 11:47:34 -0400, Bruce Momjian wrote in
> > OK, I have developed the attached patch based on yours. I reordered the
> > tests, simplified the documentation, and removed the hint since they
argument that it's going to require more
> maintenance effort than any other part of the system does.
Well, my point is that even bucket/calculation/data text respresentation
changes could affect dumping statistics, and that is kind of rare for
other changes we make.
--
Bruce Momjian ht
On Mon, Aug 31, 2020 at 05:46:22PM -0400, Bruce Momjian wrote:
> On Mon, Aug 31, 2020 at 01:53:01PM -0400, Tom Lane wrote:
> > Stephen Frost writes:
> > > Feature work either requires changes to pg_dump, or not. I agree that
> > > features which don't require pg_dump
On Mon, Aug 31, 2020 at 01:26:59PM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > I actually don't know which statement above is correct, because of the
> > "forever" maintenance.
>
> I can understand not being sure which is correct,
On Mon, Aug 24, 2020 at 04:58:34PM +0900, Michael Paquier wrote:
> On Fri, Aug 21, 2020 at 06:03:32PM -0400, Bruce Momjian wrote:
> > On Tue, Aug 18, 2020 at 02:41:09PM +0200, Bernd Helmle wrote:
> >> protocol.sgml describes the protocol messages received by a BASE_BACKUP
>
On Sun, Sep 6, 2020 at 04:59:11PM +0200, Peter Eisentraut wrote:
> On 2020-08-25 21:48, Bruce Momjian wrote:
> > On Sat, Jul 4, 2020 at 08:47:53AM +0200, Fabien COELHO wrote:
> > >
> > > Hello Peter,
> > >
> > > > The original
On Fri, Sep 4, 2020 at 09:39:45AM -0300, Ranier Vilela wrote:
> Em qui., 3 de set. de 2020 às 23:57, Bruce Momjian
> escreveu:
>
> On Wed, Apr 1, 2020 at 08:57:18AM -0300, Ranier Vilela wrote:
> > Hi,
> > New patch with yours suggestions.
>
>
On Fri, Sep 4, 2020 at 11:31:55PM +0800, Kelly Min wrote:
> hello, hackers.
>
>
> I found a comment error in buffer descriptors comment. The cache line size is
> 64 bytes, not 64 bits
Thanks, fix applied to all active branches.
--
Bruce Momjian https://momjian.us
On Fri, Sep 4, 2020 at 12:45:36PM -0700, David G. Johnston wrote:
> On Thu, Sep 3, 2020 at 6:21 PM Bruce Momjian wrote:
>
> On Wed, Jul 15, 2020 at 09:26:53AM -0700, David G. Johnston wrote:
>
> > Whether to actually change the behavior of to_date is up for deb
On Tue, Sep 1, 2020 at 12:05:02PM -0400, Bruce Momjian wrote:
> > copy test from '/tmp/data' DELIMITER ',';
> >
> > An end-of-copy marker corrupt error will be raised.
> >
> > This requires users to escape the end-of-data marker manually in their data.
>
tingly, you can use period as s delimiter if you are copying from
a file that doesn't need an end-of-data marker and you never need to
escape the delimiter, but that seems like too rare a use case to allow
period to be supported as a delimiter.
--
Bruce Momjian https://momjian.us
Enter
, you are using comma as the delimiter, but have \. (backslash-period)
as a data value. You need to double-up backslashes in your input data,
no matter what is after the backslash. You just happen to hit backslash
period, but other things like \N could cause problems --- litera
On Tue, Sep 1, 2020 at 01:59:25PM +0900, Kyotaro Horiguchi wrote:
> At Mon, 31 Aug 2020 11:34:29 -0400, Bruce Momjian wrote in
> > On Mon, Aug 31, 2020 at 05:56:58PM +0900, Kyotaro Horiguchi wrote:
> > > Ok, this is that. If we spcify clientcert=no-verify other th
ion, I suggest we also
> change the example to point to the data/log directory which is likely to exist
> in a lot more of the cases. I keep getting people who ask "who is josh" based
> on the /home/josh path. Not that it's that important, but...
Thanks, and agreed.
--
On Mon, Aug 31, 2020 at 05:56:58PM +0900, Kyotaro Horiguchi wrote:
> Hello, Bruce.
>
> At Thu, 27 Aug 2020 15:41:40 -0400, Bruce Momjian wrote in
> > > My point here is just "are we OK to remove it?"
> >
> > Yes, in PG 14. Security is confusing
I've received some more replies to your email as soon as I had replied. I
> don't insist on my proposal, just go ahead with your simpler changes.
Patch applied.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On Mon, Aug 31, 2020 at 12:19:52PM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > I don't think there was enough value to do statistics migration just for
> > pg_upgrade, but doing it for pg_upgrade and FDWs seems like it might
> > have eno
On Mon, Aug 31, 2020 at 12:56:21PM -0400, Stephen Frost wrote:
> Greetings,
> * Bruce Momjian (br...@momjian.us) wrote:
> The point I was making was that it has value and people did realize it
> but there's only so many resources to go around when it comes to hacking
> on P
don't think there was enough value to do statistics migration just for
pg_upgrade, but doing it for pg_upgrade and FDWs seems like it might
have enough demand to justify the required work and maintenance.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On Wed, Oct 7, 2020 at 10:42:49AM +0900, Michael Paquier wrote:
> On Tue, Oct 06, 2020 at 09:22:29AM -0400, Bruce Momjian wrote:
> > I propose moving the pg_stat_statements queryid hash code into the
> > server (with a version number), and also adding a postgresql.conf
> > v
r two to all supported versions?
Have you tested this output back to 9.5?
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
eems to be the right function here.
>
> Yes, that looks like a simple typo to me as well.
> AtEOXact_MultiXact() shares portions of the logics in
> PostPrepare_MultiXact and multixact_twophase_postcommit.
FYI, this patch was applied.
--
Bruce Momjian https://momjian.us
EnterpriseDB
On Thu, Oct 8, 2020 at 06:58:14PM +0200, Michael Meskes wrote:
> On Thu, 2020-10-08 at 12:27 -0400, Bruce Momjian wrote:
> > On Thu, Oct 8, 2020 at 10:35:41AM +0900, Michael Paquier wrote:
> > > On Wed, Oct 07, 2020 at 02:31:54PM +0300, Maksim Kita wrote:
> > > > Fi
.6 because the change happened in
> 10.
OK, so the patch should be applied only to PG 10 and later?
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
n
expect it to be committed. Always discuss design on Hackers list before
starting to code. The flow should be:
Desirability -> Design -> Implement -> Test -> Review -> Commit
--
Bruce Momjian https://momjian.us
EnterpriseDB
t; (at least not without significant revisions).
I think we should just go for simple application cases for this.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
debugging more complicated
Should it be removed?
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
ncoding conversion.
I suppose we either have to document this as BYTEA with no backslash
processing, or TEXT with no encoding conversion --- I think I prefer the
later.
Attached is a patch to update the docs, and the data type passed by
SendTimeLineHistory(). Does this look safe to everyone?
--
B
On Fri, Oct 9, 2020 at 08:52:50AM +0900, Michael Paquier wrote:
> On Thu, Oct 08, 2020 at 04:23:06PM -0400, Bruce Momjian wrote:
> > I have looked at this. It seems SendTimeLineHistory() is sending raw
> > bytes from the history file, with no encoding conversion, and
> &
On Thu, Oct 8, 2020 at 11:17:59PM -0400, Bruce Momjian wrote:
> Good point. The reporter was assuming the data would come to the client
> in the bytea output format specified by the GUC, e.g. \x..., so that
> doesn't happen either. As I said before, it is more raw bytes, but we
>
On Wed, Oct 14, 2020 at 05:10:30PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Patch attached. I would like to backpatch this to all supported
> > versions so we are consistent and people don't think different PG
> > versions use different return values for this. I
On Tue, Oct 13, 2020 at 06:37:14PM +0200, Pavel Stehule wrote:
>
>
> út 13. 10. 2020 v 18:33 odesílatel Bruce Momjian napsal:
>
> On Tue, Oct 13, 2020 at 06:20:41PM +0200, Pavel Stehule wrote:
> > Hi
> >
> > One customer reports issue related
> But I didn't find documentation of this limitation?
So, what is the question? Peter Eisentraut is right that WAL is not
preserved, so replication slots are not preserved. We do have
pg_upgrade instructions for upgrading binary replication, but I assume
people recreate the slots.
--
Bruc
; > this stage.
>
> Now we are in the dev of v13, so it's time to rip the functions out?
Where are we on this? Can the functions be removed in PG 14?
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
e upgrade, this should
> appear transparent to the subscribers. They'll just see that the publisher
> was offline for a while.
I guess that is possible since pg_upgrade resets the WAL location,
though not the WAL contents.
--
Bruce Momjian https://momjian.us
EnterpriseDB
On Thu, Oct 15, 2020 at 11:18:33AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Oct 15, 2020 at 10:03:46AM -0400, Tom Lane wrote:
> >> I don't really see why our only documentation choices are "text" or
> >> "bytea". Can't
On Thu, Oct 15, 2020 at 10:03:46AM -0400, Tom Lane wrote:
> Brar Piening writes:
> > Bruce Momjian wrote:
> >> I did some more research on this. It turns out timeline 'content' is
> >> the only BYTEA listed in the protocol docs, even though it just passes C
> >
On Thu, Oct 15, 2020 at 12:01:21PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > We would want the timeline history file contents label changed from
> > BYTEA to TEXT in the docs changed for all supported versions, add a C
> > comment to all backbranches that BYTE
On Fri, Oct 9, 2020 at 07:42:51PM -0400, Bruce Momjian wrote:
> On Fri, Oct 9, 2020 at 02:23:10PM -0500, Justin Pryzby wrote:
> > In my local branch, I had revised this comment to say:
> >
> > + * Note, v8.4 has no tablespace_suffix, which is fine so long as the
> &g
801 - 900 of 2589 matches
Mail list logo
