Re: Ordering of header file inclusion

On Fri, Nov 22, 2019 at 8:07 PM Tom Lane wrote: > > vignesh C writes: > > After the inclusion they have define and further include based on #if > > defined. In few cases I had seen the include happens at the end of the > > file like in regcomp.c as there may be impact. I felt it is better not > >

RE: [BUG] (firsttupleslot)==NULL is redundant or is possible null dereference?

>And why do you think this is a bug? Immediately before the part of code >you copied we have this: > > /* > * The ScanTupleSlot holds the (copied) first tuple of each group. > */ > firsttupleslot = node->ss.ss_ScanTupleSlot; >And node->ss.ss_ScanTupleSlot is expected to be non-NUL

Re: Assertion failing in master, predicate.c

On 11/22/19 3:25 PM, Tom Lane wrote: I wrote: Mark Dilger writes: `git bisect` shows the problem occurs earlier than that, and by chance the first bad commit was one of yours. I'm not surprised that your commit was regarding LISTEN/NOTIFY, as the error is always triggered with a LISTEN sta

Re: Avoid full GIN index scan when possible

Attached 8th version of the patches. A brief description of the patches and their improvements/overheads: 1. Avoid full scan in "empty-ALL AND regular" case. One EVERYTHING entry with unconditional recheck is used instead of multiple ALL entries. Overhead for rechecking NULLs and "empt

RE: [PATCH] Tiny optmization or a bug?

Hi, I just wanted to help a little bit, sorry for the out balls. Maybe, I got one or two right. Anyway, thank you very much for your attention and patience. best regards. Ranier Vilela De: Tomas Vondra Enviado: sexta-feira, 22 de novembro de 2019 23:25

Re: [PATCH] Tiny optmization or a bug?

On Fri, Nov 22, 2019 at 11:06:53PM +, Ranier Vilela wrote: Hi, Hi, Maybe this is a real bug. The assignment has no effect, or forget dereferencing it? Best regards. Ranier Vilela --- \dll\postgresql-12.0\a\backend\optimizer\plan\initsplan.c Mon Sep 30 17:06:55 2019 +++ initsplan.c Fri N

Re: Assertion failing in master, predicate.c

I wrote: > Mark Dilger writes: >> `git bisect` shows the problem occurs earlier than that, and by >> chance the first bad commit was one of yours. I'm not surprised >> that your commit was regarding LISTEN/NOTIFY, as the error is >> always triggered with a LISTEN statement. (I've now hit this >>

Re: [BUG] (firsttupleslot)==NULL is redundant or is possible null dereference?

On Fri, Nov 22, 2019 at 10:57:13PM +, Ranier Vilela wrote: Hi, Sorry, you are right. Had not seen this line: firsttupleslot = node->ss.ss_ScanTupleSlot; OK, no problem. When writing future messages to this list, please * Make sure you explain why you think a given code is broken. Ideally,

[PATCH] Tiny optmization or a bug?

Hi, Hi, Maybe this is a real bug. The assignment has no effect, or forget dereferencing it? Best regards. Ranier Vilela --- \dll\postgresql-12.0\a\backend\optimizer\plan\initsplan.c Mon Sep 30 17:06:55 2019 +++ initsplan.c Fri Nov 22 19:48:42 2019 @@ -1718,7 +1718,7 @@

RE: [BUG] (firsttupleslot)==NULL is redundant or is possible null dereference?

Hi, Sorry, you are right. Had not seen this line: firsttupleslot = node->ss.ss_ScanTupleSlot; Best regards. Ranier Vilela De: Tomas Vondra Enviado: sexta-feira, 22 de novembro de 2019 22:54 Para: Ranier Vilela Cc: pgsql-hack...@postgresql.org Assunto: Re:

Re: Attempt to consolidate reading of XLOG page

On 2019-Nov-22, Antonin Houska wrote: > As I pointed out in > > https://www.postgresql.org/message-id/88183.1574261429%40antos > > seg.ws_off only replaced readOff in XLogReaderState. So we should only update > ws_off where readOff was updated before commit 709d003. This does happen in > ReadPag

Re: [BUG] (firsttupleslot)==NULL is redundant or is possible null dereference?

