On Mon, Feb 21, 2022 at 2:19 AM Amit Kapila wrote:
> On Mon, Feb 21, 2022 at 1:18 PM Andres Freund wrote:
>
> > > The view name could be pg_stat_subscription_lrep,
> > > pg_stat_logical_replication, or something on those lines.
> >
> > pg_stat_subscription_stats :)
> >
>
> Having *stat* two time
On Sun, Feb 20, 2022 at 10:10 PM Amit Kapila
wrote:
> On Sat, Feb 19, 2022 at 10:35 PM David G. Johnston
> wrote:
> >
> > On Sat, Feb 19, 2022 at 9:37 AM Andres Freund
> wrote:
> >>
> >> IMO the type of information you'd want for apply failures i
On Sat, Feb 26, 2022 at 5:42 AM Shay Rojansky wrote:
> FWIW I've received feedback from a SQL Server engineer that one definitely
> should *not* depend on such ordering there, and that future optimizations
> (e.g. parallel insertion of many rows) could result in row ordering which
> differs from
On Wed, Mar 2, 2022 at 7:44 PM Japin Li wrote:
>
> Hi, hackers
>
> When I try to change wal_level to minimal and restart the database, it
> complains
> max_wal_senders > 0.
>
> 2022-03-03 10:10:16.938 CST [6389] FATAL: WAL streaming (max_wal_senders
> > 0) requires wal_level "replica" or "logica
On Fri, Mar 4, 2022 at 1:50 PM Robert Haas wrote:
> On Mon, Feb 28, 2022 at 2:09 PM Stephen Frost wrote:
> > The ability of a role to revoke itself from some other role is just
> > something we need to accept as being a change that needs to be made, and
> > I do believe that such a change is sup
On Sun, Mar 6, 2022 at 9:53 AM Tom Lane wrote:
> Robert Haas writes:
> > ... Suppose the superuser grants "admin" to both "joe" and "sally".
> > Now "joe" can SET ROLE to "admin" and revoke it from "sally", and the
> > superuser has no tool to prevent this.
>
> Really?
>
> regression=# grant adm
On Sun, Mar 6, 2022 at 8:19 AM Robert Haas wrote:
> The choice of names in my example wasn't accidental. If the granted
> role is a login role, then the superuser's intention was to vest the
> privileges of that role in some other role, and it is surely not right
> for that role to be able to dec
On Mon, Mar 7, 2022 at 8:37 AM Robert Haas wrote:
> A role is not considered to hold WITH
> ADMIN OPTION on itself, but it may grant or revoke membership in
> itself from a database session where the session user matches the
> role."
>
> Is there some use case for the behavior described in that l
On Mon, Mar 7, 2022 at 9:04 AM Tom Lane wrote:
> Just looking at it now, without having done any historical research,
>
I wonder why it is that we don't attach significance to WITH ADMIN
> OPTION being granted to the role itself. It seems like the second
> part of that sentence is effectively sa
On Mon, Mar 7, 2022 at 11:18 AM Robert Haas wrote:
> On Sun, Mar 6, 2022 at 11:01 PM David G. Johnston
> wrote:
> > The example, which you moved here, then attempts to demonstrate this
> "fact" but gets it wrong. Boss became a member of peon so if you want to
> dem
On Mon, Mar 7, 2022 at 11:18 AM Robert Haas wrote:
> In terms of how
>
things work today, see Joshua Brindle's email about the use of groups
> in pg_hba.conf. That is an excellent example of how removing oneself
> from a group could enable one to bypass security restrictions intended
> by the DBA
On Mon, Mar 7, 2022 at 1:16 PM Tom Lane wrote:
> Based on Robert's archaeological dig, it now seems that the fact that
> we have any such behavior at all was just a mistake. What would be
> lost if we drop it?
>
Probably nothing that couldn't be replaced, and with a better model, but I
do have
On Thu, Mar 3, 2022 at 11:05 PM Kyotaro Horiguchi
wrote:
> But,
> anyway, IMHO, it is mere a performance tips that is not necessarily
> required in this section, or even in this documentaiotn. Addtion to
> that, if we write this for max_wal_senders, archive_mode will deserve
> the similar tips b
On Fri, Mar 4, 2022 at 2:49 AM Japin Li wrote:
> Thanks for your review. Modified.
>
Works for me. I have some additional sparks of ideas but nothing that need
hold this up.
David J.
On Tue, Mar 8, 2022 at 1:54 PM Andres Freund wrote:
>
> One thing I'm not yet happy around the shared memory stats patch is
> naming. Currently a lot of comments say things like:
>
> * [...] We convert to
> * microseconds in PgStat_Counter format when transmitting to the
> collector.
>
> or
>
On Tue, Mar 8, 2022 at 6:50 PM Andres Freund wrote:
> On 2022-03-08 15:55:04 -0700, David G. Johnston wrote:
> > On Tue, Mar 8, 2022 at 1:54 PM Andres Freund wrote:
> > > One thing I'm not yet happy around the shared memory stats patch is
> > > naming. Curren
On Tue, Mar 8, 2022 at 7:32 PM Andres Freund wrote:
> we need a descriptive term / shorthand that
> describes the type of statistics we currently send to the stats collector.
>
> "cumulative stats subsystem"?
>
>
I'm growing fond of "cumulative". It is more precise (and restrictive)
than "metric
On Wed, Mar 9, 2022 at 2:31 PM Tom Lane wrote:
> Robert Haas writes:
> > Well, the problem is that as far as I can see, the admin option is an
> > optional feature of membership. You can grant someone membership
> > without admin option, or with admin option, but you can't grant them
> > the adm
On Thu, Mar 10, 2022 at 7:46 AM Robert Haas wrote:
> On Wed, Mar 9, 2022 at 4:31 PM Tom Lane wrote:
> > I don't think we need syntax to describe it. As I just said in my
> > other reply, we have a perfectly good precedent for this already
> > in ordinary object permissions. That is: an object
On Thu, Mar 10, 2022 at 9:19 AM Stephen Frost wrote:
> Greetings,
>
> * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > On Thu, Mar 10, 2022 at 7:46 AM Robert Haas
> wrote:
> > > On Wed, Mar 9, 2022 at 4:31 PM Tom Lane wrote:
> > > > I don'
On Thu, Mar 10, 2022 at 11:05 AM Stephen Frost wrote:
> Greetings,
>
> * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > On Thu, Mar 10, 2022 at 9:19 AM Stephen Frost
> wrote:
> > > * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > > >
On Thu, Mar 10, 2022 at 12:45 PM Stephen Frost wrote:
>
> * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > On Thu, Mar 10, 2022 at 11:05 AM Stephen Frost
> wrote:
>
Why not just look at the admin_option field of pg_auth_members...? I
> don't get why that
On Thu, Mar 10, 2022 at 12:58 PM Stephen Frost wrote:
> I don't think we're that far from having all of these though. To start
> with, we remove from CREATEROLE the random things that it does which go
> beyond what folks tend to expect- remove the whole 'grant any role to
> any other' stuff, rem
On Thu, Mar 10, 2022 at 3:01 PM Robert Haas wrote:
> On Thu, Mar 10, 2022 at 4:00 PM David G. Johnston
> wrote:
> > I dislike changing the documented behavior of CREATEROLE to the degree
> suggested here. However, there are three choices here, only one of which
> can be
On Fri, Mar 11, 2022 at 6:55 AM Robert Haas wrote:
> On Thu, Mar 10, 2022 at 5:14 PM Tom Lane wrote:
> > This seems reasonable in isolation, but
> >
> > (1) it implies a persistent relationship between creating and created
> > roles. Whether you want to call that ownership or not, it sure walks
On Fri, Mar 11, 2022 at 8:32 AM Stephen Frost wrote:
>
> Such scripts as will break will still
> break in a pretty clear way with a clear answer as to how to fix them
> and I don't think there's some kind of data corruption or something that
> would happen.
>
>
I largely agree and am perfectly fi
On Tue, Mar 15, 2022 at 12:31 PM Mark Dilger
wrote:
>
> > On Mar 15, 2022, at 12:27 PM, Robert Haas wrote:
> >
> > - Justin Pryzby, who originally discovered the problem, prefers the
> > same behavior that I prefer long-term, but thinks Tom's behavior is
> > better than doing nothing.
> > - Mark
On Tue, Mar 22, 2022 at 3:39 PM David Rowley wrote:
> On Thu, 17 Mar 2022 at 17:04, Corey Huinker
> wrote:
> > It seems like this effort would aid in implementing what some other
> databases implement via the QUALIFY clause, which is to window functions
> what HAVING is to aggregate functions.
>
On Wed, Mar 23, 2022 at 5:55 PM Andres Freund wrote:
>
> Starting with the below commit, pg_stat_reset_single_function_counters,
> pg_stat_reset_single_table_counters don't just reset the stats for the
> individual function, but also set pg_stat_database.stats_reset.
>
> commit 4c468b37a281941afd
Hackers,
Given that we have already heard about 3 separate minor release regressions
in the most recent update I'm putting forth for discussion whether an
off-schedule release should be done. I probably wouldn't care as much if
it wasn't for the fact that the same release fixes two CVEs.
https:/
On Wed, Dec 2, 2020 at 5:26 PM Bruce Momjian wrote:
> I think the ideal solution is to create a section for all the rename
> cases and do all the redirects to that page. The page would list the
> old and new name for each item, and would link to the section for each
> new item.
>
>
Nothing preve
On Fri, Dec 4, 2020 at 12:00 PM Stephen Frost wrote:
> Obviously, I'd then have to adjust the patch that I proposed for default
> roles, or move forward with it as-is, depending on what we end up doing
> here. I dislike what feels like a state of limbo for this right now
> though.
>
>
We have a
Hey,
Would it be accurate to add the following sentence to the INSERT
documentation under "Outputs"?
"...inserted or updated by the command." For a multiple-values insertion,
the order of output rows will match the order that rows are presented in
the values or query clause.
https://www.postgre
On Thursday, December 10, 2020, Ashutosh Bapat
wrote:
> On Wed, Dec 9, 2020 at 9:10 PM David G. Johnston
> wrote:
> >
> > Hey,
> >
> > Would it be accurate to add the following sentence to the INSERT
> documentation under "Outputs"?
> >
&g
On Fri, Dec 11, 2020 at 6:24 AM Ashutosh Bapat
wrote:
> On Thu, Dec 10, 2020 at 7:49 PM David G. Johnston
> wrote:
>
> > Yeah, the ongoing work on parallel inserts would seem to be an issue.
> We should probably document that though. And maybe as part of parallel
> inserts
On Sat, Dec 12, 2020 at 7:02 AM James Coleman wrote:
>
> Certainly almost every ORM, and maybe even other forms of application
> code, need to be able to associate the serial column value returned
> with what it inserted.
>
Yet most ORM would perform single inserts at a time, not in bulk, making
On Mon, Dec 14, 2020 at 12:50 PM Joshua Drake wrote:
> -hackers,
>
> The community has spent a lot of time optimizing features over the years.
> Excellent examples include parallel query and partitioning which have been
> multi-year efforts to increase the quality, performance, and extend
> feat
On Mon, Dec 14, 2020 at 1:40 PM Joshua Drake wrote:
> For example, what would be exceedly helpful would be a documentation style
>>> guide that is canonical and we can review documentation against.
>>>
>>
I do agree with that premise, with the goal of getting more people to
contribute to writing
On Sun, Dec 20, 2020 at 11:07 AM Tom Lane wrote:
> If we could draw a line between "safe" and "unsafe" environment
> variables, I'd be willing to consider a patch that allows directly
> setting only the former. But I don't see how to draw that line.
>
>
IIUC the threat here is for users that wri
On Mon, Dec 21, 2020 at 2:44 PM Bruce Momjian wrote:
> On Sun, Dec 20, 2020 at 09:38:55PM -0500, Stephen Frost wrote:
> > > I'll have a go at adding another keyring and/or abstracting the key
> > > wrap and see how well a true peer to the passphrase approach fits in.
> >
> > Having patches to rev
On Mon, Jan 4, 2021 at 8:26 AM Joel Jacobson wrote:
> In the documentation at
> https://www.postgresql.org/docs/current/functions-admin.html
> this behaviour is not mentioned anywhere as far as I can see:
>
>
https://www.postgresql.org/docs/current/runtime-config-custom.html
I do think "Customiz
On Wednesday, February 17, 2021, Bossart, Nathan
wrote:
>
> postgres=# ALTER ROLE test1 SET ROLE test2;
> ALTER ROLE
>
I would not have expected this to work - “role” isn’t a
configuration_parameter. Its actually cool that it does, but this doc fix
should address this oversight as well.
On Thu, Feb 18, 2021 at 9:00 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
>
> And that seems definitely wrong. Declaring c1 in the above example as
> FOR UPDATE or FOR SHARE does not change the result. I think this
> discussion is mixing up the concept of cursor sensitivity wi
On Saturday, March 6, 2021, David Fetter wrote:
>
> > > SELECT BIT_XOR(b ORDER BY a, c).../* works */
> > > SELECT BIT_XOR(b) OVER (ORDER BY a, c)... /* works */
> > > SELECT BIT_XOR(b) FROM... /* errors out */
> >
> >
> > Why would such an error be necessary,
On Mon, Mar 8, 2021 at 8:48 AM Fujii Masao
wrote:
>
> Thanks for updating the patch! I applied cosmetic changes to that.
> Patch attached. Barring any objection, I will commit this version.
>
Read over the patch and it looks good.
One minor "the" omission (in a couple of places, copy-paste styl
On Wed, Mar 3, 2021 at 5:45 PM Justin Pryzby wrote:
> I'm proposing some minor changes.
>
>
Some additional tweaks/comments for the documentation with the edit
proposed edits:
(edit) + PQresultStatus, will report a
Remove the comma
(orig) + the failed operation are skipped entirely. Th
On Thu, Feb 25, 2021 at 8:37 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 18.02.21 19:14, Peter Eisentraut wrote:
> > On 18.02.21 17:11, David G. Johnston wrote:
> >> The OP was doing a course based on Oracle and was confused regarding
> >>
On Thu, Feb 18, 2021 at 6:18 PM Bossart, Nathan wrote:
> On 2/17/21 2:12 PM, David G. Johnston wrote:
> > On Wednesday, February 17, 2021, Bossart, Nathan > <mailto:bossa...@amazon.com>> wrote:
> >
> >
> > postgres=# ALTER ROLE test1 SET ROLE test
On Mon, Mar 8, 2021 at 4:41 PM David G. Johnston
wrote:
> On Thu, Feb 18, 2021 at 6:18 PM Bossart, Nathan
> wrote:
>
>> On 2/17/21 2:12 PM, David G. Johnston wrote:
>> > On Wednesday, February 17, 2021, Bossart, Nathan > > <mailto:bossa...@amazon.com>>
On Tuesday, March 9, 2021, David Steele wrote:
>
> Further, I think we should close this entry at the end of the CF if it
> does not attract committer interest. Tom is not in favor of the patch and
> it appears Alexander decided not to commit it.
>
Pavel re-reviewed it and was fine with ready-to
On Tue, Mar 9, 2021 at 10:45 AM Pavel Stehule
wrote:
>
>
> út 9. 3. 2021 v 18:03 odesílatel David Steele
> napsal:
>
>> On 11/30/20 10:37 AM, Pavel Stehule wrote:
>> > po 30. 11. 2020 v 16:06 odesílatel David G. Johnston
>> >
>> > ok
>>
On Thu, Mar 11, 2021 at 7:58 AM Laurenz Albe
wrote:
> I think we should *not* document that under "server configuration".
> This is confusing and will lead people to think that a role is
> a configuration parameter. But you cannot add
>
>role = myrole
>
> to "postgresql.conf". A role is not
On Thursday, March 11, 2021, Bossart, Nathan wrote:
> Thanks for reviewing.
>
> On 3/11/21, 6:59 AM, "Laurenz Albe" wrote:
> > I have had a look at the patch, and while I agree that this should
> > be documented, I am not happy with the patch as it is.
> >
> > I think we should *not* document th
On Fri, Mar 12, 2021 at 7:35 AM Laurenz Albe
wrote:
> On Fri, 2021-03-12 at 10:16 +0100, I wrote:
> > After sleeping on it, I have come to think that it is excessive to write
> > so much documentation for a feature that is that unimportant.
> >
> > It takes some effort to come up with a good use
On Fri, Mar 12, 2021 at 1:36 PM Tom Lane wrote:
> Pavel Stehule writes:
> > pá 12. 3. 2021 v 21:08 odesílatel Tom Lane napsal:
> >> I attach a v3 that I like better, although there's room to disagree
> >> about that.
>
> > I am not sure if people can understand the "optimizable command" term.
>
On Monday, October 26, 2020, Nikolay Samokhvalov
wrote:
>
>
> Although, this triggers a question – should ANALYZE be automated in, say,
> pg_restore as well?
>
Independent concern.
>
> And another question: how ANALYZE needs to be run? If it's under the
> user's control, there is an option to u
On Wed, Oct 28, 2020 at 6:50 AM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> Thanks for the comments.
>
> On Wed, Oct 28, 2020 at 6:41 PM Fujii Masao
> wrote:
> >
> > I prefer that false is returned when the timeout happens,
> > like pg_promote() does.
> >
>
> Earlier it w
On Wed, Oct 28, 2020 at 11:55 AM Tomas Vondra
wrote:
> I agree the lack of stats may be quite annoying and cause issues, but my
> guess is the chances of backpatching such change are about 0.01%. We
> have a usable 'workaround' for this - manual analyze.
>
My guess is that it wouldn't be too
On Mon, Oct 26, 2020 at 9:44 PM Nikolay Samokhvalov
wrote:
> On Mon, Oct 26, 2020 at 7:03 PM David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> On Monday, October 26, 2020, Nikolay Samokhvalov
>> wrote:
>>>
>>> Although, this trigger
On Wed, Oct 28, 2020 at 12:05 PM Tom Lane wrote:
> This doesn't seem clearly different from any other situation where
> auto-analyze doesn't react fast enough to suit you.
> I would not
> call it a bug, at least not without a wholesale redefinition of
> how auto-analyze is supposed to work.
On Wed, Oct 28, 2020 at 10:14 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Wed, Oct 28, 2020 at 7:51 PM David G. Johnston
> wrote:
>
> > I was thinking this would be useful for orchestration. However, as you
> say, its a pretty fragile
On Fri, Oct 30, 2020 at 9:16 AM Anastasia Lubennikova <
lubennikov...@gmail.com> wrote:
> Status update for a commitfest entry.
>
> It looks like there was no real progress on this issue since April. I see
> only an experimental patch. What kind of review does it need right now? Do
> we need more
On Tue, Oct 27, 2020 at 1:19 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-10-13 00:43, David G. Johnston wrote:
> > Over in Bug# 16652 [1] Christoph failed to recognize the fact that
> > signal sending functions are inherently one-way just as signa
On Mon, Nov 2, 2020 at 8:58 AM Alvaro Herrera
wrote:
> On 2020-Nov-02, Alvaro Herrera wrote:
>
> > In v23 I've gone over docs; discovered that PQgetResults docs were
> > missing the new values. Added those. No significant other changes yet.
>
>
Just reading the documentation of this patch, have
On Thu, Nov 5, 2020 at 3:43 PM Mohamed Wael Khobalatte <
mkhobala...@grubhub.com> wrote:
> You can always cast to text yourself, of course, but I am not familiar
> with the type hierarchy enough to tell why `to_json` can't deduce that as
> text whereas the other function can.
>
My understanding
On Mon, Nov 9, 2020 at 8:18 AM Stephen Frost wrote:
> Presently, my feeling is that we could address this use-case without
>
having to introduce a new cluster-wide WAL level, and that's the
> direction I'd want to see this going. Perhaps I'm missing something
> about why the approach I've set fo
On Mon, Nov 9, 2020 at 10:36 AM Stephen Frost wrote:
> * David G. Johnston (david.g.johns...@gmail.com) wrote:
>
> > If the commit doesn't complete all of the newly created pages are junk.
> > Otherwise, you have a crash-recoverable state for those tables as regards
&
On Sun, Nov 8, 2020 at 8:56 AM Jürgen Purtz wrote:
>
> Good catches. Everything applied.
>
Reviewed the first three sections.
template0 - I would remove the schema portions of this and simply note this
as being a pristine recovery database in the diagram.
I would drop the word "more" and just
On Sun, Nov 8, 2020 at 8:56 AM Jürgen Purtz wrote:
> Good catches. Everything applied.
>
MVCC Section
The first paragraph and example in the MVCC section is a good example but
seems misplaced - its relationship to MVCC generally is tenuous, rather I
would expect a discussion of the serializable
On Wed, Nov 11, 2020 at 8:56 AM Bruce Momjian wrote:
> > It would be useful if the name of column will be autoassigned based on
> > name of json key. Like at next query:
> >
> > tucha=# select info->>'suma' as suma, docn from document order by id
> desc limit 5;
> > suma | docn
> > +--
On Wed, Nov 11, 2020 at 11:59 AM Eugen Konkov wrote:
> So I feature request to allow zero size step for cases when start
> point is equest to finish
>
> What do you think?
>
I don't see how this is useful. If they are equal and you use a non-zero
step you get back the one record you ar
On Wed, Nov 11, 2020 at 12:12 PM Eugen Konkov wrote:
>
> > So I feature request to allow zero size step for cases when
> start point is equest to finish
>
> > What do you think?
>
>
>
> hm probably with step 0 we always should generate series of one
> value and exit, despite on fin
On Wed, Nov 11, 2020 at 12:44 PM Bruce Momjian wrote:
> On Tue, Nov 10, 2020 at 01:38:14PM +0800, Craig Ringer wrote:
> > Hi all
> >
> > I noticed that when recovery.conf was removed in 2dedf4d9a8 (yay!) the
> docs for
> > it were removed completely as well. That's largely sensible, but is
> conf
On Wed, Nov 11, 2020 at 5:56 PM Bruce Momjian wrote:
> On Thu, Nov 12, 2020 at 12:18:49AM +, Dagfinn Ilmari Mannsåker wrote:
> > Bruce Momjian writes:
> > > I think we could do it, but it would only work if the column was output
> > > as a single json value, and not a multi-key/value field.
On Wed, Nov 11, 2020 at 7:54 PM Eugen Konkov wrote:
> Hello David,
>
> I have a table with services, each service have a period. After which
> service is auto renewal
>
> Services also could be one-time. At this case its interval is '00:00:00'
>
In which case the concept of interval is undefined
On Thu, Nov 12, 2020 at 7:18 AM Eugen Konkov wrote:
> Hello Andrew,
>
> Thursday, November 12, 2020, 3:19:39 PM, you wrote:
>
>
> > On 11/11/20 7:55 PM, Bruce Momjian wrote:
>
> > select j->>x from mytable;
> > What should the column be named?
>
> Suppose it should be named 'as x'
>
+1
>
>
>
On Thu, Nov 12, 2020 at 8:59 AM Andrew Dunstan wrote:
>
>
> So if we then say:
>
>
> select x, j->>x from mytable;
>
>
> you want both result columns named x? That seems like a recipe for
> serious confusion. I really don't think this proposal has been properly
> thought through.
>
>
IMO It n
On Thu, Nov 12, 2020 at 9:32 AM Andrew Dunstan wrote:
>
> On 11/12/20 11:12 AM, David G. Johnston wrote:
> > On Thu, Nov 12, 2020 at 8:59 AM Andrew Dunstan > <mailto:and...@dunslane.net>> wrote:
> >
> >
> >
> > So if we then say:
On Thursday, November 12, 2020, Bruce Momjian wrote:
> On Thu, Nov 12, 2020 at 01:52:11PM -0500, Tom Lane wrote:
> > On the whole, I'm on the side of the people who don't want to change
> this.
> > The implementation cost seems likely to greatly outweigh the value, plus
> > it feels more like a w
On Fri, Nov 13, 2020 at 10:42 AM Bruce Momjian wrote:
> I think the big problem, and I have seen this repeatedly, is showing up
> with a patch without discussing whether people actually want the
> feature. I know it is a doc issue, but our TODO list has the order as:
>
> Desirability ->
On Mon, Nov 16, 2020 at 1:52 PM Simon Riggs wrote:
> The docs are misleading for this feature, since they say:
> "This option disables all page-skipping behavior, and is
> intended to be used only when the contents of the visibility map are
> suspect, which should happen only if there is a hardwa
On Fri, Nov 13, 2020 at 5:38 PM Alvaro Herrera
wrote:
> Here's a v25.
>
> I made a few more changes to the docs per David's suggestions; I also
> reordered the sections quite a bit. It's now like this:
> * Batch Mode
>* Using Batch Mode
> * Issuing Queries
> * Processing Results
>
On Mon, Nov 16, 2020 at 5:41 AM Li Japin wrote:
> Thanks for your review! Attached.
>
Reading the doc changes:
I'd rather not name postgres_fdw explicitly, or at least not solely, as a
reason for setting this to zero. Additionally, using postgres_fdw within
the server doesn't cause issues, its
On Monday, November 16, 2020, Li Japin wrote:
>
>
> Consider setting this for specific users instead of as a server default.
> Client connections managed by connection poolers, or initiated indirectly
> like those by a remote postgres_fdw using server, should probably be
> excluded from this tim
On Tue, Nov 17, 2020 at 6:13 AM Heikki Linnakangas wrote:
> On 02/11/2020 18:02, David G. Johnston wrote:
> > diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
> > index bf6004f321..43bc2cf086 100644
> > --- a/doc/src/sgml/func.sgml
> > +++ b/doc/src/sgm
On Tue, Nov 17, 2020 at 7:00 PM Michael Paquier wrote:
> On Tue, Nov 17, 2020 at 11:18:12PM +0100, Peter Eisentraut wrote:
> > So the mention of the "port" doesn't really add any information here and
> > just introduces new terminology that isn't really relevant.
> >
> > My idea is to change the
On Wednesday, November 18, 2020, Vlad Bokov wrote:
> Hi, I wonder why there's no function to aggregate arrays by
> concatenation out of the box?
>
See array_agg(...)
David J.
On Wed, Nov 18, 2020 at 5:37 PM Vik Fearing wrote:
> On 11/18/20 11:19 PM, David G. Johnston wrote:
> > On Wednesday, November 18, 2020, Vlad Bokov wrote:
> >
> >> Hi, I wonder why there's no function to aggregate arrays by
> >> concatenation out
On Wed, Nov 18, 2020 at 5:54 PM Chapman Flack wrote:
> On 11/18/20 19:46, David G. Johnston wrote:
>
> > I doubt there is any substantial resistance to including such a function
> > but it would have to be written in C.
>
> Would anything have to be written at all, s
Hackers,
Over in news [1] Josh Drake and Eric Ridge discovered the undocumented
feature "IS [NOT] OF"; introduced seemingly as an "oh-by-the-way" in 2002
via commit eb121ba2cfe [2].
Is there any reason not to document this back to 9.5, probably with a note
nearby to pg_typeof(any), which is a con
On Wednesday, November 18, 2020, Tom Lane wrote:
> I wrote:
> > So my vote would be to rip it out, not document it. Somebody can try
> > again in future, perhaps. But if we document it we're just locking
> > ourselves into a SQL incompatibility.
>
> Apparently, somebody already had that thought
On Friday, November 20, 2020, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-11-18 04:35, David G. Johnston wrote:
>
>>
>>
>> I agree that there isn't a useful hint for the abstract case as it
>> shouldn't happen unless the
On Mon, Nov 23, 2020 at 6:50 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-11-20 18:23, David G. Johnston wrote:
> > If there is dead code there is an underlying problem to
> > address/discover, not just removing the dead code. In this case are we
On Mon, Nov 23, 2020 at 5:02 PM kuroda.hay...@fujitsu.com <
kuroda.hay...@fujitsu.com> wrote:
> No one have any comments, patch tester says OK, and I think this works
> well.
> I changed status to "Ready for Committer."
>
Some proof-reading:
v8-0001
Documentation:
My suggestion wasn't taken for
On Mon, Nov 23, 2020 at 11:22 PM Li Japin wrote:
>
> How about use “foreign-data wrapper” replace “postgres_fdw”?
>
I don't see much value in avoiding mentioning that specific term - my
proposal turned it into an example instead of being exclusive.
> - This parameter should be set to z
On Mon, Nov 23, 2020 at 9:00 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> Or is it the case that we always attempt to bind the TCP/IP port,
> regardless of the presence of a socket file, in which case the failure for
> port binding does cover the socket situation a
On Tue, Nov 24, 2020 at 8:45 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> We're subject to whatever the kernel behavior is. If the kernel doesn't
> report address conflicts for Unix-domain sockets, then we can't do
> anything about that. Having an error message ready in case
On Wed, Nov 25, 2020 at 8:14 AM Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
> Hi hackers,
>
> I wonder if it is considered as correct behavior that transaction
> conflict detection depends on presence of primary key:
>
> create table t(pk integer, val integer);
> insert into t values (
On Sat, Nov 28, 2020 at 4:18 PM Eugen Konkov wrote:
> Hi all.
>
> I often fall into error like this:
>
> DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st
> execute failed: ERROR: timestamp out of range
> CONTEXT: SQL function "accounting_ready" statement 1 [for Statement
>
On Thu, Nov 26, 2020 at 12:49 AM Pavel Stehule
wrote:
>
>
> čt 26. 11. 2020 v 6:41 odesílatel David G. Johnston <
> david.g.johns...@gmail.com> napsal:
>
>> Hackers,
>>
>> Bug # 16519 [1] is another report of confusion regarding trying to use
>> pa
1 - 100 of 1174 matches
Mail list logo
