On Thu, Mar 8, 2018 at 12:27 AM, Robert Haas wrote:
> New patches attached, fixing all 3 of the issues you reported:
>
Thanks. new patches applied cleanly on head and fixing all reported issue.
Thanks & Regards,
Rajkumar Raghuwanshi
QMG, EnterpriseDB Corporation
On Wed, Mar 7, 2018 at 8:07 PM, Jeevan Chalke
wrote:
Here are some more review comments esp. on
try_partitionwise_grouping() function. BTW name of that function
doesn't go in sync with enable_partitionwise_aggregation (which btw is
in sync with enable_fooagg GUCs). But it goes in sync with
create_
2018-03-07 22:16 GMT+01:00 David Fetter :
> On Wed, Mar 07, 2018 at 09:37:26PM +0100, Pavel Stehule wrote:
> > 2018-03-07 21:31 GMT+01:00 Daniel Verite :
> >
> > > David Fetter wrote:
> > >
> > > > We have some inconsistency here in that fewer table formats are
> > > > supported, but I thi
Hi
2018-03-08 1:53 GMT+01:00 Peter Eisentraut :
> On 3/6/18 04:22, Pavel Stehule wrote:
> > why just OUT variables are disallowed?
> >
> > The oracle initializes these values to NULL - we can do same?
>
> The problem is function call resolution. If we see a call like
>
> CALL foo(a, b, c);
>
> t
On Thu, Mar 8, 2018 at 12:31 PM, Amit Kapila
wrote:
> On Thu, Mar 8, 2018 at 11:04 AM, Pavan Deolasee
> wrote:
> >
> > On Tue, Feb 13, 2018 at 12:41 PM, amul sul wrote:
> >>
> >> Thanks for the confirmation, updated patch attached.
> >>
> >
> > I am actually very surprised that 0001-Invalidate-
On 8 March 2018 at 12:34, Amit Kapila wrote:
> On Thu, Mar 8, 2018 at 11:57 AM, Amit Khandekar
> wrote:
>> On 8 March 2018 at 09:15, Pavan Deolasee wrote:
>>> For example, with your patches applied:
>>>
>>> CREATE TABLE pa_target (key integer, val text)
>>> PARTITION BY LIST (key);
>>> CREA
Some updates on patch status:
- "version-dependent-tab-completion-1.patch" by Tom Lane was committed in
722408bcd.
- "psql-tab-completion-savepoint-v1.patch" by Edmund Horner is probably not
needed.
- "psql-select-tab-completion-v6.patch" (the latest) is still under
development/review.
On Thu, Mar 8, 2018 at 11:57 AM, Amit Khandekar wrote:
> On 8 March 2018 at 09:15, Pavan Deolasee wrote:
>> For example, with your patches applied:
>>
>> CREATE TABLE pa_target (key integer, val text)
>> PARTITION BY LIST (key);
>> CREATE TABLE part1 PARTITION OF pa_target FOR VALUES IN (1);
On 8 March 2018 at 12:34, Tom Lane wrote:
> Craig Ringer writes:
> > As I understand it, because we allow multiple Pg instances on a system,
> we
> > identify the small sysv shmem segment we use by the postmaster's pid. If
> > you remove the DirLockFile (postmaster.pid) you remove the interlock
On Thu, Mar 8, 2018 at 11:04 AM, Pavan Deolasee
wrote:
>
> On Tue, Feb 13, 2018 at 12:41 PM, amul sul wrote:
>>
>> Thanks for the confirmation, updated patch attached.
>>
>
> I am actually very surprised that 0001-Invalidate-ip_blkid-v5.patch does not
> do anything to deal with the fact that t_ct
On 8 March 2018 at 09:15, Pavan Deolasee wrote:
> For example, with your patches applied:
>
> CREATE TABLE pa_target (key integer, val text)
> PARTITION BY LIST (key);
> CREATE TABLE part1 PARTITION OF pa_target FOR VALUES IN (1);
> CREATE TABLE part2 PARTITION OF pa_target FOR VALUES IN (2);
On Tue, Mar 6, 2018 at 8:15 PM, David Rowley
wrote:
> On 6 March 2018 at 22:40, David Rowley wrote:
>> Okay, it looks like the patch should disable physical tlists when
>> there's a missing column the same way as we do for dropped columns.
>> Patch attached.
>
> Please disregard the previous patc
On Sun, Mar 4, 2018 at 3:18 PM, David Gould wrote:
> On Sun, 4 Mar 2018 07:49:46 -0800
> Jeff Janes wrote:
>
> > On Wed, Jan 17, 2018 at 4:49 PM, David Gould wrote:
> ...
> >
> > Maybe a well-timed crash caused n_dead_tup to get reset to zero and that
> is
> > why autovac is not kicking in? Wh
On Tue, Feb 13, 2018 at 12:41 PM, amul sul wrote:
>
> Thanks for the confirmation, updated patch attached.
>
>
I am actually very surprised that 0001-Invalidate-ip_blkid-v5.patch does
not do anything to deal with the fact that t_ctid may no longer point to
itself to mark end of the chain. I just
In the thread about being able to prove constraint exclusion from
an IN clause mentioning a NULL,
https://www.postgresql.org/message-id/flat/3bad48fc-f257-c445-feeb-8a2b2fb62...@lab.ntt.co.jp
I expressed concern about whether there were existing bugs in predtest.c
given the lack of clarity of the c
On Wed, Mar 7, 2018 at 8:55 AM, Stephen Frost wrote:
> Greetings Robert, Ashutosh, Arthur, Etsuro, all,
>
> * Arthur Zakirov (a.zaki...@postgrespro.ru) wrote:
>> On Tue, Mar 06, 2018 at 08:09:50PM +0900, Etsuro Fujita wrote:
>> > Agreed. I added a comment to that function. I think that that comm
Craig Ringer writes:
> As I understand it, because we allow multiple Pg instances on a system, we
> identify the small sysv shmem segment we use by the postmaster's pid. If
> you remove the DirLockFile (postmaster.pid) you remove the interlock
> against starting a new postmaster. It'll think it's
New patch that fixes a little bug with appending NULL addons to schema queries.
psql-select-tab-completion-v6.patch
Description: Binary data
Kyotaro HORIGUCHI writes:
> At Thu, 8 Mar 2018 00:28:04 +, "Tsunakawa, Takayuki"
> wrote in
> <0A3221C70F24FB45833433255569204D1F8FF0D9@G01JPEXMBYT05>
>> Yes. We are now facing the problem of too much memory use by PostgreSQL,
>> where about some applications randomly access about 200,000
On 8 March 2018 at 10:18, Andres Freund wrote:
>
>
> On March 7, 2018 5:51:29 PM PST, Craig Ringer
> wrote:
> >My favourite remains an organisation that kept "fixing" an issue by
> >kill
> >-9'ing the postmaster and removing postmaster.pid to make it start up
> >again. Without killing all the le
Hello,
At Thu, 8 Mar 2018 00:28:04 +, "Tsunakawa, Takayuki"
wrote in
<0A3221C70F24FB45833433255569204D1F8FF0D9@G01JPEXMBYT05>
> From: Alvaro Herrera [mailto:alvhe...@alvh.no-ip.org]
> > The thing that comes to mind when reading this patch is that some time ago
> > we made fun of other datab
On Wed, Feb 28, 2018 at 12:38 PM, Rajkumar Raghuwanshi <
rajkumar.raghuwan...@enterprisedb.com> wrote:
> On Wed, Feb 14, 2018 at 5:44 PM, Amit Kapila
> wrote:
>
>> +# Concurrency error from GetTupleForTrigger
>> +# Concurrency error from ExecLockRows
>>
>> I think you don't need to mention above
On Fri, Mar 2, 2018 at 5:17 PM, Tom Lane wrote:
> (1) do we really want to go over to treating ANALYZE's tuple density
> result as gospel, contradicting the entire thrust of the 2011 discussion?
>
>> This tables reltuples is 18 times the actual row count. It will never
>> converge
>> because with
On Wed, Mar 7, 2018 at 6:43 PM, Michael Paquier wrote:
> On Wed, Mar 07, 2018 at 06:39:32PM -0500, Tom Lane wrote:
>> OK, seems like I'm on the short end of that vote. I propose to push the
>> GUC-crosschecking patch I posted yesterday, but not the default-value
>> change, and instead push Kyotar
On Tue, 06 Mar 2018 11:16:04 -0500
Tom Lane wrote:
> so that we can decide whether this bug is bad enough to justify
> back-patching a behavioral change. I remain concerned that the proposed
> fix is too simplistic and will have some unforeseen side-effects, so
> I'd really rather just put it in
At Wed, 7 Mar 2018 07:10:34 -0300, Alvaro Herrera
wrote in <20180307101034.l7z7kqwqfkjg6c2p@alvherre.pgsql>
> Kyotaro HORIGUCHI wrote:
>
> > 1. some messages are missing partitioned table/index
..
> I *think* the idea here is that a partitioned table is a table, so there
> is no need to say "foo
On March 7, 2018 5:51:29 PM PST, Craig Ringer wrote:
>My favourite remains an organisation that kept "fixing" an issue by
>kill
>-9'ing the postmaster and removing postmaster.pid to make it start up
>again. Without killing all the leftover backends. Of course, the system
>kept getting more unsta
Alvaro Herrera wrote:
> I reserve the right to revise this further, as I'm going to spend a
> couple of hours looking at it this afternoon, particularly to see how
> concurrent DDL behaves, but I don't see anything obviously wrong with
> it.
I do now. TLDR; I'm afraid this cute idea crashed and
On Thu, Mar 1, 2018 at 2:47 PM, Peter Geoghegan wrote:
> No. Just an oversight. Looks like _bt_parallel_build_main() should
> call pgstat_report_activity(), just like ParallelQueryMain().
>
> I'll come up with a patch soon.
Attached patch has parallel CREATE INDEX propagate debug_query_string
to
On 8 March 2018 at 04:58, Robert Haas wrote:
> On Wed, Feb 28, 2018 at 8:03 PM, Craig Ringer
> wrote:
> > A huge +1 from me for the idea. I can't even count the number of black
> box
> > "WTF did you DO?!?" servers I've looked at, where bizarre behaviour has
> > turned out to be down to the user
On Wed, Mar 07, 2018 at 10:56:32AM -0500, David Steele wrote:
> On 3/6/18 10:04 PM, Michael Paquier wrote:
>> Seems like you forgot to re-add the chmod calls in initdb.c.
>
> Hmmm, I thought we were talking about moving the position of umask().
>
> I don't think the chmod() calls are needed becau
On 8 March 2018 at 07:32, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Mar 1, 2018 at 2:03 AM, Craig Ringer
> wrote:
> >> So I can't say it's definitely impossible. It seems astonishingly
> unlikely,
> >> but that's not always good enough.
>
> > Race conditions tend to happen a lot more of
On March 7, 2018 5:40:18 PM PST, Peter Geoghegan wrote:
>On Wed, Mar 7, 2018 at 5:16 PM, Tomas Vondra
> wrote:
>> FWIW that's usually written to the system log. Does dmesg say
>something
>> about the kill?
>
>While it would be nice to confirm that it was indeed the OOM killer,
>either way the cr
On Wed, Mar 7, 2018 at 5:16 PM, Tomas Vondra
wrote:
> FWIW that's usually written to the system log. Does dmesg say something
> about the kill?
While it would be nice to confirm that it was indeed the OOM killer,
either way the crash happened because SIGKILL was sent to a parallel
worker. There i
Hi,
I’ve been encouraged to submit this code as there has been talk in the past
about a simple pgcopy command to use with the archive_command. Currently there
is really no good solution in most base systems without having to introduce a
dedicated third party Postgres solution. The best base
On Thu, Mar 08, 2018 at 10:15:11AM +0900, Michael Paquier wrote:
> Other than that the patch looks in pretty good shape to me.
The regression tests of file_fdw are blowing up because of an error
string patch 2 changes.
--
Michael
signature.asc
Description: PGP signature
On 03/07/2018 03:21 PM, Robert Haas wrote:
> On Wed, Mar 7, 2018 at 8:59 AM, Prabhat Sahu
> mailto:prabhat.s...@enterprisedb.com>>
> wrote:
>
> 2018-03-07 19:24:44.263 IST [54400] LOG: background worker
> "parallel worker" (PID 54482) was terminated by signal 9: Killed
>
>
> That looks
On Wed, Mar 07, 2018 at 07:00:03AM -0500, Stephen Frost wrote:
> * Michael Paquier (mich...@paquier.xyz) wrote:
>> First, could it be possible to do a split for 1) and 2)?
>
> Done, because it was less work than arguing about it, but I'm not
> convinced that we really need to split out patches to
On 3/6/18 04:22, Pavel Stehule wrote:
> why just OUT variables are disallowed?
>
> The oracle initializes these values to NULL - we can do same?
The problem is function call resolution. If we see a call like
CALL foo(a, b, c);
the this could be foo() with zero input and three output parameters
On Wed, Mar 7, 2018 at 11:13 PM, Alvaro Herrera wrote:
> 0001:
>
> there are a bunch of other messages of the same ilk in the file. I
> don't like how the current messages are worded; maybe Peter or Petr had
> some reason why they're like that, but I would have split out the reason
> for not star
On 03/06/2018 06:23 AM, Yura Sokolov wrote:
> 05.03.2018 18:00, Tom Lane пишет:
>> Tomas Vondra writes:
>>> Snapshots are static (we don't really add new XIDs into existing ones,
>>> right?), so why don't we simply sort the XIDs and then use bsearch to
>>> lookup values? That should fix the linear
From: Alvaro Herrera [mailto:alvhe...@alvh.no-ip.org]
> The thing that comes to mind when reading this patch is that some time ago
> we made fun of other database software, "they are so complicated to configure,
> they have some magical settings that few people understand how to set".
> Postgres wa
On Wed, Mar 07, 2018 at 06:39:32PM -0500, Tom Lane wrote:
> OK, seems like I'm on the short end of that vote. I propose to push the
> GUC-crosschecking patch I posted yesterday, but not the default-value
> change, and instead push Kyotaro-san's initdb change. Should we back-patch
> these things t
Robert Haas writes:
> On Tue, Mar 6, 2018 at 10:51 PM, Stephen Frost wrote:
>> Changing the defaults to go back down strikes me as an entirely wrong
>> approach after we've had a release with the higher defaults without
>> seriously compelling arguments against, and I don't agree that we've had
>
Robert Haas writes:
> On Thu, Mar 1, 2018 at 2:03 AM, Craig Ringer wrote:
>> So I can't say it's definitely impossible. It seems astonishingly unlikely,
>> but that's not always good enough.
> Race conditions tend to happen a lot more often than one might think.
Just to back that up --- we've s
Robert Haas writes:
> On Wed, Feb 28, 2018 at 9:34 PM, Peter Eisentraut
> wrote:
>> Except ... this doesn't actually work. find_my_exec() resolves symlinks
>> to find the actual program installation, and so for example the
>> installed initdb will look for postgres in src/bin/initdb/. I would
>
On Thu, Mar 1, 2018 at 2:03 AM, Craig Ringer wrote:
> So I can't say it's definitely impossible. It seems astonishingly unlikely,
> but that's not always good enough.
Race conditions tend to happen a lot more often than one might think.
If there's a theoretical opportunity for this to go wrong, i
On Wed, Feb 28, 2018 at 6:59 PM, Euler Taveira wrote:
> This is a cosmetic patch that removes some unused includes in
> test_decoding. It seems to be like this since day 1 (9.4).
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Wed, Mar 7, 2018 at 2:48 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 3/7/18 10:05, Stephen Frost wrote:
> > I liken this to a well-known and well-trodden feature for auto creating
> > user home directories on Unix.
>
> I don't think likening schemas to home directories
On Wed, Feb 28, 2018 at 9:34 PM, Peter Eisentraut
wrote:
> Except ... this doesn't actually work. find_my_exec() resolves symlinks
> to find the actual program installation, and so for example the
> installed initdb will look for postgres in src/bin/initdb/. I would
> like to revert this behavio
On 3/7/18 10:05, Stephen Frost wrote:
> I liken this to a well-known and well-trodden feature for auto creating
> user home directories on Unix.
I don't think likening schemas to home directories is really addressing
the most typical use cases. Database contents are for the most part
carefully co
On Wed, Feb 28, 2018 at 11:35 PM, Thomas Munro
wrote:
> On Mon, Feb 26, 2018 at 6:37 PM, Thomas Munro
> wrote:
>> I've now broken it into two patches.
>
> Rebased.
+SerializableXactHandle
+ShareSerializableXact(void)
+{
+Assert(!IsParallelWorker());
+
+return MySerializableXact;
+}
Uh,
On Wed, Mar 07, 2018 at 09:37:26PM +0100, Pavel Stehule wrote:
> 2018-03-07 21:31 GMT+01:00 Daniel Verite :
>
> > David Fetter wrote:
> >
> > > We have some inconsistency here in that fewer table formats are
> > > supported, but I think asciidoc, etc., do this correctly via
> > > invocatio
On Wed, Feb 28, 2018 at 8:03 PM, Craig Ringer wrote:
> A huge +1 from me for the idea. I can't even count the number of black box
> "WTF did you DO?!?" servers I've looked at, where bizarre behaviour has
> turned out to be down to the user doing something very silly and not saying
> anything about
On Tue, Mar 6, 2018 at 10:51 PM, Stephen Frost wrote:
> Changing the defaults to go back down strikes me as an entirely wrong
> approach after we've had a release with the higher defaults without
> seriously compelling arguments against, and I don't agree that we've had
> such a case made here. I
2018-03-07 21:31 GMT+01:00 Daniel Verite :
> David Fetter wrote:
>
> > We have some inconsistency here in that fewer table formats are
> > supported, but I think asciidoc, etc., do this correctly via
> > invocations like:
> >
> >psql -P format=asciidoc -o foo.adoc -AtXc 'TABLE foo'
>
>
On Thu, Mar 8, 2018 at 6:17 AM, Alvaro Herrera wrote:
> Here's another version of this patch. It is virtually identical to the
> previous one, except for a small doc update and whitespace changes.
What is this test for?
+create trigger failed after update on parted_trig
+ referencing old table
David Fetter wrote:
> We have some inconsistency here in that fewer table formats are
> supported, but I think asciidoc, etc., do this correctly via
> invocations like:
>
>psql -P format=asciidoc -o foo.adoc -AtXc 'TABLE foo'
-A is equivalent to -P format=unaligned, so in the above
i
On Wed, Mar 7, 2018 at 6:01 AM, Alvaro Herrera wrote:
> The thing that comes to mind when reading this patch is that some time
> ago we made fun of other database software, "they are so complicated to
> configure, they have some magical settings that few people understand
> how to set". Postgres
On Mon, Mar 5, 2018 at 10:38 AM, Robert Haas wrote:
> While trying to track down a bug today, I found a different bug.
>
> As of 6946280cded903b6f5269fcce105f8ab1d455d33:
>
> rhaas=# create table foo (a int);
> CREATE TABLE
> rhaas=# set min_parallel_table_scan_size = 0;
> SET
> rhaas=# set parall
David Fetter wrote:
> This seems pretty specialized. If we're adding something new, how about
>
>psql --format=csv -o foo.csv -c 'TABLE foo'
It's a bit easier to memorize than -P format=csv,
but psql doesn't have any long option that does not a have a short
form with a single lette
I wrote:
> a better idea would to have a new \pset fieldsep_csv
PFA a v3 patch that implements that, along with
regression tests this time.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
diff --git a/doc/src/sgml/ref/psql-ref.sgml b
2018-03-07 20:25 GMT+01:00 David Fetter :
> On Wed, Mar 07, 2018 at 08:04:05PM +0100, Fabien COELHO wrote:
> >
> > >> psql --csv -c 'TABLE foo' > foo.csv
> > >>
> > >>With a -c to introduce the command.
> > >
> > >This seems pretty specialized. If we're adding something new, how about
> > >
> >
On Wed, Mar 07, 2018 at 08:04:05PM +0100, Fabien COELHO wrote:
>
> >> psql --csv -c 'TABLE foo' > foo.csv
> >>
> >>With a -c to introduce the command.
> >
> >This seems pretty specialized. If we're adding something new, how about
> >
> > psql --format=csv -o foo.csv -c 'TABLE foo'
> >
> >Or we
Hi all,
The attached patch just fix missing spaces in documentation of CREATE
SERVER and CREATE USER MAPPING.
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
>> Linkedin: http://br.linkedin.com/in/
psql --csv -c 'TABLE foo' > foo.csv
With a -c to introduce the command.
This seems pretty specialized. If we're adding something new, how about
psql --format=csv -o foo.csv -c 'TABLE foo'
Or we could stick with:
psql -P format=csv -o foo.csv -c 'TABLE foo'
Currently "-P format=c
On Wed, Mar 7, 2018 at 5:36 AM, Rajkumar Raghuwanshi
wrote:
> With 0001 applied on PG-head, I got reference leak warning and later a
> server crash.
> this crash is reproducible with enable_parallel_append=off also.
> below is the test case to reproduce this.
New patches attached, fixing all 3 of
Hello Andres,
working on overflow correctness in pg I noticed that pgbench isn't quite
there.
Indeed.
I assume it won't matter terribly often, but the way it parses integers
makes it incorrect for, at least, the negativemost number. [...] but
that unfortunately means that the sign is no in
On Wed, Mar 07, 2018 at 07:40:49PM +0100, Fabien COELHO wrote:
>
> Hello Pavel,
>
> >>psql --csv 'TABLE Stuff;' > stuff.csv
> >
> >There is commad -c and it should be used. The --csv options should not to
> >have a parameter. I don't like a idea to have more options for query
> >execution
2018-03-07 19:40 GMT+01:00 Fabien COELHO :
>
> Hello Pavel,
>
> psql --csv 'TABLE Stuff;' > stuff.csv
>>>
>>
>> There is commad -c and it should be used. The --csv options should not to
>> have a parameter. I don't like a idea to have more options for query
>> execution.
>>
>
> Yes, I agre
Hello Pavel,
psql --csv 'TABLE Stuff;' > stuff.csv
There is commad -c and it should be used. The --csv options should not to
have a parameter. I don't like a idea to have more options for query
execution.
Yes, I agree and that is indeed what I meant, sorry for the typo. The
cleaner
Em 3 de mar de 2018 19:32, "Peter Eisentraut" <
peter.eisentr...@2ndquadrant.com> escreveu:
On 2/20/18 10:10, Matheus de Oliveira wrote:
> Besides that, there is a another change in this patch on current ALTER
> CONSTRAINT about deferrability options. Previously, if the user did
> ALTER CONSTRAINT
Em 2 de mar de 2018 08:15, "Andres Freund" escreveu:
Hi,
On 2018-02-20 12:10:22 -0300, Matheus de Oliveira wrote:
> I attached a patch to add support for changing ON UPDATE/DELETE actions of
> a constraint using ALTER TABLE ... ALTER CONSTRAINT.
This patch has been submitted to the last commit
On 2018-03-07 14:48:48 -0300, Alvaro Herrera wrote:
> Oh, I wasn't suggesting to throw away the whole cache at that point;
> only that that is a convenient to do whatever cleanup we want to do.
But why is that better than doing so continuously?
> What I'm not clear about is exactly what is the c
Hello,
Andres Freund wrote:
> On 2018-03-07 08:01:38 -0300, Alvaro Herrera wrote:
> > I wonder if this is just because we refuse to acknowledge the notion of
> > a connection pooler. If we did, and the pooler told us "here, this
> > session is being given back to us by the application, we'll kee
Hi,
On 2018-03-07 08:01:38 -0300, Alvaro Herrera wrote:
> I wonder if this is just because we refuse to acknowledge the notion of
> a connection pooler. If we did, and the pooler told us "here, this
> session is being given back to us by the application, we'll keep it
> around until the next app
Hi,
On 2018-03-07 11:58:51 -0300, Alvaro Herrera wrote:
> > This appears to be a duplicate of
> > https://commitfest.postgresql.org/17/1466/ - as the other one is older, I'm
> > closing this one.
>
> This comment makes no sense from the POV of the mail archives. I had to
> look at the User-Age
I suggest to create a new function GinPredicateLockPage() that checks
whether fast update is enabled for the index. The current arrangement
looks too repetitive and it seems easy to make a mistake.
Stylistically, please keep #include lines ordered alphabetically, and
cut long lines to below 80 ch
Here's another version of this patch. It is virtually identical to the
previous one, except for a small doc update and whitespace changes.
To recap: when a row-level trigger is created on a partitioned table, it
is marked tginherits; partitions all have their pg_class row modified
with relhastrig
Greetings Petr,
* Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
> On 07/03/18 17:55, Stephen Frost wrote:
> > Greetings Petr, all,
> >
> > * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
> >> On 07/03/18 13:14, Stephen Frost wrote:
> >>> * Noah Misch (n...@leadboat.com) wrote:
> On
On 07/03/18 17:55, Stephen Frost wrote:
> Greetings Petr, all,
>
> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
>> On 07/03/18 13:14, Stephen Frost wrote:
>>> * Noah Misch (n...@leadboat.com) wrote:
On Tue, Mar 06, 2018 at 09:28:21PM -0500, Stephen Frost wrote:
> * Tom Lane (t...@
Greetings Petr, all,
* Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
> On 07/03/18 13:14, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> >> On Tue, Mar 06, 2018 at 09:28:21PM -0500, Stephen Frost wrote:
> >>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> I wonder whether i
Greetings Petr, all,
* Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
> On 07/03/18 16:26, Stephen Frost wrote:
> > Greeting Petr, all,
> >
> > * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
> >> On 07/03/18 13:18, Stephen Frost wrote:
> >>> Greetings,
> >>>
> >>> * Petr Jelinek (petr.j
On 3/5/18, 7:08 PM, "Andres Freund" wrote:
> On 2018-03-05 19:57:44 -0500, Tom Lane wrote:
>> Andres Freund writes:
>>> One wrinkle in that plan is that it'd not be trivial to discern whether
>>> a lock couldn't be acquired or whether the object vanished. I don't
>>> really have good idea how to
On 07/03/18 13:14, Stephen Frost wrote:
> Greetings,
>
> * Noah Misch (n...@leadboat.com) wrote:
>> On Tue, Mar 06, 2018 at 09:28:21PM -0500, Stephen Frost wrote:
>>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
I wonder whether it'd be sensible for CREATE USER --- or at least the
createuser s
On 07/03/18 16:26, Stephen Frost wrote:
> Greeting Petr, all,
>
> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
>> On 07/03/18 13:18, Stephen Frost wrote:
>>> Greetings,
>>>
>>> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
Certain "market leader" database behaves this way as we
Hi Hongyuan,
On Tue, Mar 06, 2018 at 01:36:23AM +0800, Hongyuan Ma wrote:
> Hi Mark,
> In the past few days I have read some code in pgperffarm.git repository.I
> look forward to discussing the project in detail with you and gradually
> defining the datasheet structure and refining the requireme
On 3/6/18 10:04 PM, Michael Paquier wrote:
> On Tue, Mar 06, 2018 at 01:32:49PM -0500, David Steele wrote:
>> On 3/5/18 10:46 PM, Michael Paquier wrote:
>
>>> Those two are separate issues. Could you begin a new thread on the
>>> matter? This will attract more attention.
>>
>> OK, I'll move it b
Nikolay Shaplov wrote:
> Actually that's me who have lost it.
Yeah, I realized today when I saw your reply to Nikita. I didn't
realize it was him submitting a new version of the patch.
> The code with oxford comma would be a
> bit more complicated. We should put such coma when we have 3+ item
В письме от 2 марта 2018 11:27:49 пользователь Andres Freund написал:
> > Since I get a really big patch as a result, it was decided to commit it in
> > parts.
>
> I get that, but I strongly suggest not creating 10 loosely related
> threads, but keeping it as a patch series in one thread. It's re
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> Since we are discussing locking down our defaults is revoking the global
> function execution privilege granted to PUBLIC - instead limiting it to
> just the pg_catalog schema - on the table?
>
> I'm not sure how strongly I feel
On 3/6/18, 11:04 PM, "Michael Paquier" wrote:
> + if (!(options & VACOPT_SKIP_LOCKED))
> + relid = RangeVarGetRelid(vrel->relation, AccessShareLock,
> false);
> + else
> + {
> + relid = RangeVarGetRelid(vrel->relation, NoLock, false);
> Yeah, I agree with Andr
Since we are discussing locking down our defaults is revoking the global
function execution privilege granted to PUBLIC - instead limiting it to
just the pg_catalog schema - on the table?
I'm not sure how strongly I feel toward the proposal but it does come up on
these lists; and the fact that it
Greeting Petr, all,
* Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
> On 07/03/18 13:18, Stephen Frost wrote:
> > Greetings,
> >
> > * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
> >> Certain "market leader" database behaves this way as well. I just hope
> >> we won't go as far as the
On 07/03/18 13:18, Stephen Frost wrote:
> Greetings,
>
> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
>> Certain "market leader" database behaves this way as well. I just hope
>> we won't go as far as them and also create users for schemas (so that
>> the analogy of user=schema would be co
В письме от 1 марта 2018 14:47:35 пользователь Alvaro Herrera написал:
> I see you lost the Oxford comma:
>
> -DETAIL: Valid values are "on", "off", and "auto".
> +DETAIL: Valid values are "auto", "on" and "off".
>
> Please put these back.
Actually that's me who have lost it. The code with ox
On Mon, Jan 15, 2018 at 09:14:02PM +, Joe Wildish wrote:
> Hi David,
>
> > On 15 Jan 2018, at 16:35, David Fetter wrote:
> >
> > It sounds reasonable enough that I'd like to make a couple of Modest
> > Proposals™, to wit:
> >
> > - We follow the SQL standard and make SERIALIZABLE the defaul
В письме от 1 марта 2018 19:11:05 пользователь Nikita Glukhov написал:
> Hi.
>
> I have refactored patch by introducing new struct relop_enum_element to make
> it possible to use existing C-enum values in option's definition. So,
> additional enum GIST_OPTION_BUFFERING_XXX was removed.
Hi! I've i
Greetings,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> Stephen Frost wrote:
>
> > * Noah Misch (n...@leadboat.com) wrote:
>
> > > I like the idea of getting more SQL-compatible, if this presents a
> > > distinct
> > > opportunity to do so. I do think it would be too weird to create the
Andres Freund wrote:
> This appears to be a duplicate of https://commitfest.postgresql.org/17/1466/
> - as the other one is older, I'm closing this one.
This comment makes no sense from the POV of the mail archives. I had to
look at the User-Agent in your email to realize that you wrote it in t
1 - 100 of 153 matches
Mail list logo
