Hi
rebase
Pavel
diff --git a/contrib/decode/.gitignore b/contrib/decode/.gitignore
new file mode 100644
index 00..5dcb3ff972
--- /dev/null
+++ b/contrib/decode/.gitignore
@@ -0,0 +1,4 @@
+# Generated subdirectories
+/log/
+/results/
+/tmp_check/
diff --git a/contrib/decode/Makefile b/cont
On Tue, 13 Aug 2019 at 21:50, Konstantin Knizhnik
wrote:
> As far as I understand relpages and reltuples are set only when you
>> perform "analyze" of the table.
>>
>
> Also autovacuum's autoanalyze.
>
>
> When it happen?
> I have created normal table, populated it with some data and then wait
>
On Thu, Aug 15, 2019 at 8:31 PM Etsuro Fujita wrote:
> While working on the PWJ patch [1], I noticed $SUBJECT. They seem to
> be leftovers from the original partitionwise-join patch, perhaps.
> Attached is a patch for removing them.
Pushed.
Best regards,
Etsuro Fujita
Hi,
On 2019-08-16 09:44:25 +0530, Dilip Kumar wrote:
> On Wed, Aug 14, 2019 at 2:48 PM Dilip Kumar wrote:
> >
> > On Wed, Aug 14, 2019 at 12:27 PM Andres Freund wrote:
>
> > > I think that batch reading should just copy the underlying data into a
> > > char* buffer. Only the records that cu
Hi Kuntal,
On Thu, Jul 25, 2019 at 5:40 PM Kuntal Ghosh wrote:
> Here are some review comments on 0003-Add-undo-log-manager.patch. I've
> tried to avoid duplicate comments as much as possible.
Thanks! Replies inline. I'll be posting a new patch set shortly with
these and other fixes.
> 1. In
Hi Amit,
I've combined three of your messages into one below, and responded
inline. New patch set to follow shortly, with the fixes listed below
(and others from other reviewers).
On Wed, Jul 24, 2019 at 9:15 PM Amit Kapila wrote:
> 0003-Add-undo-log-manager.patch
> 1.
> allocate_empty_undo_seg
On Fri, Aug 16, 2019 at 10:01 AM Stephen Frost wrote:
>
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Thu, Aug 15, 2019 at 06:10:24PM +0900, Masahiko Sawada wrote:
> > > On Thu, Aug 15, 2019 at 10:19 AM Bruce Momjian wrote:
> > > >
> > > > On Wed, Aug 14, 2019 at 04:36:35PM +0
On Wed, Aug 14, 2019 at 2:48 PM Dilip Kumar wrote:
>
> On Wed, Aug 14, 2019 at 12:27 PM Andres Freund wrote:
> > I think that batch reading should just copy the underlying data into a
> > char* buffer. Only the records that currently are being used by
> > higher layers should get exploded
On Wed, Aug 14, 2019 at 10:35 PM Andres Freund wrote:
>
> Hi,
>
> On 2019-08-14 14:48:07 +0530, Dilip Kumar wrote:
> > On Wed, Aug 14, 2019 at 12:27 PM Andres Freund wrote:
> > > - I think there's two fairly fundamental, and related, problems with
> > > the sequence outlined above:
> > >
> > >
On Wed, Jul 17, 2019 at 10:00 AM Gareth Palmer wrote:
>
> Hello,
>
> Attached is a patch that adds the option of using SET clause to specify
> the columns and values in an INSERT statement in the same manner as that
> of an UPDATE statement.
>
> A simple example that uses SET instead of a VALUES()
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Wed, 2019-08-14 at 11:38 +0900, Michael Paquier wrote:
> > What I got in mind was a comma-separated list of authorized protocols
> > which can be specified as a connection parameter, which extends to
> > all
> > the types of AUTH_REQ requests
Hi Ibrar,
> On 16/08/2019, at 7:14 AM, Ibrar Ahmed wrote:
>
> Patch conflict with this assertion
> Assert(pstate->p_expr_kind == EXPR_KIND_UPDATE_SOURCE);
>
> src/backend/parser/parse_expr.c line 1570
>
> The new status of this patch is: Waiting on Author
Thank-you for reviewing the patch.
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Aug 15, 2019 at 06:10:24PM +0900, Masahiko Sawada wrote:
> > On Thu, Aug 15, 2019 at 10:19 AM Bruce Momjian wrote:
> > >
> > > On Wed, Aug 14, 2019 at 04:36:35PM +0200, Antonin Houska wrote:
> > > > I can work on it right away but don
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Aug 15, 2019 at 11:24:46AM +0200, Antonin Houska wrote:
> > > I think there are several directions we can go after all-cluster
> > > encryption,
> >
> > I think I misunderstood. What you summarize in
> >
> > https://wiki.postgresql.o
On Fri, Aug 16, 2019 at 10:55 AM Chapman Flack wrote:
> On 08/15/19 02:58, Yonatan Misgan wrote:
> > From this source code how can I get only the year to convert my own
> > calendar year. I need this because Ethiopian calendar is totally differ
> > from GC in terms of day, month and year.
>
> I f
On 08/15/19 02:58, Yonatan Misgan wrote:
> From this source code how can I get only the year to convert my own
> calendar year. I need this because Ethiopian calendar is totally differ
> from GC in terms of day, month and year.
I find myself wondering whether getting only the year is sufficient
On Wed, Aug 14, 2019 at 05:24:26PM +1200, Thomas Munro wrote:
On Wed, Aug 14, 2019 at 5:06 PM Tom Lane wrote:
Oh, hmm --- yeah, that should mean it's safe. Maybe somebody incautiously
changed one of the other tests that run concurrently with "rules"?
Looks like stats_ext.sql could be the pro
On Wed, Aug 14, 2019 at 07:25:10PM +1200, David Rowley wrote:
On Thu, 25 Jul 2019 at 05:49, Tom Lane wrote:
On the whole, I don't especially like this approach, because of the
confusion between peak lock count and end-of-xact lock count. That
seems way too likely to cause problems.
Thanks fo
On Thu, Aug 15, 2019 at 06:58:07AM +, Yonatan Misgan wrote:
Hello, I am trying to develop calendar extension for PostgreSQL but
there is a difficulties on how to get day, month and year from
PostgreSQL source code because when am read the PostgreSQL source code
it uses DateADT as a data type
On Fri, Aug 16, 2019 at 12:16 AM <066ce...@free.fr> wrote:
> Generally speaking, when executing UNION ; a DISTINCT is run afterward on
> the resultset.
>
> So, if you're sure that each part of UNION cannot return a line returned
> by another one, you may use UNION ALL, you'll cut the cost of the f
Generally speaking, when executing UNION ; a DISTINCT is run afterward on the
resultset.
So, if you're sure that each part of UNION cannot return a line returned by
another one, you may use UNION ALL, you'll cut the cost of the final implicit
DISTINCT.
- Mail original -
De: "Mark Past
Patch conflict with this assertion
Assert(pstate->p_expr_kind == EXPR_KIND_UPDATE_SOURCE);
src/backend/parser/parse_expr.c line 1570
The new status of this patch is: Waiting on Author
Mark Pasterkamp writes:
> I was wondering if someone could help me understands what a union all
> actually does.
Generally speaking, it runs the first query and then the second query.
You'd really need to provide a lot more detail for anyone to say more
than that.
https://wiki.postgresql.org/wik
Dear all,
I was wondering if someone could help me understands what a union all
actually does.
For my thesis I am using Apache Calcite to rewrite queries into using
materialized views which I then give to a Postgres database.
For some queries, this means that they will be rewritten in a UNION ALL
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
The patch passed my review, I have not reviewed the documentation
On Wed, Jul 10, 2019 at 11:33 AM Fabien COELHO wrote:
>
> Hello Ibrar,
>
> >> SELECT 1 AS one \;
> >> SELECT 2 AS two UNION SELECT 2 \;
> >> SELECT 3 AS three \aset
> >>
> >> will set both "one" and "three", while "two" is not set because there
> were
> >> two rows. It is a kind of more permis
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> In hopes of moving this along, I've pushed Ian's last code change,
>> as there seems to be no real argument about that anymore.
>>
>> As for the doc changes, how about the attached revision of what
>> I wrote previously? It gives
On Thu, Aug 15, 2019 at 11:24:46AM +0200, Antonin Houska wrote:
> > I think there are several directions we can go after all-cluster
> > encryption,
>
> I think I misunderstood. What you summarize in
>
> https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#TODO_for_Full-Cluster_Encryption
On Thu, Aug 15, 2019 at 06:10:24PM +0900, Masahiko Sawada wrote:
> On Thu, Aug 15, 2019 at 10:19 AM Bruce Momjian wrote:
> >
> > On Wed, Aug 14, 2019 at 04:36:35PM +0200, Antonin Houska wrote:
> > > I can work on it right away but don't know where to start.
> >
> > I think the big open question is
Hi
> Sergei, can we enlist you to submit a patch for this? Namely reduce the
> log level to DEBUG1 and add a TAP test in src/test/modules/alter_table/
> that verifies that the message is or isn't emitted, as appropriate.
Yes, will do. Probably in few days.
regards, Sergei
> 13 авг. 2019 г., в 20:30, Peter Geoghegan написал(а):
>
> That's one possibility. When I first designed amcheck it was important
> to be conservative, so I invented a general rule about never acquiring
> multiple buffer locks at once. I still think that that was the correct
> decision for the
Alexander Korotkov writes:
> On Thu, Aug 15, 2019 at 2:08 AM Tom Lane wrote:
>> Or maybe we're just being too ambitious here and we should discard some of
>> this information. I'm not really sure that the format_operator result
>> can be included without complete loss of intelligibility.
> Coul
On Wed, Aug 14, 2019 at 09:19:44PM -0400, Bruce Momjian wrote:
> I think there are several directions we can go after all-cluster
> encryption, and it does matter because we would want minimal API
> breakage. The options are:
>
> 1) Allow per-table encyption control to limit encryption overhead,
This is an implementation of the idea I mentioned in [0].
The naming and description perhaps isn't ideal yet but it works in
principle.
The idea is that if you connect over a Unix-domain socket and the local
(effective) user is the same as the server's (effective) user, then
access should be gran
Hi,
While working on the PWJ patch [1], I noticed $SUBJECT. They seem to
be leftovers from the original partitionwise-join patch, perhaps.
Attached is a patch for removing them.
Best regards,
Etsuro Fujita
[1]
https://www.postgresql.org/message-id/CAPmGK16wDqJiUof8+e4HuGmrAqqoFzb=iQX4V+xicsJ5_
On 30.07.2019 16:12, Tomas Vondra wrote:
On Tue, Jul 30, 2019 at 01:01:48PM +0300, Konstantin Knizhnik wrote:
On 30.07.2019 4:02, Tomas Vondra wrote:
My idea (sorry if it wasn't too clear) was that we might handle some
cases more gracefully.
For example, if we only switch between transact
On 14/08/2019 20:32, Ashwin Agrawal wrote:
On Wed, Aug 14, 2019 at 2:51 AM Ashutosh Sharma wrote:
2) Is there a chance that IndexOnlyScan would ever be required for
zedstore tables considering the design approach taken for it?
We have not given much thought to IndexOnlyScans so far. But I t
Bruce Momjian wrote:
> On Wed, Aug 14, 2019 at 04:36:35PM +0200, Antonin Houska wrote:
> > I can work on it right away but don't know where to start.
>
> I think the big open question is whether there will be acceptance of an
> all-cluster encyption feature. I guess if no one objects, we can mo
On Thu, Aug 15, 2019 at 10:19 AM Bruce Momjian wrote:
>
> On Wed, Aug 14, 2019 at 04:36:35PM +0200, Antonin Houska wrote:
> > I can work on it right away but don't know where to start.
>
> I think the big open question is whether there will be acceptance of an
> all-cluster encyption feature. I g
On Thu, Aug 15, 2019 at 5:49 PM Tom Lane wrote:
> So that leads to the thought that "the infinite_recurse test is fine
> if it runs by itself, but it tends to fall over if there are
> concurrently-running backends". I have absolutely no idea how that
> would happen on anything that passes for a p
40 matches
Mail list logo
