Re: prokind column (was Re: [HACKERS] SQL procedures)

On 2/25/18, Tom Lane wrote: > We need a plan for when/how to apply this, along with the proposed > bootstrap data conversion patch, which obviously conflicts with it > significantly. The bulk changes in the bootstrap data patch are scripted rather than patched, so the prokind patch will pose litt

Re: handling of heap rewrites in logical decoding

On 25 February 2018 at 09:57, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > A heap rewrite during a DDL command publishes changes for relations > named like pg_temp_%u, which are not real tables, and this breaks > replication systems that are not aware of that. We have a hack in t

Re: New gist vacuum.

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Hello. I have added small change to patch to allow it be compiled us

Re: New gist vacuum.

> I'll attach patch file next message. Updated patch is attached. gist-vacuum-count.patch Description: Binary data

Re: Online enabling of checksums

On Sun, Feb 25, 2018 at 1:21 AM, Greg Stark wrote: > > The change of the checksum state is WAL logged with a new xlog record. > All the buffers written by the background worker are forcibly enabled full > page writes to make sure the checksum is fully updated on the standby even > if no actual co

Re: Online enabling of checksums

On Sat, Feb 24, 2018 at 11:06 PM, Andres Freund wrote: > Hi, > > On 2018-02-24 22:56:57 +0100, Magnus Hagander wrote: > > On Sat, Feb 24, 2018 at 10:49 PM, Andres Freund > wrote: > > > > We did consider doing it at a per-table basis as well. But this is > also > > > an > > > > overhead that has

Re: Online enabling of checksums

On Sat, Feb 24, 2018 at 10:48 PM, Magnus Hagander wrote: > On Sat, Feb 24, 2018 at 4:29 AM, Tomas Vondra < > tomas.von...@2ndquadrant.com> wrote: > >> Hi, >> >> I see the patch also does throttling by calling vacuum_delay_point(). >> Being able to throttle the checksum workers not to affect user

Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

On 07/17/17 11:29, Michael Paquier wrote: > On Thu, Jul 6, 2017 at 3:48 PM, Heikki Linnakangas wrote: >> On 07/03/2017 06:30 PM, Chapman Flack wrote: >>> Although it's moot in the straightforward approach of re-zeroing in >>> the loop, it would still help my understanding of the system to know >>>

VACUUM FULL name is very confusing to some people (or to most non expert people)

Hi all, For most beginners (and even a lot of advanced users) there is a strong confusion between simple VACUUM and VACUUM FULL. They think "full" is simply an option to the maintenance operation vacuum while it's not. It's a complete different operation. I have a hard time explaining it when I

Re: VACUUM FULL name is very confusing to some people (or to most non expert people)

2018-02-25 18:51 GMT+01:00 Lætitia Avrot : > Hi all, > > For most beginners (and even a lot of advanced users) there is a strong > confusion between simple VACUUM and VACUUM FULL. They think "full" is > simply an option to the maintenance operation vacuum while it's not. It's a > complete differe

Re: [HACKERS] Small improvement to compactify_tuples

23.01.2018 06:34, Stephen Frost пишет: > Greetings, > > * Юрий Соколов (funny.fal...@gmail.com) wrote: >> On Wed, Nov 29, 2017 at 8:00 AM, Peter Geoghegan wrote: >>> On Tue, Nov 28, 2017 at 2:41 PM, Andres Freund wrote: Maybe it's a stupid question. But would we still want to have this afte

Re: Online enabling of checksums

On 02/24/2018 03:51 AM, Stephen Frost wrote: > Greetings, > > * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: >> On 02/24/2018 03:11 AM, Andres Freund wrote: >>> On 2018-02-24 03:07:28 +0100, Tomas Vondra wrote: I agree having to restart the whole operation after a crash is not id

Re: Online enabling of checksums

On 02/25/2018 03:57 PM, Magnus Hagander wrote: > > ... > >> > I very strongly doubg it's a "very noticeable operational problem". People >> > > don't restart their databases very often... Let's say it takes 2-3 weeks >> > to >> > > complete a run in a fairly large database. How many such large d

Re: TupleTableSlot abstraction

Hi! Thank you for working on this subject. See some my comments below. On Wed, Feb 21, 2018 at 1:43 AM, Andres Freund wrote: > - TupleTableSlots have to contain all the necessary information for each > type of slot. Some implementations might require a buffer pin to be > hold (our heap), o

Re: Online enabling of checksums

On 02/24/2018 10:45 PM, Magnus Hagander wrote: > On Sat, Feb 24, 2018 at 1:34 AM, Robert Haas > wrote: > > On Thu, Feb 22, 2018 at 3:28 PM, Magnus Hagander > mailto:mag...@hagander.net>> wrote: > > I would prefer that yes. But having to re-read 9TB is s

Re: Online enabling of checksums

> On 26 Feb 2018, at 05:48, Tomas Vondra wrote: > On 02/24/2018 10:45 PM, Magnus Hagander wrote: >> Is it really that invisible? Given how much we argue over adding >> single counters to the stats system, I'm not sure it's quite that >> low. > > I'm a bit unsure where would the flags be stored -

Re: [bug fix] Cascaded standby cannot start after a clean shutdown

On Fri, Feb 23, 2018 at 11:02:19PM +0900, Michael Paquier wrote: > Tsunakawa-san has proposed upthread to fix the problem by zero-ing the > page read in the WAL receiver. While I agree that zeroing the page is > the way to go, doing so in the WAL receiver does not take care of > problems with the

