On Mon, Apr 13, 2020 at 8:11 AM Amit Kapila wrote:
>
> On Sat, Apr 11, 2020 at 6:55 PM Julien Rouhaud wrote:
> >
> > On Fri, Apr 10, 2020 at 9:37 PM Julien Rouhaud wrote:
> > >
> > I tried to take into account all that have been discussed, but I have
> > to admit that I'm absolutely not sure of
On Tue, 7 Apr 2020 at 11:42, Zhang, Jie wrote:
>
> Hi al
>
> In getDefaultACLs function, some PQExpBuffer are not destroy
>
Yes, it looks like an oversight. It's related to the commit
e2090d9d20d809 which is back-patched to 9.6.
The patch looks good to me.
Regards,
--
Masahiko Sawada
Bonjour Michaël,
Patch v3 is also a rebase.
This has rotten for half a year, so I am marking it as returned with
feedback. There have been comments from Alvaro and Andres as well...
Attached a v4. I'm resurrecting this small patch, after "\aset" has been
added to pgbench (9d8ef988).
Alv
On Mon, 6 Apr 2020 at 23:32, freebsdjlu wrote:
>
> Hi
> I also met the same issue :
> WAL stream: ERROR: option "proto_version" = "1" is unknown
>
> do you know what is the root cause ?
>
It's usually a good idea to provide reproducible steps along with the
error you're having.
I suspect the er
> 2020年4月8日 下午6:34，tushar 写道：
>
> On 4/7/20 2:27 PM, 曾文旌 wrote:
>> Vacuum full GTT, cluster GTT is already supported in
>> global_temporary_table_v24-pg13.patch.
> Please refer this below scenario , where pg_upgrade is failing
> 1)Server is up and running (./pg_ctl -D data status)
> 2)Stop the
On Mon, Apr 13, 2020 at 10:44:42AM +0530, Amit Kapila wrote:
> On Fri, Apr 10, 2020 at 7:16 PM Justin Pryzby wrote:
> >
> > Also, this part still doesn't read well:
> >
> > -* amvacuumcleanup to the DSM segment if it's the first time to get
> > it?
> > -* from them? because they?
On 4/13/20 1:57 PM, 曾文旌 wrote:
[tushar@localhost bin]$ tail -20 pg_upgrade_dump_13592.log
pg_restore: error: could not execute query: ERROR: pg_type array OID value not
set when in binary upgrade mode
I found that the regular table also has this problem, I am very unfamiliar with
this part,
Hi,
On 2020-04-13 15:24:55 +0900, Masahiko Sawada wrote:
> On Sat, 11 Apr 2020 at 09:00, Teja Mupparti wrote:
> >
> > Thanks Andres and Kyotaro for the quick review. I have fixed the typos and
> > also included the critical section (emulated it with try-catch block since
> > palloc()s are caus
At Mon, 13 Apr 2020 13:51:07 +0900, Michael Paquier wrote
in
> On Mon, Apr 13, 2020 at 11:52:51AM +0900, Kyotaro Horiguchi wrote:
> > Since I'm not sure about the work flow that contains taking a
> > basebackup from a server of a different version, I'm not sure which is
> > better between silent
On Sat, Apr 11, 2020 at 4:11 AM Tom Lane wrote:
> Konstantin Knizhnik writes:
> > On 25.03.2020 13:36, Richard Guo wrote:
> >> I tried this recipe on different PostgreSQL versions, starting from
> >> current master and going backwards. I was able to reproduce this issue
> >> on all versions abov
On Fri, Apr 10, 2020 at 7:05 PM Justin Pryzby wrote:
>
>
> No problem. I think I was trying to make my text similar to that from
> 14a4f6f37.
>
> I realized that I didn't sq!uash my last patch, so it didn't include the
> functional change (which is maybe what Robert was referring to).
>
I think
On Mon, Apr 13, 2020 at 2:00 PM Justin Pryzby wrote:
>
> |Copy the index
> |bulk-deletion result returned from ambulkdelete and amvacuumcleanup to
> |the DSM segment if it's the first time [???] because they allocate locally
> |and it's possible that an index will be vacuumed by a different
> |vac
On Mon, 13 Apr 2020 at 17:40, Andres Freund wrote:
>
> Hi,
>
> On 2020-04-13 15:24:55 +0900, Masahiko Sawada wrote:
> > On Sat, 11 Apr 2020 at 09:00, Teja Mupparti wrote:
> > >
> > > Thanks Andres and Kyotaro for the quick review. I have fixed the typos
> > > and also included the critical sect
On 4/9/20 6:26 PM, 曾文旌 wrote:
On 4/7/20 2:27 PM, 曾文旌 wrote:
Vacuum full GTT, cluster GTT is already supported in
global_temporary_table_v24-pg13.patch.
Here , it is skipping GTT
postgres=# \c foo
You are now connected to database "foo" as user "tushar".
foo=# create global temporary table g1
On Thu, Apr 9, 2020 at 2:40 PM Dilip Kumar wrote:
>
> I have rebased the patch on the latest head. I haven't yet changed
> anything for xid assignment thing because it is not yet concluded.
>
Some review comments from 0001-Immediately-WAL-log-*.patch,
+bool
+IsSubTransactionAssignmentPending(voi
On Mon, 13 Apr 2020 at 18:25, Amit Kapila wrote:
>
> On Fri, Apr 10, 2020 at 7:05 PM Justin Pryzby wrote:
> >
> >
> > No problem. I think I was trying to make my text similar to that from
> > 14a4f6f37.
> >
> > I realized that I didn't sq!uash my last patch, so it didn't include the
> > function
On Mon, Apr 13, 2020 at 1:10 PM Julien Rouhaud wrote:
>
> On Mon, Apr 13, 2020 at 8:11 AM Amit Kapila wrote:
> >
> > On Sat, Apr 11, 2020 at 6:55 PM Julien Rouhaud wrote:
> > >
> > > On Fri, Apr 10, 2020 at 9:37 PM Julien Rouhaud wrote:
> > > >
> > > I tried to take into account all that have b
On Mon, Apr 13, 2020 at 4:14 PM Kuntal Ghosh wrote:
>
> On Thu, Apr 9, 2020 at 2:40 PM Dilip Kumar wrote:
> >
> > I have rebased the patch on the latest head. I haven't yet changed
> > anything for xid assignment thing because it is not yet concluded.
> >
> Some review comments from 0001-Immedia
On Mon, Apr 13, 2020 at 4:23 PM Masahiko Sawada
wrote:
>
> On Mon, 13 Apr 2020 at 18:25, Amit Kapila wrote:
> >
> > On Fri, Apr 10, 2020 at 7:05 PM Justin Pryzby wrote:
> > >
> > >
> > > No problem. I think I was trying to make my text similar to that from
> > > 14a4f6f37.
> > >
> > > I realize
On Mon, Apr 13, 2020 at 5:20 PM Dilip Kumar wrote:
> On Mon, Apr 13, 2020 at 4:14 PM Kuntal Ghosh
> wrote:
> >
> > +#define SizeOfTransactionId (sizeof(TransactionId) + sizeof(char))
> > This looks wrong. We should change the name of this Macro or we can
> > add the 1 byte directly in HEADER_SCR
On Mon, Apr 13, 2020 at 6:12 PM Kuntal Ghosh wrote:
>
> On Mon, Apr 13, 2020 at 5:20 PM Dilip Kumar wrote:
> > On Mon, Apr 13, 2020 at 4:14 PM Kuntal Ghosh
> > wrote:
> > >
> > > +#define SizeOfTransactionId (sizeof(TransactionId) + sizeof(char))
> > > This looks wrong. We should change the nam
Le lun. 13 avr. 2020 à 13:47, Amit Kapila a
écrit :
> On Mon, Apr 13, 2020 at 1:10 PM Julien Rouhaud wrote:
> >
> > On Mon, Apr 13, 2020 at 8:11 AM Amit Kapila
> wrote:
> > >
> > > On Sat, Apr 11, 2020 at 6:55 PM Julien Rouhaud
> wrote:
> > > >
> > > > On Fri, Apr 10, 2020 at 9:37 PM Julien Ro
Richard Guo writes:
> At first I was wondering if we need to check whether HashState.hashtable
> is not NULL in ExecShutdownHash() before we decide to allocate save
> space for HashState.hinstrument. And then I convinced myself that that's
> not necessary since HashState.hinstrument and HashState.
I'm not a fan of error messages like
relation "%s" is not a table, foreign table, or materialized view
It doesn't tell me what's wrong, it only tells me what else could have
worked. It's also tedious to maintain and the number of combinations
grows over time.
This was discussed many yea
On Sun, Apr 12, 2020 at 09:18:28PM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Fri, Apr 10, 2020 at 10:54:10AM -0400, Stephen Frost wrote:
> > > * Robert Haas (robertmh...@gmail.com) wrote:
> > > > On Thu, Apr 9, 2020 at 6:44 PM Bruce Momjian wrote:
> > > > > Goo
Hi,
I am experimenting with postgres and am wondering if there is any tutorial
on how to properly add a new command to postgres.
I want to add a new constraint on "CREATE ROLE" that requires an integer,
it has an identifier that is not a known (reserved or unreserved keyword)
in postgres, say we
On Sun, Apr 12, 2020 at 9:18 PM Stephen Frost wrote:
> There's two different questions we're talking about here and I feel like
> they're being conflated. To try and clarify:
>
> - Could you implement FDWs with shell scripts, and custom programs? I'm
> pretty confident that the answer is yes,
I've read through all of the previous discussions related to stable
subexpression caching, and I'm planning to send a summary email with
all of those links in one place.
But I also happened to stumble upon mention in the TODO of some email
discussion way back in 2007 where Tom suggested [1] we sho
On Sat, 11 Apr 2020 at 00:47, Andres Freund wrote:
>
> Hi,
>
> On 2020-04-10 13:09:13 +0530, Amit Khandekar wrote:
> > On my Intel Xeon machine with 8 cores, I tried to test PAUSE also
> > using a sample C program (attached spin.c). Here, many child processes
> > (much more than CPUs) wait in a ti
On Sat, 11 Apr 2020 at 04:18, Tom Lane wrote:
>
> I wrote:
> > A more useful test would be to directly experiment with contended
> > spinlocks. As I recall, we had some test cases laying about when
> > we were fooling with the spin delay stuff on Intel --- maybe
> > resurrecting one of those woul
On Sun, Apr 12, 2020 at 10:20 PM Shinoda, Noriyoshi (PN Japan A&PS
Delivery) wrote:
> Sorry this email is not a discussion about word selection.
> Since part of the manual had left pg_validatebackup in commit
> dbc60c5593f26dc777a3be032bff4fb4eab1ddd1.
> I've attached a patch to fix this.
Commit
On Mon, Apr 13, 2020 at 9:55 AM Peter Eisentraut
wrote:
> Attached is another attempt to improve this.
Nice effort. Most of these seem like clear improvements, but some I don't like:
+ errmsg("relation \"%s\" is of unsupported kind",
+ RelationGetRelationName(rel)),
+ errdetail_relkind(RelationG
On Sun, Apr 12, 2020 at 8:56 PM Michael Paquier wrote:
> On Sun, Apr 12, 2020 at 08:08:17AM +0900, Michael Paquier wrote:
> > Exactly. My point is exactly that. The current code would force
> > users maintaining scripts with pg_basebackup to use --no-manifest if
> > such a script runs with older
Peter Eisentraut writes:
> I'm not a fan of error messages like
> relation "%s" is not a table, foreign table, or materialized view
Agreed, they're not great.
> For example:
> -ERROR: relation "ti" is not a table, foreign table, or materialized view
> +ERROR: cannot define statistics for
On Sun, Apr 12, 2020 at 10:09 PM Fujii Masao
wrote:
> I found other minor issues.
I think these are all correct fixes. Thanks for the post-commit
review, and sorry for this mistakes.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 4/13/20 11:13 AM, Tom Lane wrote:
>
> ERROR: cannot define statistics for relation "ti"
> DETAIL: This operation is not supported for indexes.
>
> which still leaves implicit that "ti" is an index, but probably that's
> something the user can figure out.
>
+1 for this. It's clear and succin
On 4/12/20 3:42 AM, Noah Misch wrote:
> On Sat, Apr 11, 2020 at 12:13:08PM -0400, Andrew Dunstan wrote:
>> --- a/src/tools/msvc/Project.pm
>> +++ b/src/tools/msvc/Project.pm
>> @@ -420,13 +420,10 @@ sub read_file
>> {
>> my $filename = shift;
>> my $F;
>> -my $t = $/;
>> -
>> -
As discussed in the thread at [1], I've been working on redesigning
the tables we use to present SQL functions and operators. The
first installment of that is now up; see tables 9.30 and 9.31 at
https://www.postgresql.org/docs/devel/functions-datetime.html
and table 9.33 at
https://www.postgres
On Fri, Apr 10, 2020 at 3:59 PM Tom Lane wrote:
>
> They can't be strict because the initial iteration needs to produce
> something from a null state and non-null input. nodeAgg's default
> behavior won't work for those because nodeAgg doesn't know how to
> copy a value of type "internal".
>
>
On Mon, Apr 13, 2020 at 1:13 PM Tom Lane wrote:
> As discussed in the thread at [1], I've been working on redesigning
> the tables we use to present SQL functions and operators. The
> first installment of that is now up; see tables 9.30 and 9.31 at
>
> https://www.postgresql.org/docs/devel/functi
On Fri, Mar 27, 2020 at 4:32 PM Andres Freund wrote:
> I don't like having a file format that's intended to be used by external
> tools too that's undocumented except for code that assembles it in a
> piecemeal fashion. Do you mean in a follow-on patch this release, or
> later? I don't have a pro
On 2020-04-13 19:13, Tom Lane wrote:
As discussed in the thread at [1], I've been working on redesigning
the tables we use to present SQL functions and operators. The
first installment of that is now up; see tables 9.30 and 9.31 at
https://www.postgresql.org/docs/devel/functions-datetime.html
On Mon, Apr 13, 2020 at 01:40:56PM -0400, Robert Haas wrote:
> On Fri, Mar 27, 2020 at 4:32 PM Andres Freund wrote:
> > I don't like having a file format that's intended to be used by external
> > tools too that's undocumented except for code that assembles it in a
> > piecemeal fashion. Do you m
On Mon, 13 Apr 2020 at 13:13, Tom Lane wrote:
> As discussed in the thread at [1], I've been working on redesigning
> the tables we use to present SQL functions and operators. The
> first installment of that is now up; see tables 9.30 and 9.31 at
>
> https://www.postgresql.org/docs/devel/functio
On 2020-Apr-13, Tom Lane wrote:
> As discussed in the thread at [1], I've been working on redesigning
> the tables we use to present SQL functions and operators. The
> first installment of that is now up; see tables 9.30 and 9.31 at
>
> https://www.postgresql.org/docs/devel/functions-datetime.ht
On Mon, Apr 13, 2020 at 1:55 PM Justin Pryzby wrote:
> typos:
> manifes
> hexademical (twice)
Thanks. v2 attached.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
v2-0001-Document-the-backup-manifest-file-format.patch
Description: Binary data
Jesse Zhang writes:
> On Fri, Apr 10, 2020 at 3:59 PM Tom Lane wrote:
>> They can't be strict because the initial iteration needs to produce
>> something from a null state and non-null input. nodeAgg's default
>> behavior won't work for those because nodeAgg doesn't know how to
>> copy a value o
On Mon, Apr 13, 2020 at 6:34 PM Dilip Kumar wrote:
>
Skipping 0003 for now. Review comments from 0004-Gracefully-handle-*.patch
@@ -5490,6 +5523,14 @@ heap_finish_speculative(Relation relation,
ItemPointer tid)
ItemId lp = NULL;
HeapTupleHeader htup;
+ /*
+ * We don't expect direct calls to
On Fri, Apr 10, 2020 at 2:26 PM Andres Freund wrote:
> > Still, it might be the case that having the process that is reading
> > the data also find the line endings is so fast that it makes no sense
> > to split those two tasks. After all, whoever just read the data must
> > have it in cache, and
Isaac Morland writes:
> - showing the signature like this is interesting. For a moment I was
> wondering why it doesn’t say, for example, "interval → interval → interval”
> then I remembered this is Postgres, not Haskell. On the one hand, I like
> putting the signature like this; on the other, I d
On 2020-04-13 20:08, Robert Haas wrote:
[v2-0001-Document-the-backup-manifest-file-format.patch]
Can you double check this sentence? Seems strange to me but I don't
know why; it may well be that my english is not good enough. Maybe a
comma after 'required' makes reading easier?
The tim
Alvaro Herrera writes:
> One improvement (that I don't know is possible in docbook) would be to
> have the inter-logical-row line be slightly thicker than the
> intra-logical-row one. That'd make each entry visually more obvious.
Yeah, I don't see any way to do that :-(. We could suppress the r
+ The LSN at which replay must begin on the indicated timeline in order to
+ make use of this backup. The LSN is stored in the format normally used
+ by PostgreSQL; that is, it is a string
+ consisting of two strings of hexademical characters, each with a length
+ of betwe
PGSQLCommunities,
We migrated Oracle 11.x Database to PostgreSQL 12.x Database on a RH Linux
7.x server.
On a different RH Linux 7.x Server, I have Oracle Client installed. Since
we have many scripts developed in Oracle SQL, is it possible for the
PostgreSQL 12.x DB to process the Oracle Scr
On Mon, Apr 13, 2020 at 2:28 PM Erik Rijkers wrote:
> Can you double check this sentence? Seems strange to me but I don't
> know why; it may well be that my english is not good enough. Maybe a
> comma after 'required' makes reading easier?
>
> The timeline from which this range of WAL record
Hi,
On 2020-04-11 10:54:49 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > How about a compile-time option to turn all the warnings in resowner.c
> > into errors? This could be enabled automatically by --enable-cassert,
> > similar to other defines that that option enables.
>
> [ itch..
On 4/13/20 1:40 PM, Robert Haas wrote:
> On Fri, Mar 27, 2020 at 4:32 PM Andres Freund wrote:
>> I don't like having a file format that's intended to be used by external
>> tools too that's undocumented except for code that assembles it in a
>> piecemeal fashion. Do you mean in a follow-on patc
On Mon, Apr 13, 2020 at 3:34 PM Alvaro Herrera wrote:
> Are these hex figures upper or lower case? No leading zeroes? This
> would normally not matter, but the toplevel checksum will care.
Not really. You just feed the whole file except for the last line
through shasum and you get the answer.
On Mon, Apr 13, 2020 at 4:10 PM Andrew Dunstan
wrote:
> Seems ok. A tiny example, or an excerpt, might be nice.
An empty database produces a manifest about 1200 lines long, so a full
example seems like too much to include in the documentation. An
excerpt could be included, I suppose.
--
Robert
Hi,
On 2020-04-13 14:13:46 -0400, Robert Haas wrote:
> On Fri, Apr 10, 2020 at 2:26 PM Andres Freund wrote:
> > > Still, it might be the case that having the process that is reading
> > > the data also find the line endings is so fast that it makes no sense
> > > to split those two tasks. After a
On Mon, Apr 13, 2020 at 2:47 PM Tom Lane wrote:
> Another possibility, which'd only help in HTML, would be to render
> some of the cells with a slightly different background color.
> That's beyond my docbook/css skills, but it might be possible.
I think some visual distinction would be really hel
On 4/13/20 1:13 PM, Tom Lane wrote:
> As discussed in the thread at [1], I've been working on redesigning
> the tables we use to present SQL functions and operators. The
> first installment of that is now up; see tables 9.30 and 9.31 at
>
> https://www.postgresql.org/docs/devel/functions-datetim
On Mon, Apr 13, 2020 at 4:16 PM Andres Freund wrote:
> I don't think so. If only one process does the splitting, the
> exclusively locked section is just popping off a bunch of offsets of the
> ring. And that could fairly easily be done with atomic ops (since what
> we need is basically a single p
Andres Freund writes:
> On 2020-04-11 10:54:49 -0400, Tom Lane wrote:
>> I guess you could make them PANICs, but it would be an option that nobody
>> could possibly want to have enabled in anything resembling production.
>> So I"m kind of -0.5 on making --enable-cassert do it automatically.
>> Alt
Robert Haas writes:
> I just wonder if there's too much clutter here. Like, line 1:
> date - interval → timestamp
> OK, gotcha. Line 2:
> Subtract an interval from a date
> Well, is that really adding anything non-obvious?
Yeah, back in the other thread I said
>>> I decided to try converting
On Mon, Apr 13, 2020 at 11:27 AM Tom Lane wrote:
> Isaac Morland writes:
>
> > - I think there should be much more distinctive lines between the
> different
> > functions. As it is the fact that the table is groups of 3 lines doesn’t
> > jump out at the eye.
>
> I don't know any easy way to do t
Andrew Dunstan writes:
> One thing that did occur to me is that the function/operator name is
> essentially redundant, as it's in the signature anyway. Not sure if that
> helps us any though.
Hm, you have a point there. However, if we drop the lefthand column
then there really isn't any visual d
"David G. Johnston" writes:
> Can we lightly background color every other rowgroup (i.e., "greenbar")?
If you know how to do that at all, let alone in a maintainable way (ie
one where inserting a new function doesn't require touching the entries
for the ones after), let's see it. I agree it'd be
On 4/13/20 4:14 PM, Robert Haas wrote:
On Mon, Apr 13, 2020 at 3:34 PM Alvaro Herrera wrote:
Also, I
see no mention of prettification-chars such as newlines or indentation.
I suppose if I pass a manifest file through prettification (or Windows
newline conversion), the checksum may break.
It
I wrote:
> "David G. Johnston" writes:
>> I don't think having a separate Result column helps. The additional
>> horizontal whitespace distances all relevant context information (at least
>> on a wide monitor). Having the example rows mirror the Signature row seems
>> like an easier to consume c
On Mon, Apr 13, 2020 at 1:41 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > Can we lightly background color every other rowgroup (i.e., "greenbar")?
>
> If you know how to do that at all, let alone in a maintainable way (ie
> one where inserting a new function doesn't require touching the
On Mon, Apr 13, 2020 at 03:22:06PM +0530, Amit Kapila wrote:
> On Mon, Apr 13, 2020 at 2:00 PM Justin Pryzby wrote:
> >
> > |Copy the index
> > |bulk-deletion result returned from ambulkdelete and amvacuumcleanup to
> > |the DSM segment if it's the first time [???] because they allocate locally
>
On Mon, Apr 13, 2020 at 1:57 PM Tom Lane wrote:
> Actually ... if we did it like that, then it would be possible to treat
> the signature + description + example(s) as one big table cell with line
> breaks rather than row-separator bars.
> That would help address the
> inadequate-visual-separa
On 2020-Apr-13, Robert Haas wrote:
> On Mon, Apr 13, 2020 at 3:34 PM Alvaro Herrera
> wrote:
> > Are these hex figures upper or lower case? No leading zeroes? This
> > would normally not matter, but the toplevel checksum will care.
>
> Not really. You just feed the whole file except for the l
On Mon, Apr 13, 2020 at 11:13:06AM -0400, Robert Haas wrote:
> I think that this patch is incorrect. I have no objection to
> introducing MINIMUM_VERSION_FOR_MANIFESTS, but this is not OK:
>
> - else
> - {
> - if (serverMajor < 1300)
> - manifest_clause = "";
> - else
> - manifest_clause = "MANIFE
On 4/13/20 1:13 PM, Tom Lane wrote:
> As discussed in the thread at [1], I've been working on redesigning
> the tables we use to present SQL functions and operators. The
> first installment of that is now up; see tables 9.30 and 9.31 at
>
> https://www.postgresql.org/docs/devel/functions-datetime
>
> Thinking out loud, it'd also be great if we could add in some anchors as
> well, so perhaps in the future on the pgweb side we could add in some
> discoverable links that other documentation has -- which in turn people
> could click / link to others directly to the function name.
>
+1
>
> Yeah, back at the beginning of this exercise, Alvaro wondered aloud
> if we should go to something other than tables altogether. I dunno
> what that'd look like though.
>
It would probably look like our acronyms and glossary pages.
Maybe the return example and return values get replaced with
"Jonathan S. Katz" writes:
> I think one thing that was throwing me off was having the function
> signature before the description. I would recommend flipping them: have
> the function description first, followed by signature, followed be
> examples. I think that follows the natural flow more of w
On 4/13/20 6:51 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> I think one thing that was throwing me off was having the function
>> signature before the description. I would recommend flipping them: have
>> the function description first, followed by signature, followed be
>> examples. I thi
On 2020-Apr-13, Michael Paquier wrote:
> On Mon, Apr 13, 2020 at 11:52:51AM +0900, Kyotaro Horiguchi wrote:
> > Since I'm not sure about the work flow that contains taking a
> > basebackup from a server of a different version, I'm not sure which is
> > better between silently disabling and errorin
On 4/13/20 7:02 PM, Jonathan S. Katz wrote:
> On 4/13/20 6:51 PM, Tom Lane wrote:
>> "Jonathan S. Katz" writes:
>>> I think one thing that was throwing me off was having the function
>>> signature before the description. I would recommend flipping them: have
>>> the function description first, fol
I wrote:
> I don't think I like the version better than --- it adds
> quite a bit of vertical space, more than I was expecting really.
Actually, after staring more at HTML-hr.png, what's *really* bothering
me about that rendering is that the lines made by are actually
wider than the inter-table
On 2020-Apr-13, Jonathan S. Katz wrote:
> On 4/13/20 7:02 PM, Jonathan S. Katz wrote:
> > Perhaps a counterproposal: We eliminate the content in the leftmost
> > "function column, but leave that there to allow the function name /
> > signature to span the full 3 columns. Then the rest of the info
On Mon, Apr 13, 2020 at 6:26 PM Michael Paquier wrote:
> Well, the documentation tells me that as of protocol.sgml:
> "For compatibility with previous releases, the default is
> MANIFEST 'no'."
>
> The code also tells me that, in line with the docs:
> static void
> parse_basebackup_options(List *o
"Jonathan S. Katz" writes:
> On 4/13/20 7:02 PM, Jonathan S. Katz wrote:
>> Perhaps a counterproposal: We eliminate the content in the leftmost
>> "function column, but leave that there to allow the function name /
>> signature to span the full 3 columns. Then the rest of the info goes
>> below. T
On Mon, Apr 13, 2020 at 07:55:07PM -0400, Robert Haas wrote:
> Oh, hmm. Maybe I'm getting confused with a previous version of the
> patch that behaved differently.
No problem. If you prefer keeping this part of the code, that's fine
by me. If you think that the patch is suited as-is, including
s
On Mon, Apr 13, 2020 at 09:54:01AM +0200, Fabien COELHO wrote:
> Attached a v4. I'm resurrecting this small patch, after "\aset" has been
> added to pgbench (9d8ef988).
Hmm. It seems to me that this stuff needs to be more careful with the
function handling? For example, all those cases fail but
On Mon, Apr 13, 2020 at 04:51:06PM +0900, Masahiko Sawada wrote:
> On Tue, 7 Apr 2020 at 11:42, Zhang, Jie wrote:
>> In getDefaultACLs function, some PQExpBuffer are not destroy
>
> Yes, it looks like an oversight. It's related to the commit
> e2090d9d20d809 which is back-patched to 9.6.
>
> The
On Mon, Apr 13, 2020 at 11:13:15AM -0400, Tom Lane wrote:
> Fixing this while avoiding your concern about proliferation of messages
> seems a bit difficult though. The best I can do after a couple minutes'
> thought is
>
> ERROR: cannot define statistics for relation "ti"
> DETAIL: "ti" is an i
Kyotaro Horiguchi writes:
> At Sat, 11 Apr 2020 18:30:30 -0400, Tom Lane wrote in
>> What I think we should do about this is, essentially, to get rid of
>> SyncRepGetSyncStandbys. Instead, let's have each walsender advertise
>> whether *it* believes that it is a sync standby, based on its last
On Sun, Apr 05, 2020 at 11:36:49PM -0700, Noah Misch wrote:
> Executive summary: the "MyWalSnd->write < sentPtr" in WalSndWaitForWal() is
> important for promptly updating pg_stat_replication. When caught up, we
> should impose that logic before every sleep. The one-line fix is to sleep in
> WalS
Noah Misch writes:
> This seems to have made the following race condition easier to hit:
> https://www.postgresql.org/message-id/flat/20200206074552.GB3326097%40rfd.leadboat.com
> https://www.postgresql.org/message-id/flat/21519.1585272409%40sss.pgh.pa.us
Yeah, I just came to the same guess in th
On Mon, Apr 13, 2020 at 9:53 PM Tom Lane wrote:
> Richard Guo writes:
> > At first I was wondering if we need to check whether HashState.hashtable
> > is not NULL in ExecShutdownHash() before we decide to allocate save
> > space for HashState.hinstrument. And then I convinced myself that that's
On Mon, Apr 13, 2020 at 04:22:26PM -0400, Tom Lane wrote:
> Andres Freund writes:
>> I'd much rather see this throw an assertion than the current
>> behaviour. But I'm wondering if there's a chance we can throw an error
>> in non-assert builds without adding too much complexity to the error
>> pat
On Mon, Apr 13, 2020 at 05:55:43PM +0530, Amit Kapila wrote:
> On Mon, Apr 13, 2020 at 4:23 PM Masahiko Sawada
> wrote:
> I am not very sure about this. I don't think the current text is wrong
> especially when you see the value we can specify there is described
> as: "Specifies a non-negative int
Hi,
I find that most of the code does not check the return value of close(), When
open a file for reading(O_RDONLY).
But I find that it checks the return value of close() in code
"src/bin/pg_rewind/copy_fetch.c" When open a file for reading(O_RDONLY).
And it will call pg_fatal to cause pre
At Mon, 13 Apr 2020 18:53:26 +0900, Masahiko Sawada
wrote in
> On Mon, 13 Apr 2020 at 17:40, Andres Freund wrote:
> >
> > Hi,
> >
> > On 2020-04-13 15:24:55 +0900, Masahiko Sawada wrote:
> > > On Sat, 11 Apr 2020 at 09:00, Teja Mupparti wrote:
> > > /*
> > > * We WAL-log the truncation before
On Tue, Apr 14, 2020 at 2:54 AM Justin Pryzby wrote:
>
> Looks good. One more change:
>
> [-Even if-]{+If+} this option is specified with the ANALYZE
> [-option-]{+option,+}
>
> Remove "even" and add comma.
>
Pushed after making this change.
--
With Regards,
Amit Kapila.
EnterpriseDB: http:
On Tue, Apr 14, 2020 at 7:52 AM Michael Paquier wrote:
>
> Makes sense. I have two comments.
>
> ereport(ERROR,
> (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> - errmsg("cannot specify both FULL and PARALLEL options")));
> + errmsg("VACUUM FU
1 - 100 of 112 matches
Mail list logo
