Re: REINDEX CONCURRENTLY 2.0

On Mon, Apr 01, 2019 at 03:43:43PM +0900, Michael Paquier wrote: > And I would have expected concur_reindex_part1v1_c1_idx to still be > part of the partition tree. I think that the issue is in > index_concurrently_create_copy() where we create the new index with > index_create() without setting p

Re: Status of the table access method work

On 08/04/2019 19:38, Andres Freund wrote: On 2019-04-08 14:53:53 +0300, Heikki Linnakangas wrote: On 05/04/2019 23:25, Andres Freund wrote: - the (optional) bitmap heap scan API - that's fairly intrinsically block based. An AM could just internally subdivide TIDs in a different way, but

Re: ToDo: show size of partitioned table

On 2019/04/09 2:37, Alvaro Herrera wrote: > On 2019-Apr-08, Amit Langote wrote: > >> I noticed that the size shown in the output of both \dP+ and \dPt+ does >> include toast relation sizes of (leaf) partitions, because >> pg_table_size(), which is used by all the queries that >> listPartitionedTab

RE: libpq debug log

Hi, I update patch to improve PQtrace(); output log message in one line. Please find my attached patch. How it changed: > > The basic idea being: > > > > - Each line is a whole message. > > - The line begins with <<< for a message received and >>> for a message > sent. > > - Strings in single quo

Re: [PATCH] Implement uuid_version()

On 2019-04-08 23:06, Andres Freund wrote: > The randomness based UUID generators don't really have dependencies, now > that we have a dependency on strong randomness. I kinda thing the > dependency argument actually works *against* uuid-ossp - precisely > because of its dependencies (which also va

Re: Sparse bit set data structure

On 09/04/2019 03:45, Alvaro Herrera wrote: On 2019-Apr-08, Bruce Momjian wrote: Uh, should this be applied? Yes, it's a pretty obvious typo methinks. Pushed, thanks, and sorry for the delay. - Heikki

Re: "could not reattach to shared memory" on buildfarm member dory

On Sun, Apr 07, 2019 at 12:43:23AM -0400, Tom Lane wrote: > Noah Misch writes: > > On Tue, Apr 02, 2019 at 10:09:00AM -0400, Tom Lane wrote: > >> I worry that your proposed fix is unstable, in particular this assumption > >> seems shaky: > >>> + * ... The idea is that, if the allocator handed out

Re: hyrax vs. RelationBuildPartitionDesc

On 2019/03/16 6:41, Robert Haas wrote: > On Fri, Mar 15, 2019 at 3:45 PM Tom Lane wrote: >> I agree that copying data isn't great. What I don't agree is that this >> solution is better. In particular, copying data out of the relcache >> rather than expecting the relcache to hold still over long

Re: [PATCH v20] GSSAPI encryption support

Peter Eisentraut writes: > On 2019-04-05 23:37, Stephen Frost wrote: >> I've also reached out to some colleagues about having one of them test >> with MacOS. What version are you on..? > macOS 10.14.14 it says. I tried to replicate this on my own laptop (macOS 10.14.4 ... I do not think there

Re: 2019-03 Starts Tomorrow

út 9. 4. 2019 v 6:04 odesílatel Michael Paquier napsal: > On Sat, Apr 06, 2019 at 04:52:42PM -0400, David Steele wrote: > > OK, these have all been pushed now. > > Please note that the commit fest has been closed as a result of the > feature freeze, any remaining items have been moved to the next

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

Hello. At Mon, 8 Apr 2019 19:22:04 +0900, Fujii Masao wrote in > > "TRUNCATE" option for vacuum command should be added to the open items? > > Yes, I think. > Attached is the patch which adds TRUNCATE option into VACUUM. By the way, this might have been discussed upthread, but boolean options

Re: 2019-03 Starts Tomorrow

On Sat, Apr 06, 2019 at 04:52:42PM -0400, David Steele wrote: > OK, these have all been pushed now. Please note that the commit fest has been closed as a result of the feature freeze, any remaining items have been moved to the next CF if they still were in "Needs Review" state and patches waiting

Re: hyrax vs. RelationBuildPartitionDesc

On 2019/04/08 22:59, Tom Lane wrote: > Amit Langote writes: >> Should I add this patch to Older Bugs [1]? > > Yeah, it's an open issue IMO. I think we've been focusing on getting > as many feature patches done as we could during the CF, but now it's > time to start mopping up problems like this

