Re: [HACKERS] Runtime Partition Pruning

Hello David, On Wed, Dec 27, 2017 at 8:36 AM, David Rowley wrote: > Hi, > > Please find attached my 4th version this patch. Thanks for the patch > > This is now based on v17 of Amit's faster partition pruning patch [1]. > It also now includes Beena's tests which

Re: Increasing timeout of poll_query_until for TAP tests

On Tue, Aug 02, 2016 at 06:21:03PM -0400, Alvaro Herrera wrote: > Michael Paquier wrote: > > $node_master->safe_psql('postgres', > > "INSERT INTO tab_int VALUES (generate_series(1001,2000))"); > > my $recovery_txid = > > $node_master->safe_psql('postgres', "SELECT txid_current()"); > >

Re: Contributing with code

On 1 January 2018 at 03:27, Peter Geoghegan wrote: > On Sun, Dec 31, 2017 at 6:35 PM, Robert Haas > wrote: > > Also, let's delete the TODO list. People keep using it as a source of > > project ideas, and that's bad. > > It would be great if the TODO list

Re: ALTER TABLE ADD COLUMN fast default

On 12/12/2017 02:13 PM, Andrew Dunstan wrote: > > On 12/06/2017 11:26 AM, Andrew Dunstan wrote: >>> In general, you need to be thinking about this in terms of making sure >>> that it's impossible to accidentally not update code that needs to be >>> updated. Another example is that I noticed

Re: Foreign keys and partitioned tables

-- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services 0001-Local-partitioned-indexes.patch.gz Description: application/gunzip >From b7e85e873ba77509793180e9076295fae2fd88a7 Mon Sep 17 00:00:00 2001 From: Alvaro

Foreign keys and partitioned tables

This patch enables foreign key constraints to and from partitioned tables. Naturally, FKs that reference a partitioned table require unique constraints, and therefore they shares the restrictions of those: in my proposed patch, it is only possible if the partition keys are part of the unique

Add default role 'pg_access_server_files'

Greetings, This patch adds a new default role called 'pg_access_server_files' which allows an administrator to GRANT to a non-superuser role the ability to access server-side files through PostgreSQL (as the user the database is running as). By itself, having this role allows a non-superuser to

Re: TODO list (was Re: Contributing with code)

On Sun, Dec 31, 2017 at 11:42 AM, Tom Lane wrote: > Robert Haas writes: > > Also, let's delete the TODO list. People keep using it as a source of > > project ideas, and that's bad. > > If we're not going to maintain/curate it properly, I agree it's

Re: What does Time.MAX_VALUE actually represent?

Hi Bear, Please don't top post! On 01/01/2018 06:17 AM, Bear Giles wrote: ​You don't need to store 25:20 in the database though - your app can use a window that treats a day as "from 5 am today until 5 am tomorrow" and adds 24:00 to the times for tomorrow.​ Bear On Sat, Dec 30, 2017 at

Re: Contributing with code

On Thu, Dec 28, 2017 at 5:42 PM, Craig Ringer wrote: > Well, it's arguably solveable, if the solution is to allow at least limited > cross-database access to catalog relations. I think this is a bad idea. It's bound to add complexity and fragility to the system and I

Re: [HACKERS] Re: [HACKERS] generated columns

On 12/31/2017 09:38 AM, Peter Eisentraut wrote: > On 12/30/17 16:04, Joe Conway wrote: >> + >> + The generation expression can refer to other columns in the table, but >> + not other generated columns. Any functions and operators used must be >> + immutable. References to other tables are not

Re: What does Time.MAX_VALUE actually represent?

Peter Eisentraut writes: > select timestamp '2017-12-30 24:00:00'; > returns > 2017-12-31 00:00:00 > which makes some sense. > I don't know why we accept that and not '24:00:01' and beyond, but it's > probably historical. We also accept regression=# select

Re: [HACKERS] Re: [HACKERS] generated columns

On 12/30/17 16:04, Joe Conway wrote: > + > + The generation expression can refer to other columns in the table, but > + not other generated columns. Any functions and operators used must be > + immutable. References to other tables are not allowed. > + > > Question -- when the "stored" kind of

[Patch] Checksums for SLRU files