Precision loss casting float to numeric

Back in https://www.postgresql.org/message-id/4e384467-f28a-69ce- 75aa-4bc01125a39d%40anastigmatix.net I got intrigued about casting float values to numeric. Two queries below (one for float4, one for float8) show what happens for float values with bits of precision from one up to the limit of th

Re: PlaceHolderVars in pushed down child-join cause error

On Thu, Feb 22, 2018 at 8:36 PM, Robert Haas wrote: > On Thu, Feb 22, 2018 at 7:41 AM, Ashutosh Bapat > wrote: >> postgres_fdw isn't expected to push down joins with placeholder vars. >> But the check for that in foreign_join_ok() only considers >> joinrel->relids. For a child-join relids contain

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

From: Craig Ringer [mailto:cr...@2ndquadrant.com] > The patch proposed here means that early crashes will invoke WER. If we're > going to allow WER we should probably just do so unconditionally. > > I'd be in favour of leaving WER on when we find out we're in a noninteractive > service too, but th

Re: [HACKERS] Runtime Partition Pruning

(Sorry, I had mistakenly replied only to Simon on Friday) On Fri, Feb 23, 2018 at 9:04 PM, Simon Riggs wrote: > On 23 February 2018 at 11:40, David Rowley > wrote: >> On 23 February 2018 at 04:11, Jesper Pedersen >> wrote: >>> Are UPDATE and DELETE suppose to be supported ? >> >> To be honest,

Re: [HACKERS] Runtime Partition Pruning

On 2018/02/23 20:40, David Rowley wrote: > On 23 February 2018 at 04:11, Jesper Pedersen > wrote: >> Are UPDATE and DELETE suppose to be supported ? > > To be honest, I had not even considered those. Without looking in > detail I imagine it may be possible to allow this simply by setting > the Ap

Re: remove pg_class.relhaspkey

On Sat, Feb 24, 2018 at 10:21:44PM -0500, Tom Lane wrote: > Peter Eisentraut writes: > > pg_class.relhaspkey doesn't seem to be used or useful for anything, so > > can we remove it? See attached patch. > > We've discussed that at least twice before, and not pulled the trigger > for fear of break

Re: [HACKERS] SERIALIZABLE with parallel query

On Sat, Feb 24, 2018 at 12:04 AM, Thomas Munro wrote: > I'm testing another version that is a lot simpler: like v10, it relies > on the knowledge that the leader's transaction will always end after > the workers have finished, but it handles the RO_SAFE optimisation by > keeping the SERIALIZABLEXA

Re: remove pg_class.relhaspkey

Michael Paquier writes: > On Sat, Feb 24, 2018 at 10:21:44PM -0500, Tom Lane wrote: >> We've discussed that at least twice before, and not pulled the trigger >> for fear of breaking client code. > Speaking of which, I have looked at where relhaspkey is being used. And > there are a couple of thi

[bug fix] pg_rewind takes long time because it mistakenly copies data files

Hello, Our customer reported that pg_rewind took many hours to synchronize 400GB of data, even if the new primary doesn't perform any updates. The attached patch fixes that. The cause was that pg_rewind failed to recognize data files in tablespace directories, resulting in the full copy of th

Re: remove pg_class.relhaspkey

On Mon, Feb 26, 2018 at 12:45:48AM -0500, Tom Lane wrote: > Michael Paquier writes: > > On Sat, Feb 24, 2018 at 10:21:44PM -0500, Tom Lane wrote: > >> We've discussed that at least twice before, and not pulled the trigger > >> for fear of breaking client code. > > > Speaking of which, I have look

Re: SSL passphrase prompt external command

> On 23 Feb 2018, at 11:14, Peter Eisentraut > wrote: > > Here is a patch that adds a way to specify an external command for > obtaining SSL passphrases. There is a new GUC setting > ssl_passphrase_command. +1 on going down this route. > Right now, we rely on the OpenSSL built-in prompting m

Re: Precision loss casting float to numeric

Here are two patches. The 0001-*.patch simply adds a regression test to numeric.sql that bits aren't lost casting from float[48] to numeric. Naturally, it fails at this stage. The 0002-*.patch is a proof-of-concept patching float4_numeric and float8_numeric in the trivial way (just using FLT_DECI

invalid memory alloc request size error with commit 4b93f579

Hi, With commit 4b93f57999a2ca9b9c9e573ea32ab1aeaa8bf496, which plpgsql use its DTYPE_REC code paths for composite-type variables - below test started failing with "invalid memory alloc request size 2139062167 <%28213%29%20906-2167>" error. Testcase: create table foo ( name varchar(20), type var

RE: [bug fix] Cascaded standby cannot start after a clean shutdown

From: Michael Paquier [mailto:mich...@paquier.xyz] > I have been playing more with that this morning, and trying to tweak the > XLOG reader so as the fetched page is zeroed where necessary does not help > much. XLogReaderState->EndRecPtr is updated once the last record is set > so it is possible t

Re: [bug fix] pg_rewind takes long time because it mistakenly copies data files

On Mon, Feb 26, 2018 at 06:01:43AM +, Tsunakawa, Takayuki wrote: > The cause was that pg_rewind failed to recognize data files in > tablespace directories, resulting in the full copy of those files > instead of WAL replay. Ouch. Confirmed. If I test pg_rewind with a tablespace (primary and s