Re: Error message inconsistency

On Tue, 21 Jan 2020 at 10:51, Amit Kapila wrote: > > On Mon, Jan 6, 2020 at 6:31 PM Mahendra Singh Thalor wrote: > > > > On Sat, 6 Jul 2019 at 09:53, Amit Kapila wrote: > > > > > > On Mon, Jul 1, 2019 at 10:05 PM Alvaro Herrera < alvhe...@2ndquadrant.com> wrote: > > > > > > > > Do we have an

Re: table partitioning and access privileges

Fujii-san, Thanks for taking a look. On Fri, Jan 10, 2020 at 10:29 AM Fujii Masao wrote: > On Tue, Jan 7, 2020 at 5:15 PM Amit Langote wrote: > > I tend to agree that TRUNCATE's permission model for inheritance > > should be consistent with that for the other commands. How about the > >

RE: Index Skip Scan

> > Could you please elaborate why does it sound like that? If I understand > correctly, to stop a scan only "between" pages one need to use only > _bt_readpage/_bt_steppage? Other than that there is no magic with scan > position in the patch, so I'm not sure if I'm missing something here.

Re: Error message inconsistency

On Tue, 21 Jan 2020 at 20:09, Alvaro Herrera wrote: > > On 2020-Jan-21, MBeena Emerson wrote: > > > The usage of the function errtableconstraint seems only to set the > > schema_name table_name constraint_name internally and not for display > > purposes. As seen in the following two cases where

Re: [HACKERS] Block level parallel vacuum

On Wed, 22 Jan 2020 at 11:23, Amit Kapila wrote: > > On Wed, Jan 22, 2020 at 7:14 AM Masahiko Sawada > wrote: > > > > Thank you for updating the patch. Yeah MAXDEADTUPLES is better than > > what I did in the previous version patch. > > > > Would you like to resubmit your vacuumdb utility patch

Re: Do we need to handle orphaned prepared transactions in the server?

> First and foremost is to define what an orphaned transaction is. At > this stage, I believe any prepared transaction that has been there > for more than X time may be considered as an orphan. X may be defined > as an integer in seconds (a GUC perhaps). May be there are better > ways to define

Re: ssl passphrase callback

On Sun, Dec 8, 2019 at 9:02 AM Tom Lane wrote: > > Andrew Dunstan writes: > > Well that pretty much brings us back to the patch as submitted :-) > > Yeah, pretty nearly. Taking a quick look over the v3 patch, my > only quibble is that it doesn't provide any convenient way for the > external

Do we need to handle orphaned prepared transactions in the server?

Hello Everyone, I have been thinking about the orphaned prepared transaction problem in PostgreSQL and pondering on ways for handling it. A prepared transaction can be left unfinished (neither committed nor rollbacked) if the client has disappeared. It can happen for various reasons including a

Re: [Proposal] Global temporary tables

st 22. 1. 2020 v 7:16 odesílatel 曾文旌(义从) napsal: > > > 2020年1月22日 上午2:51，Pavel Stehule 写道： > > > > út 21. 1. 2020 v 9:46 odesílatel 曾文旌(义从) > napsal: > >> >> >> 2020年1月12日 上午4:27，Pavel Stehule 写道： >> >> Hi >> >> so 11. 1. 2020 v 15:00 odesílatel 曾文旌(义从) >> napsal: >> >>> Hi all >>> >>> This

Re: Errors when update a view with conditional-INSTEAD rules

> I am wondering whether a simple auto-updatable view can have a > conditional update instead rule. > > Well, the decision reached in [1] was that we wouldn't allow that. We > could decide to allow it now as a new feature enhancement, but it > wouldn't be a back-patchable bug-fix, and to be honest

Re: FETCH FIRST clause WITH TIES option

On Thu, Nov 28, 2019 at 5:49 PM Alvaro Herrera wrote: > On 2019-Nov-28, Surafel Temesgen wrote: > > > On Thu, Nov 28, 2019 at 12:36 AM Alvaro Herrera < > alvhe...@2ndquadrant.com> > > wrote: > > > > > I think you should add a /* fall-though */ comment after changing > state. > > > Like this

RE: VACUUM memory management

Hi Ibrar, Are you still working on this patch? Currently the patch does not apply mainly because of recent commits for parallel vacuum have updated the files in this patch. Kindly rebase it and change the status to "Needs Review" after. Upon quick scan of another thread [1] mentioned above, I