Re: PostgreSQL 12 Release Management Team & Feature Freeze

On Sat, Mar 30, 2019 at 06:40:43PM +0900, Michael Paquier wrote: > The Release Management Team (RMT) for the PostgreSQL 12 release > has been assembled and has determined that the feature freeze date > for the PostgreSQL 12 release will be April 7, 2019. This means that > any feature that will be

Re: COLLATE: Hash partition vs UPDATE

Hi Jesper, On 2019/04/09 1:33, Jesper Pedersen wrote: > Hi, > > The following case > > -- test.sql -- > CREATE TABLE test (a text PRIMARY KEY, b text) PARTITION BY HASH (a); > CREATE TABLE test_p0 PARTITION OF test FOR VALUES WITH (MODULUS 2, > REMAINDER 0); > CREATE TABLE test_p1 PARTITION OF t

Re: [PATCH v20] GSSAPI encryption support

Greetings, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 2019-04-05 23:37, Stephen Frost wrote: > > I wonder if somehow the keytab file that the server is using isn't > > getting destroyed between the two test runs and so you're ending up with > > the server using the key from

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On Sat, Mar 30, 2019 at 09:13:01PM +0100, Tomas Vondra wrote: > Hmmm, what's the right status in the CF app when a part of a patch was > committed and the rest should be moved to the next CF? Committed, Moved > to next CF, or something else? This stuff has been around for nine commit fests, and yo

Re: Zedstore - compressed in-core columnar storage

On Mon, Apr 8, 2019 at 6:04 PM Andres Freund wrote: > Hi, > > On 2019-04-08 17:27:05 -0700, Ashwin Agrawal wrote: > > Heikki and I have been hacking recently for few weeks to implement > > in-core columnar storage for PostgreSQL. Here's the design and initial > > implementation of Zedstore, compr

Re: Status of the table access method work

On Sat, Apr 6, 2019 at 7:25 AM Andres Freund wrote: > Hi, > > In this email I want to give a brief status update of the table access > method work - I assume that most of you sensibly haven't followed it > into all nooks and crannies. > > I want to thank Haribabu, Alvaro, Alexander, David, Dmitry

Re: pg_rewind vs superuser

On Mon, Apr 08, 2019 at 10:03:48AM +0200, Peter Eisentraut wrote: > How about some tests to show that this is actually true? Sure. With something like the attached? I don't think that there is much point to complicate the test code with multiple roles if the default is a superuser. -- Michael di

Re: Problem with default partition pruning

Sigh.. At Tue, 09 Apr 2019 10:28:48 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20190409.102848.252476604.horiguchi.kyot...@lab.ntt.co.jp> > As the second thought. Partition constraint is not constraint > expression so that's fair to apply partqual ignoring > constraint_exclusion.

Re: Problem with default partition pruning

At Mon, 8 Apr 2019 16:57:35 +0900, "Yuzuko Hosoya" wrote in <00c101d4ede0$babd4390$3037cab0$@lab.ntt.co.jp> > > BTW, now I'm a bit puzzled between whether this case should be fixed by > > hacking on partprune.c like > > this patch does or whether to work on getting the other patch committed and

Re: Zedstore - compressed in-core columnar storage

Hi, On 2019-04-08 17:27:05 -0700, Ashwin Agrawal wrote: > Heikki and I have been hacking recently for few weeks to implement > in-core columnar storage for PostgreSQL. Here's the design and initial > implementation of Zedstore, compressed in-core columnar storage (table > access method). That's v

Re: [Sender Address Forgery]Re: [HACKERS] generated columns

On 2019/04/08 20:50, Peter Eisentraut wrote: > On 2019-04-04 16:37, Amit Langote wrote: >> OK, thanks for explaining. We do allow DEFAULT to be specified on >> foreign tables, although locally-defined defaults have little meaning >> if the FDW doesn't allow inserts. Maybe same thing applies to >

Re: Sparse bit set data structure

On 2019-Apr-08, Bruce Momjian wrote: > Uh, should this be applied? Yes, it's a pretty obvious typo methinks. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: change password_encryption default to scram-sha-256?

>> I am not sure all third party programs concerning scram-sha-256 are >> listed on this. There are some programs that talk to PostgreSQL using >> frontend/backend protocol, but not based on libpq or other native >> drivers (for example Pgpool-II). I guess PgBouncer is in the same >> category too.

