it can't hurt to do this as well -- just in
case the issue is transient or something.
Thanks
--
Peter Geoghegan
) (or maybe just more
predictable access patterns in our "batch binary search") making
everything much faster through batching. This will also naturally make
btvacuumpage() much less "branchy", since of course it will no longer
need to process the page one TID at a time -- that helps too.
--
Peter Geoghegan
d must be
absolutely negligible. Adding a "goto restart" to the HEAPTUPLE_DEAD
case is ugly, but the "tupgone = true" thing is an abomination, so
that seems okay. This approach definitely seems like the way forward,
because it's obviously safe -- it may even be safer, because
heap_prepare_freeze_tuple() kind of expects this behavior today.
--
Peter Geoghegan
On Wed, Mar 17, 2021 at 12:45 AM Amit Kapila wrote:
>
>
> Attached, please find the patch to update the description of substream
> in pg_subscription.
>
I applied your patch and regenerated the PG docs to check the result.
LGTM.
Kind Regards,
Peter Smith.
Fujitsu Australia
rectories?
e.g. Are you only supposed to run "make coverage-html" from the top folder?
Or is it supposed to work but I did something wrong?
--
[1] https://www.postgresql.org/docs/13/regress-coverage.html
Kind Regards.
Peter Smith
Fujitsu Australia.
On 2020-10-19 13:15, Andrew Dunstan wrote:
On 10/19/20 5:19 AM, Peter Eisentraut wrote:
A follow-up to the recently added support for OUT parameters for
procedures. The JDBC driver sends OUT parameters with type void.
This makes sense when calling a function, so that the parameters are
ignored
ps in practice. How can you detect
reload errors by inspecting pg_settings etc.?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
CACHE_ALWAYS or
CLOBBER_CACHE_RECURSIVE are defined.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
is a
good thing.
I don't know the reason or context why they were deprecated, but I agree
that the timeline for removing them now is good.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
also, but didn't come to
a conclusion.
https://www.postgresql.org/message-id/flat/1389237323.30068.8.camel%40vanquo.pezone.net
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
t after we remove the analyze script, as discussed
in a different thread?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
the kind of things I wanted to check anyway before
considering doing the switch.
If we're going to change it I think we need an updated patch that covers
pg_dump. (Even if we argue that pg_dump would not normally dump this
variable, keeping it up to date with respect to GUC_LIST_QUOTE s
h this.
Indeed the message is wrong, and patch LGTM.
Committed. Btw., the patch didn't update the regression test output.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-10-27 11:53, Bruce Momjian wrote:
On Tue, Oct 27, 2020 at 11:35:25AM +0100, Peter Eisentraut wrote:
On 2020-10-06 12:26, Magnus Hagander wrote:
I went with the name --no-instructions to have the same name for both
initdb and pg_upgrade. The downside is that "no-instructions&
tions are just to keep the
C compiler from spitting up." are now redundant in their new setting.
Hmm, I don't really see what's wrong there. Do you mean the macro
definitions should be different, or the comments are wrong, or something
else?
--
Peter Eisentraut ht
Here is another updated patch. I did some merging and some small fixes
and introduced the pg_proc column prosqlbody to store the parsed
function body separately from probin. Aside from one TODO left it seems
feature-complete to me for now.
--
Peter Eisentraut http://www
dered-set
aggregate arguments. I couldn't come up with a test case that would
tickle that codepath either, but it seems like a sensible change. You
might want to mention it in the commit message though.
OK, committed with that.
--
Peter Eisentraut http://www.2ndQuadrant.com/
impossible for the cost to cause sudden
surprises (except maybe once, after an initial upgrade to Postgres 14,
though I doubt it). Whereas it seems very likely to prevent many large
and unpleasant surprises caused by hidden, latent risk.
I believe that approximately 100% of DBAs would gladly take that
trade-off, even if the total cost in cycles was higher. It happens to
also be true that they're very likely to use far fewer cycles over
time, but that's really just a bonus.
--
Peter Geoghegan
>
> You can run the "make coverage-html" command in a subdirectory
> if you want a coverage report for only a portion of the code tree.
Thank you for the clarifications and the updated documentation.
Kind Regards,
Peter Smith
Fujitsu Australia
amed. Which is why this
> function will not be called when a streaming transaction is prepared
> as part of a two-phase commit.
AFAIK the last remaining issue now is only about the complexity of the
aforementioned code/comment. If you want to defer changing that until
we can come up with something better, then that is OK by me.
Apart from that I have no other pending review comments at this time.
Kind Regards,
Peter Smith.
Fujitsu Australia
t, txn, prepare_lsn);
else
logicalrep_write_prepare(ctx->out, txn, prepare_lsn);
OutputPluginWrite(ctx, true);
}
===
Kind Regards,
Peter Smith.
Fujitsu Australia
://www.postgresql.org/message-id/CAHut%2BPt6zB-YffCrMo7%2BZOKn7C2yXkNYnuQTdbStEJJJXZZXaw%40mail.gmail.com
Kind Regards,
Peter Smith.
Fujitsu Australia
v12-patch-test-coverage-20201029.xlsx
Description: MS-Excel 2007 spreadsheet
rspective. I really like the stability of operations on patched
> version. I would rather stick to the "restricted" version of the patch though.
You're using EBS here, which probably has much higher latency than
what I have here (an NVME SSD). What you have is probably more
relevant to the real world, though.
> Hope this helps. I'm open to do more tests if necessary.
It's great, thanks!
--
Peter Geoghegan
g of promising/duplicate tuples into
_bt_dedup_delete_finish_pending(), too (move it from
_bt_dedup_delete_pass()). That would allow me to talk about all of the
TIDs that get added to the deltids array (promising and non-promising)
in one central function. I'll do it that way soon.
--
Peter Geoghegan
On Thu, Oct 29, 2020 at 4:30 PM Peter Geoghegan wrote:
> I found that the "fiver" and "tenner" indexes in particular took a
> very long time to have even one page split with a long running
> transaction. Another interesting effect was that all page splits
> sudd
e switch can make the missing
enum detection easier because then you can use -Wswitch option to
expose the problem (instead of -Wswitch-enum which may give lots of
false positives as well)
===
[1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wswitch
Kind Regards,
Peter Smith.
Fujitsu Australia
pgoutput_startup where we are
> disabling the streaming for init phase. But it is always good to once
> test this and ensure the same.
I have tested this scenario and confirmed that even when the
subscriber is capable of streaming it does NOT do any streaming during
its tablesync phase.
Kind Regards
Peter Smith.
Fujitsu Australia
itrary in a few corner cases,
but it hardly matters at all. Right now we have something that's
technically correct but also practically useless.
--
Peter Geoghegan
eeds to say
"create OR REPLACE constraint trigger my_trig" to be testing what it
claims to be testing.
I also think there is a missing check in the code - see COMMENT (2) -
for handling this scenario. But since this test case is broken you do
not then notice the code check is missing.
===
Kind Regards,
Peter Smith.
Fujitsu Australia
From 171c58bc37c211cab11f6b588220e9e773f67e67 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 2 Nov 2020 08:24:28 +0100
Subject: [PATCH] Enable hash partitioning of text arrays
hash_array_extended() needs to pass PG_GET_COLLATION() to the hash
function of the element type. Otherwise, the hash function
needle
in terms of the general security-uneasiness about the public schema and
search paths. AFAICT, in any of your proposals, the default would still
be to have the public schema world-writable and in the path.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Develop
I have committed 0003.
For 0001, normal_rand(), I think you should reject negative arguments
with an error.
For 0002, I think you should change the block number arguments to int8,
same as other contrib modules do.
On Fri, Oct 23, 2020 at 11:10 AM Peter Geoghegan wrote:
> I suspect that we need to move in this direction within nbtree. I'm a
> bit concerned about the partial index problem, though. I suppose maybe
> we could do it the old way (which won't account for posting list
> tup
On Mon, Nov 2, 2020 at 10:03 AM Peter Geoghegan wrote:
> Attached is my proposed fix, which takes this approach. I will commit
> this on Wednesday or Thursday, barring any objections.
Just to be clear: I am not proposing that we set
'IndexBulkDeleteResult.estimated_count = false&
Just one more postscript...
On Mon, Nov 2, 2020 at 12:06 PM Peter Geoghegan wrote:
> Just to be clear: I am not proposing that we set
> 'IndexBulkDeleteResult.estimated_count = false' here
I meant 'IndexBulkDeleteResult.estimated_count = true'. So my patch
doesn't
ak. I'm not
going to commit a patch like this unless and until it's crystal clear
what the benefits are.
if Andres cannot spend any time on this in the foreseeable future then
I'll withdraw the patch. I intend to formally withdraw the patch on
November 9th, provided no new informatio
, I would mark it as "ready for
> committer", except that there doesn't yet seem to be enough evidence that it
> is a net win.
Thank you for testing my patch. Sorry for the delay in getting back to this.
--
Peter Geoghegan
n seems to have done about
1.17% less work than master did.
I've marked this patch back as waiting for review. It would be good if
someone could run some tests on some intel hardware and see if they
can see any speedup.
What is the way forward here? What exactly would you like to have tes
On 2020-10-27 04:25, Justin Pryzby wrote:
Forking this thread:
https://www.postgresql.org/message-id/fd93f1c5-7818-a02c-01e5-1075ac0d4...@iki.fi
They have been deprecated for a Long Time, so finally remove them for v14.
Four fewer exclamation marks makes the documentation less exciting, which is
On 2020-09-25 15:07, Peter Eisentraut wrote:
We could probably fix this by having ALTER TABLE ONLY / DROP EXPRESSION
update the attlocal column of direct children to true, to make the
catalog state look like something that can be restored. However, that's
a fair amount of complicated cod
.
Any further thoughts?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
it(struct LogicalDecodingContext *ctx,
> ReorderBufferTXN *txn,
> XLogRecPtr commit_lsn);
> -
> +static void pgoutput_stream_prepare_txn(LogicalDecodingContext *ctx,
> + ReorderBufferTXN *txn, XLogRecPtr prepare_lsn);
>
> Spurious line removal.
Fixed.
---
Kind Regards,
P
On 2020-11-03 11:48, Michael Paquier wrote:
On Mon, Nov 02, 2020 at 10:01:53AM -0500, Tom Lane wrote:
Peter Eisentraut writes:
I noticed that hash_array_extended() does not pass down the collation to
the element's collation function, unlike hash_array(). As a
consequence, hash partiti
On Mon, Nov 2, 2020 at 10:03 AM Peter Geoghegan wrote:
> Actually, it seems better to always count num_index_tuples the old way
> during cleanup-only index VACUUMs, despite the inaccuracy that that
> creates with posting list tuples.
Pushed a fix for this just now.
Thanks for t
replace constraint trigger my_trig
after insert on my_table
for each row execute procedure funcB(); -- Test 1a. Replace regular
trigger with constraint trigger. Expect ERROR (bad syntax)
drop trigger my_trig on my_table;
create constraint trigger my_trig -- 2. create a constraint trigger. OK
after insert on my_table
for each row execute procedure funcA();
create or replace trigger my_trig
after insert on my_table
for each row execute procedure funcB(); -- Test 2a. Replace
constraint trigger with regular trigger. Expect ERROR (cannot replace
a constraint trigger)
create or replace constraint trigger my_trig
after insert on my_table
for each row execute procedure funcB(); -- Test 2b. Replace
constraint trigger with constraint trigger. Expect ERROR (bad syntax)
drop table my_table;
drop function funcA();
drop function funcB();
--
Kind Regards,
Peter Smith.
Fujitsu Australia
o make it valid. I guess this could be explained in
more detail (as I'm attempting in this email), but this isn't materially
changed by this patch.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
q has. But I think these
few cases are not particularly hard to keep in sync.
From a2c1e26ceff05ec6ebbdb9cf74a3171ebf969911 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Thu, 5 Nov 2020 13:24:47 +0100
Subject: [PATCH] Fix redundant error messages in client tools
A few client tools dupl
d.
BKI_ROWTYPE_OID on the other hand is not used at the top level like
this, so it can be defined to empty.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-11-02 20:50, Andres Freund wrote:
On 2020-10-31 22:25:36 +0500, Andrey Borodin wrote:
But the price of compression is 1 cpu for 500MB/s (zstd). With a
20Gbps network adapters cost of recompressing all traffic is at most
~4 cores.
It's not quite that simple, because presumably each conn
You have to list the data types that you're interested in
somehow. Any other ideas?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
s meaning "use the session's per-type default", and
then if you don't want that you can pass 0 or 1. An advantage of that
is that you couldn't accidentally break an application that wasn't
ready for this feature, because it would not be the default to use
gresql.org/30/2307/
---
Kind Regards,
Peter Smith.
Fujitsu Australia
On 2020-11-05 12:59, John Naylor wrote:
And yes, this doesn't materially change the patch, it's just nitpicking
:-) . Materially, I believe it's fine.
OK, committed.
--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/
On 2020-11-05 13:27, Peter Eisentraut wrote:
A few client tools duplicate error messages already provided by libpq,
such as
pg_rewind: fatal: could not connect to server: could not connect to
server: No such file or directory
pg_basebackup: error: could not connect to server: could not connect
as the reason this option
exists, and glibc tags its realloc() with this attribute, so doing the
same for repalloc() seems sensible.
--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/
ot very
elegant, but I couldn't come up with a better way that didn't involve
having to duplicate some of the error messages into multiple branches.
--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/
On 2020-11-05 22:03, Peter Eisentraut wrote:
Independently of that, how would you implement "says otherwise" here,
ie do a single-query override of the session's prevailing setting?
Maybe the right thing for that is to define -1 all the way down to the
protocol level as m
to formalize my findings into pg_dump test cases as a next
step. Then we can figure out what combination of tweaks will make them
all work.
--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/
On 2020-11-09 11:22, Magnus Hagander wrote:
I have spotted one small-ish thing. This patch is missing to update
the following code in vcregress.pl:
print "\nSetting up stats on new cluster\n\n";
system(".\\analyze_new_cluster.bat") == 0 or exit 1;
Ah, nice catch -- thanks! I guess thi
On Mon, Nov 2, 2020 at 1:04 PM Peter Geoghegan wrote:
> if Andres cannot spend any time on this in the foreseeable future then
> I'll withdraw the patch. I intend to formally withdraw the patch on
> November 9th, provided no new information comes to light.
I have now formally withd
ing a tool like
stabilizer:
https://github.com/ccurtsinger/stabilizer
I am not aware of anybody having actually used the tool with Postgres,
though. It looks rather inconvenient.
--
Peter Geoghegan
a visibility hint (think of a new "probably going to be garbage before
too long" index tuple bit) when DELETE statements run. Again, this
doesn't have to be reliable in the same way that setting an LP_DEAD
bit does. This delete marking stuff is not on my agenda right now.
Just an example of another mechanism based on similar principles.
--
Peter Geoghegan
found almost all of the normal (not error) code paths are getting executed.
For details please see attached the study results. (MS Excel file)
===
[1]
https://www.postgresql.org/message-id/CAHut%2BPu4BpUr0GfCLqJjXc%3DDcaKSvjDarSN89-4W2nxBeae9hQ%40mail.gmail.com
Kind Regards,
Peter Smith.
Fujitsu
n the line.
The attached patch cleans this up to make them all look like the first
style.
From 49ca423b136e65d162ede1b906930e22de4e5f8e Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Wed, 11 Nov 2020 10:04:48 +0100
Subject: [PATCH] Clean up optional rules in grammar
Various rules for opt
documentation as the reason this option
exists, and glibc tags its realloc() with this attribute, so doing the same
for repalloc() seems sensible.
Good point.
committed
--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/
onfusing reference to "port" in the Unix case.)
Or we just drop the hint in the Unix case. The primary error message is
clear enough.
--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/
On 2020-11-11 12:43, Vik Fearing wrote:
No objections, but could we also take this opportunity to standardize
the comment itself? Even in your patch there is a mix of spacing and
casing.
My preference is /* EMPTY */. That is, uppercase with spaces, but
whatever gets chosen is fine with me.
L
The subscriber tests are updated to include test cases for "cascading"
pub/sub scenarios.
i.e.. NODE_A publisher => subscriber NODE_B publisher => subscriber NODE_C
PSA only the modified v20-0006 patch (the other 5 patches remain unchanged)
Kind Regards,
Peter Smith.
Fujitsu
On 2020-11-11 11:54, Heikki Linnakangas wrote:
On 11/11/2020 11:12, Peter Eisentraut wrote:
The attached patch cleans this up to make them all look like the first
style.
+1
done
On 2020-06-30 06:34, John Naylor wrote:
In v9, I've simplified the patch somewhat to make it easier for future
work to build on.
- When truncating on month-or-greater intervals, require the origin to
align on month. This removes the need to handle weird corner cases
that have no straightforward
ame garbage (and actually had
their LP_DEAD bits set) after VACUUM began, but before VACUUM reached
the leaf pages. That's really wasteful, and doesn't actually have any
upside -- we're scanning all of the line pointers only when we're
about to split (or dedup) the same page anyway, so the extra work is
practically free.
--
Peter Geoghegan
On Thu, Nov 12, 2020 at 3:00 PM Peter Geoghegan wrote:
> Attached is v8, which has the enhancements for low cardinality data
> that I mentioned earlier today. It also simplifies the logic for
> dealing with posting lists that we need to delete some TIDs from.
> These posting list sim
On 2020-11-12 23:28, Tom Lane wrote:
I'm on board with pulling these now --- 8.2 to v14 is plenty of
deprecation notice. However, the patch seems incomplete in that
the code support for these is still there -- look for
RTOldContainedByStrategyNumber and RTOldContainsStrategyNumber.
Admittedly, t
On 2020-11-10 16:15, Georgios Kokolatos wrote:
I noticed that this patch fails on the cfbot.
For this, I changed the status to: 'Waiting on Author'.
Cheers,
//Georgios
The new status of this patch is: Waiting on Author
Here is a rebased and lightly retouched patch.
--
Peter
ndependent of the presence of the alias "x", so I don't
think it has to do with this patch.
There is a fair amount of documentation on outer joins, so I expect that
this is discussed there.
--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/
On 2020-11-16 04:04, Michael Paquier wrote:
On Fri, Nov 13, 2020 at 12:58:52PM +0530, Bharath Rupireddy wrote:
It's not required to set bistate to null as we have allocated myState
with palloc0 in CreateIntoRelDestReceiver, it will anyways be null.
if (!into->skipData)
myState->bista
On 2020-11-13 16:57, Tom Lane wrote:
Peter Eisentraut writes:
On 2020-11-12 23:28, Tom Lane wrote:
I'm on board with pulling these now --- 8.2 to v14 is plenty of
deprecation notice. However, the patch seems incomplete in that
the code support for these is still there -- loo
performance POV.
Great, thanks for testing!
--
Peter Geoghegan
uitable column types may decrease
to empty over time, making it hard to maintain the test case.
I used the money type for now. If someone adds hash support for that,
we'll change it. I don't think this will change too rapidly, though.
--
Peter Eisentraut
2ndQuadrant, an EDB compa
mall value for
forensic or debugging purposes, and saves callers the trouble of
telling _bt_delitems_delete() (and code like it) whether or not this
is a heapkeyspace index.
--
Peter Geoghegan
I'll post a rebased version
of the patch series later on today.
Thanks
--
Peter Geoghegan
index. This works with only one or two
tweaks to the tests (IIRC the amcheck tests need to be tweaked in one
place for this to work). I don't anticipate that !heapkeyspace indexes
will be a problem, because they won't use any of the new stuff anyway,
and because nothing about the on-disk format is changed by bottom-up
index deletion.
--
Peter Geoghegan
On 2020-11-12 08:12, Michael Paquier wrote:
On Wed, Nov 11, 2020 at 01:39:17PM +0100, Peter Eisentraut wrote:
Thinking about it further, I think the hint in the Unix-domain socket case
is bogus. A socket in the file-system namespace never reports EADDRINUSE
anyway, it just overwrites the file
ply worker: called
process_syncing_tables
2020-11-18 17:03:04.081 AEDT [15886] LOG: !!>> apply worker:
LogicalRepApplyLoop
2020-11-18 17:03:04.082 AEDT [15886] LOG: !!>> apply worker: called
process_syncing_tables
2020-11-18 17:03:05.103 AEDT [15886] LOG: !!>> apply worker:
LogicalRepApplyLoop
2020-11-18 17:03:05.103 AEDT [15886] LOG: !!>> apply worker: called
process_syncing_tables
etc ...
At this point there is a problem because the tablesync worker has
COMMITTED that PREPARED INSERT.
See the subscriber node has ONE record but the publisher node has NONE!
[postgres@CentOS7-x64 ~]$ psql -d test_pub -c "SELECT count(*) FROM test_tab;"
count
---
0
(1 row)
[postgres@CentOS7-x64 ~]$
[postgres@CentOS7-x64 ~]$ psql -d test_sub -p 54321 -c "SELECT
count(*) FROM test_tab;"
count
---
1
(1 row)
[postgres@CentOS7-x64 ~]$
-
[1] -
https://www.postgresql.org/message-id/CAHut%2BPsprtsa4o89wtNnKLxxwXeDKAX9nNsdghT1Pv63siz%2BAA%40mail.gmail.com
[2] -
https://www.postgresql.org/message-id/CAHut%2BPt4PyKQCwqzQ%3DEFF%3DbpKKJD7XKt_S23F6L20ayQNxg77A%40mail.gmail.com
Kind Regards,
Peter Smith.
Fujitsu Australia
On Wed, Nov 18, 2020 at 7:37 PM Amit Kapila wrote:
>
> On Wed, Nov 18, 2020 at 1:18 PM Peter Smith wrote:
> >
> > Hi.
> >
> > Using a tablesync debugging technique as described in another mail
> > thread [1][2] I have caused the tablesync worker to handle (e.
On 2020-11-17 20:33, Tom Lane wrote:
Peter Eisentraut writes:
I wrote a new patch to add a lot more tests around hash-based plans.
This is intended to apply separately from the other patch, and the other
patch would then "flip" some of the test cases.
OK, that addresses my concerns
On 2020-11-17 02:32, Michael Paquier wrote:
The SQL standard says that for CREATE TABLE AS, the INSERT "is effectively
executed without further Access Rule checking", which means the INSERT
privilege shouldn't be required at all. I suggest we consider doing that
instead. I don't see a use for t
e complicated to avoid
extremely unlikely segfaults then we're actually doing the user a
disservice, because we're increasing the chances that we the
guarantors will be the weakest link (which was already high enough).
This smacks of hubris.
I also agree that hardening is a worthwhile exercise here, of course.
We should be holding amcheck to a higher standard when it comes to not
segfaulting with corrupt data.
--
Peter Geoghegan
ere are lots of specific ways in which it is
hardened (e.g., there are many defensive "can't happen" elog()
statements). I really don't know why you insist on this black and
white framing.
--
Peter Geoghegan
ts to the now-LP_UNUSED line pointer. But many big
improvements are possible without violating this basic invariant.)
If you are able to pursue this project, in whole or in part, I would
definitely be supportive of that. I may be able to commit it. I think
that this project has many benefits, not just one or two. It seems
strategic.
--
Peter Geoghegan
On 2020-11-10 16:21, Georgios Kokolatos wrote:
Hi,
I noticed that this patch fails on the cfbot.
For this, I changed the status to: 'Waiting on Author'.
Cheers,
//Georgios
The new status of this patch is: Waiting on Author
Here is an updated patch to get it building again.
On 2020-11-19 17:35, Bharath Rupireddy wrote:
So, should we be doing it this way?
For CTAS: retain the existing CREATE privilege check and remove the
INSERT privilege check altogether for all the cases i.e. with data,
with no data, explain analyze, plain, with execute?
For CREATE MATERIALIZED VI
On 2020-11-20 06:37, Michael Paquier wrote:
But if you consider materialized views as a variant of normal views,
then the INSERT privilege would be applicable if you pass an INSERT on
the materialized view through to the underlying tables, like for a view.
INSERT to materialized views is not sup
equivalent of
496ee647ecd2917369ffcf1eaa0b2cdca07c8730, which allows promotion while
recovery is paused. I'm not sure that would be necessary, and it
doesn't look easy to add either.
--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/
From 99724e2ee14b5f3ec926c7a
On 2020-11-03 21:53, David Rowley wrote:
On Tue, 3 Nov 2020 at 20:08, Peter Eisentraut
wrote:
On 2020-09-29 11:26, David Rowley wrote:
I've marked this patch back as waiting for review. It would be good if
someone could run some tests on some intel hardware and see if they
can se
ppropriate action with any Unix-domain socket
(because with file system namespace sockets, you never get an
EADDRINUSE, so it's dead code). So my proposal here is to just delete
that line from the hint and leave the rest the same. There could be
value in further refining and rephras
On 2020-09-03 12:14, Michael Paquier wrote:
On Fri, Jun 26, 2020 at 01:11:55PM +0900, Michael Paquier wrote:
From what I can see on this thread, we could just remove currtid() per
the arguments of the RETURNING ctid clause supported since PG 8.2, but
it would make more sense to me to just remov
be
some kind of verbose or debug mode, we wouldn't really lose much. With
that in mind, I'm a bit concerned about adding options (and thus
documentation surface area etc.) to select exactly which slice of the
chattiness to omit.
--
Peter Eisentraut
2ndQuadrant, an EDB compan
On 2020-10-17 21:21, Justin Pryzby wrote:
Added at:https://commitfest.postgresql.org/30/2766/
diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c
index 41317f1837..7345971507 100644
--- a/src/backend/commands/explain.c
+++ b/src/backend/commands/explain.c
@@ -839,7 +839,
On 2020-10-29 03:44, Justin Pryzby wrote:
diff --git a/doc/src/sgml/contrib.sgml b/doc/src/sgml/contrib.sgml
index 4e833d79ef..be4292ec33 100644
--- a/doc/src/sgml/contrib.sgml
+++ b/doc/src/sgml/contrib.sgml
@@ -199,6 +199,5 @@ pages.
part of the core PostgreSQL distribution.
- &pgs
401 - 500 of 10726 matches
Mail list logo