Re: [Proposal] Global temporary tables

> 2020年1月22日 上午2:51，Pavel Stehule 写道： > > > > út 21. 1. 2020 v 9:46 odesílatel 曾文旌(义从) > napsal: > > >> 2020年1月12日 上午4:27，Pavel Stehule > > 写道： >> >> Hi >> >> so 11. 1. 2020 v 15:00 odesílatel 曾文旌(义从) >

Re: [PATCH] Windows port, fix some resources leaks

On Tue, Jan 21, 2020 at 11:01:07AM -0300, Ranier Vilela wrote: > Done. I would recommend that you also run all the regression tests present in the source before sending a patch. If you don't know how to do that, there is some documentation on the matter:

Re: progress report for ANALYZE

On Wed, Jan 22, 2020 at 2:52 PM Amit Langote wrote: > > On Fri, Jan 17, 2020 at 12:19 AM Justin Pryzby wrote: > > > > On Wed, Jan 15, 2020 at 02:11:10PM -0300, Alvaro Herrera wrote: > > > I just pushed this after some small extra tweaks. > > > > > > Thanks, Yamada-san, for seeing this to

Re: pgsql: walreceiver uses a temporary replication slot by default

Hi Peter, (Adding Andres and Sergei in CC.) On Tue, Jan 14, 2020 at 01:57:34PM +, Peter Eisentraut wrote: > walreceiver uses a temporary replication slot by default > > If no permanent replication slot is configured using > primary_slot_name, the walreceiver now creates and uses a temporary

Re: progress report for ANALYZE

On Fri, Jan 17, 2020 at 12:19 AM Justin Pryzby wrote: > > On Wed, Jan 15, 2020 at 02:11:10PM -0300, Alvaro Herrera wrote: > > I just pushed this after some small extra tweaks. > > > > Thanks, Yamada-san, for seeing this to completion! > > Find attached minor fixes to docs - sorry I didn't look

Re: Protect syscache from bloating with negative cache entries

At Tue, 21 Jan 2020 17:29:47 +0100, Tomas Vondra wrote in > I see this patch is stuck in WoA since 2019/12/01, although there's a > new patch version from 2020/01/14. But the patch seems to no longer > apply, at least according to https://commitfest.cputube.org :-( So at > this point the status

Re: adding partitioned tables to publications

Hi Peter , Thanks for the review and sorry it took me a while to get back. On Wed, Jan 8, 2020 at 7:54 PM Peter Eisentraut wrote: > Looking through 0001, I think perhaps there is a better way to structure > some of the API changes. > > Instead of passing the root_target_rel to

Re: vacuum verbose detail logs are unclear; log at *start* of each stage; show allvisible/frozen/hintbits

On Tue, Jan 21, 2020 at 07:49:34AM -0600, Justin Pryzby wrote: > Rebased against 40d964ec997f64227bc0ff5e058dc4a5770a70a9 > I added to March CF https://commitfest.postgresql.org/27/2425/ Please be careful with the sets of patches sent to a thread, just to say that what you are sending is

Re: [Proposal] Global temporary tables