RE: reloption to prevent VACUUM from truncating empty pages at the end of relation

From: Fujii Masao [mailto:masao.fu...@gmail.com] > Thanks for the info, so I marked the patch as committed. Thanks a lot for your hard work! This felt relatively tough despite the simplicity of the patch. I'm starting to feel the difficulty and fatigue in developing in the community... Regar

Re: Adding a concept of TEMPORARY TABLESPACE for the use in temp_tablespaces

On Thu, Mar 14, 2019 at 12:53:02AM -0700, Mitar wrote: > Hi! > > On Fri, Jan 25, 2019 at 2:32 PM Bruce Momjian wrote: > > I wrote a blog entry about this: > > > > https://momjian.us/main/blogs/pgblog/2017.html#June_2_2017 > > > > This is certainly an area we can improve, but it would requ

Re: Problem with default partition pruning

At Mon, 08 Apr 2019 20:42:51 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20190408.204251.143128146.horiguchi.kyot...@lab.ntt.co.jp> > At Mon, 8 Apr 2019 16:57:35 +0900, "Yuzuko Hosoya" > wrote in > <00c101d4ede0$babd4390$3037cab0$@lab.ntt.co.jp> > > > BTW, now I'm a bit puzzled b

Re: change password_encryption default to scram-sha-256?

