Re: pg_promote() can cause busy loop

On Thu, Sep 5, 2019 at 11:10 AM Michael Paquier wrote: > > On Thu, Sep 05, 2019 at 10:53:19AM +0900, Fujii Masao wrote: > > It's ok to use PG_RETURN_BOOL(false) instead of breaking out of the loop > > in that case. Which would make the code simpler. > > Okay. I would have done so FWIW. > > > But

Re: enhance SPI to support EXECUTE commands

čt 5. 9. 2019 v 8:39 odesílatel Quan Zongliang < zongliang.q...@postgresdata.com> napsal: > Dear hackers, > > I found that such a statement would get 0 in PL/pgSQL. > > PREPARE smt_del(int) AS DELETE FROM t1; > EXECUTE 'EXECUTE smt_del(100)'; > GET DIAGNOSTICS j = ROW_COUNT; > > In fact, this is a

Re: standby recovery fails (tablespace related) (tentative patch and discussion)

On Tue, Sep 3, 2019 at 11:58 PM Alvaro Herrera wrote: > On 2019-Aug-22, Anastasia Lubennikova wrote: > > > 22.08.2019 16:13, Paul Guo wrote: > > > Thanks. I updated the patch to v5. It passes install-check testing and > > > recovery testing. > > Hi, > > Thank you for working on this fix. > > The

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

Hi, On Thu, Sep 5, 2019 at 1:24 PM amul sul wrote: > On Wed, Sep 4, 2019 at 2:40 AM Alvaro Herrera > wrote: >> CFbot complains that Fujita-san submitted a patch that doesn't apply, >> which makes sense since the necessary previous patch was only referred >> to without being resubmitted. I sugg

Re: Plug-in common/logging.h with vacuumlo and oid2name

On Thu, Sep 05, 2019 at 08:59:41AM +0900, Michael Paquier wrote: > There is an argument to allow libpq to find out a service file for > a connection from the executable path. Note that oid2name can use a > connection string for connection, but not vacuumlo, so I somewhat > missed that. If you thi

Re: Two pg_rewind patches (auto generate recovery conf and ensure clean shutdown)

> > It seems there's minor breakage in the build, per CFbot. Can you > please rebase this? > > There is a code conflict. See attached for the new version. Thanks. v5-0001-Extact-common-functions-from-pg_basebackup-into-s.patch Description: Binary data v5-0002-Add-option-to-write-recovery-conf

Re: pg_promote() can cause busy loop

On Thu, Sep 05, 2019 at 04:03:22PM +0900, Fujii Masao wrote: > So, barring any objection, I will commit the attached patch. LGTM. Thanks! -- Michael signature.asc Description: PGP signature

Re: enhance SPI to support EXECUTE commands

On 2019/9/5 15:09, Pavel Stehule wrote: čt 5. 9. 2019 v 8:39 odesílatel Quan Zongliang > napsal: Dear hackers, I found that such a statement would get 0 in PL/pgSQL. PREPARE smt_del(int) AS DELETE FROM t1; EXECUTE 'EXECUTE smt_del(100

Re: unexpected rowlock mode when trigger is on the table

Thanks for response. > I think there should be no overlap (PK is column "id", not modified) The update command sets the detail_id column which has unique constraint. If I read documentation correctly (13.3.2. Row-level Locks), unique columns also count to columns whose presence in update stateme

Re: [HACKERS] [PATCH] pageinspect function to decode infomasks