> 2020年1月21日 下午1:43，Pavel Stehule 写道： > > Hi > > I have a free time this evening, so I will check this patch > > I have a one question > > + /* global temp table get relstats from localhash */ > + if (RELATION_IS_GLOBAL_TEMP(rel)) > + { > +

Re: allow online change primary_conninfo

On Tue, Jan 21, 2020 at 06:03:18PM +0300, Sergei Kornilov wrote: > PS: also, I surprised why it's ok for wal_receiver_create_temp_slot > to be PGC_SIGHUP and ignore change of this setting until walreceiver > will reconnect by unrelated reason. I means walreceiver does nothing > special on SIGHUP.

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Sat, Jan 4, 2020 at 4:07 PM Amit Kapila wrote: > Update on the open items > As per my understanding apart from the above comments, the known > pending work for this patchset is as follows: > a. The two open items agreed to you in the email [3]. -> The first part is > done and the second part

Re: We're getting close to the end of 2020-01 CF

On Tue, Jan 21, 2020 at 05:20:17PM +0100, Tomas Vondra wrote: > Yeah, you're right returning them with feedback seems more appropriate, > given the long inactivity. Plus, the CF app apparently does not allow > moving WoA patches to the next CF anyway. FWIW, I tend to take a base of two weeks as a

Re: Protect syscache from bloating with negative cache entries

On Tue, Jan 21, 2020 at 02:17:53PM -0500, Tom Lane wrote: > Alvaro Herrera writes: >> Hmm ... travis is running -Werror? That seems overly strict. I think >> we shouldn't punt a patch because of that. > > Why not? We're not going to allow pushing a patch that throws warnings > on common

Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM

On Tue, Jan 21, 2020 at 09:21:46PM +, Bossart, Nathan wrote: > I've attached a patch for a couple of new options for VACUUM: > MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP. The motive > behind these options is to allow table owners to easily vacuum only > the TOAST table or only the

Re: doc: alter table references bogus table-specific planner parameters

On Tue, Jan 21, 2020 at 07:27:47PM -0600, Justin Pryzby wrote: > Attached minimal patch with just this hunk. > > https://commitfest.postgresql.org/27/2417/ > => RFC I think that you should be more careful when you think that you create a new thread. On my client for example, I can see that this

Re: PATCH: standby crashed when replay block which truncated in standby but failed to truncate in master node

On 2020/01/18 12:48, Michael Paquier wrote: On Fri, Jan 17, 2020 at 07:36:51PM +0900, Fujii Masao wrote: On Fri, Jan 17, 2020 at 1:47 PM Michael Paquier wrote: Thanks. I have few tweaks to propose to the docs. +raise a PANIC-level error, aborting the recovery. Setting Instead of

Re: Protect syscache from bloating with negative cache entries

Hello. At Tue, 21 Jan 2020 14:17:53 -0500, Tom Lane wrote in > Alvaro Herrera writes: > > On 2020-Jan-21, Tomas Vondra wrote: > >> Not sure about the appveyor build (it seems to be about jsonb_set_lax), > > FWIW, I think I fixed jsonb_set_lax yesterday, so that problem should > be gone the

RE: Complete data erasure

Hello Stephen, Thank you for comment. From: Stephen Frost > Greetings, > > * asaba.takan...@fujitsu.com (asaba.takan...@fujitsu.com) wrote: > > This feature erases data area just before it is returned to the OS (“erase” > means that overwrite data area to hide its contents here) > > because

Re: [HACKERS] Block level parallel vacuum

On Wed, Jan 22, 2020 at 7:14 AM Masahiko Sawada wrote: > > Thank you for updating the patch. Yeah MAXDEADTUPLES is better than > what I did in the previous version patch. > Would you like to resubmit your vacuumdb utility patch for this enhancement? I see some old version of it and it seems to

Re: error context for vacuum to include block number

On 2020-Jan-21, Justin Pryzby wrote: > And I knew that, so (re)tested that the extracted patches would apply, but it > looks like maybe the patch checker is less smart (or more strict) than git, so > it didn't work after all. Honestly, I think we should be scared of a patch applier that ignored

Re: [HACKERS] Block level parallel vacuum

On Wed, Jan 22, 2020 at 7:14 AM Masahiko Sawada wrote: > > On Tue, 21 Jan 2020 at 18:16, Amit Kapila wrote: > > > > > > I have reproduced the issue by defining MaxAllocSize as 1024 and > > then during debugging, skipped the check related to LAZY_ALLOC_TUPLES. > > After patch, it fixes the

Re: Increase psql's password buffer size

On 2020/01/22 9:41, David Fetter wrote: On Tue, Jan 21, 2020 at 07:05:47PM +0100, David Fetter wrote: On Tue, Jan 21, 2020 at 10:23:59AM -0500, Bruce Momjian wrote: On Tue, Jan 21, 2020 at 04:19:13PM +0100, David Fetter wrote: On Tue, Jan 21, 2020 at 10:12:52AM -0500, Bruce Momjian wrote:

Re: Increase psql's password buffer size

On 2020/01/22 0:12, Bruce Momjian wrote: On Tue, Jan 21, 2020 at 02:42:07PM +0900, Fujii Masao wrote: I have no strong opinion about the maximum length of password, for now. But IMO it's worth committing that 0001 patch as the first step for this problem. Also IMO the more problematic thing

Re: progress report for ANALYZE

Hi Alvaro and All reviewers, On 2020/01/16 2:11, Alvaro Herrera wrote: I just pushed this after some small extra tweaks. Thanks, Yamada-san, for seeing this to completion! Thanks for reviewing and committing the patch! Hope this helps DBA. :-D P.S. Next up is progress reporting for query

Re: [HACKERS] Block level parallel vacuum

On Tue, 21 Jan 2020 at 18:16, Amit Kapila wrote: > > On Tue, Jan 21, 2020 at 12:51 PM Masahiko Sawada > wrote: > > > > On Tue, 21 Jan 2020 at 16:13, Amit Kapila wrote: > > > > > > SizeOfLVDeadTuplesHeader is not defined by patch. Do you think it > > > makes sense to add a comment here about

Re: doc: alter table references bogus table-specific planner parameters

On Mon, Jan 06, 2020 at 04:33:46AM +, Simon Riggs wrote: > On Mon, 6 Jan 2020 at 04:13, Justin Pryzby wrote: > > > I agree with the sentiment of the third doc change, but your patch removes > > > the mention of n_distinct, which isn't appropriate. > > > > I think it's correct to remove

Re: error context for vacuum to include block number

On Tue, Jan 21, 2020 at 05:54:59PM -0300, Alvaro Herrera wrote: > > On Tue, Jan 21, 2020 at 03:11:35PM +0900, Masahiko Sawada wrote: > > > Some of them conflicts with the current HEAD(62c9b52231). Please rebase > > > them. > > > > Sorry, it's due to other vacuum patch in this branch. > > > >

Re: Patch to document base64 encoding

On Sat, 18 Jan 2020 18:05:49 -0500 Tom Lane wrote: > And there were some errors; notably, the patch added descriptions > for shaNNN(text), which are functions we do not have AFAICS. Apologies for that, my mistake. Thank you to Fabien and everybody who helped. Regards, Karl Free Software:

Re: Increase psql's password buffer size

On Tue, Jan 21, 2020 at 07:05:47PM +0100, David Fetter wrote: > On Tue, Jan 21, 2020 at 10:23:59AM -0500, Bruce Momjian wrote: > > On Tue, Jan 21, 2020 at 04:19:13PM +0100, David Fetter wrote: > > > On Tue, Jan 21, 2020 at 10:12:52AM -0500, Bruce Momjian wrote: > > > > I think we should be using a

Re: making the backend's json parser work in frontend code

On Tue, Jan 21, 2020 at 5:34 PM David Steele wrote: > Though, throw_a_json_error() is not my favorite name. Perhaps > json_ereport()? That name was deliberately chosen to be dumb, with the thought that readers would understand it was to be replaced at some point before this was final. It sounds

Re: Minor issues in .pgpass

On Tue, Jan 21, 2020 at 03:27:50PM +0900, Fujii Masao wrote: > Hi, > > When I was researching the maximum length of password in PostgreSQL > to answer the question from my customer, I found that there are two > minor issues in .pgpass file. > > (1) If the length of a line in .pgpass file is

Re: proposal: schema variables

Hi, I did a quick review of this patch today, so let me share a couple of comments. Firstly, the patch is pretty large - it has ~270kB. Not the largest patch ever, but large. I think breaking the patch into smaller pieces would significantly improve the chnce of it getting committed. Is it

Re: Allow to_date() and to_timestamp() to accept localized names

=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?= writes: > [ 0001-Allow-localized-month-names-to_date-v6.patch ] I took a quick look through this. One thing I completely don't understand is why it's sufficient for seq_search_localized to do "initcap" semantics. Shouldn't it cover the

Re: Psql patch to show access methods info

On 2020-Jan-21, Alvaro Herrera wrote: > c) it would be damn handy if \dAf (maybe \dAf+) lists the datatypes that >each opfamily has opclasses for. Maybe make the output an array, like >{int4,int8,numeric,...} Something like [*] but somehow make it >prettier? Sorry, I forgot to

