e some of the path names in our tarball, so
> > keeping things from getting to carpal-tunnel-inducing lengths
> > does have its advantages.
>
> On Wed, Jun 9, 2021 at 2:51 PM Noah Misch wrote:
> > Not bad, but I would instead shorten the names to detach-[1234] or
> &g
On Wed, Jun 09, 2021 at 01:57:45PM +1200, Thomas Munro wrote:
> test deadlock-simple ... ok 20 ms
> test deadlock-hard... ok10624 ms
> test deadlock-soft... ok 147 ms
> test deadlock-soft-2 ... ok 5154 ms
On Sun, Jun 06, 2021 at 03:10:07PM -0400, Tom Lane wrote:
> I wrote:
> > We could make use of COMPARE_COERCIONFORM_FIELD 100% correct by removing
> > these two tests of the funcformat value, but on the whole I doubt that
> > would be better.
>
> On still closer inspection, that seems like it'd be
On Tue, Nov 03, 2020 at 07:22:14PM -0500, Tom Lane wrote:
> I feel like this is committable at this point --- any objections?
(This became commit 40c24bf, "Improve our ability to regurgitate SQL-syntax
function calls.")
> --- a/src/backend/nodes/equalfuncs.c
> +++
On Sat, Mar 27, 2021 at 01:17:14AM +0100, Tomas Vondra wrote:
> OK, pushed after a bit more polishing and testing.
This added a "transformed" field to CreateStatsStmt, but it didn't mention
that field in src/backend/nodes. Should those functions handle the field?
On Wed, Apr 07, 2021 at 09:55:40PM +0200, Peter Eisentraut wrote:
> Committed. Thanks!
I get a NULL pointer dereference if the function body has a doubled semicolon:
create function f() returns int language sql begin atomic select 1;; end;
Program received signal SIGSEGV, Segmentation fault.
On Sat, Jun 05, 2021 at 12:06:46PM +0530, Bharath Rupireddy wrote:
> On Sat, Jun 5, 2021 at 7:02 AM Noah Misch wrote:
> > On Tue, Jun 01, 2021 at 01:25:24PM +0530, Bharath Rupireddy wrote:
> > > On Tue, Jun 1, 2021 at 9:19 AM Noah Misch wrote:
> > &
On Fri, Apr 09, 2021 at 05:16:11PM -0400, Alvaro Herrera wrote:
> Pushed now.
This added a PQtraceSetFlags() function. We have a dozen PQset*() functions,
but this and PQresultSetInstanceData() are the only PQSomethingSet()
functions. Is it okay if I rename it to PQsetTraceFlags()? I think
On Tue, Jun 01, 2021 at 01:25:24PM +0530, Bharath Rupireddy wrote:
> On Tue, Jun 1, 2021 at 9:19 AM Noah Misch wrote:
> > Given that limitation, is pg_wait_for_backend_termination() useful enough?
> > If
> > waiting for procarray departure is enough, should
> >
On Tue, Jun 01, 2021 at 04:45:52PM -0400, Robert Haas wrote:
> On Fri, May 28, 2021 at 2:05 AM Kyotaro Horiguchi
> wrote:
> > Agreed. I often annoyed by a long-lasting TAP script when I wanted to
> > do one of the test items in it. However, I was not sure which is our
> > policy here,
On Thu, Apr 08, 2021 at 11:41:17AM +0200, Magnus Hagander wrote:
> I've applied this patch with some minor changes.
I wondered if the new pg_wait_for_backend_termination() could replace
regress.c:wait_pid(). I think it can't, because the new function requires the
backend to still be present in
On Sun, Apr 25, 2021 at 02:40:54PM -0400, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> > On Mon, Apr 19, 2021 at 05:38:43PM -0400, Stephen Frost wrote:
> > > > > > On Fri, Apr 16, 2021 at 3:57 AM Noah Misch
> > > > > > wrote:
>
On Tue, May 25, 2021 at 01:33:54PM -0700, Mark Dilger wrote:
> v3-0001 adds a new pg_logical_replication role with permission to manage
> publications and subscriptions.
> v3-0004 adds a new pg_database_security role with permission to perform many
> actions that would otherwise require
On Tue, May 25, 2021 at 11:32:38AM -0400, Alvaro Herrera wrote:
> On 2021-May-24, Noah Misch wrote:
> > What if we had a standard that the step after the cancel shall send a query
> > to
> > the backend that just received the cancel? Something like:
>
> Hmm ... I don'
On Mon, May 24, 2021 at 09:12:40PM -0400, Tom Lane wrote:
> The experiments I did awhile ago are coming back to me now. I tried
> a number of variations on this same theme, and none of them closed
> the gap entirely. The fundamental problem is that it's possible
> for backend A to complete its
On Wed, Apr 21, 2021 at 04:38:55PM -0400, Alvaro Herrera wrote:
[fix to let CLOBBER_CACHE_ALWAYS pass]
> Barring objections, I will get this pushed early tomorrow.
prairiedog and wrasse failed a $SUBJECT test after this (commit 8aba932).
Also, some non-CLOBBER_CACHE_ALWAYS animals failed a test
On Mon, Apr 19, 2021 at 05:42:51PM +1200, Thomas Munro wrote:
> Currently initdb sets up template databases with old-style Windows
> locale names reported by the OS, and they seem to have caused us quite
> a few problems over the years:
>
> db29620d "Work around Windows locale name with non-ASCII
On Wed, Apr 07, 2021 at 10:13:30AM -0700, Richard Yen wrote:
> I noticed that in some situations involving the use of REVOKE ON SCHEMA,
> pg_dump
> can produce a dump that cannot be restored. This prevents successful
> pg_restore (and by corollary, pg_upgrade).
>
> An example shell script to
On Wed, Apr 14, 2021 at 10:25:08AM +0300, Ivan Ivanov wrote:
> In Postgres we can create view with view owner privileges only. What’s the
> reason that there is no option to create view with invoker privileges? Is
> there any technical or security subtleties related to absence of this
> feature?
On Mon, May 10, 2021 at 11:09:43AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 27.04.21 18:16, Tom Lane wrote:
> >> That's kind of a lot of complication, and inefficiency, for a corner case
> >> that may never arise in practice. We've ignored the risk for default
> >> expressions,
On Sat, May 08, 2021 at 05:53:20PM -0400, Jonathan S. Katz wrote:
> I have attached the draft for the 2021-05-13 cumulative update release
> announcement.
Looks good.
On Sat, May 08, 2021 at 04:57:54PM +1200, Thomas Munro wrote:
> On Sat, May 8, 2021 at 2:30 AM Tom Lane wrote:
> > May 07 03:31:39 gcc202 kernel: sunvdc: vdc_tx_trigger() failure, err=-11
>
> That's -EAGAIN (assuming errnos match x86) and I guess it indicates
> that VDC_MAX_RETRIES is exceeded
On Fri, May 07, 2021 at 10:18:14PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2021-05-07 17:14:18 -0700, Noah Misch wrote:
> >> Having a flaky buildfarm member is bad news. I'll LD_PRELOAD the attached
> >> to
> >> prevent fsync from reaching th
On Fri, May 07, 2021 at 01:18:19PM -0400, Tom Lane wrote:
> Realizing that 9989d37d prevents the assertion failure, I went
> to see if thorntail had shown EIO failures without assertions.
> Looking back 180 days, I found these:
>
> sysname |branch | snapshot | stage
On Thu, May 06, 2021 at 09:43:32PM -0400, Tom Lane wrote:
> 2. We evidently need to put a bit more effort into this error
> reporting logic. More generally, I wonder how we could audit
> the code for similar hazards elsewhere, because I bet there are
> some. (Or ... could it be sane to run
On Wed, May 05, 2021 at 03:46:43PM -0400, Tom Lane wrote:
> I know that the parallel-worker code is held
> together with chewing gum and baling wire
Having spent time in that code, I didn't notice such weakness. I'm sure it
has bugs, but I doubt its bug density is unusual for PostgreSQL.
quot;Standard public schema")) == 0)
> + {
> + ncomments = 0;
>
> Is it possible that, in the case ncomments > 0, there are more than one
> comment ?
Yes, I think that's normal when the search terms include an objsubid (subid !=
InvalidOid).
Author: Noah
On Mon, Apr 19, 2021 at 05:38:43PM -0400, Stephen Frost wrote:
> > > > On Fri, Apr 16, 2021 at 3:57 AM Noah Misch wrote:
> > > >> Hence, I do find it reasonable to let pg_read_all_data be sufficient
> > > >> for
> > > >>
On Tue, Jun 30, 2020 at 02:51:38PM -0400, Tom Lane wrote:
> The point remains that exposing the function body's dependencies will
> constrain restore order far more than we are accustomed to see. It
> might be possible to build examples that flat out can't be restored,
> even granting that we
On Thu, Apr 15, 2021 at 07:25:39PM -0400, Tom Lane wrote:
> Here's a draft patch that converts all the built-in and information_schema
> SQL functions to new style, except for half a dozen that cannot be
> converted because they use polymorphic arguments.
This patch looks good.
> One thing I was
On Mon, Apr 12, 2021 at 02:35:27PM -0700, Andres Freund wrote:
> On 2021-04-12 17:14:20 -0400, Tom Lane wrote:
> > I doubt that falsely labeling a function LEAKPROOF can get you more
> > than the ability to read data you're not supposed to be able to read
> > ... but that ability is then available
On Wed, Apr 14, 2021 at 02:03:56PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Apr 14, 2021 at 1:41 PM Tom Lane wrote:
> >> Could we hack things so that extension scripts are only allowed to
> >> reference objects created (a) by the system, (b) earlier in the
> >> same script, or
On Tue, Apr 13, 2021 at 11:11:13PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Tue, Apr 13, 2021 at 06:26:34PM -0400, Tom Lane wrote:
> >> Attached are some draft patches to convert almost all of the
> >> contrib modules' SQL functions to use SQL-standard func
On Wed, Apr 14, 2021 at 10:38:17AM +0900, Michael Paquier wrote:
> On Tue, Apr 13, 2021 at 08:00:34AM -0700, Noah Misch wrote:
> > On Tue, Apr 13, 2021 at 02:43:11PM +0900, Michael Paquier wrote:
> >>> - If extschema='public', "pg_dump -e plpgsql --schema=public" in
On Tue, Apr 13, 2021 at 06:26:34PM -0400, Tom Lane wrote:
> Attached are some draft patches to convert almost all of the
> contrib modules' SQL functions to use SQL-standard function bodies.
> The point of this is to remove the residual search_path security
> hazards that we couldn't fix in
On Tue, Apr 13, 2021 at 02:43:11PM +0900, Michael Paquier wrote:
> On Sun, Apr 04, 2021 at 03:08:02PM -0700, Noah Misch wrote:
> > I noticed the patch's behavior for relations that are members of non-dumped
> > extensions and are also registered using pg_extension_config_dump().
On Mon, Apr 12, 2021 at 02:25:53PM +0900, Michael Paquier wrote:
> On Fri, Apr 09, 2021 at 08:07:10PM -0700, Noah Misch wrote:
> > "pg_regress --outputdir" is not a great location for a file or directory
> > created by a user other than the user running pg_regress. If
On Sat, Apr 10, 2021 at 10:52:15AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Fri, Apr 09, 2021 at 12:09:43PM -0400, Tom Lane wrote:
> >> The real value of 0003 of course would be to get an error cursor at
> >> runtime
>
> > A key benefit of $SUBJEC
On Fri, Apr 09, 2021 at 12:09:43PM -0400, Tom Lane wrote:
> Finally, 0003 might be a bit controversial: it changes the stored
> prosrc for new-style SQL functions to be the query text of the CREATE
> FUNCTION command. The main argument I can see being made against this
> is that it'll bloat the
On Fri, Apr 09, 2021 at 03:00:31PM +0900, Michael Paquier wrote:
> I have compiled a simple patch that uses a SQL function for the base
> tablespace directory creation, that I have tested on Linux and MSVC.
> I am still not sure if people would prefer this approach over what's
> on HEAD. So if
On Sun, Apr 04, 2021 at 03:08:02PM -0700, Noah Misch wrote:
> On Wed, Mar 31, 2021 at 09:37:44AM +0900, Michael Paquier wrote:
> > On Tue, Mar 30, 2021 at 12:02:45PM +0900, Michael Paquier wrote:
> > > Okay. So I have looked at that stuff in details, and after fixing
> > &
On Tue, Apr 06, 2021 at 01:16:16PM -0700, Dan Lynch wrote:
> Final question: do you think using procedures vs writing inline queries for
> RLS quals/checks has a big difference in performance (assuming functions
> are sql)?
If the function meets the criteria for inlining (see inline_function()),
On Mon, Apr 05, 2021 at 07:51:46PM -0700, Dan Lynch wrote:
> > > I suppose if the
> > > get_group_ids_of_current_user() function is marked as STABLE, would the
> > > optimizer cache this value for every row in a SELECT that returned
> > > multiple rows?
> >
> > While there was a patch to implement
tDumpableNamespace() to set
nsinfo->dobj.dump=DUMP_COMPONENT_ALL instead of DUMP_COMPONENT_ACL.)
- If extschema is not any sort of built-in schema, "pg_dump -e plpgsql"
includes commands to dump the relation data. This surprised me.
I'm attaching a test case patch that demonstrates this. Is
On Fri, Apr 02, 2021 at 02:24:59PM -0700, Dan Lynch wrote:
> Does anyone know details of, or where to find more information about the
> implications of the optimizer on the quals/checks for the policies being
> functions vs inline?
Roughly, the PostgreSQL optimizer treats LANGUAGE SQL functions
On Sat, Mar 27, 2021 at 11:26:47AM -0400, John Naylor wrote:
> On Sat, Mar 27, 2021 at 3:00 AM Noah Misch wrote:
> > Does anyone have a strong opinion on whether to back-patch? I am weakly
> > inclined not to back-patch, because today's behavior might happen to perform
On Sat, Feb 13, 2021 at 04:56:29AM -0800, Noah Misch wrote:
> I'm attaching the patch for $SUBJECT, which applies atop the four patches from
> the two other threads below. For convenience of testing, I've included a
> rollup patch, equivalent to applying all five patches.
I
s so. An
FSM-using test would contain a VACUUM.) I plan to commit the attached
version; compared to v5, it updates comments and renames this variable.
Thanks,
nm
Author: Noah Misch
Commit: Noah Misch
Accept slightly-filled pages for tuples larger than fillfactor.
We al
On Wed, Mar 24, 2021 at 11:57:37AM -0400, John Naylor wrote:
> On Mon, Dec 28, 2020 at 12:32 AM Noah Misch wrote:
> > [v2]
>
> Hi Noah,
>
> In the refactoring patch, there is a lingering comment reference to
> roles_has_privs_of(). Aside from that, it looks good
On Thu, Mar 25, 2021 at 07:44:02AM +0900, Michael Paquier wrote:
> On Wed, Mar 24, 2021 at 10:50:50AM -0400, Robert Haas wrote:
> > On Wed, Mar 24, 2021 at 5:56 AM Christoph Berg wrote:
> >> Maybe creating the tablespace directory from within the testsuite
> >> would suffice?
> >>
> >> CREATE
On Wed, Jan 27, 2021 at 12:35:30PM -0500, Robert Haas wrote:
> On Mon, Jan 25, 2021 at 2:11 PM Heikki Linnakangas wrote:
> > Having a separate FullTransactionIdToLatestPageNumber() function for
> > this seems like overkill to me.
>
> I initially thought so too, but it turned out to be pretty
On Mon, Mar 15, 2021 at 02:57:20PM -0400, Tom Lane wrote:
> Mark Dilger writes:
> > On Mar 15, 2021, at 10:04 AM, Tom Lane wrote:
> >> These animals have somewhat weird alignment properties: MAXALIGN is 8
> >> but ALIGNOF_DOUBLE is only 4. I speculate that that is affecting their
> >> choices
A cfbot failure showed I had missed ORDER BY in some test queries.
On Sun, Dec 27, 2020 at 08:31:48PM -0800, Noah Misch wrote:
> I ended up blocking DDL that creates role memberships involving the new role;
> see reasons in user.c comments. Lifting those restrictions looked fe
On Sat, Mar 13, 2021 at 10:51:27AM -0800, Mark Dilger wrote:
> > On Mar 13, 2021, at 10:46 AM, Noah Misch wrote:
> > On Fri, Mar 12, 2021 at 05:04:09PM -0800, Mark Dilger wrote:
> >>> On Mar 12, 2021, at 3:24 PM, Mark Dilger
> >>> wrote:
> >>&g
On Fri, Mar 12, 2021 at 05:04:09PM -0800, Mark Dilger wrote:
> > On Mar 12, 2021, at 3:24 PM, Mark Dilger
> > wrote:
> >
> > and the second deals with an apparent problem with IPC::Run shell expanding
> > an asterisk on some platforms but not others. That second one, if true,
> > seems like
On Sat, Mar 13, 2021 at 01:36:11AM -0500, Tom Lane wrote:
> Mark Dilger writes:
> > On Mar 12, 2021, at 10:22 PM, Tom Lane wrote:
> >> Coping with both endiannesses might be painful.
>
> > Not too bad if the bigint value is zero, as both the low and high 32bits
> > will be zero, regardless of
On Sat, Mar 13, 2021 at 01:07:15AM -0500, Tom Lane wrote:
> I wrote:
> >> ... btw, prairiedog (which has a rather old Perl) has a
> >> different complaint:
> >> Invalid type 'q' in unpack at t/004_verify_heapam.pl line 104.
>
> > Hmm ... "man perlfunc" on that system quoth
> >
On Wed, Mar 10, 2021 at 10:03:24AM +0100, Laurenz Albe wrote:
> On Tue, 2021-03-09 at 14:15 -0500, Tom Lane wrote:
> > As for procedures, I'm of the opinion that we should just reject those
> > too, but some other security team members were not happy with that
> > idea. Conceivably we could
On Thu, Feb 11, 2021 at 08:16:30PM +0300, Anastasia Lubennikova wrote:
> On 28.01.2021 09:55, Noah Misch wrote:
> >On Wed, Jan 27, 2021 at 07:32:42PM +0300, Anastasia Lubennikova wrote:
> >>On 27.01.2021 14:21, Noah Misch wrote:
> >>>On Mon, Jan 25, 2021 at 10:14:43P
On Sat, Feb 13, 2021 at 06:19:34PM +0100, Joel Jacobson wrote:
> To test the correctness of the patches,
> I thought it would be nice with some real-life regexes,
> and just as important, some real-life text strings,
> to which the real-life regexes are applied to.
>
> I therefore patched
On Mon, Mar 01, 2021 at 04:32:23PM +0100, Hannu Krosing wrote:
> It looks like we are unnecessarily instructing our usiers to vacuum their
> databases in single-user mode when just vacuuming would be enough.
> When I started looking at improving the situation I discovered, that there
> already is
On Fri, Jan 15, 2021 at 07:07:44PM -0300, Alvaro Herrera wrote:
> I wrote this patch last year in response to a customer issue and I
> thought I had submitted it here, but evidently I didn't. So here it is.
>
> The short story is: in commit 5364b357fb11 we increased the size of
> pg_commit (née
I'm attaching the patch for $SUBJECT, which applies atop the four patches from
the two other threads below. For convenience of testing, I've included a
rollup patch, equivalent to applying all five patches.
On Sat, Oct 31, 2020 at 09:35:18AM -0700, Noah Misch wrote:
> More deta
On Thu, Feb 11, 2021 at 04:08:34AM -0800, Noah Misch wrote:
> On Sun, Jan 17, 2021 at 12:00:06PM +0100, Vik Fearing wrote:
> > On 1/17/21 10:41 AM, Noah Misch wrote:
> > > On Sat, Jan 16, 2021 at 02:05:43PM +0100, Vik Fearing wrote:
> > >> On 12/30/20 12:59 PM, No
On Tue, Feb 09, 2021 at 05:34:37PM -0500, Tom Lane wrote:
> Now granting that the best answer is just to forbid these cases,
> there are still a couple of decisions about how extensive the
> prohibition ought to be:
>
> * We could forbid these characters only when you try to actually
> put such a
On Mon, Feb 08, 2021 at 05:40:41PM -0500, Jonathan S. Katz wrote:
> This update also fixes over 80 bugs that were reported in the last several
> months. Some of these issues only affect version 13, but may also apply to
> other
> supported versions.
Did you want s/may/many/?
> * Fix an issue
il.com
Author: Noah Misch
Commit: Noah Misch
Not for commit; for demonstration only.
Before applying this, apply
https://postgr.es/m/CAPpHfdtSEOHX8dSk9Qp%2BZ%2B%2Bi4BGQoffKip6JDWngEA%2Bg7Z-XmQ%40mail.gmail.com
diff --git a/src/backend/access/transam/xlog.c
b/src/backend/a
On Fri, Jan 22, 2021 at 02:08:02PM -0800, Paul Martinez wrote:
> Some of the original justifications for requiring superuser to create
> subscriptions include:
> - Replication inherently adds significant network traffic and extra background
> process, and we wouldn't want unprivileged users to
On Thu, Jan 28, 2021 at 12:06:27PM +0900, Kyotaro Horiguchi wrote:
> At Wed, 27 Jan 2021 02:48:48 -0800, Noah Misch wrote in
> > On Thu, Jan 21, 2021 at 01:23:36AM -0800, Noah Misch wrote:
> > > On Thu, Jan 21, 2021 at 06:02:11PM +0900, Kyotaro Horiguchi wrote:
> >
On Wed, Jan 27, 2021 at 07:32:42PM +0300, Anastasia Lubennikova wrote:
> On 27.01.2021 14:21, Noah Misch wrote:
> >On Mon, Jan 25, 2021 at 10:14:43PM +0300, Anastasia Lubennikova wrote:
> >
> >>1) Could you please clarify, what do you mean by REVOKE failures?
> >&
On Mon, Jan 25, 2021 at 10:14:43PM +0300, Anastasia Lubennikova wrote:
> On 24.01.2021 11:39, Noah Misch wrote:
> >On Thu, Jan 21, 2021 at 01:03:58AM +0300, Anastasia Lubennikova wrote:
> >>On 03.01.2021 14:29, Noah Misch wrote:
> >>>Overall, this patch predicts a
On Thu, Jan 21, 2021 at 01:23:36AM -0800, Noah Misch wrote:
> On Thu, Jan 21, 2021 at 06:02:11PM +0900, Kyotaro Horiguchi wrote:
> > At Thu, 21 Jan 2021 00:19:58 -0800, Noah Misch wrote in
> > > On Thu, Jan 21, 2021 at 12:28:44AM +0900, Kyotaro Horiguchi wrote:
> > > &
On Mon, Jan 25, 2021 at 10:12:28PM +0900, Michael Paquier wrote:
> SHA-1 is now an option available for cryptohashes, and like the
> existing set of functions of SHA-2, I don't really see a reason why we
> should not have a SQL function for SHA1.
NIST deprecated SHA1 over ten years ago. It's too
On Mon, Jan 18, 2021 at 09:29:53PM +0100, Fabien COELHO wrote:
> >>>The "no such file" error seems more like a machine local issue to me.
> >>
> >>I'll look into it when I have time, which make take some time. Hopefully
> >>over the holidays.
> >
> >This is still happening ... Any chance you can
On Thu, Jan 21, 2021 at 01:03:58AM +0300, Anastasia Lubennikova wrote:
> On 03.01.2021 14:29, Noah Misch wrote:
> >Overall, this patch predicts a subset of cases where pg_dump will emit a
> >failing GRANT or REVOKE that targets a pg_catalog object. Can you write a
> >code
On Thu, Jan 21, 2021 at 05:32:56PM -0500, Tom Lane wrote:
> I happened to notice that PQreset is documented thus:
>
> This function will close the connection to the server and attempt to
> reestablish a new connection to the same server, using all the same
> parameters previously
On Thu, Jan 21, 2021 at 06:02:11PM +0900, Kyotaro Horiguchi wrote:
> At Thu, 21 Jan 2021 00:19:58 -0800, Noah Misch wrote in
> > On Thu, Jan 21, 2021 at 12:28:44AM +0900, Kyotaro Horiguchi wrote:
> > > However, with the previous patch, two existing test
On Thu, Jan 21, 2021 at 12:28:44AM +0900, Kyotaro Horiguchi wrote:
> At Wed, 20 Jan 2021 17:34:44 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > Anyway, it seems actually dangerous that cause pruning on wal-skipped
> > relation.
> >
> > > with your patch versions. Could you try implementing
On Thu, Jan 21, 2021 at 01:03:58AM +0300, Anastasia Lubennikova wrote:
> On 03.01.2021 14:29, Noah Misch wrote:
> >On Thu, Jun 11, 2020 at 07:58:43PM +0300, Anastasia Lubennikova wrote:
> Thank you for the review.
> New version of the patch is attached, though I haven't tested it
On Tue, Jan 19, 2021 at 01:48:31PM +0900, Kyotaro Horiguchi wrote:
> At Mon, 18 Jan 2021 17:30:22 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > At Sun, 17 Jan 2021 23:02:18 -0800, Noah Misch wrote in
> > > On Sun, Jan 17, 2021 at 10:36:31PM -0800, Noah Misch wrote:
>
On Sun, Jan 17, 2021 at 10:36:31PM -0800, Noah Misch wrote:
> On Mon, Jan 18, 2021 at 03:08:38PM +0900, Kyotaro Horiguchi wrote:
> > At Fri, 15 Jan 2021 20:38:16 -0800, Noah Misch wrote in
> > > On Wed, Jan 13, 2021 at 04:07:05PM +0900, Kyotaro Horiguchi wrote:
> > >
On Mon, Jan 18, 2021 at 03:08:38PM +0900, Kyotaro Horiguchi wrote:
> At Fri, 15 Jan 2021 20:38:16 -0800, Noah Misch wrote in
> > On Wed, Jan 13, 2021 at 04:07:05PM +0900, Kyotaro Horiguchi wrote:
> > > --- a/src/include/utils/snapmgr.h
> > > +++ b/src/include/utils/sna
On Sun, Jan 17, 2021 at 01:51:35PM +0100, Magnus Hagander wrote:
> On Sat, Jan 16, 2021 at 8:27 AM Noah Misch wrote:
> > On Fri, Jan 15, 2021 at 01:35:50PM +0900, Ian Lawrence Barwick wrote:
> > > $ tail -3 pg_upgrade_utility.log
> > > ALTER ROLE "po
On Sat, Jan 16, 2021 at 02:05:43PM +0100, Vik Fearing wrote:
> On 12/30/20 12:59 PM, Noah Misch wrote:
> > On Tue, Dec 29, 2020 at 05:49:24AM -0800, Noah Misch wrote:
> >> https://postgr.es/m/20201031163518.gb4039...@rfd.leadboat.com gave
> >> $SUBJECT as
> >
On Sat, Jan 16, 2021 at 12:03:19PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Wed, Jan 13, 2021 at 10:28:26AM -0500, Tom Lane wrote:
> >> So a non-rewriting conversion would only be possible if local time is
> >> identical to UTC; which is true for few en
On Wed, Jan 13, 2021 at 10:28:26AM -0500, Tom Lane wrote:
> So a non-rewriting conversion would only be possible if local time is
> identical to UTC; which is true for few enough people that nobody has
> bothered with attempting the optimization.
PostgreSQL 12 and later do have that optimization.
On Fri, Jan 15, 2021 at 01:35:50PM +0900, Ian Lawrence Barwick wrote:
> $ tail -3 pg_upgrade_utility.log
> ALTER ROLE "postgres" SET "password_encryption" TO 'true';
> psql:pg_upgrade_dump_globals.sql:75: ERROR: invalid value for
> parameter "password_encryption": "true"
> HINT:
On Wed, Jan 13, 2021 at 04:07:05PM +0900, Kyotaro Horiguchi wrote:
> The definition of the macro RelationNeedsWAL has been changed by
> c6b92041d3 to include conditions related to the WAL-skip optimization
> but some uses of the macro are not relevant to the optimization. That
> misuses are
On Mon, Jan 11, 2021 at 11:22:05AM +0500, Andrey Borodin wrote:
> I'm marking patch as ready for committer.
Thanks.
> I can't tell should we backpatch insurance patch or not: it potentially fixes
> unknown bugs, and potentially contains unknown bugs. I can't reason because
> of such
On Sun, Jan 10, 2021 at 08:22:42PM +0900, Tatsuo Ishii wrote:
> In doc/src/sgml/func.sgml description of SHOW command use
> "SQL", while SET command description the same
> section does not use "". Shouldn't the description of SET use
> "" for "SQL" as well? Patch attached.
On Sun, Jan 10, 2021 at 11:44:14AM +0500, Andrey Borodin wrote:
> > 10 янв. 2021 г., в 03:15, Noah Misch написал(а):
> >
> > No; it deletes the most recent ~1B and leaves the older segments. An
> > exception is multixact, as described in the commit message an
On Sat, Jan 09, 2021 at 08:25:39PM +0500, Andrey Borodin wrote:
> > 9 янв. 2021 г., в 15:17, Noah Misch написал(а):
> >> I'm a little bit afraid that this kind of patch can hide bugs (while
> >> potentially saving some users data). Besides this patch seems like a
>
reviewing "diff -w" output first. I'm not certain the test suite will always
find those REVOKE statements in the same order; if that order varies, one
regex will need more help.
Author: Noah Misch
Commit: Noah Misch
Fix pg_dump for GRANT OPTION among initial
On Wed, Jan 06, 2021 at 11:28:36AM +0500, Andrey Borodin wrote:
> First patch fixes a bug with possible SLRU truncation around wrapping point
> too early.
> Basic idea of the patch is "If we want to delete a range we must be eligible
> to delete it's beginning and ending".
> So to test if page
On Tue, Jan 05, 2021 at 11:21:07AM +1300, Thomas Munro wrote:
> On Tue, Jan 5, 2021 at 8:07 AM Bruce Momjian wrote:
> > * "git apply" and "git am" can't process context diffs (they throw an
> >error once a context-like section of the diff is hit; simple
> >adding/removing lines in a
On Thu, Jun 11, 2020 at 07:58:43PM +0300, Anastasia Lubennikova wrote:
> On 08.06.2020 19:31, Alvaro Herrera wrote:
> >I'm thinking what's a good way to have a test that's committable. Maybe
> >it would work to add a TAP test to pg_upgrade that runs initdb, does a
> >few GRANTS as per your
On Sat, Jan 02, 2021 at 12:31:45PM +0500, Andrey Borodin wrote:
> Do I understand correctly that this is bugfix that needs to be back-patched?
The slru-truncate-modulo patch fixes a bug. The slru-truncate-t-insurance
patch does not. Neither _needs_ to be back-patched, though I'm proposing to
On Fri, Jan 01, 2021 at 11:05:29PM +0500, Andrey Borodin wrote:
> I've found this thread in CF looking for something to review.
Thanks for taking a look.
> > 9 нояб. 2020 г., в 09:53, Noah Misch написал(а):
> >
> > Rebased both patches, necessitated by commit c732c3
On Wed, Dec 30, 2020 at 04:28:44PM -0500, Andrew Dunstan wrote:
> On 12/30/20 3:42 PM, Tom Lane wrote:
> > Since I'd just seen Noah's commit 52202bb39 go by, I tried
> > modifying src/bin/pg_upgrade/test.sh to do the drop, but that
> > isn't helping. I recall now from prior discussions that we
>
On Tue, Dec 29, 2020 at 05:49:24AM -0800, Noah Misch wrote:
> https://postgr.es/m/20201031163518.gb4039...@rfd.leadboat.com gave $SUBJECT as
> one of the constituent projects for changing the public schema default ACL.
> This ended up being simple. Attached.
This is defective;
401 - 500 of 867 matches
Mail list logo
