On Thu, Oct 7, 2021 at 1:37 PM Michael Paquier wrote:
>
> On Thu, Oct 07, 2021 at 01:27:34PM +0900, Masahiko Sawada wrote:
> > On Thu, Oct 7, 2021 at 11:44 AM Justin Pryzby wrote:
> >> I'm not quite sure how you managed to search for it - well done ;)
> >
> > I could not find the recent thread, t
On Wed, Oct 6, 2021 at 12:41 PM Masahiko Sawada wrote:
>
> Hi all,
>
> A customer reported that during parallel index vacuum, the oldest xmin
> doesn't advance. Normally, the calculation of oldest xmin
> (ComputeXidHorizons()) ignores xmin/xid of processes having
> PROC_IN_VACUUM flag in MyProc->s
On Mon, Sep 27, 2021 at 11:45 PM Mark Dilger
wrote:
>
> Thanks for looking! I have pulled together a new patch set which applies
> cleanly against current master.
Hi Mark, thanks for this work. I'm late to be here in this thread,
please note that I didn't go through the entire thread as it is q
On Sat, Oct 2, 2021 at 4:16 PM Dilip Kumar wrote:
>
> On Fri, Oct 1, 2021 at 6:24 PM Alvaro Herrera wrote:
> >
> > On 2021-Oct-01, Amit Kapila wrote:
>
> > I think a straight standalone variable (probably a static boolean in
> > xloginsert.c) might be less confusing.
>
> I have written two patche
On Wed, Oct 6, 2021 at 10:26 PM Jeremy Schneider
wrote:
>
> On 10/5/21 17:43, Bruce Momjian wrote:
> > On Tue, Oct 5, 2021 at 03:30:07PM -0700, Jeremy Schneider wrote:
> >> Specifically exposing pg_waldump functionality in SQL could speed up
> >> finding bugs in the PG logical replication code. W
On Thu, Oct 07, 2021 at 01:27:34PM +0900, Masahiko Sawada wrote:
> On Thu, Oct 7, 2021 at 11:44 AM Justin Pryzby wrote:
>> I'm not quite sure how you managed to search for it - well done ;)
>
> I could not find the recent thread, though :)
Hm. It looks like there are more occurences of "false :
Hi Fujii-san and Sawada-san,
Thank you very much for your replies.
> >> I noticed that this thread and its set of patches have been marked with
> "Returned with Feedback" by yourself.
> >> I find the feature (atomic commit for foreign transactions) very
> >> useful and it will pave the road for h
On Thu, Oct 7, 2021 at 11:44 AM Justin Pryzby wrote:
>
> On Thu, Oct 07, 2021 at 11:18:24AM +0900, Masahiko Sawada wrote:
> > On Sat, Sep 11, 2021 at 2:44 PM Michael Paquier wrote:
> > >
> > > On Thu, Sep 09, 2021 at 02:14:50PM +0900, Kyotaro Horiguchi wrote:
> > > > Maybe I'm missing something,
On Wed, Oct 06, 2021 at 09:33:24PM -0500, Chris Bandy wrote:
> I don't have a windows machine to test, but this refactor looks good to me.
Thanks for the review! I did test this on Windows, only MSVC builds.
>> +/* Write to CSV log, if enabled */
>> +if ((Log_destination & LOG_DESTINATIO
On Thu, Sep 23, 2021 at 5:44 PM Drouvot, Bertrand wrote:
>
> Hi,
>
> On 7/29/21 10:25 AM, Masahiko Sawada wrote:
> > Thank you for reporting the issue.
> >
> > I could reproduce this issue by the steps you shared.
>
> Thanks for looking at it!
>
> >
> >> Currently, the system relies on processing
Dear Hackers,
While reading source codes about timeouts and GUC and I found that
strange behavior about client_connection_check_interval.
Currently we did not an assign_hook about client_connection_check_interval,
that means a timeout will not turn on immediately if users change the GUC
from zero
Fujita-san,
On Wed, Oct 6, 2021 at 5:41 PM Etsuro Fujita wrote:
> On Fri, Sep 24, 2021 at 4:20 PM Etsuro Fujita wrote:
> > On Fri, Sep 24, 2021 at 3:34 PM Amit Langote
> > wrote:
> > > I think there's a word missing in the following comment:
> > >
> > > /*
> > > * See if the p
Dear Fujii-san,
Thank you for reviewing!
> + else if (*p == '-' ? isdigit(p[1]) : isdigit(p[0]))
> + {
> + char *endptr;
> + padding = strtol(p, &endptr, 10);
>
> Maybe isdigit() and strtol() work differently depending on locale set
On Thu, Oct 07, 2021 at 11:18:24AM +0900, Masahiko Sawada wrote:
> On Sat, Sep 11, 2021 at 2:44 PM Michael Paquier wrote:
> >
> > On Thu, Sep 09, 2021 at 02:14:50PM +0900, Kyotaro Horiguchi wrote:
> > > Maybe I'm missing something, but I can see several instances of the
> > > "eval-bool ? true : f
On 10/6/21 12:10 AM, Michael Paquier wrote:
> I have thought about various ways to
> fix that, and finished with a solution where we handle csvlog first,
> and fallback to stderr after so as there is only one code path for
> stderr, as of the attached. This reduces a bit the confusion around
> the
On Sat, Sep 11, 2021 at 2:44 PM Michael Paquier wrote:
>
> On Thu, Sep 09, 2021 at 02:14:50PM +0900, Kyotaro Horiguchi wrote:
> > Maybe I'm missing something, but I can see several instances of the
> > "eval-bool ? true : false" pattern after fd0625c7a9 that are not in
> > the latest 0002.
>
> Yep
Hi,
On 2021-10-06 09:47:54 -0700, Andres Freund wrote:
> I'll also try to figure out print a bit more detail about timing for each tap
> test, looks like I need to figure out how to pass PROVE_TEST='--timer' through
> the buildfarm. Shouldn't be too hard.
Turns out that the buildfarm already adds
On Wed, Oct 06, 2021 at 10:55:53AM +0200, Daniel Gustafsson wrote:
> Indeed, thanks for all your work this CF!
+1. Thanks, Jaime!
--
Michael
signature.asc
Description: PGP signature
On Wed, Oct 06, 2021 at 06:43:25PM -0400, Tom Lane wrote:
> ... as, no doubt, are a lot of applications that this will gratuitously
> break. We've long had a policy that ALTER TABLE will work on relations
> that aren't tables, so long as the requested operation is sensible.
Yeah, that was my firs
On Wed, Oct 06, 2021 at 07:33:22AM -0400, Andrew Dunstan wrote:
> We should probably state a requirement for this somewhere. Maybe in
> src/test/perl/README. AIUI, the general rule is that any subroutine that
> directly or indirectly calls ok() and friends should increase the level.
> Such subrouti
On Wed, Oct 6, 2021 at 2:28 PM Pavel Borisov wrote:
>> It is the most consistent with the general design of the system, for
>> reasons that are pretty deeply baked into the system. I'm reminded of
>> the fact that REINDEX CONCURRENTLY's completion became blocked due to
>> similar trepidations. Und
On 2021/10/07 4:58, Jelte Fennema wrote:
Ugh forgot to attach the patch. Here it is.
Thanks for working on this patch!
@@ -4546,10 +4684,21 @@ PQrequestCancel(PGconn *conn)
return false;
}
-
- r = internal_cancel(&conn->raddr, conn->be_pid, conn->be_key,
Since PQreques
On Tue, Oct 05, 2021 at 04:11:58PM +0530, Amul Sul wrote:
>On Mon, Oct 4, 2021 at 1:57 PM Rushabh Lathia
> wrote:
> >
> > I tried to apply the patch on the master branch head and it's failing
> > with conflicts.
> >
>
> Thanks, Rushabh, for the quick check, I have attached a rebased version f
On 2021-Oct-06, Bossart, Nathan wrote:
> On 10/6/21, 3:44 PM, "Tom Lane" wrote:
> > The situation for "ALTER some-other-relation-kind" is a bit more
> > confused, because some cases throw errors and some don't; but I really
> > doubt that tightening things up here will earn you anything but
> >
On Wed, Oct 6, 2021 at 3:47 PM Mark Dilger wrote:
> I totally agree that the amcheck functions cannot prove the absence of
> corruption.
>
> I prefer not to even use language about proving the presence of corruption
> when discussing pg_amcheck.
I agree that it doesn't usually help. But sometim
> On Oct 6, 2021, at 1:48 PM, Stephen Frost wrote:
>
> This specific syntax, including the CASCADE bit, has, at minimum, at least
> been contemplate by the SQL folks sufficiently to be described in one
> specific way. I don’t have a copy of 2016 handy, unfortunately, and so I’m
> not sure
On 10/5/21 10:30 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Seems OK. Note that the Msys DTK perl currawong uses to build with is
>> ancient (5.6.1). That's going to stay as it is until it goes completely
>> out of scope in about 13 months. The perl it builds plperl against is
>> much more
On 10/6/21, 3:44 PM, "Tom Lane" wrote:
> "Bossart, Nathan" writes:
>> Here's a patch that ERRORs if the object type and statement type do
>> not match. Interestingly, some of the regression tests were relying
>> on this behavior.
>
> ... as, no doubt, are a lot of applications that this will gra
> On Oct 6, 2021, at 3:20 PM, Peter Geoghegan wrote:
>
>> I think the disagreements are about something else.
>
> Informally speaking, you could say that pg_amcheck and amcheck verify
> relations. More formally speaking, both amcheck (whether called by
> pg_amcheck or some other thing) can on
"Bossart, Nathan" writes:
> On 10/6/21, 1:52 PM, "Bruce Momjian" wrote:
>> I can confirm this bug in git head, and I think it should be fixed.
> Here's a patch that ERRORs if the object type and statement type do
> not match. Interestingly, some of the regression tests were relying
> on this be
On Wed, Oct 6, 2021 at 2:45 PM Mark Dilger wrote:
> I think the disagreements are about something else.
Informally speaking, you could say that pg_amcheck and amcheck verify
relations. More formally speaking, both amcheck (whether called by
pg_amcheck or some other thing) can only prove the prese
On 10/6/21 23:03, Zhihong Yu wrote:
Hi,
+ conditions2 = statext_determine_join_restrictions(root, rel, mcv);
+
+ /* if the new statistics covers more conditions, use it */
+ if (list_length(conditions2) > list_length(conditions1))
+ {
+ mcv = stat;
It seems con
> On Oct 6, 2021, at 2:45 PM, Mark Dilger wrote:
>
> and db3 is in recovery.
> they're scattered across different databases, some in recovery, some not.
What I mean here is that, since pg_amcheck might run for many hours, and
database may start in recovery but then exit recovery, or may b
> On Oct 6, 2021, at 1:49 PM, Peter Geoghegan wrote:
>
>> The analogy here is: are we trying to verify that the relations are
>> valid? Or are we just trying to verify that they are as valid as we
>> can expect them to be?
>
> I think that we do the latter (or something much closer to the lat
>
>
> It is the most consistent with the general design of the system, for
> reasons that are pretty deeply baked into the system. I'm reminded of
> the fact that REINDEX CONCURRENTLY's completion became blocked due to
> similar trepidations. Understandably so.
I may mistake, but I recall the fac
On Wed, Oct 6, 2021 at 12:33 PM Tomas Vondra
wrote:
> Hi,
>
> attached is an improved version of this patch, addressing some of the
> points mentioned in my last message:
>
> 1) Adds a couple regression tests, testing various join cases with
> expressions, additional conditions, etc.
>
> 2) Adds
I can confirm this bug in git head, and I think it should be fixed.
---
On Mon, Oct 4, 2021 at 10:23:23AM +, Onder Kalaci wrote:
> Hi hackers,
>
> I realized a subtle behavior with ALTER INDEX .. RENAME. It seems like
On Wed, Oct 6, 2021 at 1:15 PM Robert Haas wrote:
> > Where I might go further than you or Mark (not sure) is on this: I
> > also think that it's the caller's job to not call the functions with
> > temp relations, or (in the case of the index verification stuff) with
> > !indisready or !indisvalid
Greetings,
On Wed, Oct 6, 2021 at 16:28 Robert Haas wrote:
> On Wed, Oct 6, 2021 at 3:29 PM Stephen Frost wrote:
> > Does that mean that we also get to change what a specific set of
> > commands, which are all well-defined in the standard, do even when that
> > goes against what an SQL complian
Greetings,
On Wed, Oct 6, 2021 at 16:01 Mark Dilger
wrote:
> > On Oct 6, 2021, at 11:48 AM, Stephen Frost wrote:
> >
> > In the spec, under , there is a 'General Rules'
> > section (as there is with most statements) and in that section it says
> > that for every authorization identifier (that i
On Mon, Oct 4, 2021 at 12:44 PM Shruthi Gowda wrote:
> Thanks for the inputs, Robert. In the v4 patch, an unused OID (i.e, 4)
> is fixed for the template0 and the same is removed from unused oid
> list.
>
> In addition to the review comment fixes, I have removed some code that
> is no longer neede
On Tue, Oct 5, 2021 at 5:32 AM Bossart, Nathan wrote:
> On 10/4/21, 8:19 PM, "Stephen Frost" wrote:
> > It's also been discussed, at least around the water cooler (as it were
> > in pandemic times- aka our internal slack channels..) that the existing
> > archive command might be reimplemented as
On Wed, Oct 6, 2021 at 3:29 PM Stephen Frost wrote:
> Does that mean that we also get to change what a specific set of
> commands, which are all well-defined in the standard, do even when that
> goes against what an SQL compliant implementation would do? I really
> don't think so. If this was *n
On Wed, Oct 6, 2021 at 3:56 PM Peter Geoghegan wrote:
> I agree, with the stipulation that the caller (in this case
> pg_amcheck) is required to know certain basic things about the
> relation in order to get useful behavior. For example, if you use
> bt_index_check() with a GIN index, you're going
On Wed, Oct 6, 2021 at 12:36 PM Mark Dilger
wrote:
> The user may not know that the system has changed.
>
> For example, if I see errors in the logs suggesting corruption in a relation
> named "mark" and run pg_amcheck --relation=mark, I expect that to check the
> relation. If that relation is
On Wed, Oct 6, 2021 at 03:17:00PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Tue, Oct 5, 2021 at 04:29:25PM -0400, Bruce Momjian wrote:
> > > On Tue, Sep 28, 2021 at 12:30:02PM +0300, Ants Aasma wrote:
> > > > On Mon, 27 Sept 2021 at 23:34, Bruc
> On Oct 6, 2021, at 11:48 AM, Stephen Frost wrote:
>
> In the spec, under , there is a 'General Rules'
> section (as there is with most statements) and in that section it says
> that for every authorization identifier (that is, some privilege, be it
> a GRANT of SELECT rights on an object, or
Ugh forgot to attach the patch. Here it is.
From: Jelte Fennema
Sent: Wednesday, October 6, 2021 21:56
To: Zhihong Yu
Cc: pgsql-hack...@postgresql.org
Subject: Re: [EXTERNAL] Re: PQcancel does not use tcp_user_timeout,
connect_timeout and keepalive settings
We
We actually ran into an issue caused by this in production, where a PQcancel
connection was open on the client for a 2+ days because the server had
restarted at the wrong moment in the cancel handshake. The client was now
indefinitely waiting for the server to send an EOF back, and because keepa
On Wed, Oct 6, 2021 at 12:33 PM Robert Haas wrote:
> To me, it doesn't matter which specific option we're talking about. If
> I tell pg_amcheck to pass a certain flag to the underlying functions,
> then it should do that. If the behavior needs to be changed, it should
> be changed in those underly
> On Oct 6, 2021, at 12:28 PM, Peter Geoghegan wrote:
>
> I think that what I've said boils down to this:
>
> * pg_amcheck shouldn't attempt to verify temp relations, on the
> grounds that this is fundamentally not useful, and not something that
> could ever be sensibly interpreted as "just d
On Wed, Oct 6, 2021 at 2:56 PM Peter Geoghegan wrote:
> --heapallindexed doesn't complicate things for us at all. It changes
> nothing about the locking considerations. It's just an additive thing,
> some extra checks with the same basic underlying requirements. Maybe
> you meant to say --parent-c
Hi,
attached is an improved version of this patch, addressing some of the
points mentioned in my last message:
1) Adds a couple regression tests, testing various join cases with
expressions, additional conditions, etc.
2) Adds support for expressions, so the join clauses don't need to
reference
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Oct 6, 2021 at 2:48 PM Stephen Frost wrote:
> > What I'm saying above is that the command explicitly listed there
> > *isn't* 'DROP ROLE A DB', even though that is something which the spec
> > *could* have done, had they wished to.
On Wed, Oct 6, 2021 at 11:55 AM Peter Geoghegan wrote:
> I am pretty sure that I agree with you about all these details. We
> need to tease them apart some more.
I think that what I've said boils down to this:
* pg_amcheck shouldn't attempt to verify temp relations, on the
grounds that this is f
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Oct 5, 2021 at 04:29:25PM -0400, Bruce Momjian wrote:
> > On Tue, Sep 28, 2021 at 12:30:02PM +0300, Ants Aasma wrote:
> > > On Mon, 27 Sept 2021 at 23:34, Bruce Momjian wrote:
> > > We are still working on our TDE patch. Right now th
On Wed, Oct 6, 2021 at 2:48 PM Stephen Frost wrote:
> What I'm saying above is that the command explicitly listed there
> *isn't* 'DROP ROLE A DB', even though that is something which the spec
> *could* have done, had they wished to. Given that they didn't, it seems
> very clear that making such
On Wed, Oct 6, 2021 at 11:32 AM Robert Haas wrote:
> All of the decisions we're talking about here really have to do with
> determining the user's intent. I think that if the user says
> pg_amcheck --all, there's a good argument that they don't want us to
> check unlogged relations on a standby wh
Hi,
On 2021-10-06 12:58:34 -0400, Tom Lane wrote:
> Andres Freund writes:
> > One thing I think would really help is having the total time for each run
> > visible in an animals run history. That way we could pinpoint regressions
> > reasonably efficiently, right now that's not easily possible wi
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Oct 6, 2021, at 11:09 AM, Stephen Frost wrote:
> > After all, it says
> > "REOKVE R FROM A DB", not "DROP ROLE A CASCADE".
>
> Wait, are you arguing what DROP ROLE A CASCADE should do based on what the
> spec says REVOKE R F
On Wed, Oct 6, 2021 at 1:57 PM Mark Dilger wrote:
> > To me #2 sounds like a tautology. It could almost be phrased as
> > "pg_amcheck does not check the things that it cannot check".
>
> I totally disagree. It is uncomfortable to me that `pg_amcheck
> --parent-check` will now silently not perfor
> On Oct 6, 2021, at 11:09 AM, Stephen Frost wrote:
>
> After all, it says
> "REOKVE R FROM A DB", not "DROP ROLE A CASCADE".
Wait, are you arguing what DROP ROLE A CASCADE should do based on what the spec
says REVOKE R FROM A DB should do? If so, I'd say that's irrelevant. I'm not
propo
On Wed, Oct 6, 2021 at 10:57 AM Mark Dilger
wrote:
> > Clearly pg_amcheck never checked all relations, because it never
> > checked indexes that are not B-Tree indexes. I'm pretty sure that I
> > can poke big holes in almost any positivist statement like that with
> > little effort.
>
> There is a
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Oct 6, 2021, at 10:20 AM, Stephen Frost wrote:
> >
> > Consistency is not having dangling pointers around to things which no
> > longer exist- FK reference kind of things. Object management is about
> > actual *removal* of fu
> On Oct 6, 2021, at 10:39 AM, Peter Geoghegan wrote:
>
>> The differences in the upcoming version are
>>
>> 1) --all no longer means "all relations" but rather "all checkable relations"
>
> Clearly pg_amcheck never checked all relations, because it never
> checked indexes that are not B-Tre
On Wed, Oct 6, 2021 at 10:19 AM Mark Dilger
wrote:
> > A return value of 0 cannot be said to indicate that the database is
> > not corrupt;
>
> Nor can a non-zero value be said to indicate that the database is corrupt.
I never said otherwise. I think it's perfectly fine that there are
multiple no
> On Oct 6, 2021, at 10:20 AM, Stephen Frost wrote:
>
> Consistency is not having dangling pointers around to things which no
> longer exist- FK reference kind of things. Object management is about
> actual *removal* of full blown objects like roles, tables, etc. DROP
> TABLE ... CASCADE doe
On 2021-Oct-06, Jeremy Schneider wrote:
> Well this whole conversation is just theoretical anyway until the code
> is shared. :) But if Bharath is writing functions to decode WAL, then
> wouldn't we just have pg_waldump use these same functions in order to
> avoid duplicating code?
Actually, a
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Oct 6, 2021, at 9:01 AM, Stephen Frost wrote:
> > I can see how what you describe as the behavior you'd like to see of
> > DROP ROLE ... CASCADE could be useful... However, at least in the
> > latest version of the standard th
On Wed, Oct 6, 2021 at 09:56:34AM -0700, Jeremy Schneider wrote:
> On 10/5/21 17:43, Bruce Momjian wrote:
> > On Tue, Oct 5, 2021 at 03:30:07PM -0700, Jeremy Schneider wrote:
> >> Specifically exposing pg_waldump functionality in SQL could speed up
> >> finding bugs in the PG logical replication
> On Oct 6, 2021, at 10:16 AM, Peter Geoghegan wrote:
>
> A return value of 0 cannot be said to indicate that the database is
> not corrupt;
Nor can a non-zero value be said to indicate that the database is corrupt.
These invocations will still return a non-zero exit status:
pg_amch
On Wed, Oct 6, 2021 at 9:25 AM Mark Dilger wrote:
> Thanks for reviewing!
>
> I expect to post a new version shortly.
Not sure how much it matters, but I have some thoughts on the return
value of pg_amcheck. (I'm mostly going into this now because it seems
related to how we discuss these issues g
On Wed, Oct 6, 2021 at 12:47 PM Andres Freund wrote:
> There's probably some of that.
>
> The fact that the tap test infrastructure does all communication with the
> server via psql each only execute only a single query is a problem -
> connection startup is expensive.
Ageed. safe_psql() is a poo
On Wed, Oct 6, 2021 at 11:17:59AM -0400, Robert Haas wrote:
> If you enable checksums or set wal_log_hints=on, then you might incur
> a some write-ahead log records that would otherwise be avoided, and
> those records will include full page images. This can happen once per
> page per checkpoint cy
On Wed, Oct 6, 2021 at 12:54:49PM -0400, Bruce Momjian wrote:
> On Wed, Oct 6, 2021 at 11:01:25AM -0400, Robert Haas wrote:
> > On Tue, Oct 5, 2021 at 4:29 PM Bruce Momjian wrote:
> > > On Tue, Sep 28, 2021 at 12:30:02PM +0300, Ants Aasma wrote:
> > > > On Mon, 27 Sept 2021 at 23:34, Bruce Momji
Andres Freund writes:
> One thing I think would really help is having the total time for each run
> visible in an animals run history. That way we could pinpoint regressions
> reasonably efficiently, right now that's not easily possible without writing
> nontrivial queries to the buildfarm databas
Hello,
I reviewed your patch. At a first glance, I have the below comments.
1. The below change crosses the 80-character limit in a line. Please
maintain the same.
- "LARGE OBJECT", "TABLESPACE", "TEXT SEARCH", "ROLE");
+ "LARGE OBJECT", "TABLESPACE", "TEXT SEARCH", "TRANSFORM FOR"
On 10/5/21 17:43, Bruce Momjian wrote:
> On Tue, Oct 5, 2021 at 03:30:07PM -0700, Jeremy Schneider wrote:
>> Specifically exposing pg_waldump functionality in SQL could speed up
>> finding bugs in the PG logical replication code. We found and fixed a
>> few over this past year, but there are more
On Wed, Oct 6, 2021 at 11:01:25AM -0400, Robert Haas wrote:
> On Tue, Oct 5, 2021 at 4:29 PM Bruce Momjian wrote:
> > On Tue, Sep 28, 2021 at 12:30:02PM +0300, Ants Aasma wrote:
> > > On Mon, 27 Sept 2021 at 23:34, Bruce Momjian wrote:
> > > We are still working on our TDE patch. Right now the f
Hi,
On 2021-10-06 12:09:36 -0400, Robert Haas wrote:
> Is the problem here that we're adding a lot of new new test cases? Or
> is the problem that valgrind runs are getting slower for the same
> number of test cases?
I don't know precisely. It's probably a combination of several factors. I do
thi
On 10/6/21, 12:13 AM, "Masahiko Sawada" wrote:
> A customer reported that during parallel index vacuum, the oldest xmin
> doesn't advance. Normally, the calculation of oldest xmin
> (ComputeXidHorizons()) ignores xmin/xid of processes having
> PROC_IN_VACUUM flag in MyProc->statusFlags. But since
On 10/6/21, 5:20 AM, "Maxim Orlov" wrote:
> We've looked through the code and everything looks good except few minor
> things:
> 1). Using dedicated bg worker seems not optimal, it introduces a lot of
> redundant code for little single action.
> We'd join initial proposal of Andres to implem
On master with the v54 patches applied the following script leads to crash:
export
ASAN_OPTIONS=detect_leaks=0:abort_on_error=1:disable_coredump=0:strict_string_checks=1:check_initialization_order=1:strict_init_order=1
initdb -D data
pg_ctl -w -t 5 -D data -l server.log start
psql -c "create global
> On Oct 6, 2021, at 8:14 AM, Pavel Borisov wrote:
>
> We've looked through the initial patch and the exclusion of temporary tables
> from pg_amcheck seems the right thing. Also it is not the matter anyone
> disagrees here, and we propose to commit it alone.
Thanks for reviewing!
I expect
I've made some remarks in related thread:
https://www.postgresql.org/message-id/flat/0A3221C70F24FB45833433255569204D1FB976EF@G01JPEXMBYT05
The new status of this patch is: Waiting on Author
> On Oct 6, 2021, at 9:01 AM, Stephen Frost wrote:
>
> I can see how what you describe as the behavior you'd like to see of
> DROP ROLE ... CASCADE could be useful... However, at least in the
> latest version of the standard that I'm looking at, when a
> DROP ROLE ... CASCADE is executed, wh
Good day, David and all.
В Вт, 05/10/2021 в 11:07 +1300, David Rowley пишет:
> On Mon, 4 Oct 2021 at 20:37, Jaime Casanova
> wrote:
> > Based on your comments I will mark this patch as withdrawn at midday
> > of
> > my monday unless someone objects to that.
>
> I really think we need a hash tabl
On Wed, Oct 6, 2021 at 1:57 AM Andres Freund wrote:
> After a recent migration of the skink and a few other animals (sorry for the
> false reports on BF, I forgot to adjust a path), I looked at the time it takes
> to complete a valgrind run:
>
> 9.6: Consumed 4h 53min 18.518s CPU time
> 10: Consum
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Oct 5, 2021, at 10:20 AM, Stephen Frost wrote:
> > On Tue, Oct 5, 2021 at 13:17 Mark Dilger
> > wrote:
> > > On Oct 5, 2021, at 10:14 AM, Stephen Frost wrote:
> > >
> > > What does the “ownership” concept actually buy us th
Andres Freund writes:
> After a recent migration of the skink and a few other animals (sorry for the
> false reports on BF, I forgot to adjust a path), I looked at the time it takes
> to complete a valgrind run:
> 9.6: Consumed 4h 53min 18.518s CPU time
> 10: Consumed 5h 32min 50.839s CPU time
>
On Wed, Oct 6, 2021 at 11:22 AM Stephen Frost wrote:
> Seems like it'd be easier to achieve that by having something that looks
> very close to how write() looks, but just happens to have the option to
> run the data through a stream cipher and maybe does better error
> handling for us. Making th
On Tue, Oct 5, 2021 at 3:41 PM Mark Dilger wrote:
> If roles have owners, then DROP ROLE bob CASCADE drops bob, bob's objects,
> roles owned by bob, their objects and any roles they own, recursively. Roles
> which bob merely has admin rights on are unaffected, excepting that they are
> adminis
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Oct 5, 2021 at 1:24 PM Robert Haas wrote:
> > On Mon, Oct 4, 2021 at 10:00 PM Stephen Frost wrote:
> > > I do want to point out, as I think I did when we discussed this but want
> > > to be sure it's also captured here- I don't th
On Wed, Oct 6, 2021 at 9:35 AM Bruce Momjian wrote:
> The above text isn't very clear. What I am saying is that currently
> torn pages can be tolerated by hint bit writes because only a single
> byte is changing. If we use a block cipher like AES-XTS, later 16-byte
> encrypted blocks would be ch
Hi, hackers!
We've looked through the initial patch and the exclusion of temporary
tables from pg_amcheck seems the right thing. Also it is not the matter
anyone disagrees here, and we propose to commit it alone.
Supplementary things/features might be left for further discussion but
refusing to ch
Hi, Andrey!
I’ve tried to apply your patch v2-0001 on current master, but i failed.
There were git apply errors at:
pg_stat_statements.out:941
pg_stat_statements.sql:385
Best Regards,
Anton Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Hi,
On 9/11/21 2:31 PM, Andrey Borodin wrote:
> Hi hackers!
>
> There's a lot of compression discussions nowadays. And that's cool!
> Recently Naresh Chainani in private discussion shared with me the
> idea to compress temporary files on disk. And I was thrilled to find
> no evidence of implemen
On Tue, Oct 5, 2021 at 4:29 PM Bruce Momjian wrote:
> On Tue, Sep 28, 2021 at 12:30:02PM +0300, Ants Aasma wrote:
> > On Mon, 27 Sept 2021 at 23:34, Bruce Momjian wrote:
> > We are still working on our TDE patch. Right now the focus is on refactoring
> > temporary file access to make the TDE patc
On Tue, Oct 5, 2021 at 1:55 PM Antonin Houska wrote:
> I'm just trying to make our changes to buffile.c less invasive. Or do you mean
> that this module should be reworked regardless the encryption?
I wasn't thinking of buffile.c specifically. I think improving that
might be a really good idea, a
On Sat, Sep 11, 2021 at 8:31 AM Andrey Borodin wrote:
> I've prototyped Random Access Compressed File for fun[0]. The code is very
> dirty proof-of-concept.
> I compress Buffile by one block at a time. There are directory pages to store
> information about the size of each compressed block. If a
1 - 100 of 128 matches
Mail list logo