Re: making the backend's json parser work in frontend code

Hi Robert, On 1/17/20 2:33 PM, Robert Haas wrote: > On Fri, Jan 17, 2020 at 12:36 PM David Steele wrote: > >> I used the callbacks because that's the first method I found but it >> seems like json_lex() might be easier to use in practice. > > Ugh, really? That doesn't seem like it would be

Re: Psql patch to show access methods info

I think I would like this feature to be in, but I'm not sure that the shape is final yet. My points: a) I don't see any use for \dA as presented; I think the \dA+ output is useful. Therefore my preference would be that \dA presents what the latest patch has as \dA+. I think we should

Re: Minor issues in .pgpass

> On 21 Jan 2020, at 07:27, Fujii Masao wrote: > For (2), libpq should treat any lines beginning with # as comments. I haven't read the code to confirm that it really isn't, but +1 on making it so. I can't see a reason for allowing a hostname to start with #, but allowing comments does seem

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

Hi, Michael! Thank you for your review! The revised patch is attached. On Sun, Jan 19, 2020 at 1:24 PM Michael Paquier wrote: > On Sat, Jan 18, 2020 at 06:21:22PM +0300, Alexander Korotkov wrote: > > I made some minor cleanup. In particular, I've to fix usage of terms > > "WAL" and "WALs".

