Re: Physical replication slot advance is not persistent

On Mon, Jan 20, 2020 at 11:00:14AM -0800, Andres Freund wrote: > On 2020-01-20 15:45:40 +0900, Michael Paquier wrote: >> 1) The slot advancing has to mark the slot as dirty, but should we >> make the change persistent at the end of the function or should we >> wait for a checkpoint to do the work,

Re: Greatest Common Divisor

On 20/01/2020 08:44, Dean Rasheed wrote: > On Tue, 7 Jan 2020 at 12:31, Tom Lane wrote: >> Dean Rasheed writes: >>> Do we actually need the smallint versions of these functions? >> Doubt it. It'd be fairly hard even to call those, since e.g. "42" >> is an int not a smallint. >> > I see this has

Re: Error message inconsistency

Hi Amit, On Tue, 21 Jan 2020 at 10:49, Amit Kapila wrote: > On Thu, Jan 9, 2020 at 5:42 PM MBeena Emerson > wrote: > > > > Hi Beena, > > It is better to reply inline. > > > Hi Mahendra, > > > > Thanks for the patch. > > I am not sure but maybe the relation name should also be added to the >

Re: Increase psql's password buffer size

On 2020/01/21 4:21, David Fetter wrote: On Mon, Jan 20, 2020 at 07:44:25PM +0100, David Fetter wrote: On Mon, Jan 20, 2020 at 01:12:35PM -0500, Tom Lane wrote: David Fetter writes: At least two cloud providers are now stuffing large amounts of information into the password field. This