On Fri, Nov 22, 2019 at 10:32:11PM +, Ranier Vilela wrote: Hi, This is real bug? firsttupleslot == NULL. Ranier, I don't want to be rude, but I personally am getting a bit annoyed by this torrent of bug reports that are essentially just a bunch of copy-pasted chunks of code, without any sp

[BUG] (firsttupleslot)==NULL is redundant or is possible null dereference?

Hi, This is real bug? firsttupleslot == NULL. \backend\executor\nodeGroup.c if (TupIsNull(firsttupleslot)) { outerslot = ExecProcNode(outerPlanState(node)); if (TupIsNull(outerslot)) { /* empty input, so return

Re: backup manifests

On 11/22/19 5:15 PM, Tels wrote: > On 2019-11-22 20:01, Robert Haas wrote: >> On Fri, Nov 22, 2019 at 1:10 PM David Steele wrote: > >>> > Phrased more positively, if you want a cryptographic hash >>> > at all, you should probably use one that isn't widely viewed as too >>> > weak. >>> >>> Sure. 

Re: [PATCH] Tiny optmization.

On Fri, Nov 22, 2019 at 10:24:05PM +, Ranier Vilela wrote: Hi, pstate is touched here: a) BeginCopy line 1489: ProcessCopyOptions(pstate, cstate, is_from, options); b) ProcessCopyOptions line 1137: if (format_specified) ereport(

RE: [PATCH] Tiny optmization.

Hi, pstate is touched here: a) BeginCopy line 1489: ProcessCopyOptions(pstate, cstate, is_from, options); b) ProcessCopyOptions line 1137: if (format_specified) ereport(ERROR, (errcode(E

Re: [PATCH] Tiny optmization.

On Fri, Nov 22, 2019 at 10:10:29PM +, Ranier Vilela wrote: Hi, Redudant because he it's been dereferenced here: line 3410: cstate = BeginCopy(pstate, true, rel, NULL, InvalidOid, attnamelist, options); There's no pstate dereference here. It just passed the value to BeginCopy. BTW

Re: [PATCH] Tiny optmization.

Ranier Vilela writes: > Redudant because he it's been dereferenced here: > line 3410: > cstate = BeginCopy(pstate, true, rel, NULL, InvalidOid, attnamelist, > options); Not necessarily ... the rel!=NULL code path there doesn't touch pstate, and that seems to be what contrib/file_fdw is r

Re: backup manifests

Moin Robert, On 2019-11-22 20:01, Robert Haas wrote: On Fri, Nov 22, 2019 at 1:10 PM David Steele wrote: Well, the maximum amount of data that can be protected with a 32-bit CRC is 512MB according to all the sources I found (NIST, Wikipedia, etc). I presume that's what we are talking about

Re: [PATCH] Tiny optmization or is a bug?

On Fri, Nov 22, 2019 at 09:51:50PM +, Ranier Vilela wrote: Hi, Maybe this is a real bug. The assignment has no effect, or forget dereferencing it? Best regards. Ranier Vilela --- \dll\postgresql-12.0\a\backend\commands\lockcmds.c Mon Sep 30 17:06:55 2019 +++ lockcmds.c Fri Nov 22 18:45:0

Re: Getting psql to redisplay command after \e

I wrote: > Fabien COELHO writes: >> This suggests that readline cannot be used to edit simply a known string? >> :-( "rl_insert_text" looked promising, although probably not portable, and >> I tried to make it work without much success anyway. Maybe I'll try to >> investigate more deeply later.

RE: [PATCH] Tiny optmization.

Hi, Redudant because he it's been dereferenced here: line 3410: cstate = BeginCopy(pstate, true, rel, NULL, InvalidOid, attnamelist, options); Best regards. Ranier Vilela De: Tomas Vondra Enviado: sexta-feira, 22 de novembro de 2019 22:05 Para:

Re: [PATCH] Tiny optmization.

On Fri, Nov 22, 2019 at 09:41:44PM +, Ranier Vilela wrote: Hi, Maybe it doesn't matter, but, I think it's worth discussing. The expression "if(pstate)" is redundant or is possible null dereference. Eh? Redundant with what? Why would it be a null dereference? It's a parameter passed from ou

[PATCH] Tiny optimization.

Hi, Remove redutant test. best regards. Ranier Vilela --- \dll\postgresql-12.0\a\backend\executor\execExpr.c Mon Sep 30 17:06:55 2019 +++ execExpr.c Fri Nov 22 18:50:32 2019 @@ -2426,7 +2426,7 @@ { desc = parent->scandesc; - if (parent && parent->scanops)

[PATCH] Tiny optmization or is a bug?

Hi, Maybe this is a real bug. The assignment has no effect, or forget dereferencing it? Best regards. Ranier Vilela --- \dll\postgresql-12.0\a\backend\commands\lockcmds.c Mon Sep 30 17:06:55 2019 +++ lockcmds.c Fri Nov 22 18:45:01 2019 @@ -285,7 +285,7 @@ LockViewRecurse_walker((Node

[PATCH] Tiny optmization.

Hi, Maybe it doesn't matter, but, I think it's worth discussing. The expression "if(pstate)" is redundant or is possible null dereference. Best regards. Ranier Vilela --- \dll\postgresql-12.0\a\backend\commands\copy.c Mon Sep 30 17:06:55 2019 +++ copy.c Fri Nov 22 18:33:05 2019 @@ -3426

Re: TAP tests aren't using the magic words for Windows file access

Andrew Dunstan writes: > I think the best course is for us to give your latest patch an outing on > the buildfarm and verify that the issues seen with slurp_file disappear. > That shouldn't take us more than a week or two to see - drongo has had 6 > such failures in the last 11 days on master. Aft

Re: Why overhead of SPI is so large?

Kyotaro Horiguchi writes: > At Fri, 22 Nov 2019 08:08:24 +0100, Pavel Stehule > wrote in >> a) we allow to call volatile functions from nonvolatile (stable, immutable) >> that really does write >> b) but this change is not visible in parent nonvolatile functions. Is >> visible only in volatile

Re: [PATCH][BUG FIX] Pointer arithmetic with NULL

On Fri, Nov 22, 2019 at 05:19:11PM +, Ranier Vilela wrote: Hi, Pointer addition with NULL, is technically undefined behavior. Best regards. Ranier Vilela --- \dll\postgresql-12.0\a\backend\access\transam\xlog.cMon Sep 30 17:06:55 2019 +++ xlog.c Fri Nov 22 13:57:17 2019 @@ -18

Re: WAL archive is lost

On Fri, Nov 22, 2019 at 05:31:55AM +, matsumura@fujitsu.com wrote: Hi all I find a situation that WAL archive file is lost but any WAL segment file is not lost. It causes for archive recovery to fail. Is this behavior a bug? example: WAL segment files 00010001 0

Re: Assertion failing in master, predicate.c

On 11/22/19 11:22 AM, Mark Dilger wrote: predicate.c was changed a few times after REL_12_STABLE was branched from master but before Thomas's change that you initially thought might be to blame.  I checked whether rolling back the changes in predicate.c while keeping your LISTEN/NOTIFY changes

Re: backup manifests

On 11/22/19 2:01 PM, Robert Haas wrote: > On Fri, Nov 22, 2019 at 1:10 PM David Steele wrote: >> Well, the maximum amount of data that can be protected with a 32-bit CRC >> is 512MB according to all the sources I found (NIST, Wikipedia, etc). I >> presume that's what we are talking about since I

Re: Assertion failing in master, predicate.c

On 11/22/19 11:07 AM, Tom Lane wrote: Mark Dilger writes: On 11/21/19 8:03 PM, Tom Lane wrote: I also confirm that it only happens in HEAD, not v12. I've not actually bisected, but a look at the git history for predicate.c sure makes it look like db2687d1f ("Optimize PredicateLockTuple") m

Re: Assertion failing in master, predicate.c

Mark Dilger writes: > On 11/21/19 8:03 PM, Tom Lane wrote: >> I also confirm that it only happens in HEAD, not v12. I've not >> actually bisected, but a look at the git history for predicate.c >> sure makes it look like db2687d1f ("Optimize PredicateLockTuple") >> must be to blame. > `git bisect

Re: backup manifests

On Fri, Nov 22, 2019 at 1:10 PM David Steele wrote: > Well, the maximum amount of data that can be protected with a 32-bit CRC > is 512MB according to all the sources I found (NIST, Wikipedia, etc). I > presume that's what we are talking about since I can't find any 64-bit > CRC code in core or t

Re: backup manifests

On 11/22/19 1:24 PM, Robert Haas wrote: > On Tue, Nov 19, 2019 at 4:34 PM David Steele wrote: >> On 11/19/19 5:00 AM, Rushabh Lathia wrote: >>> My colleague Suraj did testing and noticed the performance impact >>> with the checksums. On further testing, he found that specifically with >>> sha it

Re: Assertion failing in master, predicate.c

On 11/21/19 8:03 PM, Tom Lane wrote: Mark Dilger writes: I have winnowed down the test a bit further. The attached smaller patch still triggers the same assertion as the prior patch did. FWIW, I can reproduce the assertion failure with your first test, but not with this simplified one.

Re: backup manifests

On Tue, Nov 19, 2019 at 4:34 PM David Steele wrote: > On 11/19/19 5:00 AM, Rushabh Lathia wrote: > > My colleague Suraj did testing and noticed the performance impact > > with the checksums. On further testing, he found that specifically with > > sha its more of performance impact. > > We have f

Re: backup manifests

On 11/22/19 10:58 AM, Robert Haas wrote: > On Tue, Nov 19, 2019 at 8:49 AM Andrew Dunstan > wrote: >> I admit I haven't been following along closely, but why do we need a >> cryptographic checksum here instead of, say, a CRC? Do we think that >> somehow the checksum might be forged? Use of cryptog

Re: [PATCH][BUG FIX] Uninitialized variable parsed

On 11/22/19 8:50 AM, Ranier Vilela wrote: Hi, Typo mystake? Memset only fill a pointer size, not the size of struct. Hello Ranier, I think you may be misunderstanding how sizeof(*parsed) works in the attached code. Try compiling and running: #include typedef struct mystruct {

Re: [PATCH][BUG FIX] Pointer var initilialized with boolean.

On Fri, Nov 22, 2019 at 9:30 AM Ranier Vilela wrote: > > Hi, > Typo mystake? > Pointer var initilialized with boolean. This was already fixed by commit 0cafdd03a850265006c0ada1b0bf4f83e087a409. -- Peter Geoghegan

[PATCH][BUG FIX] Pointer var initilialized with boolean.

Hi, Typo mystake? Pointer var initilialized with boolean. Best regards. Ranier Vilela --- \dll\postgresql-12.0\a\backend\commands\trigger.c Mon Sep 30 17:06:55 2019 +++ trigger.c Fri Nov 22 14:20:56 2019 @@ -2536,7 +2536,7 @@ TupleTableSlot *slot) {

[PATCH][BUG FIX] Pointer arithmetic with NULL

Hi, Pointer addition with NULL, is technically undefined behavior. Best regards. Ranier Vilela --- \dll\postgresql-12.0\a\backend\access\transam\xlog.cMon Sep 30 17:06:55 2019 +++ xlog.c Fri Nov 22 13:57:17 2019 @@ -1861,7 +1861,7 @@ { Assert(((XLogPageHeader

Re: range_agg

pá 22. 11. 2019 v 17:25 odesílatel Paul A Jungwirth < p...@illuminatedcomputing.com> napsal: > On Thu, Nov 21, 2019 at 9:21 PM Pavel Stehule > wrote: > > I though about it, and I think so cast from multirange to range is > useless, minimally it should be explicit. > > I agree: definitely not impl

[PATCH][BUG FIX] Uninitialized variable parsed

Hi, Typo mystake? Memset only fill a pointer size, not the size of struct. Best regards. Ranier Vilela --- \dll\postgresql-12.0\a\backend\access\rmgrdesc\xactdesc.c Mon Sep 30 17:06:55 2019 +++ xactdesc.c Fri Nov 22 13:40:13 2019 @@ -35,7 +35,7 @@ { char *data = ((char *) xlrec

Re: range_agg

On Thu, Nov 21, 2019 at 9:21 PM Pavel Stehule wrote: > I though about it, and I think so cast from multirange to range is useless, > minimally it should be explicit. I agree: definitely not implicit. If I think of a good reason for it I'll add it, but otherwise I'll leave it out. > On second ha

Re: backup manifests

On Tue, Nov 19, 2019 at 8:49 AM Andrew Dunstan wrote: > I admit I haven't been following along closely, but why do we need a > cryptographic checksum here instead of, say, a CRC? Do we think that > somehow the checksum might be forged? Use of cryptographic hashes as > general purpose checksums has

Re: Attempt to consolidate reading of XLOG page

Alvaro Herrera wrote: > On 2019-Nov-22, Michael Paquier wrote: > > > On Fri, Nov 22, 2019 at 10:35:51AM -0300, Alvaro Herrera wrote: > > > FWIW I think the new code is buggy because it doesn't seem to be setting > > > ws_off, so I suppose the optimization in ReadPageInternal to skip > > > readin

Re: tableam vs. TOAST

On Thu, Nov 21, 2019 at 5:37 AM Peter Eisentraut wrote: > Partial review: The 0001 patch seems very sensible. Some minor comments > on that: Thanks for the review. Updated patches attached. This version is more complete than the last set of patches I posted. It looks like this: 0001 - Lets a t

Re: SimpleLruTruncate() mutual exclusion

> On Sun, Nov 17, 2019 at 10:14:26PM -0800, Noah Misch wrote: > > Though I did reproduce this bug, I'm motivated by the abstract problem more > than any particular way to reproduce it. Commit 996d273 inspired me; by > removing a GetCurrentTransactionId(), it allowed the global xmin to advance at >

Re: Ordering of header file inclusion

vignesh C writes: > After the inclusion they have define and further include based on #if > defined. In few cases I had seen the include happens at the end of the > file like in regcomp.c as there may be impact. I felt it is better not > to change these files. Let me know your thoughts on the same

Re: Attempt to consolidate reading of XLOG page

On 2019-Nov-22, Michael Paquier wrote: > On Fri, Nov 22, 2019 at 10:35:51AM -0300, Alvaro Herrera wrote: > > FWIW I think the new code is buggy because it doesn't seem to be setting > > ws_off, so I suppose the optimization in ReadPageInternal to skip > > reading the page when it's already the pag

Re: logical decoding : exceeded maxAllocatedDescs for .spill files

On Fri, 22 Nov 2019 at 4:26 PM, Amit Kapila wrote: > On Fri, Nov 22, 2019 at 11:00 AM Amit Khandekar > wrote: > > > > On Fri, 22 Nov 2019 at 09:08, Amit Kapila > wrote: > > > Have you tried before that fix , if not, can you once try by > > > temporarily reverting that fix in your environment an

Re: Attempt to consolidate reading of XLOG page

On Fri, Nov 22, 2019 at 10:35:51AM -0300, Alvaro Herrera wrote: > FWIW I think the new code is buggy because it doesn't seem to be setting > ws_off, so I suppose the optimization in ReadPageInternal to skip > reading the page when it's already the page we have is not hit, except > for the first pag

Re: Attempt to consolidate reading of XLOG page

On 2019-Nov-22, Antonin Houska wrote: > I thought that in [1] you try discourage me from using pg_pread(), but now it > seems to be the opposite. Ideally I'd like to see no overhead added by my > patch at all, but the code simplicity should matter too. FWIW I think the new code is buggy because i

Re: TAP tests aren't using the magic words for Windows file access

On 11/22/19 3:55 AM, Juan José Santamaría Flecha wrote: > > On Fri, Nov 22, 2019 at 9:00 AM Michael Paquier > wrote: > > On Thu, Nov 21, 2019 at 08:09:38PM +0100, Juan José Santamaría > Flecha wrote: > > I think Perl's open() is a bad candidate for an over

Re: obsolete example

On Fri, Nov 22, 2019 at 06:11:32AM +0100, Pavel Stehule wrote: > +1 Okay, done. I have added a .gitignore while on it in the path for the files generated. -- Michael signature.asc Description: PGP signature

WAL archive is lost

Hi all I find a situation that WAL archive file is lost but any WAL segment file is not lost. It causes for archive recovery to fail. Is this behavior a bug? example: WAL segment files 00010001 00010002 00010003 Archive files 0001

libpq calls blocking recv when it could not send data enough.

Hi all Libpq may be blocked by recv without checking data arrival when libpq could not send data enough. I think it should check by pqReadReady() for avoiding blocking. Note: I didn't encounter any issue that the pqReadData is blocked. [src/interfaces/libpq/fe-misc.c] pqSendSome(PGconn *conn

Re: base backup client as auxiliary backend process

On Fri, Nov 22, 2019 at 11:21:53AM +0100, Peter Eisentraut wrote: > After thinking about this a bit more, doing the temporary slot stuff on the > walsender side might lead to too many complications in practice. > > Here is another patch set that implements the temporary slot use on the > walreceiv

Re: [HACKERS] WAL logging problem in 9.4.3?

On 2019-11-05 22:16, Robert Haas wrote: First, I'd like to restate my understanding of the problem just to see whether I've got the right idea and whether we're all on the same page. When wal_level=minimal, we sometimes try to skip WAL logging on newly-created relations in favor of fsync-ing the

Re: pause recovery if pitr target not reached

"Peter Eisentraut" skrev 22. november 2019 kl. 11:50: > On 2019-11-21 13:50, Leif Gunnar Erlandsen wrote: > >> Pausing was choosen in the patch as pause was the expected behaivior if >> target was reached. > > Pausing is the expect behavior when the target is reached because that is the > de

Re: pause recovery if pitr target not reached

"Kyotaro Horiguchi" skrev 22. november 2019 kl. 05:26: > Hello, Lief, Peter. > > At Thu, 21 Nov 2019 12:50:18 +, "Leif Gunnar Erlandsen" > wrote in > >> Adding another patch which is not only for recovery_target_time but also for >> xid, name and lsn. >> >> After studying this a bit mo

Re: adding partitioned tables to publications

On Fri, Nov 22, 2019 at 4:16 PM Peter Eisentraut wrote: > > On 2019-11-22 07:28, Amit Langote wrote: > > >> What happens when you add a leaf table directly to a publication? Is it > >> replicated under its own identity or under its ancestor partitioned > >> table? (What if both the leaf table an

Re: logical decoding : exceeded maxAllocatedDescs for .spill files

On Fri, Nov 22, 2019 at 11:00 AM Amit Khandekar wrote: > > On Fri, 22 Nov 2019 at 09:08, Amit Kapila wrote: > > Have you tried before that fix , if not, can you once try by > > temporarily reverting that fix in your environment and share the > > output of each step? After you get the error due t

Re: Planner chose a much slower plan in hashjoin, using a large table as the inner table.

Hi hackers, I have made a patch to fix the problem. Added the selection rate of the inner table non-empty bucket The planner will use big table as inner table in hash join if small table have fewer unique values. But this plan is much slower than using small table as inner table. In general, th

Re: pause recovery if pitr target not reached

On 2019-11-21 13:50, Leif Gunnar Erlandsen wrote: Pausing was choosen in the patch as pause was the expected behaivior if target was reached. Pausing is the expect behavior when the target is reached because that is the default setting of recovery_target_action. Your patch does not take rec

Re: adding partitioned tables to publications

On 2019-11-22 07:28, Amit Langote wrote: Hmm, I thought it would be more desirable to not expose a published partitioned table's leaf partitions to a subscriber, because it allows the target table to be defined more flexibly. There are multiple different variants that we probably eventually wan

RE: Planning counters in pg_stat_statements (using pgss_store)

On Wed, Nov 20, 2019 at 4:55 PM, Julien Rouhaud wrote: > On Wed, Nov 20, 2019 at 2:06 AM imai.yoshik...@fujitsu.com > wrote: > > > > On Tue, Nov 19, 2019 at 2:27 PM, Julien Rouhaud wrote: > > > On Fri, Nov 15, 2019 at 2:00 AM imai.yoshik...@fujitsu.com > > > wrote: > > > > > > > > Actually I al

Re: base backup client as auxiliary backend process

On 2019-11-15 14:52, Sergei Kornilov wrote: I looked into this. It seems trivial to make walsender create and use a temporary replication slot by default if no permanent replication slot is specified. This is basically the logic that pg_basebackup has but done server-side. See attached patch for

Re: dropdb --force

pá 22. 11. 2019 v 10:46 odesílatel vignesh C napsal: > On Fri, Nov 22, 2019 at 12:10 AM Pavel Stehule > wrote: > > > > > > > > čt 21. 11. 2019 v 6:33 odesílatel vignesh C > napsal: > >> > >> On Mon, Nov 18, 2019 at 6:30 PM Pavel Stehule > wrote: > >> >> > >> >> I'll send this test today > >> >

Re: backup manifests

Thank you Jeevan for reviewing the patch. On Thu, Nov 21, 2019 at 2:33 PM Jeevan Chalke < jeevan.cha...@enterprisedb.com> wrote: > > > On Tue, Nov 19, 2019 at 3:30 PM Rushabh Lathia > wrote: > >> >> >> My colleague Suraj did testing and noticed the performance impact >> with the checksums. On

Re: dropdb --force

On Fri, Nov 22, 2019 at 12:10 AM Pavel Stehule wrote: > > > > čt 21. 11. 2019 v 6:33 odesílatel vignesh C napsal: >> >> On Mon, Nov 18, 2019 at 6:30 PM Pavel Stehule >> wrote: >> >> >> >> I'll send this test today >> > >> > >> > here is it >> > >> >> Thanks for adding the test. >> Few comments:

Re: Why overhead of SPI is so large?

At Fri, 22 Nov 2019 08:08:24 +0100, Pavel Stehule wrote in > pá 22. 11. 2019 v 7:33 odesílatel Kyotaro Horiguchi > napsal: > > > At Fri, 22 Nov 2019 06:15:25 +0100, Pavel Stehule > > wrote in > > > čt 21. 11. 2019 v 20:44 odesílatel Tom Lane napsal: > > > > > > > Pavel Stehule writes: > > >

Re: [HACKERS] Block level parallel vacuum

On Wed, Nov 20, 2019 at 11:01 AM Masahiko Sawada wrote: > > I've attached the latest version patch set. The patch set includes all > discussed points regarding index AM options as well as shared cost > balance. Also I added some test cases used all types of index AM. > I have reviewed the first p

Re: TAP tests aren't using the magic words for Windows file access

On Fri, Nov 22, 2019 at 9:00 AM Michael Paquier wrote: > On Thu, Nov 21, 2019 at 08:09:38PM +0100, Juan José Santamaría Flecha > wrote: > > I think Perl's open() is a bad candidate for an overload, so I will > update > > the previous patch that only touches slurp_file(). > > FWIW, I don't like mu

Re: Why overhead of SPI is so large?

On 22.11.2019 11:05, Pavel Stehule wrote: We should to distinguish  between bad result and not well optimized plan. If it is not possible to implement runtime check tha timmutable function is not making any changes in database. Please notice, that even right now without any get snapshot opt

Re: add a MAC check for TRUNCATE

On Wed, Nov 20, 2019 at 02:30:12PM -0500, Joe Conway wrote: > I tested this successfully on Rhinoceros, both with and without > "db_table: { truncate }" loaded in the policy. Updated patches attached > here with some editorialization. If there are no objections I will > commit/push both in about a

Re: Why overhead of SPI is so large?

pá 22. 11. 2019 v 8:32 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 22.11.2019 10:08, Pavel Stehule wrote: > > > I test it, and there is a problem already. We doesn't raise a exception, > but the result is wrong > > > create table foo(a int); > > create or replace f

Re: TAP tests aren't using the magic words for Windows file access

On Thu, Nov 21, 2019 at 08:09:38PM +0100, Juan José Santamaría Flecha wrote: > I think Perl's open() is a bad candidate for an overload, so I will update > the previous patch that only touches slurp_file(). FWIW, I don't like much the approach of patching only slurp_file(). What gives us the guara