On Tue, 25 Jun 2019 at 06:08, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> New thread continuing from
> <
> https://www.postgresql.org/message-id/d4903af2-e7b7-b551-71f8-3e4a6bdc2...@2ndquadrant.com
> >.
>
> Here is a extended version of Álvaro's patch that adds an errbacktrace()
Hi
so 29. 6. 2019 v 7:26 odesílatel Nikita Glukhov
napsal:
> Attached 36th version of patches rebased onto jsonpath v36.
>
I cannot to apply these patches on master. Please, can you check these
patches?
Regards
Pavel
>
> --
> Nikita Glukhov
> Postgres Professional:
On Fri, Jun 28, 2019 at 10:37 AM Adam Berlin wrote:
>
> If we were to use this tool, would the community want to vendor the
> framework in the Postgres repository, or keep it in a separate
> repository that produces a versioned shared library?
>
If the library is going to actively evolve, we
On Fri, Jun 28, 2019 at 09:25:00AM +0200, Julien Rouhaud wrote:
> The patch does not apply anymore, so here's a rebased version.
Thanks for the rebase (and the reminder..). I'll look at that once
v13 opens for business.
--
Michael
signature.asc
Description: PGP signature
On Fri, Jun 28, 2019 at 08:47:33PM +0200, Julien Rouhaud wrote:
> On Fri, Jun 28, 2019 at 4:37 PM Daniel Gustafsson wrote:
>> backend/libpq/be-secure-gssapi.c is including both libpq-be.h and libpq.h,
>> which makes libpq-be.h superfluous as it gets included via libpq.h. The
>> attached patch
On Tue, Nov 6, 2018 at 10:24 AM Haribabu Kommi wrote:
>
> On Thu, Jul 26, 2018 at 3:52 PM Tsunakawa, Takayuki
> wrote:
>
>
> Thanks for confirmation of that PostgreSQL runs as service.
>
> Based on the following details, we can decide whether this fix is required or
> not.
> 1. Starting of
On Tue, May 28, 2019 at 4:33 AM Noah Misch wrote:
>
> On Mon, May 27, 2019 at 02:08:26PM +0900, Kyotaro HORIGUCHI wrote:
> > At Fri, 24 May 2019 19:33:32 -0700, Noah Misch wrote in
> > <20190525023332.ge1624...@rfd.leadboat.com>
> > > On Mon, May 20, 2019 at 03:54:30PM +0900, Kyotaro HORIGUCHI
On Fri, Jun 28, 2019 at 04:16:23PM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Fri, Jun 28, 2019 at 03:03:19PM -0400, Tom Lane wrote:
I not only don't want that function in indxpath.c, I don't even want
it to be known/called from there. If we need the ability for the index
AM to
Hi!
On 29.06.2019 1:23, Julien Rouhaud wrote:
But that kinda resembles stuff we already have - selectivity/cost. So
why shouldn't this be considered as part of costing?
Yeah, I'm not entirely convinced that we need anything new here.
The cost estimate function can detect such situations, and
On Mon, Apr 8, 2019 at 11:04 PM Peter Eisentraut
wrote:
> Yeah, I think implementing a v4 generator in core would be trivial and
> address almost everyone's requirements.
FWIW, I think that we could do better with nbtree page splits given
sequential UUIDs of one form or another [1]. We could
On Fri, Jun 28, 2019 at 10:16 PM Tom Lane wrote:
>
> Tomas Vondra writes:
> > On Fri, Jun 28, 2019 at 03:03:19PM -0400, Tom Lane wrote:
> >> I not only don't want that function in indxpath.c, I don't even want
> >> it to be known/called from there. If we need the ability for the index
> >> AM
On Fri, Jun 28, 2019 at 09:42:54AM -0400, Adam Berlin wrote:
> Here are my takeaways from the previous discussions:
>
> * there *is* interest in testing
Yep.
> * we shouldn't take it too far
> * there are already tests being written under `src/test/modules`, but
> without a consistent way of
On 6/28/19 1:15 PM, Tom Lane wrote:
Stephen Frost writes:
sh, don't look now, but there might be a "Resend email" button in
the archives now that you can click to have an email sent to you...
Oooh, lovely.
(thank you Magnus)
+many
Thank you, Magnus, this is really helpful!
--
On 2019-Feb-22, Robert Welin wrote:
> I have reproduced this bug on PostgreSQL version 10.7 and 11.2 using the
> steps described in Michael Powers' original report. The issue also still
> seems to be present even with the patch provided by Sergei Kornilov.
>
> Are there plans to address this
On Mon, Jun 24, 2019 at 11:26 PM Ashwin Agrawal wrote:
>
> On Mon, Jun 3, 2019 at 5:24 PM Ashwin Agrawal wrote:
>>
>> There were few more minor typos I had collected for table am, passing them
>> along here.
>>
>> Some of the required callback functions are missing Assert checking (minor
>>
Tomas Vondra writes:
> On Fri, Jun 28, 2019 at 03:03:19PM -0400, Tom Lane wrote:
>> I not only don't want that function in indxpath.c, I don't even want
>> it to be known/called from there. If we need the ability for the index
>> AM to editorialize on the list of indexable quals (which I'm not
On Thu, Jun 27, 2019 at 11:02 AM Pavan Deolasee
wrote:
>
>>> On 2019-04-07 18:04:27 -0700, Andres Freund wrote:
>>> > Here's a *prototype* patch for this. It only implements what I
>>> > described for heap_multi_insert, not for plain inserts. I wanted to see
>>> > what others think before
On Fri, Jun 28, 2019 at 03:03:19PM -0400, Tom Lane wrote:
Julien Rouhaud writes:
On Fri, Jun 28, 2019 at 6:10 PM Tomas Vondra
wrote:
2) I'm not sure it's a good idea to add dependency on a specific AM type
into indxpath.c. At the moment there are only two places, both referring
to
Julien Rouhaud writes:
> On Fri, Jun 28, 2019 at 6:10 PM Tomas Vondra
> wrote:
>> 2) I'm not sure it's a good idea to add dependency on a specific AM type
>> into indxpath.c. At the moment there are only two places, both referring
>> to BTREE_AM_OID, do we really hard-code another OID here?
>>
On Tue, Mar 19, 2019 at 12:38 PM legrand legrand
wrote:
> Would it make sense to add it in auto explain ?
> I don't know for explain itself, but maybe ...
I think that it should appear in EXPLAIN. pg_stat_statements already
cannot have a query hash of zero, so it might be okay to display it
only
On Fri, Jun 28, 2019 at 4:37 PM Daniel Gustafsson wrote:
>
> backend/libpq/be-secure-gssapi.c is including both libpq-be.h and libpq.h,
> which makes libpq-be.h superfluous as it gets included via libpq.h. The
> attached patch removes the inclusion of libpq-be.h to make be-secure-gssapi.c
>
On Tue, Mar 19, 2019 at 12:00 PM Robert Haas wrote:
> On the other hand, it also appears that a lot of people would be very,
> very happy to just be able to see the query ID field that already
> exists, both in pg_stat_statements in pg_stat_activity, and we
> shouldn't throw up unnecessary
OK, here's a completed patch to add checking for naming-rule violations.
I updated regress.sgml to clarify the naming rules (and failed to
resist the temptation to update a lot of other somewhat-obsolete
statements there, too).
Also worth noting is that I added an IsReservedName check to
>Restoring content of FDW table via pg_restore or psql can be dangerous -
>there I see a risk, and can be nice to allow it only >with some form of
>safeguard.
>
>I think so important questions is motivation for dumping FDW - a) clonning
>(has sense for me and it is safe), b) real backup
Here are my takeaways from the previous discussions:
* there *is* interest in testing
* we shouldn't take it too far
* there are already tests being written under `src/test/modules`, but
without a consistent way of describing expectations and displaying results
* no tool was chosen
If we were to
Stephen Frost writes:
> sh, don't look now, but there might be a "Resend email" button in
> the archives now that you can click to have an email sent to you...
Oooh, lovely.
> (thank you Magnus)
+many
regards, tom lane
On Sun, Feb 17, 2019 at 11:31:03PM -0800, Noah Misch wrote:
> I'm forking this thread from
> https://postgr.es/m/flat/20190202083822.gc32...@gust.leadboat.com, which
> reported a race condition involving the "apparent wraparound" safety check in
> SimpleLruTruncate():
>
> On Wed, Feb 13, 2019 at
On Fri, Jun 28, 2019 at 6:10 PM Tomas Vondra
wrote:
>
> I've briefly looked at the patch today. I think the idea is worthwhile,
Thanks!
> 2) I'm not sure it's a good idea to add dependency on a specific AM type
> into indxpath.c. At the moment there are only two places, both referring
> to
Hi,
I've briefly looked at the patch today. I think the idea is worthwhile,
but I found a couple of issues with the patch:
1) The index_selfuncs.h header is included in the wrong place, it should
be included before lsyscache.h (because 'i' < 'l').
2) I'm not sure it's a good idea to add
pá 28. 6. 2019 v 17:30 odesílatel Tom Lane napsal:
> Daniel Gustafsson writes:
> >> On 28 Jun 2019, at 16:49, Luis Carril wrote:
> >> pg_dump ignores the dumping of data in foreign tables
> >> on purpose, this patch makes it optional as the user maybe
> >> wants to manage the data in the
Greetings,
* Thomas Munro (thomas.mu...@gmail.com) wrote:
> If the thread for a CF entry began
> before you were subscribed, you might be able to download the whole
> thread as a mailbox file and import it into your email client so that
> you can reply to the thread; if you can't do that (it can
On Fri, Jun 28, 2019 at 4:39 PM Julien Rouhaud wrote:
>
> On Tue, Mar 19, 2019 at 3:51 PM Julien Rouhaud wrote:
> >
> > On Mon, Mar 18, 2019 at 7:33 PM Julien Rouhaud wrote:
> > >
> > > On Mon, Mar 18, 2019 at 6:23 PM Yun Li wrote:
> > > >
> > > > Let's take one step back. Since queryId is
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Furthermore, while you can do "make install" and "make installcheck"
> in this directory or its children, it is HIGHLY NOT ADVISED to do so
> with a server containing valuable data. Some of these tests may have
> undesirable
Daniel Gustafsson writes:
>> On 28 Jun 2019, at 16:49, Luis Carril wrote:
>> pg_dump ignores the dumping of data in foreign tables
>> on purpose, this patch makes it optional as the user maybe
>> wants to manage the data in the foreign servers directly from
>> Postgres. Opinions?
> Wouldn’t
pá 28. 6. 2019 v 17:17 odesílatel Daniel Gustafsson
napsal:
> > On 28 Jun 2019, at 16:49, Luis Carril wrote:
>
> > pg_dump ignores the dumping of data in foreign tables
> > on purpose, this patch makes it optional as the user maybe
> > wants to manage the data in the foreign servers
I wrote:
> My animal dromedary just reproduced this failure, which we've previously
> only seen on nightjar.
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dromedary=2019-06-26%2023%3A57%3A45
Twice:
Hi
pá 28. 6. 2019 v 16:50 odesílatel Luis Carril
napsal:
> Hello,
> pg_dump ignores the dumping of data in foreign tables
> on purpose, this patch makes it optional as the user maybe
> wants to manage the data in the foreign servers directly from
> Postgres. Opinions?
>
It has sense
> On 28 Jun 2019, at 16:49, Luis Carril wrote:
> pg_dump ignores the dumping of data in foreign tables
> on purpose, this patch makes it optional as the user maybe
> wants to manage the data in the foreign servers directly from
> Postgres. Opinions?
Wouldn’t that have the potential to
Hi
I returned to possibility to sort output of \d* and \l by size. There was
more a experiments in this area, but without success. Last patch was
example of over engineering, and now, I try to implement this feature
simply how it is possible. I don't think so we need too complex solution -
if
Hello,
pg_dump ignores the dumping of data in foreign tables
on purpose, this patch makes it optional as the user maybe
wants to manage the data in the foreign servers directly from
Postgres. Opinions?
Cheers
Luis M Carril
diff --git a/src/bin/pg_dump/pg_backup.h
On Tue, Mar 19, 2019 at 3:51 PM Julien Rouhaud wrote:
>
> On Mon, Mar 18, 2019 at 7:33 PM Julien Rouhaud wrote:
> >
> > On Mon, Mar 18, 2019 at 6:23 PM Yun Li wrote:
> > >
> > > Let's take one step back. Since queryId is stored in core as Julien
> > > pointed out, can we just add that global
backend/libpq/be-secure-gssapi.c is including both libpq-be.h and libpq.h,
which makes libpq-be.h superfluous as it gets included via libpq.h. The
attached patch removes the inclusion of libpq-be.h to make be-secure-gssapi.c
behave like other files which need both headers.
cheers ./daniel
On Sun, Mar 24, 2019 at 11:52 AM Julien Rouhaud wrote:
>
> Marc (in Cc) reported me a problematic query using a GIN index hit in
> production. The issue is that even if an GIN opclass says that the
> index can be used for an operator, it's still possible that some
> values aren't really
On 2019-Jun-28, Surafel Temesgen wrote:
> On Wed, Feb 20, 2019 at 7:04 PM Andres Freund wrote:
> > On February 20, 2019 6:05:53 AM PST, Andrew Dunstan <
> > andrew.duns...@2ndquadrant.com> wrote:
> > >Why log to a file at all? We do have, you know, a database handy, where
> > >we might more
On Fri, Jun 28, 2019 at 9:01 AM Oleg Bartunov wrote:
> On Fri, Jun 28, 2019 at 8:10 AM Alvaro Herrera
> wrote:
> >
> > On 2019-Jun-28, Alexander Korotkov wrote:
> >
> > > On Tue, Jun 25, 2019 at 6:38 PM Liudmila Mantrova
> > > wrote:
> > > > Thank you for the catch! Please see the modified
On Tue, Jun 25, 2019 at 12:42 AM Stephen Frost wrote:
>
> Greetings,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Robert Haas writes:
> > > On Fri, Jun 21, 2019 at 12:55 PM Tom Lane wrote:
> > >> Ah, got it. So it seems like the correct behavior might be for
> > >> ALTER SYSTEM to
> > >> (a)
On Tue, Jun 25, 2019 at 7:31 AM Ian Barwick wrote:
>
> > In particular, in order to consider it unexpected, you have to suppose
> >> that the content rules for postgresql.auto.conf are different from those
> >> for postgresql.conf (wherein we clearly allow last-one-wins). Can you
> >> point
Hi Greg,
On Wed, 3 Apr 2019 17:41:36 -0400
Greg Stark wrote:
> On Sun, 31 Mar 2019 at 23:22, Yugo Nagata wrote:
> >
> > Firstly, this will handle simple definition views which includes only
> > selection, projection, and join. Standard aggregations (count, sum, avg,
> > min, max) are not
On Wed, Feb 20, 2019 at 7:04 PM Andres Freund wrote:
>
>
> On February 20, 2019 6:05:53 AM PST, Andrew Dunstan <
> andrew.duns...@2ndquadrant.com> wrote:
> >
> >On 2/20/19 8:01 AM, Surafel Temesgen wrote:
> >>
> >>
> >> On Tue, Feb 19, 2019 at 3:47 PM Andres Freund >>
Hi,
Attached is a WIP patch of IVM which supports some aggregate functions.
Currently, only count and sum are supported. Avg, min, or max is not supported
although I think supporting this would not be so hard.
As a restriction, expressions specified in GROUP BY must appear in the target
list
Hi Julien,
On Fri, Jun 28, 2019 at 6:54 PM Julien Rouhaud wrote:
> On Fri, Jun 28, 2019 at 11:39 AM Etsuro Fujita
> wrote:
> > In postgresAcquireSampleRowsFunc, we 1) determine the fetch size and
> > then 2) construct the fetch command in each iteration of fetching some
> > rows from the
Hi Jim,
On Fri, 21 Jun 2019 08:41:11 -0700 (MST)
Jim Finnerty wrote:
> Hi Yugo,
>
> I'd like to compare the performance of your MV refresh algorithm versus
> an approach that logs changes into an mv log table, and can then apply the
> changes at some later point in time. I'd like to
On 2019-06-28 09:58, Sergei Kornilov wrote:
> Is this commitfest for small patches and bugfixes, similar to 2018-07 one in
> last year?
There are no restrictions about what can be submitted to this commit
fest. Review early and review often!
--
Peter Eisentraut
> On Fri, Jun 28, 2019 at 11:38 AM Adam Berlin wrote:
>
> During the unconference at PGCon in Ottawa, I asked about writing C-based
> tests for Postgres. There was interest in trying a tool and also some
> hesitation to depend on a third-party library. So, I wrote a tool that I'd
> like to
On Sat, Jun 22, 2019 at 2:51 AM Robert Haas wrote:
>
> On Thu, Jun 20, 2019 at 4:54 AM Dilip Kumar wrote:
> > The idea behind having the loop inside the undo machinery was that
> > while traversing the blkprev chain, we can read all the undo records
> > on the same undo page under one buffer
On Fri, Jun 28, 2019 at 11:39 AM Etsuro Fujita wrote:
>
> In postgresAcquireSampleRowsFunc, we 1) determine the fetch size and
> then 2) construct the fetch command in each iteration of fetching some
> rows from the remote, but that would be totally redundant.
Indeed.
> Attached
> is a patch
Here is a new patch after the discussion.
- Rename allow_system_table_mods to allow_system_table_ddl.
(This makes room for a new allow_system_table_dml, but it's not
implemented here.)
- Make allow_system_table_ddl SUSET.
- Add regression test.
- Remove the behavior that
Hi,
In postgresAcquireSampleRowsFunc, we 1) determine the fetch size and
then 2) construct the fetch command in each iteration of fetching some
rows from the remote, but that would be totally redundant. Attached
is a patch for removing that redundancy.
I'll add this to the upcoming commitfest.
During the unconference at PGCon in Ottawa, I asked about writing C-based
tests for Postgres. There was interest in trying a tool and also some
hesitation to depend on a third-party library. So, I wrote a tool that I'd
like to contribute to Postgres. I’ve been calling it cexpect [1]
Hello
Is this commitfest for small patches and bugfixes, similar to 2018-07 one in
last year?
regards, Sergei
Hello Thomas,
The first Commitfest[1] for the next major release of PostgreSQL
begins in a few days, and runs for the month of July.
There are 218 patches registered[2] right now,
ISTM that there are a couple of duplicates: 2084 & 2150, 2119 & 2180?
I volunteered to be the CF manager
On Mon, May 13, 2019 at 5:09 AM Michael Paquier wrote:
>
> On Sun, May 12, 2019 at 11:16:28AM +0200, Julien Rouhaud wrote:
> > I attach two patches to fix both (it could be squashed in a single
> > commit as both are straightforward), for upcoming v13.
>
> Squashing both patches together makes
On 2019-06-12 15:34, Tom Lane wrote:
> A bigger objection might be that this would leave us with no obvious-
> to-the-untrained-eye declaration point for either the struct name or
> the two typedef names. That might make tools like ctags sad. Perhaps
> it's not really any worse than today, but
On Fri, Jun 28, 2019 at 8:10 AM Alvaro Herrera wrote:
>
> On 2019-Jun-28, Alexander Korotkov wrote:
>
> > On Tue, Jun 25, 2019 at 6:38 PM Liudmila Mantrova
> > wrote:
> > > Thank you for the catch! Please see the modified version of patch 0004
> > > attached.
> >
> > I tried to review and revise
64 matches
Mail list logo