Re: Removing pg_pltemplate and creating "trustable" extensions

On Tue, Jan 21, 2020 at 12:40 PM Tom Lane wrote: > Given the lack of consensus about either of those being what we want, > it doesn't seem like we're going to come to an agreement in a > reasonable timeframe on a patch that includes either. So I'd like > to get this done and move on to the next

Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM

On 21/01/2020 22:21, Bossart, Nathan wrote: > I've attached a patch for a couple of new options for VACUUM: > MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP. The motive > behind these options is to allow table owners to easily vacuum only > the TOAST table or only the main relation. This

Re: error context for vacuum to include block number

On 2020-Jan-21, Justin Pryzby wrote: > On Tue, Jan 21, 2020 at 03:11:35PM +0900, Masahiko Sawada wrote: > > Some of them conflicts with the current HEAD(62c9b52231). Please rebase > > them. > > Sorry, it's due to other vacuum patch in this branch. > > New patches won't conflict, except for the

Re: error context for vacuum to include block number

On Tue, Jan 21, 2020 at 03:11:35PM +0900, Masahiko Sawada wrote: > Some of them conflicts with the current HEAD(62c9b52231). Please rebase them. Sorry, it's due to other vacuum patch in this branch. New patches won't conflict, except for the 0005, so I renamed it for cfbot. If it's deemed to be

Re: Protect syscache from bloating with negative cache entries

Alvaro Herrera writes: > On 2020-Jan-21, Tomas Vondra wrote: >> Not sure about the appveyor build (it seems to be about jsonb_set_lax), FWIW, I think I fixed jsonb_set_lax yesterday, so that problem should be gone the next time the cfbot tries this. >> but on travis it fails like this: >>

Re: Ltree syntax improvement

Dmitry Belyavsky writes: > If the C part will be reviewed and considered mergeable, I'll update the > plpython tests. I haven't looked at any of the code involved in this, but I did examine the "failing" plpython test, and I'm quite distressed about that change of behavior. Simply removing the

Re: [Proposal] Global temporary tables

út 21. 1. 2020 v 9:46 odesílatel 曾文旌(义从) napsal: > > > 2020年1月12日 上午4:27，Pavel Stehule 写道： > > Hi > > so 11. 1. 2020 v 15:00 odesílatel 曾文旌(义从) > napsal: > >> Hi all >> >> This is the latest patch >> >> The updates are as follows: >> 1. Support global temp Inherit table global temp partition

Re: Protect syscache from bloating with negative cache entries

On 2020-Jan-21, Tomas Vondra wrote: > Not sure about the appveyor build (it seems to be about jsonb_set_lax), > but on travis it fails like this: > > catcache.c:820:1: error: no previous prototype for > ‘CatalogCacheFlushCatalog2’ [-Werror=missing-prototypes] Hmm ... travis is running

Re: Increase psql's password buffer size

On Tue, Jan 21, 2020 at 10:23:59AM -0500, Bruce Momjian wrote: > On Tue, Jan 21, 2020 at 04:19:13PM +0100, David Fetter wrote: > > On Tue, Jan 21, 2020 at 10:12:52AM -0500, Bruce Momjian wrote: > > > I think we should be using a macro to define the maximum length, rather > > > than have 100 used

Re: Removing pg_pltemplate and creating "trustable" extensions

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> The patch as I'm proposing it has nothing to do with "CREATE" rights. >> You're attacking something different from what I actually want to do. > Yes, as an aside, I'm argueing that we should split up the general > CREATE

