On Mon, Oct 16, 2023 at 12:36 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Mon, Oct 16, 2023 at 12:09 PM Laurenz Albe
> wrote:
>
>> I think it won't meet with favor if there are cases that require manual
>> intervention
>> for starting the se
Hi!
This email is a first pass at a user-visible design for how our backup and
restore process, as enabled by the Low Level API, can be modified to make
it more mistake-proof. In short, it requires pg_start_backup to further
expand upon what it means for the system to be in the midst of a
On Mon, Oct 16, 2023 at 6:19 PM Laurenz Albe
wrote:
> On Mon, 2023-10-16 at 23:51 +0200, Erik Wienhold wrote:
> > What's the process for the CommitFest now since we settled on your
> > patch? This is my first time being involved in this, so still learning.
> > I'see that you've withdrawn your
On Thu, Oct 26, 2023 at 3:36 PM Bruce Momjian wrote:
> No sneaking. ;-) It would be bad to document this unevenly because it
> sets expectations in other parts of the system if we don't mention it.
>
Agreed.
Last suggestion, remove the first jsonb_agg example that lacks an order by.
+WITH
On Thu, Oct 26, 2023 at 2:56 PM Bruce Momjian wrote:
> On Wed, Oct 25, 2023 at 10:34:10PM -0700, David G. Johnston wrote:
> > I would reword the existing note to be something like:
> >
> > The SQL Standard defines specific aggregates and their properties,
> includi
On Thu, Oct 26, 2023 at 4:03 PM Bruce Momjian wrote:
>
> Sure, done in the attached patch.
>
>
WFM. Thank You!
David J.
On Thu, Oct 26, 2023 at 2:02 PM David Steele wrote:
> Hackers,
>
> This was originally proposed in [1] but that thread went through a
> number of different proposals so it seems better to start anew.
>
> The basic idea here is to simplify and harden recovery by getting rid of
> backup_label and
On Thu, Oct 26, 2023 at 3:51 PM Bruce Momjian wrote:
> On Wed, Nov 23, 2022 at 02:33:27PM -0600, Justin Pryzby wrote:
> > On Wed, Nov 23, 2022 at 12:35:59PM -0700, David G. Johnston wrote:
> > > On Wed, Nov 23, 2022 at 11:47 AM Tom Lane wrote:
> > >
> > > >
On Thu, Oct 26, 2023 at 4:13 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Thu, Oct 26, 2023 at 4:08 PM Tom Lane wrote:
>
>> Bruce Momjian writes:
>> > Ah, I was confused. I documented both in the attached patch.
>>
>> The function one
On Thu, Oct 26, 2023 at 4:08 PM Tom Lane wrote:
> Bruce Momjian writes:
> > Ah, I was confused. I documented both in the attached patch.
>
> The function one should have the same annotation as some others:
>
> can be increased by recompiling
> PostgreSQL
>
>
I'd like to see a comment on
On Wed, Oct 25, 2023 at 7:13 PM David Rowley wrote:
> On Thu, 26 Oct 2023 at 13:10, David G. Johnston
> wrote:
> > Question: Do you know whether we for certain always sort ascending here
> to compute the unique values or whether if, say, there is an index on the
> column i
On Wed, Oct 25, 2023 at 8:36 AM Bruce Momjian wrote:
> On Tue, Oct 24, 2023 at 06:45:48PM -0700, David G. Johnston wrote:
> > I'd prefer to keep pointing out that the ones documented are those whose
> > outputs will vary due to ordering.
>
> Okay, I re-added it
On Wed, Oct 25, 2023 at 4:22 PM Bruce Momjian wrote:
> On Wed, Oct 25, 2023 at 04:14:11PM -0700, David G. Johnston wrote:
> > Yeah, we punt on the entire concept in the data type section:
> >
> > "Managing these errors and how they propagate through calculations is th
On Fri, Oct 27, 2023 at 7:10 AM David Steele wrote:
> On 10/26/23 17:27, David G. Johnston wrote:
>
> > Can we not figure out some way to place the relevant files onto the
> > server somewhere so that a simple "cp" command would work? Have
> > pg_backup_sto
On Friday, November 3, 2023, Mark Hills wrote:
>
> pg_restore: error: could not execute query: ERROR: type "hash" does not
> exist
> LINE 7: )::hash;
> [...]
> CONTEXT: SQL function "gen_hash" during inlining
>
> --
> -- Relevant SQL declarations
> --
>
Those were not all of
On Mon, Oct 30, 2023 at 2:50 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tue, Oct 3, 2023 at 12:52 AM Laurenz Albe
> wrote:
>
>> On Mon, 2023-10-02 at 09:49 -0400, Tom Lane wrote:
>> > This is by design: triggers operate at a lower level tha
On Tue, Oct 3, 2023 at 12:52 AM Laurenz Albe
wrote:
> On Mon, 2023-10-02 at 09:49 -0400, Tom Lane wrote:
> > This is by design: triggers operate at a lower level than
> > foreign keys, so an ill-conceived trigger can break an FK constraint.
> > That's documented somewhere, though maybe not
On Monday, October 23, 2023, Laurenz Albe wrote:
> On Mon, 2023-10-23 at 08:35 -0700, David G. Johnston wrote:
>
> > along with not translating (none) and (default) and thus making the data
> contents
> > of these views environment independent. But minimizing the variance
On Tue, Oct 24, 2023 at 1:39 PM Bruce Momjian wrote:
> On Tue, Dec 13, 2022 at 07:38:15PM -0700, David G. Johnston wrote:
> > All,
> >
> > The recent discussion surrounding aggregates and ORDER BY moved me to
> look over
> > our existing documentation, espe
On Wednesday, October 18, 2023, David Steele wrote:
> On 10/18/23 08:39, Robert Haas wrote:
>
>> On Tue, Oct 17, 2023 at 4:17 PM David Steele wrote:
>>
>>> Given that the above can't be back patched, I'm thinking we don't need
>>> backup_label at all going forward. We just write the values we
On Fri, Oct 6, 2023 at 1:29 PM Laurenz Albe
wrote:
> On Fri, 2023-10-06 at 22:18 +0200, Laurenz Albe wrote:
> > On Fri, 2023-10-06 at 22:16 +0200, Laurenz Albe wrote:
> > > Here is a patch that does away with the special handling of NULL values
> > > in psql backslash commands.
> >
> > Erm, I
On Tue, Oct 17, 2023 at 10:50 AM Robert Haas wrote:
> Life would be a lot easier here if we could get rid of the low-level
> backup API and just have pg_basebackup DTWT, but that seems like a
> completely non-viable proposal.
>
Yeah, my contribution to this area [1] is focusing on the API
On Sun, Sep 17, 2023 at 5:34 PM Erik Wienhold wrote:
> On 18/09/2023 00:57 CEST Vik Fearing wrote:
>
> > On 9/18/23 00:41, Erik Wienhold wrote:
> > > On 18/09/2023 00:13 CEST David E. Wheeler
> wrote:
> > >
> > >> david=# select to_regtype('inteval second');
> > >> ERROR: syntax error at or
On Sun, Sep 17, 2023 at 6:25 PM Chapman Flack wrote:
> On 2023-09-17 20:58, David G. Johnston wrote:
> > Put differently, there is no syntax involved when the value being
> > provided
> > is the text literal name of a type as it is stored in pg_type.typname,
> > so
&
On Sunday, September 17, 2023, Chapman Flack wrote:
>
> In this one, both identifiers are part of the type name, and the
> separator a little more flamboyant.
>
> select to_regtype('character /* hi!
> am I part of the type name? /* what, me too? */ ok! */ -- huh!
> varying');
> to_regtype
>
On Fri, Sep 29, 2023 at 10:45 AM James Coleman wrote:
> Hello,
>
> While working on my talk for PGConf.NYC next week I came across this
> bullet in the docs on heap only tuples:
>
> > Old versions of updated rows can be completely removed during normal
> > operation, including SELECTs, instead
On Wednesday, September 27, 2023, jacktby jacktby wrote:
> postgres=# SET enable_seqscan = off;
> SET
> postgres=# explain select * from t;
>QUERY PLAN
> -
> Seq Scan on t
On Mon, Oct 2, 2023 at 12:25 PM Tom Lane wrote:
> Himanshu Upadhyaya writes:
> > V3 patch attached.
>
> Sorry for not weighing in on this before, but ... is this a feature
> we want at all? We are very clear in the existing docs that CHECK
> conditions must be immutable [1], and that's not
On Sun, Oct 1, 2023 at 8:57 AM Zhang Mingli wrote:
> And if it’s true, shall we skip the order by clause for Materialized
> View when executing create/refresh statement?
>
We tend to do precisely what the user writes into their query. If they
don't want an order by they can remove it. I
On Tue, Oct 3, 2023 at 10:56 AM Karl O. Pinc wrote:
> On Mon, 2 Oct 2023 15:18:32 -0500
> "Karl O. Pinc" wrote:
>
> Version 7
>
>
0001 - I would just call the section:
Capturing Command Results into Variables
I would add commentary in there that it is only possible for variables to
take on
On Monday, October 2, 2023, Andreas Joseph Krogh wrote:
> På fredag 07. juli 2023 kl. 13:50:44, skrev Dilip Kumar <
> dilipbal...@gmail.com>:
>
> On Wed, Jul 5, 2023 at 3:08 PM Himanshu Upadhyaya
> wrote:
> >
> > Hi,
> >
> > Currently, there is no support for CHECK constraint DEFERRABLE in a
>
On Tue, Oct 3, 2023 at 4:15 PM Karl O. Pinc wrote:
> On Tue, 3 Oct 2023 14:51:31 -0700
> "David G. Johnston" wrote:
>
> Isn't the entire section about "deviating from the normal flow of the
> code"? That's what makes me want "Exception" in the sec
Extending my prior email which is now redundant.
On Tue, Oct 3, 2023 at 7:00 PM David G. Johnston
wrote:
> On Tue, Oct 3, 2023 at 4:15 PM Karl O. Pinc wrote:
>
>> On Tue, 3 Oct 2023 14:51:31 -0700
>> "David G. Johnston" wrote:
>>
>> Isn't the entire
On Sun, Oct 8, 2023 at 6:55 PM Erik Wienhold wrote:
> On 2023-10-08 06:14 +0200, Laurenz Albe write:
> > On Sat, 2023-10-07 at 20:41 +0200, Erik Wienhold wrote:
> > > > If you are happy enough with my patch, shall we mark it as ready for
> > > > committer?
> > >
> > > I amended your patch to
On Sun, Oct 8, 2023 at 9:10 PM Noah Misch wrote:
>
> I didn't think of any phrasing that clearly explained things without the
> reader consulting the code. I considered these:
>
> "socket file descriptor out of range: %d" [what range?]
>
>
Quick drive-by...but it seems that < 0 is a
On Thu, Oct 12, 2023 at 7:36 AM Tom Lane wrote:
> Nikita Malakhov writes:
> > Please advise on the idea of preserving pg_proc oids during pg_upgrade,
> in
> > a way like relfilenodes, type id and so on. What are possible downsides
> of
> > such a solution?
>
> You have the burden of proof
On Thu, Oct 12, 2023 at 9:57 AM Nikita Malakhov wrote:
> Say, we have data processed by some user function and we want to keep
> reference to this function
> in our data.
>
Then you need to keep the user-visible identifier of said function
(schema+name+input argument types - you'd probably want
On Thu, Oct 12, 2023 at 1:31 PM Nikita Malakhov wrote:
> About using surrogate key - this feature is more for data generated by
> the DBMS itself, i.e. data processed by some extension and saved
> and re-processed automatically or by user's request, but without bothering
> user with these
On Thu, Oct 12, 2023, 11:21 Robert Haas wrote:
>
> The pg_upgrade experience right now is a bit as if you woke up in the
> morning and found that city officials came by during the night and
> renumbered your house, thus changing your address. Then, they sent
> change of address forms to everyone
On Thu, Oct 12, 2023 at 11:43 AM Robert Haas wrote:
> On Thu, Oct 12, 2023 at 2:38 PM David G. Johnston
> wrote:
> > It's more like a lot number or surveying tract than an postal address.
> Useful for a single party, the builder or the government, but not something
> you
On Thu, Oct 12, 2023 at 2:58 PM Nikita Malakhov wrote:
> Why pg_upgrade cannot be used?
>
We document both a pg_dump/pg_restore migration and a pg_upgrade one (not
to mention that logical backup and restore would cause the oids to
change). It seems odd to have a feature that requires
On Wednesday, October 4, 2023, Jon Erdman wrote:
>
> So I'd like to get a general idea how likely this would be to getting
> accepted if it did it, and did it right?
>
Run a cron job checking for them. Allow for overrides by adding a comment
to any unclogged tables you’ve identified as being
On Tue, Oct 17, 2023 at 12:30 PM David Steele wrote:
> On 10/17/23 14:28, Robert Haas wrote:
> > On Mon, Oct 16, 2023 at 5:21 PM David G. Johnston
> > wrote:
> >> But no, by default, and probably so far as pg_basebackup is concerned,
> a server crash during backup r
On Thursday, October 19, 2023, David Steele wrote:
> On 10/19/23 10:24, Robert Haas wrote:
>
>> On Wed, Oct 18, 2023 at 7:15 PM David Steele wrote:
>>
>>>
pg_llbackup -d $CONNTR --backup-label=PATH --tablespace-map=PATH
--copy-data-directory=SHELLCOMMAND
I think in most
On Mon, Oct 9, 2023 at 1:29 AM Laurenz Albe
wrote:
> On Sun, 2023-10-08 at 19:58 -0700, David G. Johnston wrote:
>
> > The built-in default privileges are only in effect if the object has not
> been
> > the target of a GRANT or REVOKE and also has not had its default
>
On Mon, Oct 9, 2023 at 1:27 PM Robert Haas wrote:
> On Tue, Oct 3, 2023 at 10:05 AM David G. Johnston
> wrote:
> >> The real-world use case, at least for me, is when using an ORM. For
> large object-graphs ORMs have a tendency to INSERT first with NULLs then
> UPDATE
On Mon, Oct 9, 2023 at 12:13 PM Tom Lane wrote:
> Laurenz Albe writes:
> > On Mon, 2023-10-09 at 09:30 -0700, David G. Johnston wrote:
> >> My point with the second paragraph is that we could, instead of
> documenting the
> >> caveat about null printing as emp
On Fri, Oct 20, 2023 at 12:34 PM Tom Lane wrote:
> Laurenz Albe writes:
> > I am not sure how to proceed. Perhaps it would indeed be better to have
> > two competing commitfest entries. Both could be "ready for committer",
> > and the committers can decide what they prefer.
>
> As near as I
On Fri, Oct 20, 2023 at 12:57 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > On Fri, Oct 20, 2023 at 12:34 PM Tom Lane wrote:
> >> As near as I can tell, doing both things (the \pset null fix and
> >> substituting "(none)" for empty
On Fri, Oct 20, 2023 at 7:29 PM Erik Wienhold wrote:
> On 2023-10-20 22:35 +0200, David G. Johnston wrote:
> > In short, I don't want default privileges to start to obey \pset null
> when
> > it never has before and is documented as displaying the empty string. I
> do
>
On Monday, October 23, 2023, Laurenz Albe wrote:
>
> --- a/src/bin/psql/describe.c
> +++ b/src/bin/psql/describe.c
> @@ -6718,7 +6680,13 @@ static void
>printACLColumn(PQExpBuffer buf, const char *colname)
>{
> appendPQExpBuffer(buf,
> -
On Monday, October 23, 2023, Laurenz Albe wrote:
> On Mon, 2023-10-23 at 07:03 -0700, David G. Johnston wrote:
> > On Monday, October 23, 2023, Laurenz Albe
> wrote:
> > >
> > > --- a/src/bin/psql/describe.c
> > > +++ b/src/bin/psql/describe.c
>
On Mon, Oct 23, 2023 at 7:57 AM Tom Lane wrote:
>
> IOW, the current definition is "NULL privileges print as an empty
> string no matter what", and I don't think that serves to reduce
> confusion about whether an ACL is NULL or not. We ought to be doing
> what we can to make clear that such an
On Monday, October 23, 2023, Laurenz Albe wrote:
> On Mon, 2023-10-23 at 11:37 -0700, David G. Johnston wrote:
> > > I didn't understand this completely. You want default privileges
> displayed as
> > > "(default)", but are you for or against "
On Monday, October 23, 2023, Tom Lane wrote:
> Laurenz Albe writes:
> > On Mon, 2023-10-23 at 11:37 -0700, David G. Johnston wrote:
> >> I do believe that we should be against exposing, like in this case, any
> internal
> >> implementation detail that encodes somet
On Friday, August 25, 2023, Hongxu Ma wrote:
>
>
> When I tried to select a big amount of rows, psql complains a error "Cannot
> add cell to table content: total cell count of 905032704 exceeded."
>
> We should use long for ncolumns and nrows and give a more obvious error
> message here.
>
> Any
On Thu, Apr 21, 2022 at 10:46 AM Alvaro Herrera
wrote:
> On 2022-Apr-20, David G. Johnston wrote:
>
> > v0001-doc-savepoint-name-reuse (-docs, reply to user request for
> > improvement)
> >
> https://www.postgresql.org/message-id/CAKFQuwYzSb9OW5qTFgc0v9R
On Thu, Apr 21, 2022 at 12:51 PM Robert Haas wrote:
> On Thu, Apr 21, 2022 at 12:30 AM Michael Paquier
> wrote:
> > On Tue, Apr 19, 2022 at 12:13:51PM -0400, Robert Haas wrote:
> > > On Mon, Apr 18, 2022 at 9:50 PM Kyotaro Horiguchi
> > > wrote:
> > >> Hmm.. So, "-r/--role" and
On Wed, Apr 20, 2022 at 11:38 PM bu...@sohu.com wrote:
> > > for now fuction cost_subqueryscan always using *total* rows even
> parallel
> > > path. like this:
> > >
> > > Gather (rows=3)
> > > Workers Planned: 2
> > > -> Subquery Scan (rows=3) -- *total* rows, should be equal
>
On Wed, Apr 20, 2022 at 1:03 AM Kyotaro Horiguchi
wrote:
>
> The reason for the 2 hits of Xact SLRU is that once for visibility
> (MVCC) check and another for commit.
>
>
Makes sense. Thanks. Now, is the lack of such a detail when looking at
pg_stat_slru (for this and the other 6 named caches)
On Wed, Apr 20, 2022 at 2:04 PM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 19.04.22 15:55, David G. Johnston wrote:
> > The motivating situation had me placing it as close to the last line as
> > possible so my 8 line or so tmux panel would
On Wed, Apr 20, 2022 at 4:39 PM Tyler Brock wrote:
> I think this makes sense but I wanted to get confirmation:
>
> I created a table with a column having the type int4 (integer). When I
> insert a row with a number into that column and get it back out I've
> observed a discrepancy:
>
> The
On Wed, Apr 20, 2022 at 5:11 PM Tyler Brock wrote:
> For sure, I’m thinking of it that way. Thanks for confirming.
>
> What I don’t understand is that if I respond to psql with the
> RowDescription indicating the format code is 1 for binary (and encode it
> that way, with 4 bytes, in the
On Wed, Apr 20, 2022 at 5:21 PM Tyler Brock wrote:
> I’m not sure what top-posting is?
>
It's when you place your replies before what you are replying to.
https://en.wikipedia.org/wiki/Posting_style
Unlike mine, which is inline-posting, where the reply is after the thing
being replied to,
Hackers,
The new cumulative stats subsystem no longer has a "lost under heavy load"
problem so that parenthetical should go (or at least be modified).
These stats can be reset so some discussion about how the system uses them
given that possibility seems like it would be good to add here. I'm
Hackers,
I posted all of these elsewhere (docs, bugs) but am consolidating them here
going forward.
v0001-database-default-name (-bugs, with a related cleanup suggestion as
well)
On Thu, Apr 21, 2022 at 7:18 AM Tom Lane wrote:
> Peter Eisentraut writes:
> > I'm not a particular fan of the current initdb output and it could use a
> > general revision IMO. If you want to look into that, please do. But
> > for your particular proposed addition, let's put it somewhere it
On Tue, Apr 19, 2022 at 2:28 AM Daniel Gustafsson wrote:
> > On 16 Apr 2022, at 01:50, David G. Johnston
> wrote:
>
> > initdb is already pretty chatty, and the version of the cluster being
> installed seems useful to include as well.
>
> That seems quite reasonabl
On Tue, Apr 19, 2022 at 7:00 AM Robert Haas wrote:
> On Mon, Apr 18, 2022 at 3:39 PM Mark Dilger
> wrote:
> > Since there hasn't been any agreement on that point, I've just rebased
> the patch to apply cleanly against the current master:
>
> This looks OK to me. There may be better ways to do
view bc is just a joining wrapper around pg_buffercache.
regression=# select datname, relname, count(*), sum(count(*)) over () AS
total from bc where isdirty group by datname, relname;
datname | relname | count | total
-+-+---+---
(0 rows)
regression=# update tenk1 set
On Mon, Apr 18, 2022 at 1:48 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > On Mon, Apr 18, 2022 at 1:00 PM Simon Riggs <
> simon.ri...@enterprisedb.com>
> > wrote:
> >> I propose that we change pg_dump so that when it creates a PK it does
&g
On Tue, Apr 19, 2022 at 9:14 AM Simon Riggs
wrote:
> On Mon, 18 Apr 2022 at 22:05, Simon Riggs
> wrote:
> >
> > On Mon, 18 Apr 2022 at 21:48, Tom Lane wrote:
> > >
> > > "David G. Johnston" writes:
> > > > On Mon, Apr 18, 20
On Tue, Apr 19, 2022 at 4:36 PM Nathan Bossart
wrote:
> On Tue, Apr 19, 2022 at 04:21:21PM -0700, David G. Johnston wrote:
> > I've done this four times in a row and while the number of dirty buffers
> > shown each time vary (see below) I see that "wrote N buffers" is al
Hi,
Both the location and name of the linked to section make no sense to me:
https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-DBOBJECT
Neither of the tables listed there manage (cause to change) anything. They
are pure informational functions - size and path of
On Mon, Apr 25, 2022 at 1:24 AM Jiří Fejfar wrote:
> contrib_regression=# copy (select 1) to :'afile';
>
Hopefully you realize that COPY is going to place that file on the server,
not send it to the psql client to be placed on the local machine.
The best way to do copy in psql is:
\set afile
On Wednesday, April 6, 2022, Andres Freund wrote:
>
>
> I'd go for
> pgstat_reset_slru_counter() -> pgstat_reset_slru()
> pgstat_reset_subscription_counter() -> pgstat_reset_subscription()
> pgstat_reset_subscription_counters() -> pgstat_reset_all_subscriptions()
>
On Wed, Apr 6, 2022 at 4:12 PM Andres Freund wrote:
>
> On 2022-04-06 15:32:39 -0700, David G. Johnston wrote:
> > On Wednesday, April 6, 2022, Andres Freund wrote:
> >
> >
> > I like having the SQL function paired with a matching implementation in
> > t
On Wed, Apr 6, 2022 at 6:16 PM Tom Lane wrote:
> "Jonathan S. Katz" writes:
> > I am a bit torn between "\dcp" (or \dsetting / \dconfig? we don't
> > necessarily need for it to be super short) and "\sc". Certainly with
> > pattern matching the interface for the "\d" commands would fit that
> >
On Friday, April 22, 2022, Jian He wrote:
> select arraymultirange(arrayrange(array[1,2], array[2,1]));
>
> ERROR: 42883: function arrayrange(integer[], integer[]) does not exist
>> LINE 1: select arraymultirange(arrayrange(array[1,2], array[2,1]));
>>^
>> HINT:
On Tuesday, May 17, 2022, Chirag Karkera wrote:
>
>
> the user has to be provided the read only access on system catalog tables
> (information_schema and pg_catalog)
>
All roles have this, no action required.
David J.
On Tue, May 17, 2022 at 6:21 AM Chirag Karkera
wrote:
> Thanks David for your reply!
>
> But when i created a role i am not able to view objects under
> information_schema.*
>
> I mean I am not able to view the data, I can see only the column names.
>
>>
>>
Which goes to demonstrate you have
On Wed, May 18, 2022 at 6:35 PM Shinya Kato
wrote:
> > Too bad there's no --comment parameter to do COMMENT ON ROLE name IS
> > 'Comment';
> >
> > As you already make such changes in createuser, I would like to ask
> > for an additional --comment parameter
> > that will allow sysadmins to set a
On Sat, May 21, 2022 at 8:32 AM Ranier Vilela wrote:
> Em sáb., 21 de mai. de 2022 às 12:05, Tomas Vondra <
> tomas.von...@enterprisedb.com> escreveu:
>
>>
>>
>> On 5/21/22 15:06, Ranier Vilela wrote:
>> >>Zhihong Yu writes:
>> >>> I was looking at the code in hash_record()
>> >>> of
On Sat, May 21, 2022 at 10:04 AM Ranier Vilela wrote:
> Em sáb., 21 de mai. de 2022 às 13:13, Tom Lane
> escreveu:
>
>> Ranier Vilela writes:
>> > Em sáb., 21 de mai. de 2022 às 12:05, Tomas Vondra <
>> > tomas.von...@enterprisedb.com> escreveu:
>> >> That's a quite bold claim, and yet you
On Wednesday, May 25, 2022, Japin Li wrote:
>
> Hi,
>
> Today, I try to use repeat() to generate 1GB text, and it occurs invalid
> memory
> alloc request size [1]. It is a limit from palloc(), then I try to reduce
> it,
> it still complains out of memory which comes from enlargeStringInfo()
>
ipped even with the couple of bad bugs being worked on.
Thank you!
David J.
On Fri, Apr 29, 2022 at 6:52 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> Updated status of the set.
>
> On Wed, Apr 20, 2022 at 5:59 PM David G. Johnston <
> david.g.johns...@gmail.com
On Sunday, May 22, 2022, Saladin wrote:
>
> The output i expected:
> pg_largeobject_metadata and pg_largeobject in both database A and database
> B should have rows.Shouldn't only in database A.So, i can use large object
> functions
> to operate large_objectin remote table or foreign table.
>
On Wed, Jun 1, 2022 at 7:05 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 31.05.22 22:12, David G. Johnston wrote:
> > Anything I should be doing differently here to get a bit of
> > reviewer/committer time on these? I'll add them to the commitfe
On Sat, May 28, 2022 at 9:35 AM Roffild wrote:
> Docker is now the DevOps standard. It's easier to build an image for
> Docker and run the site with one command.
>
> But the volume mount has a limitation with chmod 755. I don't want to
> write the database directly to the container.
>
> The
On Tue, Jun 21, 2022 at 6:49 AM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> Hi David,
>
> > It's basically a glorified cross-reference. I didn't dislike directing
> the reader to the internals section enough to try and establish a better
> location for the main content.
>
> One
On Tue, Jun 21, 2022 at 6:33 AM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> Hi David,
>
> > Per discussion here:
> >
> >
> https://www.postgresql.org/message-id/163636931138.8076.5140809232053731248%40wrigleys.postgresql.org
> >
> > We can now easily document the array_length
On Fri, Jun 24, 2022 at 1:19 PM Robert Haas wrote:
> On Mon, Jun 6, 2022 at 7:41 PM Stephen Frost wrote:
> >
> > In terms of how that's then used, yeah, it's during REVOKE because a
> > REVOKE is only able to 'find' role authorization descriptors which match
> > the triple of role revoked,
On Fri, Jun 24, 2022 at 3:08 PM Hannu Krosing wrote:
>
> 1) would it be enough to just disable WRITING to the filesystem (COPY
> ... TO ..., COPY TO ... PROGRAM ...) or are some reading functions
> also potentially exploitable or at least making attackers life easier
> ?
>
I would protect read
On Friday, June 24, 2022, Gurjeet Singh wrote:
> On Fri, Jun 24, 2022 at 4:13 PM Andres Freund wrote:
> > On 2022-06-25 00:08:13 +0200, Hannu Krosing wrote:
>
> > > 3) should this be back-patched (we can provide batches for all
> > > supported PgSQL versions)
> >
> > Err, what?
>
> Translation:
On Fri, Jun 24, 2022 at 4:13 PM Andres Freund wrote:
> Hi,
>
> On 2022-06-25 00:08:13 +0200, Hannu Krosing wrote:
> > Currently the file system access is controlled via being a SUPREUSER
> > or having the pg_read_server_files, pg_write_server_files and
> > pg_execute_server_program roles. The
On Tue, Jul 5, 2022 at 5:20 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > In passing, the authentication error examples use the phrase
> > "database user name" in a couple of locations. The word
> > database in b
On Thu, Jun 30, 2022 at 2:31 PM Peter Geoghegan wrote:
> On Thu, Jun 30, 2022 at 2:07 PM David G. Johnston
> wrote:
> > Current:
> > "The SET and WHERE clauses in ON CONFLICT DO UPDATE have access to the
> > existing row using the table's name (or an a
On Fri, Jul 1, 2022 at 7:58 AM Peter Geoghegan wrote:
> On Fri, Jul 1, 2022 at 6:01 AM Robert Haas wrote:
> > What would probably help more is adding something like this to the
> > error message:
> >
> > HINT: column "b" could refer to any of these relations: "foo", "excluded"
> >
> > That
On Friday, July 8, 2022, Bruce Momjian wrote:
> On Fri, Jul 8, 2022 at 10:17:11PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Tue, Jul 5, 2022 at 08:20:25PM -0400, Tom Lane wrote:
> > >> I agree this phrasing needs some work, but "resolved" doesn't seem
> > >> helpful, since
On Sat, Jul 9, 2022, 08:16 Bruce Momjian wrote:
> On Sat, Jul 9, 2022 at 08:06:21AM -0700, David G. Johnston wrote:
> > Maybe invoke the wording from the libpq docs and say:
> >
> > The default database name is the same as the user connection parameter.
> >
> >
601 - 700 of 1088 matches
Mail list logo
