On Fri, Dec 17, 2021 at 10:51 AM Masahiko Sawada wrote:
>
> I've attached updated patches. The first patch just moves common
> function for index bulk-deletion and cleanup to vacuum.c. And the
> second patch moves parallel vacuum code to vacuumparallel.c. The
> comments I got so far are incorporat
On 12/18/21 05:52, Tom Lane wrote:
Tomas Vondra writes:
The problem is exactly the same as in [1] - the aborted transaction
generated WAL, but RecordTransactionAbort() ignores that and does not
update LogwrtResult.Write, with the reasoning that aborted transactions
do not matter. But sequenc
Tomas Vondra writes:
> The problem is exactly the same as in [1] - the aborted transaction
> generated WAL, but RecordTransactionAbort() ignores that and does not
> update LogwrtResult.Write, with the reasoning that aborted transactions
> do not matter. But sequences violate that, because we on
On Fri, Dec 17, 2021 at 3:16 PM houzj.f...@fujitsu.com
wrote:
>
> On Friday, December 17, 2021 1:55 AM Alvaro Herrera
> wrote:
> > On 2021-Dec-16, houzj.f...@fujitsu.com wrote:
> >
> > > The patch ensures all columns of RT are in column list when
> > > CREATE/ALTER publication, but it seems does
On Sat, Dec 18, 2021 at 7:04 AM Alvaro Herrera wrote:
>
> On 2021-Dec-17, Tomas Vondra wrote:
>
> > On 12/17/21 22:07, Alvaro Herrera wrote:
> > > So I've been thinking about this as a "security" item (you can see my
> > > comments to that effect sprinkled all over this thread), in the sense
> > >
On Fri, Dec 17, 2021 at 5:29 PM Greg Nancarrow wrote:
>
> On Fri, Dec 17, 2021 at 7:20 PM Ajin Cherian wrote:
> >
> > On Fri, Dec 17, 2021 at 5:46 PM Greg Nancarrow wrote:
> >
> > > So using the v47 patch-set, I still find that the UPDATE above results in
> > > publication of an INSERT of (2,1)
On Thu, Dec 16, 2021 at 10:46 PM Masahiko Sawada wrote:
> > My emphasis here has been on making non-aggressive VACUUMs *always*
> > advance relfrozenxid, outside of certain obvious edge cases. And so
> > with all the patches applied, up to and including the opportunistic
> > freezing patch, every
On 12/18/21 02:34, Alvaro Herrera wrote:
On 2021-Dec-17, Tomas Vondra wrote:
On 12/17/21 22:07, Alvaro Herrera wrote:
So I've been thinking about this as a "security" item (you can see my
comments to that effect sprinkled all over this thread), in the sense
that if a publication "hides" som
On 12/15/21 14:51, Tomas Vondra wrote:
On 12/15/21 14:20, Amit Kapila wrote:
On Tue, Dec 14, 2021 at 7:02 AM Tomas Vondra
wrote:
Hi,
here's an updated version of the patches, dealing with almost all of the
issues (at least in the 0001 and 0002 parts). The main changes:
1) I've removed th
Hi,
while working on logical decoding of sequences, I ran into an issue with
nextval() in a transaction that rolls back, described in [1]. But after
thinking about it a bit more (and chatting with Petr Jelinek), I think
this issue affects physical sync replication too.
Imagine you have a pri
On 2021-Dec-17, Tomas Vondra wrote:
> On 12/17/21 22:07, Alvaro Herrera wrote:
> > So I've been thinking about this as a "security" item (you can see my
> > comments to that effect sprinkled all over this thread), in the sense
> > that if a publication "hides" some column, then the replica just wo
Greg Stark writes:
> But the bigger question is. Are we really concerned about this flaky
> problem? Is it worth investing time and money on? I can get money to
> go buy a G4 or G5 and spend some time on it. It just seems a bit...
> niche. But if it's a real bug that represents something broken on
On Fri, 17 Dec 2021 at 18:40, Tom Lane wrote:
>
> Greg Stark writes:
> > Hm. I seem to have picked a bad checkout. I took the last one before
> > the revert (45aa88fe1d4028ea50ba7d26d390223b6ef78acc).
>
> FWIW, I think that's the first one *after* the revert.
Doh
But the bigger question is. Are
On Dec 17, 2021 at 08:13, Peter Eisentraut wrote:
On 15.12.21 16:59, Brar Piening wrote:
On Dec 15, 2021 at 15:49, Alvaro Herrera wrote:
On 2021-Dec-15, Brar Piening wrote:
Since I can't argue towards some general utility for the xreflabels
and don't have any other solid argument in favor of a
Greg Stark writes:
> Hm. I seem to have picked a bad checkout. I took the last one before
> the revert (45aa88fe1d4028ea50ba7d26d390223b6ef78acc).
FWIW, I think that's the first one *after* the revert.
> 2021-12-17 17:51:51.688 EST [50955] LOG: background worker "parallel
> worker" (PID 54073)
On 12/17/21 23:56, Greg Stark wrote:
Hm. I seem to have picked a bad checkout. I took the last one before
the revert (45aa88fe1d4028ea50ba7d26d390223b6ef78acc). Or there's some
incompatibility with the emulation and the IPC stuff parallel workers
use.
2021-12-17 17:51:51.688 EST [50955] LOG: b
Hm. I seem to have picked a bad checkout. I took the last one before
the revert (45aa88fe1d4028ea50ba7d26d390223b6ef78acc). Or there's some
incompatibility with the emulation and the IPC stuff parallel workers
use.
2021-12-17 17:51:51.688 EST [50955] LOG: background worker "parallel
worker" (PID
On 12/17/21 22:07, Alvaro Herrera wrote:
So I've been thinking about this as a "security" item (you can see my
comments to that effect sprinkled all over this thread), in the sense
that if a publication "hides" some column, then the replica just won't
get access to it. But in reality that's m
On 2021-12-17 11:31:59 -0800, Andres Freund wrote:
> > Don't we need the ulimit call for FreeBSD?
>
> I think the default core limits were different, I will check.
Yep, freebsd has -c unlimited by default:
https://cirrus-ci.com/task/6199382239346688?logs=sysinfo#L23
vs
https://cirrus-ci.com/task/
So I've been thinking about this as a "security" item (you can see my
comments to that effect sprinkled all over this thread), in the sense
that if a publication "hides" some column, then the replica just won't
get access to it. But in reality that's mistaken: the filtering that
this patch impleme
Attached is a short patch series to develop some ideas of inlining
pg_utf_mblen().
0001 puts the main implementation of pg_utf_mblen() into an inline
function and uses this in pg_mblen(). This is somewhat faster in the
strpos tests, so that gives some measure of the speedup expected for
other call
> On 17 Dec 2021, at 20:31, Andres Freund wrote:
> On 2021-12-17 12:34:36 +0100, Peter Eisentraut wrote:
>> I don't like that the -s option is used. I would like to see what commands
>> are executed.
>
> I can change it - but it makes it *much* harder to spot compiler warnings.
Having used Cir
On Mon, Dec 13, 2021 at 05:27:52PM -0500, Melanie Plageman wrote:
> Done in attached v4
Thanks.
I think these comments can be removed from the callers:
/* it's a simple type, so don't use get_call_result_type */
You removed one call to tuplestore_donestoring(), but not the others.
I guess you co
Greg Stark writes:
> I'm guessing I should do CC=/usr/bin/powerpc-apple-darwin9-gcc-4.2.1
> or maybe 4.0.1. What version is on your G4?
$ gcc -v
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking
-enable-werror --prefix=/
I have
IBUILD:postgresql gsstark$ ls /usr/bin/*gcc*
/usr/bin/gcc
/usr/bin/gcc-4.0
/usr/bin/gcc-4.2
/usr/bin/i686-apple-darwin9-gcc-4.0.1
/usr/bin/i686-apple-darwin9-gcc-4.2.1
/usr/bin/powerpc-apple-darwin9-gcc-4.0.1
/usr/bin/powerpc-apple-darwin9-gcc-4.2.1
I'm guessing I should do CC=/usr/bin/pow
Hi,
On 2021-12-17 09:36:05 -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > Maye I have missed it, but why are we using ccache here? That seems a
> > bit pointless in an ephemeral instance.
>
> I believe Munro's cfbot tooling is able to save and re-use ccache
> across successive instantiation
Hi,
On 2021-12-17 12:34:36 +0100, Peter Eisentraut wrote:
> On 13.12.21 22:12, Andres Freund wrote:
> > Attached is an updated version of the CI patches. An example of a test run
> > with the attached version of this
> > https://cirrus-ci.com/build/6501998521483264
>
> + only_if: $CIRRUS_CHANGE_
On Fri, Dec 17, 2021 at 02:33:25PM +, Jakub Wartak wrote:
> > Justin wrote:
> > On Fri, Dec 17, 2021 at 09:10:30AM +, Jakub Wartak wrote:
> > > As the thread didn't get a lot of traction, I've registered it into
> > > current
> > commitfest
> > https://eur02.safelinks.protection.outlook.c
Greg Stark writes:
> What tools and tool versions are you using to build? Is it just GCC for PPC?
> There aren't any special build processes to make a fat binary involved?
Nope, just "configure; make" using that macOS version's regular gcc.
regards, tom lane
What tools and tool versions are you using to build? Is it just GCC for PPC?
There aren't any special build processes to make a fat binary involved?
On Thu, 16 Dec 2021 at 23:11, Tom Lane wrote:
>
> Greg Stark writes:
> > But if you're interested and can explain the tests to run I can try to
>
Hi all!
As part of a customer project we are looking to implement an reloption
for views which when set, runs the subquery as invoked by the user
rather than the view owner, as is currently the case.
The rewrite rule's table references are then checked as if the user were
referencing the table
On Thu, Dec 16, 2021 at 12:23:08PM +0100, Daniel Gustafsson wrote:
> > On 16 Dec 2021, at 12:11, Peter Eisentraut
> > wrote:
>
> > Could we make it write just one log file? Is having multiple log files
> > better?
>
> Having individual .txt files from checks with additional
> information
> o
On 2021-Dec-17, Rahila Syed wrote:
> > This means that we need to support changing the column list of a
> > table in a publication. I'm looking at implementing some form of
> > ALTER PUBLICATION for that.
>
> I think right now the patch contains support only for ALTER
> PUBLICATION.. ADD TABLE w
I want to mention that the 2nd problem I mentioned here is still broken.
https://www.postgresql.org/message-id/20210717010259.gu20...@telsasoft.com
It happens if non-inheritted triggers on child and parent have the same name.
On Fri, Jul 16, 2021 at 08:02:59PM -0500, Justin Pryzby wrote:
> On Fri
On Fri, Dec 17, 2021 at 10:21:04AM +0100, Peter Eisentraut wrote:
> On 16.12.21 07:50, Michael Paquier wrote:
> > As per $subject, avoiding the flush of the new cluster's data
> > directory shortens a bint the runtime of the test. In some of my slow
> > VMs, aka Windows, this shaves a couple of se
Andrew Dunstan writes:
> Maye I have missed it, but why are we using ccache here? That seems a
> bit pointless in an ephemeral instance.
I believe Munro's cfbot tooling is able to save and re-use ccache
across successive instantiations of a build instance. I've not
looked at this code, but if it
> Justin wrote:
> On Fri, Dec 17, 2021 at 09:10:30AM +, Jakub Wartak wrote:
> > As the thread didn't get a lot of traction, I've registered it into current
> commitfest
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommitf
> est.postgresql.org%2F36%2F3461%2F&data=04%7C01%
On 12/13/21 16:12, Andres Freund wrote:
> Hi,
>
> Attached is an updated version of the CI patches. An example of a test run
> with the attached version of this
> https://cirrus-ci.com/build/6501998521483264
>
Maye I have missed it, but why are we using ccache here? That seems a
bit pointless in
Le vendredi 17 décembre 2021, 14:39:10 CET Tomas Vondra a écrit :
> I wasn't really suggesting to investigate those other allocators in this
> patch - it seems like a task requiring a pretty significant amount of
> work/time. My point was that we should make it reasonably easy to add
> tweaks for t
On 12/17/21 09:08, Ronan Dunklau wrote:
> Le jeudi 16 décembre 2021, 18:00:56 CET Tomas Vondra a écrit :
>> On 12/16/21 17:03, Ronan Dunklau wrote:
>>> Le jeudi 16 décembre 2021, 11:56:15 CET Ronan Dunklau a écrit :
I will follow up with a benchmark of the test sorting a table with a
widt
I plan to push v25 early next week, unless there are further comments.
--
John Naylor
EDB: http://www.enterprisedb.com
On Fri, Dec 17, 2021 at 09:10:30AM +, Jakub Wartak wrote:
> I'm especially worried if I didn't screw up something/forgot something
> related to the last one (rd->rd_smgr changes), but I'm getting "All 210 tests
> passed".
> As the thread didn't get a lot of traction, I've registered it into
Hi,
Thank you for updating the patch. The regression tests and tap tests pass
with v9 patch.
>
> After working on this a little bit more, I realized that this is a bad
> idea overall. It causes lots of complications and it's just not worth
> it. So I'm back at my original thought that we need
On Fri, Dec 17, 2021 at 7:20 PM Ajin Cherian wrote:
>
> On Fri, Dec 17, 2021 at 5:46 PM Greg Nancarrow wrote:
>
> > So using the v47 patch-set, I still find that the UPDATE above results in
> > publication of an INSERT of (2,1), rather than an UPDATE of (1,1) to (2,1).
> > This is according to t
On 13.12.21 22:12, Andres Freund wrote:
Attached is an updated version of the CI patches. An example of a test run
with the attached version of this
https://cirrus-ci.com/build/6501998521483264
+ only_if: $CIRRUS_CHANGE_MESSAGE !=~ '.*\nci-os-only:.*' ||
$CIRRUS_CHANGE_MESSAGE =~ '.*\nci-os-o
On Fri, Dec 17, 2021 at 7:12 PM Amit Kapila wrote:
>
> On Fri, Dec 17, 2021 at 3:23 PM Peter Eisentraut
> wrote:
> >
> > On 13.12.21 04:12, Greg Nancarrow wrote:
> > > (ii) "Setting -1 means to reset the transaction ID"
> > >
> > > Shouldn't it be explained what resetting actually does and when i
On Fri, Dec 17, 2021 at 1:50 PM Ajin Cherian wrote:
>
> On Fri, Dec 17, 2021 at 5:46 PM Greg Nancarrow wrote:
>
> > So using the v47 patch-set, I still find that the UPDATE above results in
> > publication of an INSERT of (2,1), rather than an UPDATE of (1,1) to (2,1).
> > This is according to t
Le vendredi 17 décembre 2021, 09:08:06 CET Ronan Dunklau a écrit :
> It is my understanding that malloc will try to compact memory by moving it
> around. So the memory should be actually be released to the kernel at some
> point. In the meantime, malloc can reuse it for our next invocation (which
>
On Fri, Dec 17, 2021 at 3:23 PM Peter Eisentraut
wrote:
>
> On 13.12.21 04:12, Greg Nancarrow wrote:
> > (ii) "Setting -1 means to reset the transaction ID"
> >
> > Shouldn't it be explained what resetting actually does and when it can
> > be, or is needed to be, done? Isn't it automatically reset
On Fri, Dec 17, 2021 at 4:11 AM Peter Smith wrote:
>
> PSA the v47* patch set.
>
Few comments on v47-0002:
===
1. The handling to find rowfilter for ancestors in
RelationGetInvalidRowFilterCol seems complex. It seems you are
accumulating non-partition relations as well in topr
On 15.12.21 20:58, Florian Koch wrote:
I realized that the output of "\df+ func_name" has a formatting problem
when a
lot of arguments are used. The field 'Arguments data types' gets very
long and
destroys the whole formatting in the console. The field 'Source code' is
most of
the time multi-li
On 13.12.21 04:12, Greg Nancarrow wrote:
(ii) "Setting -1 means to reset the transaction ID"
Shouldn't it be explained what resetting actually does and when it can
be, or is needed to be, done? Isn't it automatically reset?
I notice that negative values (other than -1) seem to be regarded as
val
On Friday, December 17, 2021 1:55 AM Alvaro Herrera
wrote:
> On 2021-Dec-16, houzj.f...@fujitsu.com wrote:
>
> > The patch ensures all columns of RT are in column list when
> > CREATE/ALTER publication, but it seems doesn't prevent user from
> > changing the replica identity or dropping the inde
On 16.12.21 07:50, Michael Paquier wrote:
As per $subject, avoiding the flush of the new cluster's data
directory shortens a bint the runtime of the test. In some of my slow
VMs, aka Windows, this shaves a couple of seconds even if the bulk of
the time is still spent on the main regression test
On 17.12.21 01:41, Jacob Champion wrote:
(And I think the client should be able to enforce encryption in
the first place, before I distract you too much with other stuff.)
Yes, this is a useful point that I have added to my notes.
> Kyotaro wrote:
> > In this version, I got rid of the "CLEANUP FORK"s, and added a new
> > system "Smgr marks". The mark files have the name of the
> > corresponding fork file followed by ".u" (which means Uncommitted.).
> > "Uncommited"-marked main fork means the same as the
> CLEANUP2_FORKNUM
>
On 17.12.21 00:48, Jacob Champion wrote:
WDYT? (My responses here will be slower than usual. Hope you all have a
great end to the year!)
Looks interesting. I wonder whether putting this into pg_ident.conf is
sensible. I suspect people will want to eventually add more features
around this,
On Fri, Dec 17, 2021 at 5:46 PM Greg Nancarrow wrote:
> So using the v47 patch-set, I still find that the UPDATE above results in
> publication of an INSERT of (2,1), rather than an UPDATE of (1,1) to (2,1).
> This is according to the 2nd UPDATE rule below, from patch 0003.
>
> + * old-row (no m
Le jeudi 16 décembre 2021, 18:00:56 CET Tomas Vondra a écrit :
> On 12/16/21 17:03, Ronan Dunklau wrote:
> > Le jeudi 16 décembre 2021, 11:56:15 CET Ronan Dunklau a écrit :
> >> I will follow up with a benchmark of the test sorting a table with a
> >> width
> >> varying from 1 to 32 columns.
> >
>
On Fri, 22 Oct 2021 at 19:27, Robert Haas wrote:
>
> Another thing to think about in that regard: how likely is that
> PostgreSQL 7.4 and PostgreSQL 15 both compile and run on the same
> operating system? I suspect the answer is "not very." I seem to recall
> Greg Stark trying to compile really ol
60 matches
Mail list logo