Re: Ltree syntax improvement

Dear Tomas, If the C part will be reviewed and considered mergeable, I'll update the plpython tests. On Mon, Jan 6, 2020 at 4:49 PM Tomas Vondra wrote: > Hi, > > This patch got mostly ignored since 2019-07 commitfest :-( The latest > patch (sent by Nikita) does not apply because of a minor

Re: Index Skip Scan

Hi Peter, Thanks for your feedback; Dmitry has followed-up with some additional questions. On 1/20/20 8:05 PM, Peter Geoghegan wrote: This is definitely not okay. I suggest that you find a way to add assertions to code like _bt_readpage() that verify that we do in fact have the buffer

Re: libxml2 is dropping xml2-config

On 1/20/20 5:51 PM, Tom Lane wrote: Christoph Berg writes: Re: To PostgreSQL Hackers 2020-01-20 <20200120204715.ga73...@msg.df7cb.de> Debian reports that libxml2 is dropping the xml2-config binary: Perhaps. Are there any platforms where libxml2 doesn't install a pkg-config file? What are

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Tue, Jan 14, 2020 at 10:56:37AM +0530, Dilip Kumar wrote: On Sat, Jan 11, 2020 at 3:07 AM Alvaro Herrera wrote: On 2020-Jan-10, Alvaro Herrera wrote: > Here's a rebase of this patch series. I didn't change anything except ... this time with attachments ... The patch set fails to apply

Re: Protect syscache from bloating with negative cache entries

Hello Kyotaro-san, I see this patch is stuck in WoA since 2019/12/01, although there's a new patch version from 2020/01/14. But the patch seems to no longer apply, at least according to https://commitfest.cputube.org :-( So at this point the status is actually correct. Not sure about the

Re: We're getting close to the end of 2020-01 CF

On Tue, Jan 21, 2020 at 12:25:14PM -0300, Alvaro Herrera wrote: On 2020-Jan-21, Tomas Vondra wrote: About half of the WoA patches are inactive for a long time, i.e. have been marked like that before 2020-01 (and sometimes long before that) and there have been no substantive updates. The chance

Re: Index Skip Scan

> On Mon, Jan 20, 2020 at 01:19:30PM -0800, Peter Geoghegan wrote: Thanks for the commentaries. I'm trying to clarify your conclusions for myself, so couple of questions. > > > - nbtsearch.c in general > > > Most of the code seems to rely quite heavily on the fact that > > > xs_want_itup forces

Re: We're getting close to the end of 2020-01 CF

