On 09.07.2019 02:32, Bruce Momjian wrote:
diff --git a/src/bin/pg_dump/pg_backup.h b/src/bin/pg_dump/pg_backup.h
index db30b54a92..8c0cedcd98 100644
--- a/src/bin/pg_dump/pg_backup.h
+++ b/src/bin/pg_dump/pg_backup.h
@@ -153,7 +153,6 @@ typedef struct _dumpOptions
int
On Mon, Jul 08, 2019 at 06:45:50PM -0400, Bruce Momjian wrote:
On Mon, Jul 8, 2019 at 06:23:13PM -0400, Bruce Momjian wrote:
Yes, 'postgres' can be used to create a nice md5 rainbow table that
works on many servers --- good point. Are rainbow tables possible with
something like AES?
> I
On Mon, Jul 08, 2019 at 05:41:55PM -0400, Bruce Momjian wrote:
On Mon, Jul 8, 2019 at 09:30:03PM +0200, Tomas Vondra wrote:
I think Bruce's proposal was to minimize the time the key is "unlocked"
in memory by only unlocking them when the user connects and supplies
some sort of secret
After further research I'm thinking about dropping the libunwind
support. The backtrace()/backtrace_symbols() API is more widely
available: darwin, freebsd, linux, netbsd, openbsd (via port), solaris,
and of course it's built-in, whereas libunwind is only available for
linux, freebsd, hpux,
On 2019-07-08 18:09, Joe Conway wrote:
> In my mind, and in practice to a
> large extent, a postgres tablespace == a unique mount point.
But a critical difference is that in file systems, a separate mount
point has its own journal.
--
Peter Eisentraut http://www.2ndQuadrant.com/
On Mon, Jul 8, 2019 at 11:20 PM Bruce Momjian wrote:
>
> On Mon, Jul 8, 2019 at 06:04:28PM +0900, Masahiko Sawada wrote:
> > On Sun, Jul 7, 2019 at 1:05 AM Bruce Momjian wrote:
> > > What about referential integrity constraints that need to check primary
> > > keys in the encrypted tables? I
Thomas Munro wrote:
> On Tue, May 21, 2019 at 9:12 PM Antonin Houska wrote:
> > Robert Haas wrote:
> > > It seems to me that it's better to unwind the stack i.e. have the
> > > function return the error information to the caller and let the caller
> > > do as it likes.
> >
> > Thanks for a
On Sat, Jul 6, 2019 at 8:26 PM Dilip Kumar wrote:
>
> On Thu, Jul 4, 2019 at 5:24 PM Amit Kapila wrote:
> >
> PFA, the latest version of the undo interface and undo processing patches.
>
> Summary of the changes in the patch set
>
> 1. Undo Interface
> - Rebased over latest undo storage code
> -
On Sun, Jul 7, 2019 at 3:09 PM Thomas Munro wrote:
> + /* Timed out */
> + if (rc == 0)
> + return true;
Here's a version without that bit, because I don't think we need it.
> That still leaves the danger that the CV can be signalled some time
>
> On 8 Jul 2019, at 00:02, Thomas Munro wrote:
>
> On Wed, Jun 12, 2019 at 1:21 AM Daniel Gustafsson wrote:
>> The patch is still rough around the edges (TODO’s left to mark some areas),
>> but
>> I prefer to get some feedback early rather than working too far in
>> potentially
>> the wrong
On 2019-07-08 21:08, Julien Rouhaud wrote:
> Don't get me wrong, I do agree that implementing filtering in the
> backend is a better design. What's bothering me is that I also agree
> that there will be more glibc breakage, and if that happens within a
> few years, a lot of people will still be
Hi Alvaro, Anthony, Julien and Robert,
On 2019/07/09 3:47, Julien Rouhaud wrote:
On Mon, Jul 8, 2019 at 8:44 PM Robert Haas wrote:
On Mon, Jul 8, 2019 at 2:18 PM Alvaro Herrera wrote:
Yeah, I got the impression that that was determined to be the desirable
behavior, so I made it do that,
On Thu, 2019-06-27 at 10:06 -0400, Jesper Pedersen wrote:
> Here is a patch for the pg_receivewal documentation to highlight that
> WAL isn't acknowledged to be applied.
I think it is a good idea to document this, but I have a few quibbles
with the patch as it is:
- I think there shouldn't be
On Mon, Jul 8, 2019 at 11:46 PM Masahiko Sawada wrote:
>
> On Mon, Jul 8, 2019 at 9:00 AM Thomas Munro wrote:
> >
> > On Wed, Jun 26, 2019 at 2:46 AM Ildar Musin wrote:
> > > Attached is a simple patch that uses subxid instead of top-level xid
> > > in ReorderBufferAddNewTupleCids() call. It
On Mon, Jul 08, 2019 at 06:24:40PM -0400, Joe Conway wrote:
On 7/8/19 6:04 PM, Stephen Frost wrote:
* Bruce Momjian (br...@momjian.us) wrote:
Uh, well, renaming the user was a big problem, but that is the only case
I can think of. I don't see that as an issue for block or WAL sequence
> On 7 Apr 2019, at 20:04, Ramanarayana wrote:
> Please find the updated patch. Added to the commitfest as well
The v2 patch is somewhat confused as it has Windows carriage returns rather
than newlines, so it replaces the entire file making the diff hard to read. It
also includes a copy of
On 7/9/19 8:39 AM, Ryan Lambert wrote:
> Hi Thomas,
>
>> CBC mode does require
>> random nonces, other modes may be fine with even sequences as long as
>> the values are not reused.
>
> I disagree that CBC mode requires random nonces, at least based on what
> NIST has published. They only
The following patch fixes propagation of arguments to the trigger
function to child partitions both when initially creating the trigger
and when adding new partitions to a partitioned table.
The included regression test should demonstrate the problem, for clarity
repeated in slightly more
Dear Michael san
> > So, I'll fix this within a couple of weeks.
> Please note that I have switched the patch as waiting on author.
Thanks for your support.
I've rebased the previous patch to be applied
to the latest PostgreSQL without any failure of regression tests.
Best,
Takamichi
On Mon, Jul 8, 2019 at 9:37 PM Tomas Vondra
wrote:
>
> On Mon, Jul 08, 2019 at 12:07:06PM -0400, James Coleman wrote:
> >On Mon, Jul 8, 2019 at 10:58 AM Tomas Vondra
> > wrote:
> >>
> >> On Mon, Jul 08, 2019 at 10:32:18AM -0400, James Coleman wrote:
> >> >On Mon, Jul 8, 2019 at 9:59 AM Tomas
On Mon, Jul 8, 2019 at 6:37 PM Alexander Korotkov
wrote:
>
> On Thu, Jul 4, 2019 at 4:25 PM James Coleman wrote:
> > Process questions:
> > - Do I need to explicitly move the patch somehow to the next CF?
>
> We didn't manage to register it on current (July) commitfest. So,
> please, register
Hi,
On 7/4/19 6:59 AM, Thomas Munro wrote:
For the MIN query you just need a path with Pathkeys: { i ASC, j ASC
}, UniqueKeys: { i, j }, doing the MAX query you just need j DESC.
David, are you thinking about something like the attached ?
Some questions.
* Do you see UniqueKey as a
Richard Guo wrote:
> Another rebase is needed for the patches.
Done.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
>From f656bd8d46afb9cb0a331cf3d34b9eed39f5e360 Mon Sep 17 00:00:00 2001
From: Antonin Houska
Date: Tue, 9 Jul 2019 15:30:13 +0200
Subject: [PATCH 1/3] Introduce
On Tue, Jul 9, 2019 at 3:39 AM Tomas Vondra
wrote:
>
> BTW how do you know this is what users want? Maybe they do, but then
> again - maybe they just see it as magic and don't realize the extra
> complexity (not just at the database level). In my experience users
> generally want more abstract
On Tue, Jul 09, 2019 at 03:34:48PM +0900, Michael Paquier wrote:
> Looking closely at the code in DefineIndex() (and as Rajkumar has
> mentioned upthread for unique constraints) this can happen for primary
> keys, unique constraints and exclusion constraints. So we had better
> mention all three
Sorry for jumping in late here.
On Tue, Jul 9, 2019 at 3:51 PM Michael Paquier wrote:
> On Tue, Jul 09, 2019 at 03:34:48PM +0900, Michael Paquier wrote:
> > Looking closely at the code in DefineIndex() (and as Rajkumar has
> > mentioned upthread for unique constraints) this can happen for
On Mon, Jul 08, 2019 at 07:32:07PM -0400, Bruce Momjian wrote:
> Wow, good catch. I thought C compilers would have reported this issue,
> but obviously not. Patch applied to head. Thanks.
Yes, I don't recall that gcc nor clang have a magic recipy for that.
We have a couple of other orphaned
Thanks for the review.
On Tue, Jul 9, 2019 at 9:24 AM Michael Paquier wrote:
>
> On Mon, Jul 08, 2019 at 11:02:14PM +0200, Julien Rouhaud wrote:
> > On Mon, Jul 8, 2019 at 9:08 PM Julien Rouhaud wrote:
> >> I'll resubmit the parallel patch using per-table only
> >> approach
> >
> > Attached.
>
On Mon, Jul 08, 2019 at 08:12:18PM -0700, David G. Johnston wrote:
> Reads a bit backward. How about:
>
> "As uniqueness can only be enforced within an individual partition when
> defining a primary key on a partitioned table all columns present in the
> partition key must also exist in the
On Mon, Jul 08, 2019 at 11:10:51PM -0400, Tom Lane wrote:
> Isn't it the other way around, that the partition key column(s) must
> be
> included in the primary key? Maybe I'm confused, but it seems like
> we couldn't enforce PK uniqueness otherwise.
Yes you are right. The full column list of
On Mon, Jul 8, 2019 at 11:34 PM Michael Paquier wrote:
> On Mon, Jul 08, 2019 at 08:12:18PM -0700, David G. Johnston wrote:
> > Reads a bit backward. How about:
> >
> > "As uniqueness can only be enforced within an individual partition when
> > defining a primary key on a partitioned table all
On Tue, Jul 9, 2019 at 8:29 AM Michael Paquier wrote:
> On Mon, Jul 08, 2019 at 10:37:37PM -0400, Bruce Momjian wrote:
> > On Fri, Jul 5, 2019 at 09:20:07PM +, PG Doc comments form wrote:
> >> In the documentation for Postgres 11 table partitioning, there is no
> mention
> >> of the
On 4/16/19 1:22 AM, Noah Misch wrote:
> On Thu, Mar 07, 2019 at 03:23:50PM +0100, Sandro Mani wrote:
>> Related, no actual static libraries are produced alongside the respective
>> dlls. The attached patch 0002-Build-static-libraries.patch addresses this,
>> in a similar fashion as is already
Hi Thomas,
> CBC mode does require
> random nonces, other modes may be fine with even sequences as long as
> the values are not reused.
I disagree that CBC mode requires random nonces, at least based on what
NIST has published. They only require that the IV (not the nonce) must be
unpredictable
On Tue, Jul 9, 2019 at 9:52 AM Julien Rouhaud wrote:
>
> On Tue, Jul 9, 2019 at 9:24 AM Michael Paquier wrote:
> >
> > I have done a lookup of this patch set with a focus on the refactoring
> > part, and the split is a bit confusing.
> [...]
I finished to do a better refactoring, and ended up
Surafel,
> The cost of FITCH FIRST N PERCENT execution in current implementation is
the cost of pulling the full table plus the cost of storing and fetching
the tuple from tuplestore so it can > not perform better than pulling the
full table in any case . This is because we can't determined the
Hi Ryan,
On Tue, Jul 9, 2019 at 1:27 AM Ryan Lambert wrote:
> Hi Surafel,
>
> The v5 patch [1] applies cleanly and passes make installcheck-world.
>
> My concern with this is its performance. As a user I would expect using
> this feature to enable queries to run faster than they would simply
On 7/9/19 4:34 AM, Tomas Vondra wrote:
> On Mon, Jul 08, 2019 at 06:45:50PM -0400, Bruce Momjian wrote:
>>On Mon, Jul 8, 2019 at 06:23:13PM -0400, Bruce Momjian wrote:
>>> Yes, 'postgres' can be used to create a nice md5 rainbow table that
>>> works on many servers --- good point. Are rainbow
On 7/9/19 4:23 AM, Tomas Vondra wrote:
> On Mon, Jul 08, 2019 at 06:24:40PM -0400, Joe Conway wrote:
>>On 7/8/19 6:04 PM, Stephen Frost wrote:
>>> * Bruce Momjian (br...@momjian.us) wrote:
Uh, well, renaming the user was a big problem, but that is the only case
I can think of. I don't
On 7/9/19 6:07 AM, Peter Eisentraut wrote:
> On 2019-07-08 18:09, Joe Conway wrote:
>> In my mind, and in practice to a
>> large extent, a postgres tablespace == a unique mount point.
>
> But a critical difference is that in file systems, a separate mount
> point has its own journal.
While it
On Tue, Jul 09, 2019 at 03:37:03AM +0200, Tomas Vondra wrote:
...
Notice that cost of the second plan is almost double the first one. That
means 0004 does not even generate the first plan, i.e. there are cases
where we don't try to add the explicit sort before passing the path to
On Tue, Jul 9, 2019 at 7:32 AM Konstantin Knizhnik
wrote:
> Sorry, are you tests autoprepare-16.patch I have sent in the last e-mail?
> I can not reproduce the problem with building documentation:
+ autoprepare_threshold (integer/type>)
The problem is that "integer/type>". (Missing "<").
On Tue, Jul 9, 2019 at 08:01:35AM -0400, Joe Conway wrote:
> On 7/9/19 6:07 AM, Peter Eisentraut wrote:
> > On 2019-07-08 18:09, Joe Conway wrote:
> >> In my mind, and in practice to a
> >> large extent, a postgres tablespace == a unique mount point.
> >
> > But a critical difference is that in
On Mon, Jul 8, 2019 at 06:45:50PM -0400, Bruce Momjian wrote:
> On Mon, Jul 8, 2019 at 06:23:13PM -0400, Bruce Momjian wrote:
> > Yes, 'postgres' can be used to create a nice md5 rainbow table that
> > works on many servers --- good point. Are rainbow tables possible with
> > something like
On Mon, Jul 8, 2019 at 09:57:57PM -0600, Ryan Lambert wrote:
> Hey everyone,
>
> Here is my input regarding nonces and randomness.
>
> > As I understand it, the NIST recommendation is a 96-bit *random* nonce,
>
> I could not find that exact requirement in the NIST documents, though given
>
On Tue, Jul 9, 2019 at 10:34:06AM +0200, Tomas Vondra wrote:
> > I think the issues is that we can't use a _counter_ for the nonce since
> > each page-0 of each table would use the same nonce, and each page-1,
> > etc. I assume we would use the table oid and page number as the nonce.
> > We
On Mon, Jul 8, 2019 at 7:22 AM Thomas Munro wrote:
>
> On Sun, Apr 7, 2019 at 3:46 AM Tom Lane wrote:
> > =?UTF-8?Q?Filip_Rembia=C5=82kowski?= writes:
> > > Here is my attempt to fix a 12-years old ltree bug (which is a todo item).
> > > I see it's not backward-compatible, but in my
On Tue, Jul 9, 2019 at 10:59:12AM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> I agree that all of that isn't necessary for an initial implementation,
> I was rather trying to lay out how we could improve on this in the
> future and why having the keying done at a
On Thu, Jul 4, 2019 at 1:39 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-03-25 12:04, Panagiotis Mavrogiorgos wrote:
> > Last November snowball added support for Greek language [1]. Following
> > the instructions [2], I wrote a patch that adds fulltext search for
> >
Yes, the patches changed Makefile so that pg_rewind and pg_basebackup could
use some common code, but for Windows build, I'm not sure where are those
window build files. Does anyone know about that? Thanks.
On Tue, Jul 9, 2019 at 6:55 AM Thomas Munro wrote:
> On Tue, Jul 2, 2019 at 5:46 PM Paul
On Tue, Jul 09, 2019 at 09:28:42AM -0400, James Coleman wrote:
On Mon, Jul 8, 2019 at 9:37 PM Tomas Vondra
wrote:
On Mon, Jul 08, 2019 at 12:07:06PM -0400, James Coleman wrote:
> ...
>
>I guess I'm still not following. If (2) is responsible (currently) for
>adding an explicit sort, why
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Jul 9, 2019 at 08:01:35AM -0400, Joe Conway wrote:
> > On 7/9/19 6:07 AM, Peter Eisentraut wrote:
> > > On 2019-07-08 18:09, Joe Conway wrote:
> > >> In my mind, and in practice to a
> > >> large extent, a postgres tablespace == a
On Tue, Jul 9, 2019 at 09:16:17AM -0400, Joe Conway wrote:
> On 7/9/19 8:39 AM, Ryan Lambert wrote:
> > Hi Thomas,
> >
> >> CBC mode does require
> >> random nonces, other modes may be fine with even sequences as long as
> >> the values are not reused.
> >
> > I disagree that CBC mode
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Jul 9, 2019 at 10:59:12AM -0400, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > I agree that all of that isn't necessary for an initial implementation,
> > I was rather trying to lay out how we could improve
On Mon, Jul 08, 2019 at 09:46:44AM -0700, Paul A Jungwirth wrote:
> On Sat, Jul 6, 2019 at 12:13 PM Jeff Davis wrote:
> >
> > On Fri, 2019-07-05 at 09:58 -0700, Paul A Jungwirth wrote:
> > > user-defined range types. So how about I start on it and see how it
> > > goes? I expect I can follow the
I made bunch of changes based on Andres' review and I split some more
indisputable 1 line changes from the large commit, hoping it will be easier to
review both. Several bits and pieces of the patch have been applied piecemeal,
but I was hoping to avoid continuing to do that.
I think at least
On 7/9/19 4:12 PM, Tomas Vondra wrote:
> On Tue, Jul 09, 2019 at 03:50:39PM -0400, Bruce Momjian wrote:
>>On Tue, Jul 9, 2019 at 02:09:38PM -0400, Joe Conway wrote:
>>> the input nonce used to generate the IV could be something like
>>> pg_class.oid and blocknum concatenated together with some
On 7/9/19 11:11 AM, Bruce Momjian wrote:
> On Tue, Jul 9, 2019 at 09:16:17AM -0400, Joe Conway wrote:
>> On 7/9/19 8:39 AM, Ryan Lambert wrote:
>> > Hi Thomas,
>> >
>> >> CBC mode does require
>> >> random nonces, other modes may be fine with even sequences as long as
>> >> the values are not
On Mon, Jul 8, 2019 at 11:33 PM Alvaro Herrera
wrote:
> On 2019-Jul-08, Dmitry Belyavsky wrote:
>
> > I did not introduce any functions. I've just changed the parser.
>
> I mean the C-level functions -- count_parts_ors() and so on.
>
> Added a comment to count_parts_ors()
The other functions
On Mon, Jul 08, 2019 at 08:11:55PM -0400, Bruce Momjian wrote:
On Wed, Jul 3, 2019 at 11:42:49AM -0400, Robert Haas wrote:
On Wed, Jul 3, 2019 at 11:24 AM Tomas Vondra
wrote:
> Maybe. And it would probably work for the systems I used for benchmarks.
>
> It however assumes two things: (a) the
On Mon, Jul 8, 2019 at 12:21 PM Tom Lane wrote:
> The point of regressplans.sh is to see if anything goes seriously
> wrong when forcing non-default plan choices --- seriously wrong being
> defined as crashes or semantically wrong answers. It's not expected
> that the regression tests will
út 9. 7. 2019 v 20:25 odesílatel Jeff Davis napsal:
> On Tue, 2019-07-09 at 07:08 +0200, Pavel Stehule wrote:
> >
> > I am not against a multirange type, but I miss a explanation why you
> > introduce new kind of types and don't use just array of ranges.
> >
> > Introduction of new kind of types
On Mon, Jul 8, 2019 at 10:09 PM Pavel Stehule wrote:
> po 8. 7. 2019 v 18:47 odesílatel Paul A Jungwirth
> napsal:
> I am not against a multirange type, but I miss a explanation why you
> introduce new kind of types and don't use just array of ranges.
Hi Pavel, I'm sorry, and thanks for your
On Tue, Jul 09, 2019 at 03:00:27PM +0200, Patrick McHardy wrote:
The following patch fixes propagation of arguments to the trigger
function to child partitions both when initially creating the trigger
and when adding new partitions to a partitioned table.
Thanks for the report and bugfix. It
út 9. 7. 2019 v 21:10 odesílatel Pavel Stehule
napsal:
>
>
> út 9. 7. 2019 v 20:25 odesílatel Jeff Davis napsal:
>
>> On Tue, 2019-07-09 at 07:08 +0200, Pavel Stehule wrote:
>> >
>> > I am not against a multirange type, but I miss a explanation why you
>> > introduce new kind of types and don't
I have been wanting to contribute to the Postgres project for a while
now, and I wanted to get some suggestions about the IDE and other tools
that others are using (preferably, somewhat modern tools).
Can anyone share what IDE they are using and if they have any other tips
on setting up a
On Tue, 2019-07-09 at 07:08 +0200, Pavel Stehule wrote:
>
> I am not against a multirange type, but I miss a explanation why you
> introduce new kind of types and don't use just array of ranges.
>
> Introduction of new kind of types is not like introduction new type.
The biggest benefit, in my
On 2019-Jul-08, Paul A Jungwirth wrote:
> - You can subscript a multirange like you do an array (? This could be
> a function instead.)
Note that we already have a patch in the pipe to make subscripting an
extensible operation, which would fit pretty well here, I think.
Also, I suppose you
On Mon, 2019-07-08 at 09:46 -0700, Paul A Jungwirth wrote:
> - A multirange type is an extra thing you get when you define a range
> (just like how you get a tstzrange[]). Therefore
Agreed.
> - I'm adding a new typtype for multiranges. ('m' in pg_type).
Sounds reasonable.
> - I'm just
On Tue, Jul 9, 2019 at 02:09:38PM -0400, Joe Conway wrote:
> On 7/9/19 11:11 AM, Bruce Momjian wrote:
> > Good point about nonce and IV. I wonder if running the nonce
> > through the cipher with the key makes it random enough to use as an
> > IV.
>
> Based on that NIST document it seems so.
>
>
On Tue, Jul 09, 2019 at 03:50:39PM -0400, Bruce Momjian wrote:
On Tue, Jul 9, 2019 at 02:09:38PM -0400, Joe Conway wrote:
On 7/9/19 11:11 AM, Bruce Momjian wrote:
> Good point about nonce and IV. I wonder if running the nonce
> through the cipher with the key makes it random enough to use as
On 7/9/19 3:50 PM, Bruce Momjian wrote:
> On Tue, Jul 9, 2019 at 02:09:38PM -0400, Joe Conway wrote:
>> On 7/9/19 11:11 AM, Bruce Momjian wrote:
>> > Good point about nonce and IV. I wonder if running the nonce
>> > through the cipher with the key makes it random enough to use as an
>> > IV.
>>
Tomas Vondra writes:
> On Mon, Jul 08, 2019 at 10:58:56AM -0400, Tom Lane wrote:
>> So I think we're probably stuck with the approach of adding new internal
>> dependencies. If we go that route, then our options for the released
>> branches are (1) do nothing, or (2) back-patch the code that
On 2019-Jul-09, Tomas Vondra wrote:
> On Tue, Jul 09, 2019 at 03:00:27PM +0200, Patrick McHardy wrote:
> > The following patch fixes propagation of arguments to the trigger
> > function to child partitions both when initially creating the trigger
> > and when adding new partitions to a
On Tue, Jul 9, 2019 at 8:51 AM David Fetter wrote:
> > - A multirange type is an extra thing you get when you define a range
> > (just like how you get a tstzrange[]). Therefore
> > - I don't need separate commands to add/drop multirange types. You get
> > one when you define a range type,
See attached patch.
I think adding GUC_REPORT to search_path is probably the most important as
this is potentially a security issue. See joe conway's blog on security and
search path here
https://info.crunchydata.com/blog/postgresql-defaults-and-impact-on-security-part-2
I also see there was a
On Mon, Jul 08, 2019 at 10:58:56AM -0400, Tom Lane wrote:
Alvaro Herrera writes:
That said, I'm not sure I see the use case for an ALTER TABLE .. DROP
COLUMN command that turns a partitioned table (with existing partitions
containing data) into one non-partitioned table with all data minus the
Hi Laurenz,
On 7/9/19 5:16 AM, Laurenz Albe wrote:
On Thu, 2019-06-27 at 10:06 -0400, Jesper Pedersen wrote:
Here is a patch for the pg_receivewal documentation to highlight that
WAL isn't acknowledged to be applied.
I think it is a good idea to document this, but I have a few quibbles
with
On 7/9/19 12:01 PM, Alvaro Herrera wrote:
On 2019-Jul-08, Paul A Jungwirth wrote:
- You can subscript a multirange like you do an array (? This could be
a function instead.)
Note that we already have a patch in the pipe to make subscripting an
extensible operation, which would fit pretty
On Mon, 22 Jan 2018 at 07:39, Robert Haas wrote:
> On Sun, Jan 21, 2018 at 5:41 PM, Craig Ringer
> wrote:
> > If we'd done server_version_num in 9.5, for example, less stuff would've
> > broken with pg10.
>
> Yeah, and if Tom hadn't forced it to be reverted from *8.2*, then
> every version
John Naylor writes:
> [ v4 patches for trimming lexer table size ]
I reviewed this and it looks pretty solid. One gripe I have is
that I think it's best to limit backup-prevention tokens such as
quotecontinuefail so that they match only exact prefixes of their
"success" tokens. This seems
On 09.07.2019 15:16, Thomas Munro wrote:
On Tue, Jul 9, 2019 at 7:32 AM Konstantin Knizhnik
wrote:
Sorry, are you tests autoprepare-16.patch I have sent in the last e-mail?
I can not reproduce the problem with building documentation:
+ autoprepare_threshold (integer/type>)
The problem
On Tue, Jul 9, 2019 at 11:14 PM Andres Freund wrote:
> > + if (xlrec->wal_level < WAL_LEVEL_LOGICAL)
> > + ereport(ERROR,
> > +
> > (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
> > +
I did some more testing. I initialized a database with 1 million rows with
indexes and joins to test against and ran pgbench with a few different
settings for % to return. I started with a base query not utilizing the
new functionality. The queries used are similar to my prior examples, code
at
Hello. The patch gets disliked by my tool chain. Fixed the usage
of PG_USED_FOR_ASSERTS_ONLY and rebased to bd56cd75d2.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From 1dabdce6993b73408b950cb8c348c4999178b9a0 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: Thu, 18 Apr 2019
On Wed, Jul 10, 2019 at 9:44 AM Dilip Kumar wrote:
>
> On Fri, Nov 2, 2018 at 1:34 PM Amit Langote
> wrote:
> >
> > On 2018/11/01 20:34, Dilip Kumar wrote:
> > > On Mon, Oct 29, 2018 at 2:53 PM Amit Langote wrote:
> > >> Anyway, why don't we just use the child table's AppendRelInfo to get the
>
At Thu, 04 Jul 2019 19:27:54 +0900 (Tokyo Standard Time), Kyotaro Horiguchi
wrote in
<20190704.192754.27063464.horikyota@gmail.com>
> #db #tbl #clients #iter #xactlen #referers
> A1: 1 1 1 2100
> A2: 1 1 1 2101
>
Hi Dilip,
On Wed, Jul 10, 2019 at 1:29 PM Dilip Kumar wrote:
> On Wed, Jul 10, 2019 at 9:44 AM Dilip Kumar wrote:
> > On Fri, Nov 2, 2018 at 1:34 PM Amit Langote wrote:
> > > Okay, here are two patches:
> > >
> > > 0001 adds a new RelOptInfo member inh_root_parent that's set for
> > >
On Tue, Jul 09, 2019 at 01:09:38PM +0200, Peter Eisentraut wrote:
> You can already do that: Run a query through psql to get a list of
> affected tables or indexes and feed those to reindexdb using -i or -t
> options.
Sure, but that's limited if one can only afford a limited amount of
downtime
st 10. 7. 2019 v 6:26 odesílatel Paul A Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On Tue, Jul 9, 2019 at 12:24 PM Pavel Stehule
> wrote:
> > út 9. 7. 2019 v 21:10 odesílatel Pavel Stehule
> napsal:
> >> I afraid so with generic multiragetype there lot of array
> infrastructure will
On Mon, Jul 8, 2019 at 12:30 AM Alexander Korotkov
wrote:
> On Thu, Jul 4, 2019 at 4:38 PM Liudmila Mantrova
> wrote:
> > Thank you!
> >
> > I think we can make this sentence even shorter, the fix is attached:
> >
> > "To refer to a JSON element stored at a lower nesting level, add one or
> >
Hi
Here:
https://www.postgresql.org/docs/12/view-pg-roles.html
we state:
"This view explicitly exposes the OID column of the underlying table,
since that is needed to do joins to other catalogs."
I think it's superfluous to mention this now OIDs are exposed by default;
attached patch
On Fri, Nov 2, 2018 at 1:34 PM Amit Langote
wrote:
>
> On 2018/11/01 20:34, Dilip Kumar wrote:
> > On Mon, Oct 29, 2018 at 2:53 PM Amit Langote wrote:
> >> Anyway, why don't we just use the child table's AppendRelInfo to get the
> >> parent's version of varattno instead of creating a new
Hello. Rebased the patch to master(bd56cd75d2).
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From ac52e2c1c56a96c1745149ff4220a3a116d6c811 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: Thu, 11 Oct 2018 10:03:21 +0900
Subject: [PATCH 1/3] TAP test for copy-truncation
On Tue, Jul 9, 2019 at 12:02 PM Jeff Davis wrote:
> > - Multirange in/out work just like arrays, e.g. '{"[1,3)", "[5,6)"}'
>
> It would be cool to have a better text representation. We could go
> simple like:
>
>'[1,3) [5,6)'
Will that work with all ranges, even user-defined ones? With a
On Tue, Jul 9, 2019 at 12:24 PM Pavel Stehule wrote:
> út 9. 7. 2019 v 21:10 odesílatel Pavel Stehule
> napsal:
>> I afraid so with generic multiragetype there lot of array infrastructure
>> will be duplicated
>
> on second hand - it is true so classic array concat is not optimal for set of
>
On Tue, Jul 09, 2019 at 11:54:29AM -0700, Melanie Plageman wrote:
> It might be worth post-processing results files to ignore row ordering
> in some cases to allow for easier comparison. Has this been proposed
> in the past?
Not that I recall.
--
Michael
signature.asc
Description: PGP signature
On Wed, Jul 10, 2019 at 7:53 AM Alvaro Herrera wrote:
> On 2019-Jul-09, Amit Langote wrote:
> > "While defining a primary key and unique constraints on partitioned
> > tables is supported, the set of columns being constrained must include
> > all of the partition key columns. This limitation
Tomas Vondra 于2019年7月10日周三 上午5:12写道：
> On Sat, Jul 06, 2019 at 05:23:37PM +0200, Tomas Vondra wrote:
> >On Sat, Jul 06, 2019 at 02:27:56AM +0800, Binguo Bao wrote:
> >>Hi, Tomas!
> >>Thanks for your testing and the suggestion.
> >>
> >>That's quite bizarre behavior - it does work with a prefix,
On Wed, Jul 10, 2019 at 10:15 AM Amit Langote wrote:
>
> Hi Dilip,
>
> On Wed, Jul 10, 2019 at 1:29 PM Dilip Kumar wrote:
> > On Wed, Jul 10, 2019 at 9:44 AM Dilip Kumar wrote:
> > > On Fri, Nov 2, 2018 at 1:34 PM Amit Langote wrote:
> > > > Okay, here are two patches:
> > > >
> > > > 0001 adds
1 - 100 of 131 matches
Mail list logo
