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 I've done some mostly
> cosmetic
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()");
> > my
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 was deleted IMV.
>
> Choosing the right
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 that
--
Á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 Herre
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 const
On Sun, Dec 31, 2017 at 10:42 AM, Tom Lane wrote:
> If we're not going to maintain/curate it properly, I agree it's not
> worth keeping it around. But I'd rather see somebody put some effort
> into it ...
If somebody was going to resolve to put some effort into maintaining
it to a high standard
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 was deleted IMV.
Choosing the right project is one of the hardest and most important
parts of successfu
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 u
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 not
> worth keeping it around. But I'd rather
Tom, Robert, all,
* Tom Lane (t...@sss.pgh.pa.us) 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 not
> worth keeping it around. But I'd
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 not
worth keeping it around. But I'd rather see somebody put some effort
into it ...
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 2:25
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 don't think it's worth it.
On Thu, Dec 28, 2017 at 2:36 PM, David Steele wrote:
> Attached is a new patch set that should address various concerns raised in
> this thread.
>
> 1) group-access-v3-01-mkdir.patch
>
> Abstracts all mkdir calls in the backend into a MakeDirectory() function
> implemented in fd.c. This did not g
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 all
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 timestamp '2017-12-30 23:59:60';
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 g
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 t
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 why
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 03:07 AM, Dave Cramer wrote:
>
>> We
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
some harder questions
On Tue, Dec 12, 2017 at 2:09 AM, Rushabh Lathia
wrote:
>> I now believe that index_create() should reject catalog parallel
>> CREATE INDEX directly, just as it does for catalog CREATE INDEX
>> CONCURRENTLY. That logic should be generic to all AMs, since the
>> reasons for disallowing catalog paral
> 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 less than
> zero, but the sample code returns zero. This patch fixes this.
Your patch fixes o
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,
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
implementation.
I'd suggest to do not
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 problems due to skewed dist
> On 31 December 2017 at 06:55, Marina Polyakova
wrote:
>
> Secondly, here there's a sixth version of the patch for the
precalculation of
> stable or immutable functions, stable or immutable operators and other
> nonvolatile expressions.
Thanks for your patch, looks quite interesting!
> To not s
Often when looking through pg_stat_statements, it would be nice to have
some sample values for the constants and parameters. This patch
implements that by taking the values from the first execution of the
normalized query.
To keep things reasonable, there is a limit on how big the parameters
can
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.
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 for the insert,
> it shoul
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 arou
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 whitespace errors.
Fixe
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 was reboot unexpectedly, am
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 behaviour is a little diffe
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 condi
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
> > deadline is tonight...
>
>
>> 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, In
>> 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 les
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.
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 the test coverage for e
41 matches
Mail list logo