On 2020-Jan-21, Tomas Vondra wrote: > About half of the WoA patches are inactive for a long time, i.e. have > been marked like that before 2020-01 (and sometimes long before that) > and there have been no substantive updates. The chance of that changing > (i.e. getting a new patch version and a

Re: Increase psql's password buffer size

On Tue, Jan 21, 2020 at 04:19:13PM +0100, David Fetter wrote: > On Tue, Jan 21, 2020 at 10:12:52AM -0500, Bruce Momjian wrote: > > I think we should be using a macro to define the maximum length, rather > > than have 100 used in various places. > > It's not just 100 in some places. It's different

Re: Increase psql's password buffer size

On Tue, Jan 21, 2020 at 10:12:52AM -0500, Bruce Momjian wrote: > On Tue, Jan 21, 2020 at 02:42:07PM +0900, Fujii Masao wrote: > > I have no strong opinion about the maximum length of password, > > for now. But IMO it's worth committing that 0001 patch as the first step > > for this problem. > > >

Re: Increase psql's password buffer size

On Tue, Jan 21, 2020 at 02:42:07PM +0900, Fujii Masao wrote: > I have no strong opinion about the maximum length of password, > for now. But IMO it's worth committing that 0001 patch as the first step > for this problem. > > Also IMO the more problematic thing is that psql silently truncates >

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Jan 21, 2020 at 9:58 AM Tomas Vondra wrote: > > On Tue, Jan 21, 2020 at 09:37:01AM -0500, James Coleman wrote: > >On Tue, Jan 21, 2020 at 9:25 AM Tomas Vondra > > wrote: > >> > >> Hi, > >> > >> This patch has been marked as WoA since end of November, and there has > >> been no

Re: allow online change primary_conninfo

Hello "Waiting on Author" is the right status. I found logical conflict with recently added wal_receiver_create_temp_slot GUC and my tests are currently broken. Will fix it and post new version. PS: also, I surprised why it's ok for wal_receiver_create_temp_slot to be PGC_SIGHUP and ignore

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Jan 21, 2020 at 09:37:01AM -0500, James Coleman wrote: On Tue, Jan 21, 2020 at 9:25 AM Tomas Vondra wrote: Hi, This patch has been marked as WoA since end of November, and there has been no discussion/reviews since then :-( Based on off-list discussion with James I don't think that's

We're getting close to the end of 2020-01 CF

Hi, We're about 10 days from the end of the 2020-01 CF. The current status of the CF is this: - Needs review: 118 - Waiting on Author: 42 - Ready for Committer: 10 - Committed: 36 - Moved to next CF: 3 - Returned with Feedback: 1 - Rejected: 3 - Withdrawn: 2 About half of the WoA

Re: Error message inconsistency

On 2020-Jan-21, MBeena Emerson wrote: > The usage of the function errtableconstraint seems only to set the > schema_name table_name constraint_name internally and not for display > purposes. As seen in the following two cases where the relation name is > displayed using RelationGetRelationName

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Jan 21, 2020 at 9:25 AM Tomas Vondra wrote: > > Hi, > > This patch has been marked as WoA since end of November, and there has > been no discussion/reviews since then :-( Based on off-list discussion > with James I don't think that's going to change in this CF, so I'll move > it to the

Re: allow online change primary_conninfo

Hi, I'm a bit confused by the status of this patch - it's marked as Waiting on Author (since last week), but that status was set by Sergei Kornilov who is also the patch author. And there have been no messages since the beginning of 2019-11 CF. So what's the current status of this patch?

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

Hi, This patch has been marked as WoA since end of November, and there has been no discussion/reviews since then :-( Based on off-list discussion with James I don't think that's going to change in this CF, so I'll move it to the next CF. I plan to work on the planner part of this patch before

Re: [PATCH] Windows port, fix some resources leaks

Em ter., 21 de jan. de 2020 às 06:18, Juan José Santamaría Flecha < juanjo.santama...@gmail.com> escreveu: > Some of the code this patch touches is not windows port only, so the > subject might be misleading reviewers. > True. Some leaks occurs at other platforms. > It will be easier to review

Re: SLRU statistics

On Tue, Jan 21, 2020 at 06:24:29AM +, tsunakawa.ta...@fujitsu.com wrote: From: Tomas Vondra You're right the users can't really take advantage of this - my primary motivation was providing a feedback for devs, benchmarking etc. That might have been done with DEBUG messages or something,

Re: SLRU statistics

On Tue, Jan 21, 2020 at 05:09:33PM +0900, Masahiko Sawada wrote: On Tue, 21 Jan 2020 at 01:38, Tomas Vondra wrote: On Mon, Jan 20, 2020 at 01:04:33AM +, tsunakawa.ta...@fujitsu.com wrote: >From: Tomas Vondra >> One of the stats I occasionally wanted to know are stats for the SLRU >>

Re: vacuum verbose detail logs are unclear; log at *start* of each stage; show allvisible/frozen/hintbits

Rebased against 40d964ec997f64227bc0ff5e058dc4a5770a70a9 I added to March CF https://commitfest.postgresql.org/27/2425/ >From 83407b81dfc1ed2dfaa6f115dc6c4a276efb07fc Mon Sep 17 00:00:00 2001 From: Justin Pryzby Date: Wed, 27 Nov 2019 20:07:10 -0600 Subject: [PATCH v2 1/6] Rename buf to avoid

Re: Replication & recovery_min_apply_delay

Replay lag can build up naturally, even when recovery_min_apply_delay is not set, because WAL generation on master is concurrent and WAL replay on standby is performed by a single process. Hao and I have incorporated the new GUC from Konstantin's patch and used it to start WAL receiver in the

Re: Remove page-read callback from XLogReaderState.

On Tue, 21 Jan 2020 at 18:46, Kyotaro Horiguchi wrote: > > Hello. > > At Mon, 20 Jan 2020 17:24:07 +0900 (JST), Kyotaro Horiguchi > wrote in > > Separating XLogBeginRead seems reasonable. The annoying recptr trick > > is no longer needed. In particular some logical-decoding stuff become > >

Re: Remove page-read callback from XLogReaderState.

Hello. At Mon, 20 Jan 2020 17:24:07 +0900 (JST), Kyotaro Horiguchi wrote in > Separating XLogBeginRead seems reasonable. The annoying recptr trick > is no longer needed. In particular some logical-decoding stuff become > far cleaner by the patch. > > fetching_ckpt of ReadRecord is a bit

Re: Planning counters in pg_stat_statements (using pgss_store)

Hi, On Sat, Jan 18, 2020 at 6:14 PM legrand legrand wrote: > > Hi Julien, > > bot is still unhappy > https://travis-ci.org/postgresql-cfbot/postgresql/builds/638701399 > > portalcmds.c: In function ‘PerformCursorOpen’: > portalcmds.c:93:7: error: ‘queryString’ may be used uninitialized in this >

Re: Index Skip Scan

> On Mon, Jan 20, 2020 at 05:05:33PM -0800, Peter Geoghegan wrote: > > I suggest that you find a way to add assertions to code like > _bt_readpage() that verify that we do in fact have the buffer content > lock. Actually, there is an existing assertion here that covers the > pin, but not the

Re: [HACKERS] kqueue

Hi, On 21/01/2020 02:06, Thomas Munro wrote: > [1] > https://www.postgresql.org/message-id/CA%2BhUKGJAC4Oqao%3DqforhNey20J8CiG2R%3DoBPqvfR0vOJrFysGw%40mail.gmail.com I had a NetBSD 8.0 VM lying around and I gave the patch a spin on latest master. With the kqueue patch, a pgbench -c basically

Re: [HACKERS] WAL logging problem in 9.4.3?

Thank you for the comment. At Sat, 18 Jan 2020 19:51:39 -0800, Noah Misch wrote in > On Tue, Jan 14, 2020 at 07:35:22PM +0900, Kyotaro Horiguchi wrote: > > At Thu, 26 Dec 2019 12:46:39 +0900 (JST), Kyotaro Horiguchi > > wrote in > > > At Wed, 25 Dec 2019 16:15:21 -0800, Noah Misch wrote >

Re: Option to dump foreign data in pg_dump

Yes we can support --include-foreign-data without parallel option and later add support for parallel option as a different patch. Hi, I've attached a new version of the patch in which an error is emitted if the parallel backup is used with the --include-foreign-data option. Cheers Luis

Re: [HACKERS] Block level parallel vacuum

On Tue, Jan 21, 2020 at 2:46 PM Amit Kapila wrote: > > On Tue, Jan 21, 2020 at 12:51 PM Masahiko Sawada > wrote: > > > > On Tue, 21 Jan 2020 at 16:13, Amit Kapila wrote: > > > > > > SizeOfLVDeadTuplesHeader is not defined by patch. Do you think it > > > makes sense to add a comment here about

Re: [PATCH] Windows port, fix some resources leaks

On Sun, Jan 19, 2020 at 9:49 PM Ranier Vilela wrote: > > Continuing the process of improving windows port, I'm trying to fix some > leaks. > > Some of the code this patch touches is not windows port only, so the subject might be misleading reviewers. It will be easier to review if you break

Re: [HACKERS] Block level parallel vacuum

On Tue, Jan 21, 2020 at 12:51 PM Masahiko Sawada wrote: > > On Tue, 21 Jan 2020 at 16:13, Amit Kapila wrote: > > > > SizeOfLVDeadTuplesHeader is not defined by patch. Do you think it > > makes sense to add a comment here about the calculation? > > Oops, it should be SizeOfLVDeadTuples. Attached

Re: Duplicate Workers entries in some EXPLAIN plans

TEXT format was tricky due to its inconsistencies, but I think I have something working reasonably well. I added a simple test for TEXT format output as well, using a similar approach as the JSON format test, and liberally regexp_replacing away any volatile output. I suppose in theory we could do

Re: SLRU statistics

On Tue, 21 Jan 2020 at 01:38, Tomas Vondra wrote: > > On Mon, Jan 20, 2020 at 01:04:33AM +, tsunakawa.ta...@fujitsu.com wrote: > >From: Tomas Vondra > >> One of the stats I occasionally wanted to know are stats for the SLRU > >> stats (we have couple of those - clog, subtrans, ...). So here