Hello, I`d like to show my implementation of SLRU file protection with checksums. It only has effect if checksums on database are enabled. Detection of a checksum failure during a read normally causes PostgreSQL to report an error. Setting ignore_slru_checksum_failure to on causes the system

Re: What does Time.MAX_VALUE actually represent?

On 12/30/17 09:07, Dave Cramer wrote: > We are having a discussion on the jdbc project about dealing with 24:00:00. > > https://github.com/pgjdbc/pgjdbc/pull/992#issuecomment-354507612 select timestamp '2017-12-30 24:00:00'; returns 2017-12-31 00:00:00 which makes some sense. I don't know

Re: What does Time.MAX_VALUE actually represent?

​You don't need to store 25:20 in the database though - your app can use a window that treats a day as "from 5 am today until 5 am tomorrow" and adds 24:00 to the times for tomorrow.​ Bear On Sat, Dec 30, 2017 at 2:25 PM, Gavin Flower wrote: > On 12/31/2017

Re: [PATCH] GET DIAGNOSTICS FUNCTION_NAME

Yugo Nagata writes: > Attached is a patch to implement a feature to get the current function > name by GET DIAGNOSTICS in PL/pgSQL function. While this is certainly not a very large patch, it's still code that we'd have to maintain forever, so I think it's appropriate to ask

Re: [PROPOSAL] Shared Ispell dictionaries

Hello, hackers, On Tue, Dec 26, 2017 at 07:48:27PM +0300, Arthur Zakirov wrote: > The patch will be ready and added into the 2018-03 commitfest. > I attached the patch itself. 0001-Fix-ispell-memory-handling.patch: Some strings are allocated via compact_palloc0(). But they are not persistent,

Re: Faster inserts with mostly-monotonically increasing values

Hi! > 31 дек. 2017 г., в 11:44, Pavan Deolasee > написал(а): > On a per-session basis, we cache the last heap block used for inserts and try > to use the same block for subsequent inserts. +1, from my POV this is good idea and it's cool that it already has

Re: MCV lists for highly skewed distributions

I wrote: > On 12/28/17, Jeff Janes wrote: >> I think that perhaps maxmincount should also use the dynamic >> values_cnt_remaining rather than the static one. After all, things >> included in the MCV don' get represented in the histogram. When I've >> seen >> planning

Re: [PATCH] GET DIAGNOSTICS FUNCTION_NAME

Attached is a patch to implement a feature to get the current function name by GET DIAGNOSTICS in PL/pgSQL function. Shouldn't it be tested somewhere? -- Fabien.

Re: Faster inserts with mostly-monotonically increasing values

On Sun, Dec 31, 2017 at 6:44 AM, Pavan Deolasee wrote: > Here is a patch that implements the idea. If the last insert happens to be > in the rightmost block of an index, then we cache the block and check that > first for the next insert. For the cached block to be usable

Re: Logical decoding fast-forward and slot advance

Hi! Excellent! Just a quick note on my stab at it - it was physical only, which is more limited than this of course. My plan was to clean it up based on feedback in the next couple of days for the Jan cf, but with this submission in i think the effort is better directed there. I'll keep mine

Re: [HACKERS] [PATCH] Lockable views

Hi, The updated patch is attached. On Fri, 29 Dec 2017 23:39:39 +0900 (JST) Tatsuo Ishii wrote: > The patch produces a warning. > > /home/t-ishii/lock_view-v3.patch:542: trailing whitespace. > -- Verify that we can lock a auto-updatable views > warning: 1 line adds

Re: Why standby restores some WALs many times from archive?

On Sun, Dec 31, 2017 at 10:22:37AM +0300, Sergey Burladyan wrote: > Michael Paquier writes: >> Don't be surprised if you get corrupted instances or that you >> are not able to recover up to a consistent point if you need to roll in >> a backup. > > But only if archive

Re: Fix a Oracle-compatible　instr function　in the documentation

On Sun, 31 Dec 2017 17:52:49 +0900 (JST) Tatsuo Ishii wrote: > >> Hi, > >> > >> Attached is a patch to fix a very trivial issue of the documentation. > >> > >> The documentation of PL/pgSQL provides sample codes of Oracle-compatible > >> instr functions. However, the

Logical decoding fast-forward and slot advance

Hi, Attached is patch which adds ability to do fast-forwarding while decoding. That means wal is consumed as fast as possible and changes are not given to output plugin for sending. The implementation is less invasive than I originally though it would be. Most of it is just additional filter

Re: [PATCH] GET DIAGNOSTICS FUNCTION_NAME

On Sun, 31 Dec 2017 17:54:06 +0900 (JST) Tatsuo Ishii wrote: > >> Attached is a patch to implement a feature to get the current function > >> name by GET DIAGNOSTICS in PL/pgSQL function. > > > > Could you add it to the nexf CF, I have not seen it there? Maybe the > >

Re: [PATCH] GET DIAGNOSTICS FUNCTION_NAME

>> Attached is a patch to implement a feature to get the current function >> name by GET DIAGNOSTICS in PL/pgSQL function. > > Could you add it to the nexf CF, I have not seen it there? Maybe the > deadline is tonight... I have added this to the next CF. Best regards, -- Tatsuo Ishii SRA OSS,

Re: Fix a Oracle-compatible　instr function　in the documentation

>> Hi, >> >> Attached is a patch to fix a very trivial issue of the documentation. >> >> The documentation of PL/pgSQL provides sample codes of Oracle-compatible >> instr functions. However, the behaviour is a little differet. >> Oracle's instr raises an error when the forth argument value is

Re: [PATCH] GET DIAGNOSTICS FUNCTION_NAME

Attached is a patch to implement a feature to get the current function name by GET DIAGNOSTICS in PL/pgSQL function. Could you add it to the nexf CF, I have not seen it there? Maybe the deadline is tonight... -- Fabien.

Re: Better testing coverage and unified coding for plpgsql loops

2017-12-30 22:46 GMT+01:00 Tom Lane : > While I've been fooling around with plpgsql, I've been paying close > attention to code coverage reports to make sure that the regression tests > exercise all that new code. It started to bug me that there were some > serious gaps in