On Thu, Sep 5, 2019 at 10:41 AM Michael Paquier wrote: > > On Wed, Sep 04, 2019 at 04:50:45PM -0400, Alvaro Herrera wrote: > > According to CFbot, the Windows build fails with this patch. Please > > fix. > > To save a couple of clicks: > "C:\projects\postgresql\pageinspect.vcxproj" (default targe

RE: [PATCH] Speedup truncates of relation forks

On Tuesday, September 3, 2019 9:44 PM (GMT+9), Fujii Masao wrote: > Thanks for the patch! Thank you as well for the review! > -smgrdounlinkfork(SMgrRelation reln, ForkNumber forknum, bool isRedo) > +smgrdounlinkfork(SMgrRelation reln, ForkNumber *forknum, int nforks, > bool isRedo) > > smgrdounl

Re: enhance SPI to support EXECUTE commands

On 2019/9/5 16:31, Pavel Stehule wrote: čt 5. 9. 2019 v 10:25 odesílatel Quan Zongliang > napsal: On 2019/9/5 15:09, Pavel Stehule wrote: > > > čt 5. 9. 2019 v 8:39 odesílatel Quan Zongliang > mailto:zongliang.q...@postgresdata.

Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?

On Thu, Sep 5, 2019 at 2:12 PM Amit Langote wrote: Thanks for the patch, I was almost about to press the send button with my patch. But, this looks similar to my version. > > On Wed, Sep 4, 2019 at 8:53 AM Tom Lane wrote: > > > > Amit Langote writes: > > > [ v2-0001-Use-root-parent-s-permissio

Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?

On Thu, Sep 5, 2019 at 2:48 PM Dilip Kumar wrote: > > On Thu, Sep 5, 2019 at 2:12 PM Amit Langote wrote: > > Thanks for the patch, I was almost about to press the send button with > my patch. But, this looks similar to my version. > > > > On Wed, Sep 4, 2019 at 8:53 AM Tom Lane wrote: > > Inst

Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?

Hi Dilip, Thanks for checking. On Thu, Sep 5, 2019 at 6:18 PM Dilip Kumar wrote: > On Thu, Sep 5, 2019 at 2:12 PM Amit Langote wrote: > Thanks for the patch, I was almost about to press the send button with > my patch. But, this looks similar to my version. Good to hear that. > > On Wed, Sep

Re: enhance SPI to support EXECUTE commands

čt 5. 9. 2019 v 10:57 odesílatel Quan Zongliang < zongliang.q...@postgresdata.com> napsal: > On 2019/9/5 16:31, Pavel Stehule wrote: > > > > > > čt 5. 9. 2019 v 10:25 odesílatel Quan Zongliang > > > > napsal: > > > > On 2019/9/5 15:09, Pavel Stehule wro

Specifying attribute slot for storing/reading statistics

Dear all We are developing MobilityDB, an open source PostgreSQL/PostGIS extension that provides temporal and spatio-temporal types. The source code, manuals, and related publications are available at the address https://github.com/ULB-CoDE-WIT/MobilityDB/

Re: enhance SPI to support EXECUTE commands

čt 5. 9. 2019 v 10:25 odesílatel Quan Zongliang < zongliang.q...@postgresdata.com> napsal: > On 2019/9/5 15:09, Pavel Stehule wrote: > > > > > > čt 5. 9. 2019 v 8:39 odesílatel Quan Zongliang > > > > napsal: > > > > Dear hackers, > > > > I found tha

Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?

On Wed, Sep 4, 2019 at 8:53 AM Tom Lane wrote: > > Amit Langote writes: > > [ v2-0001-Use-root-parent-s-permissions-when-read-child-tab.patch ] > > I took a quick look through this. I have some cosmetic thoughts and > also a couple of substantive concerns: Thanks a lot for reviewing this. > *

Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?

On Thu, Sep 5, 2019 at 6:33 PM Dilip Kumar wrote: > /* > + * For inheritance child relations, we also need to remember > + * the root parent. > + */ > + if (parent->rtekind == RTE_RELATION) > + rel->inh_root_relid = parent->inh_root_relid > 0 ? > + parent->inh_root_relid : > + parent->relid; > +

Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?

On Thu, Sep 5, 2019 at 3:26 PM Amit Langote wrote: > > On Thu, Sep 5, 2019 at 6:33 PM Dilip Kumar wrote: > > /* > > + * For inheritance child relations, we also need to remember > > + * the root parent. > > + */ > > + if (parent->rtekind == RTE_RELATION) > > + rel->inh_root_relid = parent->inh_

Re: BUG #15977: Inconsistent behavior in chained transactions

On 2019-09-04 16:49, fn ln wrote: > I made another patch for suggested behavior (COMMIT/ROLLBACK AND CHAIN > now gives us an error when used in an implicit block). I'm content with this patch. Better disable questionable cases now and maybe re-enable them later if someone wants to make a case for

Re: Plug-in common/logging.h with vacuumlo and oid2name

On 2019-09-05 01:59, Michael Paquier wrote: > On Wed, Sep 04, 2019 at 02:37:12PM +0200, Peter Eisentraut wrote: Do we need set_pglocale_pgservice() calls here if we're not doing NLS? Does the logging stuff require it? I'm not sure. >>> >>> The logging part does not require it, but this c

Re: Unexpected "shared memory block is still in use"

On 2019-09-04 16:59, Tom Lane wrote: >> A related point, perhaps we should change the key printed into >> postmaster.pid to be in hexadecimal format ("0x08x") so that it matches >> what ipcs prints. > Hmm, that depends on whose ipcs you use :-(. A quick survey > of my machines says it's > >

Re: Two pg_rewind patches (auto generate recovery conf and ensure clean shutdown)

Thank for rebasing. I didn't like 0001 very much. * It seems now would be the time to stop pretending we're using a file called recovery.conf; I know we still support older server versions that use that file, but it sounds like we should take the opportunity to rename the function to be less misl

Re: Plug-in common/logging.h with vacuumlo and oid2name

Patch looks good to me, please push. Generally speaking I find the 'progname' handling a bit silly (since we have it both as a variable in each program and also in logging.c separately), but that's not the fault of this patch, and this patch doesn't make it worse. That said, I think some other me

Re: unexpected rowlock mode when trigger is on the table

On 2019-Sep-05, Tomáš Záluský wrote: > Thanks for response. > > > I think there should be no overlap (PK is column "id", not modified) > > The update command sets the detail_id column which has unique constraint. Oh, I see, yeah that explains it. > What is unclear to me, why FOR NO KEY UPDATE

Re: SegFault on 9.6.14

On Mon, Sep 2, 2019 at 4:51 PM Amit Kapila wrote: > > On Fri, Aug 9, 2019 at 6:29 PM Robert Haas wrote: > > > > > > But beyond that, the issue here is that the Limit node is shutting > > down the Gather node too early, and the right fix must be to stop > > doing that, not to change the definition

Re: Specifying attribute slot for storing/reading statistics

Esteban Zimanyi writes: > We are developing the analyze/selectivity functions for those types. Our > approach is to use the standard PostgreSQL/PostGIS functions for the value > and the time dimensions where the slots starting from 0 will be used for > the value dimension, and the slots starting f

changing wal segsize with pg_resetwal

On 2019-Aug-28, Pavel Demidov wrote: > I hear that not recommended to set pg_resetwal with --wal-segsize for wal > increasing. Are any more detailed information exists about it? What an > effects could be? Does it possible change it due full offline? The manual contains a warning about it:

Re: [PATCH] Add support for ON UPDATE/DELETE actions on ALTER CONSTRAINT

Matheus, any replies to this? I've marked the patch as Waiting on Author for now. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [PATCH][PROPOSAL] Add enum releation option type

After looking closer once again, I don't like this patch. I think the FOOBAR_ENUM_DEF defines serve no purpose, other than source-code placement next to the enum value definitions. I think for example check_option, living in reloptions.c, should look like this: { {

Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?

Amit Langote writes: > On Thu, Sep 5, 2019 at 6:18 PM Dilip Kumar wrote: >> Instead of falling back to the child, isn't it make more sense to >> check the permissions on the parent upto which we could translate (it >> may not be the root parent)? > Hmm, in that case, the parent up to which we mi

Re: Proposal: roll pg_stat_statements into core

On 2019-Sep-02, Euler Taveira wrote: > At least if pg_stat_statements > was in core you could load it by default and have a GUC to turn it > on/off without restarting the server (that was Magnus proposal and > Andres agreed). I support this idea. Actually this is possible without moving to part o

Re: accounting for memory used for BufFile during hash joins

On Tue, Sep 3, 2019 at 9:36 AM Alvaro Herrera wrote: > On 2019-Jul-11, Tomas Vondra wrote: > > > On Wed, Jul 10, 2019 at 04:51:02PM -0700, Melanie Plageman wrote: > > > > I think implementing support for parallel hashjoin or explicitly > > > disabling it would be the bare minimum for this patch,

Re: range_agg

On Sun, 2019-09-01 at 06:26 -0700, Paul A Jungwirth wrote: > @+ and @- and @* (I dunno why but I kind of like it. We already have > @> and <@.) I think I like this proposal best; it reminds me of perl. Though some might say that's an argument against it. Regards, Jeff Davis

Re: [PATCH] Connection time for \conninfo

On Tue, Sep 3, 2019 at 11:06 PM Michael Paquier wrote: > > You can do basically the same thing by looking at > pg_stat_activity.backend_start and compare it with the clock > timestamp. Doing it at SQL level the way you want has also the > advantage to offer you a modular format output. Hi Michae

Re: [PATCH] Connection time for \conninfo

On Wed, Sep 4, 2019 at 11:04 AM Alvaro Herrera wrote: > > The only thing that seems wrong about this proposal is that the time > format is a bit too verbose. I would have it do "N days 12:23:34". > Hi Alvaro!, I attach a second version with this change. -- Rodrigo Ramírez Norambuena http://ww

Re: range_agg

On Thu, Sep 5, 2019 at 10:15 AM Jeff Davis wrote: > > On Sun, 2019-09-01 at 06:26 -0700, Paul A Jungwirth wrote: > > @+ and @- and @* (I dunno why but I kind of like it. We already have > > @> and <@.) > > I think I like this proposal best; it reminds me of perl. Though some > might say that's an

Re: basebackup.c's sendFile() ignores read errors

On Fri, Aug 30, 2019 at 7:05 AM Jeevan Ladhe wrote: >> Fixed both comments in the attached patch. > > Thanks, the patch looks good to me. Here's a version of the patch with a further change to the wording of the comment. I hope this is clearer. I think this needs to be back-patched all the way

Re: [PATCH] Connection time for \conninfo

=?UTF-8?Q?Rodrigo_Ram=C3=ADrez_Norambuena?= writes: > On Tue, Sep 3, 2019 at 11:06 PM Michael Paquier wrote: >> You can do basically the same thing by looking at >> pg_stat_activity.backend_start and compare it with the clock >> timestamp. Doing it at SQL level the way you want has also the >> a

Re: tableam vs. TOAST

On Thu, Sep 5, 2019 at 10:52 AM Alvaro Herrera wrote: > I agree, and can we move forward with this 0001? The idea here is to > change no code (as also suggested by Tom elsewhere), and it's the > largest patch in this series by a mile. I checked --color-moved=zebra > and I think the patch looks f

Re: range_agg

On Thu, 2019-09-05 at 10:45 -0700, Paul A Jungwirth wrote: > Right now I'm planning to do all that before sending a patch. I'm > happy to send something something in-progress too, but I don't want > to > waste any reviewers' time. If folks want an early peak though let me > know. (You can also find

AtEOXact_Snapshot timing

Way back in 2011, commit 57eb009092684e6e1788dd0dae641ccee1668b10 moved AbortTransaction's AtEOXact_Snapshot call to CleanupTransaction to fix a problem when a ROLLBACK statement was prepared at the protocol level and executed in a transaction with REPEATABLE READ or higher isolation. RevalidateCac

Re: tableam vs. TOAST

Hi, On 2019-09-05 13:42:40 -0400, Robert Haas wrote: > Done, thanks. Here's the rest again with the additional rename added > to 0003 (formerly 0004). I think it's probably OK to go ahead with > that stuff, too, but I'll wait a bit to see if anyone wants to raise > more objections. Well, I still

Re: [HACKERS] CLUSTER command progress monitor

On Wed, Sep 4, 2019 at 9:03 PM Michael Paquier wrote: > For CLUSTER, the progress starts and ends in cluster_rel(). CLUSTER > uses its code paths at the beginning, but then things get more > complicated, particularly with finish_heap_swap() which calls directly > reindex_table(). 6f97457 include

Re: tableam vs. TOAST

On Thu, Sep 5, 2019 at 3:10 PM Andres Freund wrote: > On 2019-09-05 13:42:40 -0400, Robert Haas wrote: > > Done, thanks. Here's the rest again with the additional rename added > > to 0003 (formerly 0004). I think it's probably OK to go ahead with > > that stuff, too, but I'll wait a bit to see if

Re: tableam vs. TOAST

Andres Freund writes: > Well, I still dislike making the toast chunk size configurable in a > halfhearted manner. It's hard to make it fully configurable without breaking our on-disk storage, because of the lack of any explicit representation of the chunk size in TOAST data. You have to "just kn

Re: Index Skip Scan

On 2019-Sep-05, Dmitry Dolgov wrote: > Here is the version in which stepping between the pages works better. It seems > sufficient to fix the case you've mentioned before, but for that we need to > propagate keepPrev logic through `_bt_steppage` & `_bt_readnextpage`, and I > can't say I like this

Re: add a MAC check for TRUNCATE

On Mon, Sep 2, 2019 at 10:58 AM Kohei KaiGai wrote: > > Hello Yuli, Hello KaiGai, > > 2019年7月25日(木) 3:52 Yuli Khodorkovskiy : > > Since all DAC checks should have corresponding MAC, this patch adds a > > hook to allow extensions to implement a MAC check on TRUNCATE. I have > > also implemented t

Re: tableam vs. TOAST

On Thu, Sep 5, 2019 at 3:36 PM Tom Lane wrote: > Andres Freund writes: > > Well, I still dislike making the toast chunk size configurable in a > > halfhearted manner. > > It's hard to make it fully configurable without breaking our on-disk > storage, because of the lack of any explicit representa

Re: tableam vs. TOAST

On 2019-09-05 15:27:28 -0400, Robert Haas wrote: > On Thu, Sep 5, 2019 at 3:10 PM Andres Freund wrote: > > On 2019-09-05 13:42:40 -0400, Robert Haas wrote: > > > Done, thanks. Here's the rest again with the additional rename added > > > to 0003 (formerly 0004). I think it's probably OK to go ahead

Re: ERROR: multixact X from before cutoff Y found to be still running

On 9/4/19, 9:03 PM, "Thomas Munro" wrote: > Both patches prevent mxactLimit from being newer than the oldest > running multixact. The v1 patch uses the most aggressive setting > possible: the oldest running multi; the v2 uses the least aggressive > of the 'safe' and oldest running multi. At firs

PostgreSQL 12 Beta 4

Hi, PostgreSQL 12 Beta 4 will be released on 2019-09-12. Please make sure that fixes for bugs and other open items[1] are committed by the end of the weekend. Thanks for all of your efforts in getting PostgreSQL 12 ready for general availability! Jonathan [1] https://wiki.postgresql.org/wiki/Po

Re: Index Skip Scan

> On Mon, Sep 2, 2019 at 3:28 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Wed, Aug 28, 2019 at 9:32 PM Floris Van Nee > > wrote: > > > > I'm afraid I did manage to find another incorrect query result though > > Yes, it's an example of what I was mentioning before, that the current >

Re: fix for BUG #3720: wrong results at using ltree

On 2019-Jul-09, Oleg Bartunov wrote: > On Mon, Jul 8, 2019 at 7:22 AM Thomas Munro wrote: > > > > On Sun, Apr 7, 2019 at 3:46 AM Tom Lane wrote: > > > In short, I'm wondering if we should treat this as a documentation > > > bug not a code bug. But to do that, we'd need a more accurate > > > de

Re: [Patch] Invalid permission check in pg_stats for functional indexes

Alvaro Herrera writes: > Hmm. This seems to create a large performance drop. Yeah. It's also flat out wrong for indexes that depend on whole-row variables. For that case, we really need to insist that the user have select privilege on all the table columns, but this won't accomplish that. It

Re: Misleading comment in tuplesort_set_bound

On 2019-Aug-26, Tom Lane wrote: > James Coleman writes: > I think the comment is fine as-is. Perhaps the code would be clearer > though, if we merged those two asserts into one? > > /* Assert we're called before loading any tuples */ > Assert(state->status == TSS_INITIAL && >

Re: Misleading comment in tuplesort_set_bound

Yes, planning on it, just a bit behind right now so will likely be a few more days at least. On Thu, Sep 5, 2019 at 4:57 PM Alvaro Herrera from 2ndQuadrant wrote: > > On 2019-Aug-26, Tom Lane wrote: > > > James Coleman writes: > > > I think the comment is fine as-is. Perhaps the code would be c

Re: BUG #15977: Inconsistent behavior in chained transactions

Hi, On 2019-09-05 14:16:11 +0200, Peter Eisentraut wrote: > On 2019-09-04 16:49, fn ln wrote: > > I made another patch for suggested behavior (COMMIT/ROLLBACK AND CHAIN > > now gives us an error when used in an implicit block). > > I'm content with this patch. Would need tests. > Better disab

Re: AtEOXact_Snapshot timing

Hi, On 2019-09-05 14:50:50 -0400, Robert Haas wrote: > The best way that I've been able to come up with to enforce this rule > after a little bit of thought is to add Assert(IsTransactionState()) > to a bunch of functions in snapmgr.c, most notably > GetTransactionSnapshot and GetCatalogSnapshot.

Re: ERROR: multixact X from before cutoff Y found to be still running

On Fri, Sep 6, 2019 at 6:32 AM Jeremy Schneider wrote: > It really appears that it was the autovacuum process itself that was > providing the oldest running multixact which caused errors on yesterday's > attempts to vacuum other tables - even though I though vacuum processes were > ignored by t

Re: Fix XML handling with DOCTYPE

Hi Alvaro, On 08/03/19 12:15, Alvaro Herrera wrote: >> I don't know if it's too late to get in the upcoming minor releases, >> but maybe it can, if it looks ok, or the next ones, if that's too rushed. > > Hmm, I'm travelling back home from a conference the weekend, so yeah I > think it would be

Re: libpq debug log

Hello, Nice patch. I think there's pretty near consensus that this is something we want, and that the output format of one trace msg per libpq msg is roughly okay. (I'm not sure there's 100% agreement on this last point, but it seems close enough.) > I changed like this: > > 2019-04-04 02:39:5

Re: FETCH FIRST clause PERCENT option

Surafel Temesgen writes: > [ percent-incremental-v8.patch ] I took a quick look through this. * Why is this adding new functionality in tuplestore.c? Especially functionality to get out a different tuple representation than what was put in? I can't see a reason why nodeLimit should need that,

Re: FETCH FIRST clause WITH TIES option

As Tom just said in the thread for PERCENT, the gram.y changes need a better representation. Also, rename EXACT_NUMBER, per that thread. As far as I can tell, this concerns feature F867. I think we should mark that as supported after this patch -- please edit src/backend/catalog/sql_features.txt

Re: [bug fix] Produce a crash dump before main() on Windows

On 2019-Jul-01, Tsunakawa, Takayuki wrote: > From: Amit Kapila [mailto:amit.kapil...@gmail.com] > > Tsunakawa/Haribabu - By reading this thread briefly, it seems we need > > some more inputs from other developers on whether to fix this or not, > > so ideally the status of this patch should be 'Nee

Re: Problem during Windows service start

On 2019-Jul-24, Kyotaro Horiguchi wrote: > > Please find the proposed patch for review. I will attach it to > > commitfest as well > > Pacemaker suffers the same thing. We suggest our customers that "start > server alone to perform recovery then start pacemaker if it is > expected to take a long

Re: enhance SPI to support EXECUTE commands

On 2019/9/5 17:33, Pavel Stehule wrote: čt 5. 9. 2019 v 10:57 odesílatel Quan Zongliang > napsal: On 2019/9/5 16:31, Pavel Stehule wrote: > > > čt 5. 9. 2019 v 10:25 odesílatel Quan Zongliang > mailto:zongliang.q...@postgresdata

Re: progress report for ANALYZE

Hi Alvaro, There were some minor problems in v5 -- bogus Docbook as well as outdated rules.out, small "git diff --check" complaint about whitespace. This v6 (on today's master) fixes those, no other changes. Thanks for fixing that. :) I'll test it later. I think we have to address the fol

Re: enhance SPI to support EXECUTE commands

pá 6. 9. 2019 v 3:36 odesílatel Quan Zongliang < zongliang.q...@postgresdata.com> napsal: > On 2019/9/5 17:33, Pavel Stehule wrote: > > > > > > čt 5. 9. 2019 v 10:57 odesílatel Quan Zongliang > > > > napsal: > > > > On 2019/9/5 16:31, Pavel Stehule wrot

Re: [bug fix] Produce a crash dump before main() on Windows

Alvaro Herrera from 2ndQuadrant writes: > Tsunakawa-san, there's been some discussion downthread. Could you > please submit an updated version of the patch? I would like to get it > pushed before beta4 next week, if possible. [ confused... ] I haven't been paying attention to this thread, but

Re: POC: Cleaning up orphaned files using undo logs

Hi Thomas, While testing one of the recovery scenarios I found one issue: FailedAssertion("!(logno == context->recovery_logno) The details of the same is mentioned below: The context's try_location was not updated in UndoLogAllocateInRecovery, in PrepareUndoInsert the try_location was updated wit

Re: REINDEX filtering in the backend

On Wed, Sep 04, 2019 at 01:54:53PM +0200, Peter Eisentraut wrote: > Right. We should aim to get per-object collation version tracking done. > And then we might want to have a REINDEX variant that processes exactly > those indexes with an out-of-date version number -- and then updates > that versi

Re: Plug-in common/logging.h with vacuumlo and oid2name

On Thu, Sep 05, 2019 at 09:59:51AM -0400, Alvaro Herrera wrote: > Patch looks good to me, please push. Thanks, applied without the calls to set_pglocale_pgservice(). > Generally speaking I find the 'progname' handling a bit silly (since we > have it both as a variable in each program and also in

Re: Avoiding hash join batch explosions with extreme skew and weird stats

On Wed, Jul 31, 2019 at 6:47 AM Melanie Plageman wrote: > So, I've rewritten the patch to use a BufFile for the outer table > batch file tuples' match statuses and write bytes to and from the file > which start as 0 and, upon encountering a match for a tuple, I set its > bit in the file to 1 (also

Re: pg_promote() can cause busy loop

On Thu, Sep 5, 2019 at 4:52 PM Michael Paquier wrote: > > On Thu, Sep 05, 2019 at 04:03:22PM +0900, Fujii Masao wrote: > > So, barring any objection, I will commit the attached patch. > > LGTM. Thanks! Committed. Thanks! Regards, -- Fujii Masao

Re: [HACKERS] CLUSTER command progress monitor

On Thu, Sep 05, 2019 at 03:17:51PM -0400, Robert Haas wrote: > Oops. Yeah, that's bogus (as are some of the other things you > mention). I think we're going to have to fix this by passing down > some flags to these functions to tell them what kind of progress > updates to do (or to do none). Or

Re: [HACKERS] CLUSTER command progress monitor

On Fri, Sep 06, 2019 at 02:44:18PM +0900, Michael Paquier wrote: > I don't see exactly why we could not switch to a fixed number of > slots, say 8, with one code path to start a progress which adds an > extra report on the stack, one to remove one entry from the stack, and > a new one to reset the

Re: [bug fix] Produce a crash dump before main() on Windows

On Thu, Sep 05, 2019 at 11:49:03PM -0400, Tom Lane wrote: > Alvaro Herrera from 2ndQuadrant writes: >> Tsunakawa-san, there's been some discussion downthread. Could you >> please submit an updated version of the patch? I would like to get it >> pushed before beta4 next week, if possible. > > [

Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?

On Fri, Sep 6, 2019 at 12:53 AM Tom Lane wrote: > > Amit Langote writes: > > On Thu, Sep 5, 2019 at 6:18 PM Dilip Kumar wrote: > >> Instead of falling back to the child, isn't it make more sense to > >> check the permissions on the parent upto which we could translate (it > >> may not be the roo

Re: basebackup.c's sendFile() ignores read errors

On Thu, Sep 5, 2019 at 11:40 PM Robert Haas wrote: > On Fri, Aug 30, 2019 at 7:05 AM Jeevan Ladhe > wrote: > >> Fixed both comments in the attached patch. > > > > Thanks, the patch looks good to me. > > Here's a version of the patch with a further change to the wording of > the comment. I hope

Re: amcheck verification for GiST

Hi! > 4 сент. 2019 г., в 2:13, Alvaro Herrera написал(а): > > On 2019-Mar-29, Andrey Borodin wrote: > >> Here's updated patch with AccessShareLock. >> I've tried to stress this with combination of random inserts, vaccuums and >> checks. This process neither failed, nor deadlocked. >> The patch

RE: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

-Original Message- From: Masahiko Sawada Sent: Thursday, 15 August 2019 7:10 PM > BTW I've created PoC patch for cluster encryption feature. Attached patch set > has done some items of TODO list and some of them can be used even for finer > granularity encryption. Anyway, the implement