Re: [Proposal] Global temporary tables

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)) + { + get_gtt_relstats(RelationGetRelid(rel), + , , , + NULL, NULL); + } + else + { + /* coerce values in pg_class to

Re: closesocket behavior in different platforms

On Fri, Dec 6, 2019 at 11:24 AM vignesh C wrote: > > It is noticed that in all the 4 cases the message "FATAL: terminating > connection due to administrator command" does not appear in windows. > > However the following message is present in the server log file: > FATAL: terminating connection

Re: [HACKERS] Block level parallel vacuum

Hi, On 2020-01-20 09:09:35 +0530, Amit Kapila wrote: > Pushed, after fixing these two comments. When attempting to vacuum a large table I just got: postgres=# vacuum FREEZE ; ERROR: invalid memory alloc request size 1073741828 #0 palloc (size=1073741828) at

TODO: Allow a stalled COPY to exit if the backend is terminated

In TODO wiki: https://wiki.postgresql.org/wiki/TODO - Allow a stalled COPY to exit if the backend is terminated Re: possible bug not in open items https://www.postgresql.org/message-id/flat/200904091648.n39GmMJ07139%40momjian.us#d86f9ba37b4b34d3931c7152a028fe45 Hasn't this been fixed?

Re: error context for vacuum to include block number

On Tue, 21 Jan 2020 at 06:49, Justin Pryzby wrote: > > On Mon, Jan 20, 2020 at 11:11:20AM -0800, Andres Freund wrote: > > This I do not get. I didn't yet fully wake up, so I might just be slow? > > It was needlessly cute at the cost of clarity (meant to avoid setting > error_context_stack in

RE: SLRU statistics

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, but this seems > more convenient. Understood. I'm in favor of adding

Minor issues in .pgpass

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 larger than 319B, libpq silently treats each 319B in the line as a

Re: [HACKERS] Block level parallel vacuum

On Tue, Jan 21, 2020 at 11:30 AM Andres Freund wrote: > > Hi, > > On 2020-01-20 09:09:35 +0530, Amit Kapila wrote: > > Pushed, after fixing these two comments. > > When attempting to vacuum a large table I just got: > > postgres=# vacuum FREEZE ; > ERROR: invalid memory alloc request size

Re: TRUNCATE on foreign tables

On Mon, Jan 20, 2020 at 10:50:21PM +0900, Michael Paquier wrote: > I have spent a good amount of time polishing 0001, tweaking the docs, > comments, error messages and a bit its logic. I am getting > comfortable with it, but it still needs an extra lookup, an indent run > which has some noise and

Re: [HACKERS] Block level parallel vacuum

On Tue, 21 Jan 2020 at 15:35, Amit Kapila wrote: > > On Tue, Jan 21, 2020 at 11:30 AM Andres Freund wrote: > > > > Hi, > > > > On 2020-01-20 09:09:35 +0530, Amit Kapila wrote: > > > Pushed, after fixing these two comments. > > > > When attempting to vacuum a large table I just got: > > > >

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

On 2020/01/21 13:39, Michael Paquier wrote: On Tue, Jan 21, 2020 at 08:45:14AM +0530, Amit Kapila wrote: The original email doesn't say so. I might be missing something, but can you explain what makes you think so. Oops. Incorrect thread, I was thinking about this one previously:

Re: Physical replication slot advance is not persistent

((On Tue, 21 Jan 2020 at 11:06, Michael Paquier wrote: > > The replication interface should not immediately flush changes to the > > slot replay position on advance. It should be marked dirty and left to > > be flushed by the next checkpoint. Doing otherwise potentially > > introduces a lot of

Re: pg13 PGDLLIMPORT list

On Tue, 21 Jan 2020 at 12:49, Michael Paquier wrote: > > On Tue, Jan 21, 2020 at 08:34:05AM +0530, Amit Kapila wrote: > > As such no objection, but I am not sure if the other person need it on > > back branches as well. Are you planning to commit this, or if you > > want I can take care of it? >

Re: [HACKERS] Block level parallel vacuum

On Tue, Jan 21, 2020 at 12:11 PM Masahiko Sawada wrote: > > On Tue, 21 Jan 2020 at 15:35, Amit Kapila wrote: > > > > On Tue, Jan 21, 2020 at 11:30 AM Andres Freund wrote: > > > > > > Hi, > > > > > > On 2020-01-20 09:09:35 +0530, Amit Kapila wrote: > > > > Pushed, after fixing these two

Re: [HACKERS] Block level parallel vacuum

On Tue, 21 Jan 2020 at 16:13, Amit Kapila wrote: > > On Tue, Jan 21, 2020 at 12:11 PM Masahiko Sawada > wrote: > > > > On Tue, 21 Jan 2020 at 15:35, Amit Kapila wrote: > > > > > > On Tue, Jan 21, 2020 at 11:30 AM Andres Freund wrote: > > > > > > > > Hi, > > > > > > > > On 2020-01-20 09:09:35

Re: aggregate crash

Hi, On 2020-01-15 19:16:30 -0800, Andres Freund wrote: > The bug, in a way, exists all the way back, but it's a bit harder to > create NULL values where the datum component isn't 0. > To fix I suggest we, in all branches, do the equivalent of adding > something like: > diff --git

Re: [PATCH] Resolve Parallel Hash Join Performance Issue

(Replies to both Gang and Tom below). On Fri, Jan 10, 2020 at 1:52 PM Deng, Gang wrote: > Thank you for the comment. Yes, I agree the alternative of using > '(!parallel)', so that no need to test the bit. Will someone submit patch to > for it accordingly? Here's a patch like that. On Fri,

Re: Error message inconsistency

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 > > wrote: > > > > > > Do we have an actual patch here? > > > > > > > We have a patch, but it needs some more work like finding

Re: Error message inconsistency

On Thu, Jan 9, 2020 at 5:42 PM MBeena Emerson wrote: > Hi Beena, It is better to reply inline. > Hi Mahendra, > > Thanks for the patch. > I am not sure but maybe the relation name should also be added to the > following test case? > > create table t4 (id int); > insert into t4 values (1); >

Re: Option to dump foreign data in pg_dump

On Mon, Jan 20, 2020 at 8:34 PM Luis Carril wrote: > > > Hi Vignesh, > >yes you are right I could reproduce it also with 'file_fdw'. The issue is > that LOCK is not supported on foreign tables, so I guess that the safest > solution is to make the --include-foreign-data incompatible with

Re: Allow 'sslkey' and 'sslcert' in postgres_fdw user mappings

On Fri, 10 Jan 2020 at 06:16, Andrew Dunstan wrote: > On Fri, Jan 10, 2020 at 8:32 AM Tom Lane wrote: > > > > Andrew Dunstan writes: > > > On Fri, Jan 10, 2020 at 1:21 AM Robert Haas > wrote: > > >> I share the concern about the security issue here. I can't testify to > > >> whether

Re: Improve errors when setting incorrect bounds for SSL protocols

On 2020-01-15 03:28, Michael Paquier wrote: Good points. And the get routines are not that portable in OpenSSL either even if HEAD supports 1.0.1 and newer versions... Attached is an updated patch which uses a GUC check for both parameters, and provides a hint on top of the original error

Re: Crash in BRIN summarization

On 2020-Jan-20, Heikki Linnakangas wrote: > Sorry, forgot all about it. Pushed now. Thank you! -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Greatest Common Divisor

Looking at the docs, I think it's worth going a little further than just saying what the acronyms stand for -- especially since the behaviour for zero inputs is an implementation choice (albeit the most common one). I propose the following: + +greatest common divisor the largest

Re: Remove page-read callback from XLogReaderState.

Thanks! At Fri, 17 Jan 2020 20:14:36 +0200, Heikki Linnakangas wrote in > On 29/11/2019 10:14, Kyotaro Horiguchi wrote: > > At Thu, 28 Nov 2019 21:37:03 +0900 (JST), Kyotaro Horiguchi > > wrote in > 0dc8ead463 hit this. Rebased. > >>> > >>> Please review the pg_waldump.c hunks in 0001;

Re: Add support for automatically updating Unicode derived files

On 2020-01-15 01:37, Tom Lane wrote: Peter Eisentraut writes: Committed, thanks. This patch is making src/tools/pginclude/headerscheck unhappy: ./src/include/common/unicode_combining_table.h:3: error: array type has incomplete element type I guess that header needs another #include, or

Re: pgsql: Allow 'sslkey' and 'sslcert' in postgres_fdw user mappings

On 1/20/20 2:48 AM, Craig Ringer wrote: > On Thu, 9 Jan 2020 at 22:38, Christoph Berg > wrote: > > Re: Robert Haas 2020-01-09 > > > > Does this mean that a non-superuser can induce postgres_fdw to > read an > >

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

On Sat, Jan 18, 2020 at 9:18 AM Michael Paquier wrote: > > On Fri, Jan 17, 2020 at 07:36:51PM +0900, Fujii Masao wrote: > > So, what about > > > > --- > > causes the system to ignore invalid page references in WAL records > > (but still report a warning), and continue the recovery. >

Re: Crash in BRIN summarization

On 17/01/2020 23:35, Alvaro Herrera wrote: On 2019-Aug-28, Heikki Linnakangas wrote: I bumped into a little bug in BRIN, while hacking on something unrelated. This causes a segfault, or an assertion failure if assertions are enabled: Heikki, I just noticed that you haven't pushed this

Re: Making psql error out on output failures

David Zhang wrote: > Yes, I agree with you. For case 2 "select repeat('111', 100) \g > /mnt/ramdisk/file", it can be easily fixed with more accurate error > message similar to pg_dump, one example could be something like below. > But for case 1 "psql -d postgres -At -c "select

Re: SLRU statistics

On 2020-Jan-20, 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 is a WIP > >

Re: Increase psql's password buffer size

Alexander Kukushkin writes: > I think I should add my two cents. > We at Zalando are using JWT tokens as passwords. JWT tokens are > self-contained and therefore quite huge (up to 700-800 bytes in our > case). Tokens have a limited lifetime (1 hour) and we are using PAM to > verify them. >

Re: SLRU statistics

On Mon, Jan 20, 2020 at 03:01:36PM -0300, Alvaro Herrera wrote: On 2020-Jan-20, 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

Re: error context for vacuum to include block number

Hi, On 2019-12-12 21:08:31 -0600, Justin Pryzby wrote: > On Wed, Dec 11, 2019 at 12:33:53PM -0300, Alvaro Herrera wrote: > On Wed, Dec 11, 2019 at 08:54:25AM -0800, Andres Freund wrote: > > Hm, wonder if could be worthwhile to not use a separate struct here, but > > instead extend one of the

Re: Online checksums patch - once again

On Sat, Jan 18, 2020 at 6:18 PM Daniel Gustafsson wrote: > Thanks again for reviewing (and working on the infrastructure required for > this > patch to begin with)! Regarding the persisting the progress; that would be a > really neat feature but I don't have any suggestion on how to do that

Re: Greatest Common Divisor

On Mon, 20 Jan 2020 at 18:52, Vik Fearing wrote: > > On 20/01/2020 11:28, Dean Rasheed wrote: > > > > + > > +least common multiple the smallest strictly positive number > > +that is an integer multiple of both inputs; returns > > 0 > > +if either input is zero > >

Re: Greatest Common Divisor

On 20/01/2020 11:28, Dean Rasheed wrote: > Looking at the docs, I think it's worth going a little further than > just saying what the acronyms stand for -- especially since the > behaviour for zero inputs is an implementation choice (albeit the most > common one). I propose the following: > > +

Re: Greatest Common Divisor

On 2020-Jan-20, Dean Rasheed wrote: > + > +greatest common divisor the largest positive number that > +divides both inputs with no remainder; returns 0 > if > +both inputs are zero > + Warning, severe TOC/bikeshedding ahead. I don't know why, but this

Re: [HACKERS] kqueue

I wrote: > Peter Eisentraut writes: >> I took this patch for a quick spin on macOS. The result was that the >> test suite hangs in the test src/test/recovery/t/017_shm.pl. I didn't >> see any mentions of this anywhere in the thread, but that test is newer >> than the beginning of this

Re: Increase psql's password buffer size

On Mon, Jan 20, 2020 at 07:44:25PM +0100, David Fetter wrote: > On Mon, Jan 20, 2020 at 01:12:35PM -0500, Tom Lane wrote: > > David Fetter writes: > > > At least two cloud providers are now stuffing large amounts of > > > information into the password field. This change makes it possible to > > >

libxml2 is dropping xml2-config

Debian reports that libxml2 is dropping the xml2-config binary: Date: Mon, 20 Jan 2020 20:42:47 +0100 From: Mattia Rizzolo Reply-To: Mattia Rizzolo , 949...@bugs.debian.org Subject: Bug#949428: postgresql-12: FTBFS with libxml2 2.9.10 (uses xml2-config) Source: postgresql-12 Version: 12.1-2

Re: libxml2 is dropping xml2-config

Re: To PostgreSQL Hackers 2020-01-20 <20200120204715.ga73...@msg.df7cb.de> > Debian reports that libxml2 is dropping the xml2-config binary: Please disregard that, I had assumed this was a change made by libxml2 upstream. I'm in contact with the libxml2 Debian maintainer to get that change off

Increase psql's password buffer size

Folks, At least two cloud providers are now stuffing large amounts of information into the password field. This change makes it possible to accommodate that usage in interactive sessions. Best, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider

Re: Increase psql's password buffer size

David Fetter writes: > At least two cloud providers are now stuffing large amounts of > information into the password field. This change makes it possible to > accommodate that usage in interactive sessions. Like who? It seems like a completely silly idea. And if 2K is sane, why not much more?

Re: [HACKERS] kqueue

On Tue, Jan 21, 2020 at 2:34 AM Peter Eisentraut wrote: > I took this patch for a quick spin on macOS. The result was that the > test suite hangs in the test src/test/recovery/t/017_shm.pl. I didn't > see any mentions of this anywhere in the thread, but that test is newer > than the beginning

Re: Increase psql's password buffer size

On Mon, Jan 20, 2020 at 01:12:35PM -0500, Tom Lane wrote: > David Fetter writes: > > At least two cloud providers are now stuffing large amounts of > > information into the password field. This change makes it possible to > > accommodate that usage in interactive sessions. > > Like who? AWS and

Re: Index Skip Scan

Hi Floris, On 1/15/20 8:33 AM, Floris Van Nee wrote: I reviewed the latest version of the patch. Overall some good improvements I think. Please find my feedback below. Thanks for your review ! - I think I mentioned this before - it's not that big of a deal, but it just looks weird and

Re: Physical replication slot advance is not persistent

Hi, On 2020-01-20 15:45:40 +0900, Michael Paquier wrote: > On Thu, Jan 16, 2020 at 08:09:09PM +0300, Alexey Kondratov wrote: > > OK, I have definitely overthought that, thanks. This looks like a minimal > > subset of changes that actually solves the bug. I would only prefer to keep > > some

Re: Increase psql's password buffer size

Hi, I think I should add my two cents. On Mon, 20 Jan 2020 at 20:38, Tom Lane wrote: > > > I found another place that assumes 100 bytes and upped it to 2048. There one more place, in the code which is parsing .pgpass > > So this is pretty much exactly what I expected. And have you tried > it

Re: Greatest Common Divisor

On Mon, 20 Jan 2020 at 19:04, Alvaro Herrera wrote: > > On 2020-Jan-20, Dean Rasheed wrote: > > > + > > +greatest common divisor the largest positive number that > > +divides both inputs with no remainder; returns > > 0 if > > +both inputs are zero > > + >

Re: Add limit option to copy function

=?UTF-8?B?6rmA64yA7Zi4?= writes: > I suggest adding a limit option to the copy function that limits count of > input/output. > I think this will be useful for testing with sample data. I'm quite skeptical of the value of this. On the output side, you can already do it with COPY (SELECT ...

BRIN cost estimate breaks geometric indexes

Hi, Found out today that BRIN indexes don't really work for PostGIS and box datatypes. Since https://github.com/postgres/postgres/commit/7e534adcdc70866e7be74d626b0ed067c890a251 Postgres requires datatype to provide correlation statistics. Such statistics wasn't provided by PostGIS and box

Re: error context for vacuum to include block number

Hi, On 2020-01-19 23:41:59 -0600, Justin Pryzby wrote: > /* > + * Return whether skipping blocks or not. > + * Except when aggressive is set, we want to skip pages that are > + * all-visible according to the visibility map, but only when we can skip > + * at least SKIP_PAGES_THRESHOLD

Re: Increase psql's password buffer size

David Fetter writes: > On Mon, Jan 20, 2020 at 07:44:25PM +0100, David Fetter wrote: >> On Mon, Jan 20, 2020 at 01:12:35PM -0500, Tom Lane wrote: >>> (I can't say that s/100/2048/ in one place is a particularly evil >>> change; what bothers me is the likelihood that there are other >>> places

Re: Index Skip Scan

On Mon, Jan 20, 2020 at 11:01 AM Jesper Pedersen wrote: > > - nbtsearch.c _bt_skip line 1440 > > if (BTScanPosIsValid(so->currPos) && > > _bt_scankey_within_page(scan, so->skipScanKey, > > so->currPos.buf, dir)) > > > > Is it allowed to look at the high key / low key of the page

Re: [HACKERS] kqueue

On 2019-12-20 01:26, Thomas Munro wrote: It's still my intention to get this committed eventually, but I got a bit frazzled by conflicting reports on several operating systems. For FreeBSD, performance was improved in many cases, but there were also some regressions that seemed to be related to

Re: [HACKERS] kqueue

Thomas Munro writes: > [ 0001-Add-kqueue-2-support-for-WaitEventSet-v13.patch ] I haven't read this patch in any detail, but a couple quick notes: * It needs to be rebased over the removal of pg_config.h.win32 --- it should be touching Solution.pm instead, I believe. * I'm disturbed by the

Re: Physical replication slot advance is not persistent

On 20 Jan 2020, 09:45 +0300, Michael Paquier , wrote: > > So, I have been looking at this patch by myself, and updated it so as > the extra slot save is done only if any advancing has been done, on > top of the other computations that had better be around for > consistency. The patch includes TAP

Re: [HACKERS] kqueue

Peter Eisentraut writes: > I took this patch for a quick spin on macOS. The result was that the > test suite hangs in the test src/test/recovery/t/017_shm.pl. I didn't > see any mentions of this anywhere in the thread, but that test is newer > than the beginning of this thread. Can anyone

Re: TRUNCATE on foreign tables

On Mon, Jan 20, 2020 at 11:30:34AM +0900, Kohei KaiGai wrote: > Sorry, it was a midnight job on Friday. Should I be, err, worried about that? ;) > Please check the attached patch. + switch (behavior) + { + case DROP_RESTRICT: + appendStringInfoString(buf, " RESTRICT"); +

Re: Add support for automatically updating Unicode derived files

Peter Eisentraut writes: > On 2020-01-15 01:37, Tom Lane wrote: >> This patch is making src/tools/pginclude/headerscheck unhappy: >> ./src/include/common/unicode_combining_table.h:3: error: array type has >> incomplete element type > Hmm, this file is only meant to be included inside one

Re: Option to dump foreign data in pg_dump

On Tue, Jan 14, 2020 at 5:22 PM Luis Carril mailto:luis.car...@swarm64.com>> wrote: Can you have a look at dump with parallel option. Parallel option will take a lock on table while invoking lockTableForWorker. May be this is not required for foreign tables. Thoughts? I tried with -j and found no

Re: SLRU statistics

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 is a WIP version of a patch adding that. How can users take

Re: error context for vacuum to include block number

On Mon, Jan 20, 2020 at 11:11:20AM -0800, Andres Freund wrote: > This I do not get. I didn't yet fully wake up, so I might just be slow? It was needlessly cute at the cost of clarity (meant to avoid setting error_context_stack in lazy_scan_heap and again immediately on its return). On Mon, Jan

Re: Physical replication slot advance is not persistent

On Tue, Jan 21, 2020 at 09:44:12AM +0800, Craig Ringer wrote: > PLEASE do not make the streaming replication interface force flushes! Yeah, that's a bad idea. FWIW, my understanding is that this has been only proposed in v3, and this has been discarded:

Re: Physical replication slot advance is not persistent

Thanks for looking this. At Mon, 20 Jan 2020 11:00:14 -0800, Andres Freund wrote in > > Here is a summary of the points raised (please correct me if that > > does not sound right to you, Andres): > > > 1) The slot advancing has to mark the slot as dirty, but should we > > make the change

Re: libxml2 is dropping xml2-config

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: > Please disregard that, I had assumed this was a change made by libxml2 > upstream. I'm in contact with the libxml2 Debian

Re: Minimal logical decoding on standbys

On Fri, 17 Jan 2020 at 13:20, Andreas Joseph Krogh wrote: > > På torsdag 16. januar 2020 kl. 05:42:24, skrev Amit Khandekar > : > > On Fri, 10 Jan 2020 at 17:50, Rahila Syed wrote: > > > > Hi Amit, > > > > Can you please rebase the patches as they don't apply on latest master? > > Thanks for

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

On Tue, Jan 21, 2020 at 6:05 AM Michael Paquier wrote: > > On Mon, Jan 20, 2020 at 02:13:53PM +0530, Amit Kapila wrote: > > Are we planning to do something about the original problem reported in > > this thread? > > We should. This is on my TODO list, though seeing that it involved >

Re: pg13 PGDLLIMPORT list

On Tue, Jan 21, 2020 at 08:34:05AM +0530, Amit Kapila wrote: > As such no objection, but I am not sure if the other person need it on > back branches as well. Are you planning to commit this, or if you > want I can take care of it? Thanks for the reminder. Done now. I have also switched the

Re: Decade indication

On Fri, 17 Jan 2020 at 17:52, Bruce Momjian wrote: > I assume there is enough agreement that decades start on 20X0 that we > don't need to document that Postgres does that. > I think the inconsistency between years, decades, centuries, and millenia is worthy of documentation. In fact, it

Re: Increase psql's password buffer size

On Mon, Jan 20, 2020 at 09:17:47PM +0100, Alexander Kukushkin wrote: > Hi, > > I think I should add my two cents. > > On Mon, 20 Jan 2020 at 20:38, Tom Lane wrote: > > > > > I found another place that assumes 100 bytes and upped it to 2048. > > There one more place, in the code which is

Re: pg13 PGDLLIMPORT list

On Sat, Jan 18, 2020 at 3:19 PM Michael Paquier wrote: > > On Sat, Jan 18, 2020 at 09:19:19AM +0200, Julien Rouhaud wrote: > > On Sat, 18 Jan 2020, 09:04 Amit Kapila >> +1 for adding PGDLLIMPORT to these variables. In the past, we have > >> added it on the request of some extension authors, so

Re: Minimal logical decoding on standbys

På tirsdag 21. januar 2020 kl. 03:57:42, skrev Amit Khandekar < amitdkhan...@gmail.com >: [...] Sorry for the late reply. This patch only supports logical decoding from standby. So it's just an infrastructure for supporting logical replication from standby. We

Re: BRIN cost estimate breaks geometric indexes

On 21.01.2020 0:00, Darafei "Komяpa" Praliaskouski wrote: Hi, Found out today that BRIN indexes don't really work for PostGIS and box datatypes. Since https://github.com/postgres/postgres/commit/7e534adcdc70866e7be74d626b0ed067c890a251 Postgres requires datatype to provide correlation

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

On Mon, Jan 20, 2020 at 02:13:53PM +0530, Amit Kapila wrote: > Are we planning to do something about the original problem reported in > this thread? We should. This is on my TODO list, though seeing that it involved full_page_writes=off I drifted a bit away from it. -- Michael signature.asc

Re: [HACKERS] kqueue

On Tue, Jan 21, 2020 at 8:03 AM Tom Lane wrote: > I observe very similar behavior on FreeBSD/amd64 12.0-RELEASE-p12, > so it's not just macOS. Thanks for testing. Fixed by handling the new exit_on_postmaster_death flag from commit cfdf4dc4. On Tue, Jan 21, 2020 at 5:55 AM Tom Lane wrote: >

Re: Index Skip Scan

On Mon, Jan 20, 2020 at 1:19 PM Peter Geoghegan wrote: > On Mon, Jan 20, 2020 at 11:01 AM Jesper Pedersen > wrote: > > > - nbtsearch.c _bt_skip line 1440 > > > if (BTScanPosIsValid(so->currPos) && > > > _bt_scankey_within_page(scan, so->skipScanKey, > > > so->currPos.buf, dir)) >

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

On Tue, Jan 21, 2020 at 08:45:14AM +0530, Amit Kapila wrote: > The original email doesn't say so. I might be missing something, but > can you explain what makes you think so. Oops. Incorrect thread, I was thinking about this one previously:

Re: Rearranging ALTER TABLE to avoid multi-operations bugs

I wrote: > The squirrely-ness around identity is that while this now works: > regression=# CREATE TABLE itest8 (f1 int); > CREATE TABLE > regression=# ALTER TABLE itest8 > regression-# ADD COLUMN f2 int NOT NULL, > regression-# ALTER COLUMN f2 ADD GENERATED ALWAYS AS IDENTITY; > ALTER TABLE

Reducing WaitEventSet syscall churn

Hi, Here are some patches to get rid of frequent system calls. 0001 changes all qualifying WaitLatch() calls to use a new function WaitMyLatch() that reuses a common WaitEventSet. That's for callers that only want to wait for their own latch or an optional timeout, with automatic

Re: Physical replication slot advance is not persistent

On Fri, 17 Jan 2020 at 01:09, Alexey Kondratov wrote: > > > I think we shouldn't touch the paths used by replication protocol. And > > don't we focus on how we make a change of a replication slot from SQL > > interface persistent? It seems to me that generaly we don't need to > > save dirty