Em seg, 8 de abr de 2019 às 19:43, Tatsuo Ishii escreveu: > > I am not sure all third party programs concerning scram-sha-256 are > listed on this. There are some programs that talk to PostgreSQL using > frontend/backend protocol, but not based on libpq or other native > drivers (for example Pgpoo

Re: Sparse bit set data structure

Uh, should this be applied? --- On Thu, Mar 28, 2019 at 03:46:03PM +0100, Adrien NAYRAT wrote: > Hello, > > According to the draw and simple8b_mode struct comment, it seems there is a > typo: > > > * 20-bit integer

Re: Fix doc bug in logical replication.

Em seg, 8 de abr de 2019 às 19:38, Robert Treat escreveu: > > I noticed that the docs currently state "A different order of columns > in the target table is allowed, but the column types have to match." > This is untrue, as you can replicate between any two data types as > long as the data can be

Re: change password_encryption default to scram-sha-256?

> On Sun, Apr 07, 2019 at 12:59:05PM -0400, Tom Lane wrote: >> Peter Eisentraut writes: >> > Should we change the default of the password_encryption setting to >> > 'scram-sha-256' in PG12? >> >> I thought we were going to wait a bit longer --- that just got added >> last year, no? What do we kn

Fix doc bug in logical replication.

Howdy folks, I noticed that the docs currently state "A different order of columns in the target table is allowed, but the column types have to match." This is untrue, as you can replicate between any two data types as long as the data can be coerced into the right format on the subscriber. Attach

Re: Trailing whitespaces in various documentations

Le lun. 8 avr. 2019 à 22:43, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> a écrit : > On 2019-04-07 18:51, Julien Rouhaud wrote: > > While working on unrelated documentation change, I noticed some > > trailing whitespaces in various documentation files. PFA a simple > > patch to get rid o

Re: change password_encryption default to scram-sha-256?

On 4/8/19 4:20 PM, Alvaro Herrera wrote: > On 2019-Apr-08, Jonathan S. Katz wrote: > >> On 4/8/19 4:10 PM, Alvaro Herrera wrote: > >>> I wonder why we have two pages >>> https://wiki.postgresql.org/wiki/Client_Libraries >>> https://wiki.postgresql.org/wiki/List_of_drivers >> >> No clue, but it ap

Re: PageGetFreeSpace() isn't quite the right thing for some of its callers

On Mon, Apr 8, 2019 at 2:10 PM Andres Freund wrote: > I'm not sure I understand what the problem is. We got to get the > information for the fsm from somewhere? Are you arguing we should > instead have it included as an explicit xlog record payload? No. I am simply pointing out that PageGetFreeSp

Re: PageGetFreeSpace() isn't quite the right thing for some of its callers

Hi, On 2019-04-08 14:05:02 -0700, Peter Geoghegan wrote: > However, now that I take a closer look I also notice that there is > core code that calls PageGetFreeSpace() when it probably shouldn't, > either. For example, what business does heap_xlog_visible() have > calling PageGetFreeSpace()? I'm

Re: change password_encryption default to scram-sha-256?

Dave Cramer writes: > That said 42.2.0 was released in January 2018, so by PG13 it's going to be > 4 years old. Huh? 13 should come out in the fall of 2020. regards, tom lane

Re: [PATCH] Implement uuid_version()

Hi, On 2019-04-08 11:06:57 -0400, Robert Haas wrote: > That's not really a compelling reason, though, because anybody who > needs UUIDs can always install the extension. And on the other hand, > if we moved UUID support into core, then we'd be adding a hard compile > dependency on one of the UUID

PageGetFreeSpace() isn't quite the right thing for some of its callers

I notice that a number of contrib modules call PageGetFreeSpace() where they should really call PageGetExactFreeSpace() instead. PageGetFreeSpace() assumes that the overhead for one line pointer should be pro-actively subtracted, which is handy for plenty of nbtree code, but doesn't quite make sens

Re: [PATCH] Implement uuid_version()

On 8/4/19 17:06, Robert Haas wrote: On Sun, Apr 7, 2019 at 10:15 AM David Fetter wrote: I see some. UUIDs turn out to be super useful in distributed systems to give good guarantees of uniqueness without coordinating with a particular node. Such systems have become a good bit more common since

Re: change password_encryption default to scram-sha-256?

On Mon, 8 Apr 2019 at 16:38, Tom Lane wrote: > Dave Cramer writes: > >> If someone installs a postgres RPM/DEB from postgresql.org, they could > >> also install postgresql-jdbc, right ? > > > I would guess there might be some distro specific java apps that might > > actually use what is on the m

Re: Trailing whitespaces in various documentations

On 2019-04-07 18:51, Julien Rouhaud wrote: > While working on unrelated documentation change, I noticed some > trailing whitespaces in various documentation files. PFA a simple > patch to get rid of them (I didn't removed the one corresponding to > psql output), if that helps. committed, thanks

Re: change password_encryption default to scram-sha-256?

Dave Cramer writes: >> If someone installs a postgres RPM/DEB from postgresql.org, they could >> also install postgresql-jdbc, right ? > I would guess there might be some distro specific java apps that might > actually use what is on the machine but as mentioned any reasonably complex > Java app

Re: change password_encryption default to scram-sha-256?

> > > > > The scenario that worries me here is somebody using a bleeding-edge PGDG > > server package in an environment where the rest of the Postgres ecosystem > > is much less bleeding-edge. > > If someone installs a postgres RPM/DEB from postgresql.org, they could > also > install postgresql-jdb

Re: change password_encryption default to scram-sha-256?

On 2019-Apr-08, Tom Lane wrote: > I'm particularly concerned about the idea that they won't see a problem > during initial testing, only to have things fall over after they enter > production and do a "routine" password change. This is a fair objection. -- Álvaro Herrerahttps://

RE: minimizing pg_stat_statements performance overhead

CF entry created https://commitfest.postgresql.org/23/2092/ Regards PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html

Re: change password_encryption default to scram-sha-256?

On 2019-Apr-08, Jonathan S. Katz wrote: > On 4/8/19 4:10 PM, Alvaro Herrera wrote: > > I wonder why we have two pages > > https://wiki.postgresql.org/wiki/Client_Libraries > > https://wiki.postgresql.org/wiki/List_of_drivers > > No clue, but it appears that first one is the newer of the two[1][2

Re: change password_encryption default to scram-sha-256?

Justin Pryzby writes: > On Mon, Apr 08, 2019 at 02:28:30PM -0400, Tom Lane wrote: >> The scenario that worries me here is somebody using a bleeding-edge PGDG >> server package in an environment where the rest of the Postgres ecosystem >> is much less bleeding-edge. > If someone installs a postgre

Re: change password_encryption default to scram-sha-256?

On 4/8/19 4:10 PM, Alvaro Herrera wrote: > On 2019-Apr-08, Dave Cramer wrote: > >> On Mon, 8 Apr 2019 at 16:07, Alvaro Herrera >> wrote: > >>> I meant an exception to the common situation that SCRAM-SHA-256 is >>> supported and shipped in stable releases of each driver. The wiki here >>> still

Re: change password_encryption default to scram-sha-256?

On 2019-Apr-08, Dave Cramer wrote: > On Mon, 8 Apr 2019 at 16:07, Alvaro Herrera > wrote: > > I meant an exception to the common situation that SCRAM-SHA-256 is > > supported and shipped in stable releases of each driver. The wiki here > > still says it's unsupported on JDBC: > > https://wiki.p

Re: change password_encryption default to scram-sha-256?

On Mon, 8 Apr 2019 at 16:07, Alvaro Herrera wrote: > On 2019-Apr-08, Dave Cramer wrote: > > > > IIUC the vast majority of clients already support SCRAM auth. So the > > > vast majority of PG users can take advantage of the additional > security. > > > I think the only massive-adoption exception

Re: change password_encryption default to scram-sha-256?

On 2019-Apr-08, Dave Cramer wrote: > > IIUC the vast majority of clients already support SCRAM auth. So the > > vast majority of PG users can take advantage of the additional security. > > I think the only massive-adoption exception is JDBC, and apparently they > > already have working patches fo

Re: change password_encryption default to scram-sha-256?

On Mon, 8 Apr 2019 at 15:18, Jonathan S. Katz wrote: > On 4/8/19 2:28 PM, Tom Lane wrote: > > Andres Freund writes: > >> On 2019-04-08 13:34:12 -0400, Alvaro Herrera wrote: > >>> I'm not sure I understand all this talk about deferring changing the > >>> default to pg13. AFAICS only a few fringe

Re: change password_encryption default to scram-sha-256?

Alvaro, On Mon, 8 Apr 2019 at 13:34, Alvaro Herrera wrote: > I'm not sure I understand all this talk about deferring changing the > default to pg13. AFAICS only a few fringe drivers are missing support; > not changing in pg12 means we're going to leave *all* users, even those > whose clients ha

Re: change password_encryption default to scram-sha-256?

On Mon, Apr 08, 2019 at 02:28:30PM -0400, Tom Lane wrote: >On Mon, Apr 08, 2019 at 10:41:07AM -0700, Andres Freund wrote: >> If jdbc didn't support scram, it'd be an absolutely clear no-go imo. A >> pretty large fraction of users use jdbc to access postgres. But it seems >> to me that support has b

Re: change password_encryption default to scram-sha-256?

On 4/8/19 2:28 PM, Tom Lane wrote: > Andres Freund writes: >> On 2019-04-08 13:34:12 -0400, Alvaro Herrera wrote: >>> I'm not sure I understand all this talk about deferring changing the >>> default to pg13. AFAICS only a few fringe drivers are missing support; >>> not changing in pg12 means we'r

Re: change password_encryption default to scram-sha-256?

Andres Freund writes: > On 2019-04-08 13:34:12 -0400, Alvaro Herrera wrote: >> I'm not sure I understand all this talk about deferring changing the >> default to pg13. AFAICS only a few fringe drivers are missing support; >> not changing in pg12 means we're going to leave *all* users, even those

Re: ECPG regression with DECLARE STATEMENT support

On Wed, Mar 13, 2019 at 04:35:48AM +, Matsumura, Ryo wrote: > Hi Kurokawa-san > > I reviewd it. It's ok. > I also confirm there is no same bug. FYI, this was applied a few weeks ago: Author: Michael Meskes Date: Fri Mar 15 22:35:24 2019 +0100 Use corre

Re: change password_encryption default to scram-sha-256?

Hi, On 2019-04-08 13:34:12 -0400, Alvaro Herrera wrote: > I'm not sure I understand all this talk about deferring changing the > default to pg13. AFAICS only a few fringe drivers are missing support; > not changing in pg12 means we're going to leave *all* users, even those > whose clients have su

Re: ToDo: show size of partitioned table

On 2019-Apr-08, Amit Langote wrote: > I noticed that the size shown in the output of both \dP+ and \dPt+ does > include toast relation sizes of (leaf) partitions, because > pg_table_size(), which is used by all the queries that > listPartitionedTables sends to the server, does: > > /* >

Re: Pluggable Storage - Andres's take

Hi, On 2019-04-08 15:34:46 +0300, Heikki Linnakangas wrote: > There were a bunch of typos in the comments in tableam.h, see attached. Some > of the comments could use more copy-editing and clarification, I think, but > I stuck to fixing just typos and such for now. I pushed these after adding thr

Re: change password_encryption default to scram-sha-256?

I'm not sure I understand all this talk about deferring changing the default to pg13. AFAICS only a few fringe drivers are missing support; not changing in pg12 means we're going to leave *all* users, even those whose clients have support, without the additional security for 18 more months. IIUC

pgbench - add \aset to store results of a combined query

Hello devs, A long time ago I submitted a pgbench \into command to store results of queries into variables independently of the query being processed, which got turn into \gset (;) and \cset (\;), which got committed, then \cset was removed because it was not "up to standard", as it could not

Re: lazy_scan_heap() forgets to mark buffer dirty when setting all frozen?

Hi, On 2019-04-08 10:59:32 -0400, Robert Haas wrote: > On Mon, Apr 8, 2019 at 12:55 AM Andres Freund wrote: > > > Apparently the initial commit a892234f830e had MarkBufferDirty, but it > > > was removed one week later by 77a1d1e79892. > > > > Good catch. Kinda looks like it could have been an acc

Re: Status of the table access method work

Hi On 2019-04-08 14:53:53 +0300, Heikki Linnakangas wrote: > On 05/04/2019 23:25, Andres Freund wrote: > > - the (optional) bitmap heap scan API - that's fairly intrinsically > >block based. An AM could just internally subdivide TIDs in a different > >way, but I don't think a bitmap scan l

COLLATE: Hash partition vs UPDATE

Hi, The following case -- test.sql -- CREATE TABLE test (a text PRIMARY KEY, b text) PARTITION BY HASH (a); CREATE TABLE test_p0 PARTITION OF test FOR VALUES WITH (MODULUS 2, REMAINDER 0); CREATE TABLE test_p1 PARTITION OF test FOR VALUES WITH (MODULUS 2, REMAINDER 1); -- CREATE INDEX idx_tes

pgbench - implement strict TPC-B benchmark

Hello devs, The attached patch does $SUBJECT, as a showcase for recently added features, including advanced expressions (CASE...), \if, \gset, ending SQL commands at ";"... There is also a small fix to the doc which describes the tpcb-like implementation but gets one variable name wrong: ba

pgbench - add option to show actual builtin script code

Hello devs, The minor attached patch $SUBJECT, so that it can be inspected easily, instead of having to look at the source code or whatever. sh> pgbench --list select-only -- select-only: \set aid random(1, 10 * :scale) SELECT abalance FROM pgbench_accounts WHERE aid = :aid; The

Re: Pluggable Storage - Andres's take

On Mon, Apr 8, 2019 at 9:34 AM Heikki Linnakangas wrote: > > I wrote a little toy implementation that just returns constant data to > play with this a little. Looks good overall. > > There were a bunch of typos in the comments in tableam.h, see attached. > Some of the comments could use more copy-

Re: [PATCH] Implement uuid_version()

Robert Haas writes: > My biggest gripe about uuid-ossp is that the name is stupid. I wish > we could see our way clear to renaming that extension to just 'uuid', > because as J.L. says, virtually nobody's actually compiling against > the OSSP library any more. +1 There's no ALTER EXTENSION RENA

Re: [PATCH] Implement uuid_version()

On Sun, Apr 7, 2019 at 10:15 AM David Fetter wrote: > I see some. > > UUIDs turn out to be super useful in distributed systems to give good > guarantees of uniqueness without coordinating with a particular node. > Such systems have become a good bit more common since the most recent > time this wa

Re: lazy_scan_heap() forgets to mark buffer dirty when setting all frozen?

On Mon, Apr 8, 2019 at 12:55 AM Andres Freund wrote: > > Apparently the initial commit a892234f830e had MarkBufferDirty, but it > > was removed one week later by 77a1d1e79892. > > Good catch. Kinda looks like it could have been an accidental removal? > Robert? So you're talking about this hunk?

Re: [HACKERS] Weaker shmem interlock w/o postmaster.pid

On Mon, Apr 08, 2019 at 08:07:28PM +1200, Thomas Munro wrote: > On Mon, Apr 8, 2019 at 6:42 PM Noah Misch wrote: > > - lorikeet's FailedAssertion("!(vmq->mq_sender == ((void *)0))" looked > > suspicious, but this happened six other times in the past year[2], always > > on > > v10 lorikeet. >

Re: Translation updates for zh_CN.po (Chinese Simplified)

"Zhang, Jie" writes: > zh_CN.po has not been updated for three years. > The source has changed a lot. > I want to do something for postgresql. > I think I can update the zh_CN.po file. That would be great, but we don't use the pgsql-hackers mailing list to coordinate translation work. Please joi

Re: hyrax vs. RelationBuildPartitionDesc

On Mon, Apr 8, 2019 at 9:59 AM Tom Lane wrote: > Amit Langote writes: > > Should I add this patch to Older Bugs [1]? > > Yeah, it's an open issue IMO. I think we've been focusing on getting > as many feature patches done as we could during the CF, but now it's > time to start mopping up problems

Re: change password_encryption default to scram-sha-256?

On 4/8/19 10:08 AM, Tom Lane wrote: > "Jonathan S. Katz" writes: >> On 4/8/19 8:49 AM, Magnus Hagander wrote: >>> I think the real question is, is it OK to give them basically 5months >>> warning, by right now saying if you don't have a release out in 6 >>> months, things will break. > >> Given t

Re: clean up docs for v12

Find attached updated patches for v12 docs. Note that Alvaro applied an early patch for log_statement_sample_rate, but unfortunately I hadn't sent a v2 patch with additional change from myon, so there's one remaining hunk included here. If needed I can split up differently for review, or resend a

Re: change password_encryption default to scram-sha-256?

"Jonathan S. Katz" writes: > On 4/8/19 8:49 AM, Magnus Hagander wrote: >> I think the real question is, is it OK to give them basically 5months >> warning, by right now saying if you don't have a release out in 6 >> months, things will break. > Given the supported libraries all have open pull req

Re: hyrax vs. RelationBuildPartitionDesc

Amit Langote writes: > Should I add this patch to Older Bugs [1]? Yeah, it's an open issue IMO. I think we've been focusing on getting as many feature patches done as we could during the CF, but now it's time to start mopping up problems like this one. regards, tom lane

Re: change password_encryption default to scram-sha-256?

On 4/8/19 8:49 AM, Magnus Hagander wrote: > On Mon, Apr 8, 2019 at 2:38 PM Jonathan S. Katz > wrote: > Counter-argument: SCRAM has been available for 2 years since 10 feature > freeze, there has been a lot of time already given to implement support > for i

Re: change password_encryption default to scram-sha-256?

On Mon, Apr 8, 2019 at 2:38 PM Jonathan S. Katz wrote: > On 4/8/19 8:19 AM, Peter Eisentraut wrote: > > On 2019-04-08 13:52, Andrew Dunstan wrote: > >> Yeah, if we're not going to do it now we should announce that we will > >> do it in the next release. > > > > Targeting PG13 seems reasonable. >

Re: change password_encryption default to scram-sha-256?

On 4/8/19 8:19 AM, Peter Eisentraut wrote: > On 2019-04-08 13:52, Andrew Dunstan wrote: >> Yeah, if we're not going to do it now we should announce that we will >> do it in the next release. > > Targeting PG13 seems reasonable. Counter-argument: SCRAM has been available for 2 years since 10 featu

Re: Pluggable Storage - Andres's take

I wrote a little toy implementation that just returns constant data to play with this a little. Looks good overall. There were a bunch of typos in the comments in tableam.h, see attached. Some of the comments could use more copy-editing and clarification, I think, but I stuck to fixing just ty

Re: change password_encryption default to scram-sha-256?

On 2019-04-08 13:52, Andrew Dunstan wrote: > Yeah, if we're not going to do it now we should announce that we will > do it in the next release. Targeting PG13 seems reasonable. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training

Re: Speed up transaction completion faster after many relations are accessed in a transaction

On 2019-04-08 05:46, Tsunakawa, Takayuki wrote: > I'm registering you as another author and me as a reviewer, and marking this > ready for committer. Moved to next commit fest. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Trainin

Re: [PATCH v20] GSSAPI encryption support

On 2019-04-05 23:37, Stephen Frost wrote: > I wonder if somehow the keytab file that the server is using isn't > getting destroyed between the two test runs and so you're ending up with > the server using the key from the old KDC, while the user is using the > new one..? Or something is equally go

Re: Status of the table access method work

On 05/04/2019 23:25, Andres Freund wrote: I think what's in v12 - I don't know of any non-cleanup / bugfix work pending for 12 - is a pretty reasonable initial set of features. Hooray! - the (optional) bitmap heap scan API - that's fairly intrinsically block based. An AM could just interna

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On Mon, Apr 8, 2019 at 10:24 AM Fujii Masao wrote: > > On Mon, Apr 8, 2019 at 5:20 PM Julien Rouhaud wrote: > > > > On Mon, Apr 8, 2019 at 10:15 AM Fujii Masao wrote: > > > > > > But it has not been actually pushed into the community's git > > > repository yet.That's maybe because it's been a wh

Re: change password_encryption default to scram-sha-256?

On Mon, Apr 8, 2019 at 2:38 AM Michael Paquier wrote: > > On Mon, Apr 08, 2019 at 09:08:05AM +0300, Heikki Linnakangas wrote: > > I wouldn't hold my breath. That's the third PR to add SCRAM support already, > > see also https://github.com/lib/pq/pull/788 and > > https://github.com/lib/pq/pull/608.

Re: [HACKERS] generated columns

On 2019-04-04 16:37, Amit Langote wrote: > OK, thanks for explaining. We do allow DEFAULT to be specified on > foreign tables, although locally-defined defaults have little meaning > if the FDW doesn't allow inserts. Maybe same thing applies to > GENERATED AS columns. > > Would it make sense to

Translation updates for zh_CN.po (Chinese Simplified)

Hi all zh_CN.po has not been updated for three years. The source has changed a lot. I want to do something for postgresql. I think I can update the zh_CN.po file. I plan to translate and update the following zh_CN.po postgresql/src/bin/initdb/po/zh_CN.po [Patch has been completed]

Re: Problem with default partition pruning

At Mon, 8 Apr 2019 16:57:35 +0900, "Yuzuko Hosoya" wrote in <00c101d4ede0$babd4390$3037cab0$@lab.ntt.co.jp> > > BTW, now I'm a bit puzzled between whether this case should be fixed by > > hacking on partprune.c like > > this patch does or whether to work on getting the other patch committed and

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On Mon, Apr 8, 2019 at 12:22 PM Fujii Masao wrote: > > On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada wrote: > > > > On Mon, Apr 8, 2019 at 5:15 PM Fujii Masao wrote: > > > > > > On Mon, Apr 8, 2019 at 3:58 PM Julien Rouhaud wrote: > > > > > > > > On Mon, Apr 8, 2019 at 8:01 AM Fujii Masao >

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On Mon, Apr 8, 2019 at 7:22 PM Fujii Masao wrote: > > On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada wrote: > > > > On Mon, Apr 8, 2019 at 5:15 PM Fujii Masao wrote: > > > > > > On Mon, Apr 8, 2019 at 3:58 PM Julien Rouhaud wrote: > > > > > > > > On Mon, Apr 8, 2019 at 8:01 AM Fujii Masao > >

Re: [HACKERS] Block level parallel vacuum

Hello. # Is this still living? I changed the status to "needs review" At Sat, 6 Apr 2019 06:47:32 +0900, Masahiko Sawada wrote in > > Indeed. How about the following description? > > > > Attached the updated version patches. Thanks. heapam.h is including access/parallel.h but the file doesn

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada wrote: > > On Mon, Apr 8, 2019 at 5:15 PM Fujii Masao wrote: > > > > On Mon, Apr 8, 2019 at 3:58 PM Julien Rouhaud wrote: > > > > > > On Mon, Apr 8, 2019 at 8:01 AM Fujii Masao wrote: > > > > > > > > 2019年4月8日(月) 14:22 Tsunakawa, Takayuki : > > > >

Re: hyrax vs. RelationBuildPartitionDesc

On 2019/03/14 10:40, Amit Langote wrote: > On 2019/03/14 5:18, Tom Lane wrote: >> Robert Haas writes: >>> On Wed, Mar 13, 2019 at 3:14 PM Tom Lane wrote: Meanwhile, who's going to take point on cleaning up rd_partcheck? I don't really understand this code well enough to know whether tha

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On Mon, Apr 8, 2019 at 5:15 PM Fujii Masao wrote: > > On Mon, Apr 8, 2019 at 3:58 PM Julien Rouhaud wrote: > > > > On Mon, Apr 8, 2019 at 8:01 AM Fujii Masao wrote: > > > > > > 2019年4月8日(月) 14:22 Tsunakawa, Takayuki : > > >> > > >> From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com] > > >> >

  1   2   >