Hi,
I created a new version patch. Please find attached my patch.
Changes:
Since v2 patch
I forgot to write the detail of v2 patch changes. So I write these.
- Fixed the " Start receiving message from backend:" message location. Because
I found that message located at outside of "retry4".
- Cha
Hi,
Please suggest me on the following,
1. Is it better to configure autovacuum threshold at table level?
2. Is there any discussions in this forum which I can refer for
understanding vacuum/autovacuum?
Thanks in advance.
Rajan.
-
--
Thanks,
Rajan.
--
Sent from: http://www.postgresql-arch
On 2018/11/27 6:19, David Rowley wrote:
> On Mon, 26 Nov 2018 at 18:57, Amit Langote
> wrote:
>> On 2018/11/26 14:25, David Rowley wrote:
>>> I'm making efforts to delay per-partition work even further in the
>>> executor, for example locking of the per-partition result relations
>>> until after r
Hi,
On 2018/11/02 9:17, Haribabu Kommi wrote:
> Here I attached the cumulative fixes of the patches, new API additions for
> zheap and
> basic outline of the documentation.
I've read the documentation patch while also looking at the code and here
are some comments.
+ Each table is stored as it
On Mon, 2018-11-26 at 19:51 -0500, Stephen Frost wrote:
> If a function's results can change across minor or major versions, we
> shouldn't be marking it as immutable because, by definition, it's not
> immutable.
>
> We, today, have a baked in assumption that any function marked as
> immutable wil
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Hm. We intentionally allow SQL functions to be marked as less
> Tom> mutable than their internals, because sometimes that's useful for
> Tom> tricking the planner. However, IIRC we don't inline when we see
> Tom> that's the case. Maybe
On Mon, Nov 26, 2018 at 07:00:35PM -0800, Andres Freund wrote:
> Could you check that the attached patch this also fixes your original
> issue? Going through the code to see if there's other occurances of
> this.
Confirmed that fixes my crash.
Thanks,
Justin
Robert Haas writes:
> On Mon, Nov 26, 2018 at 11:21 PM Tom Lane wrote:
>> Alternatively, could we postpone the parallelism checks till after
>> function inlining? Do we even make any before that?
> ... I believe the parallel-safety checks are done very early, and if
> you decide that it's not s
On Mon, Nov 26, 2018 at 11:21 PM Tom Lane wrote:
> Hm. We intentionally allow SQL functions to be marked as less mutable
> than their internals, because sometimes that's useful for tricking
> the planner. However, IIRC we don't inline when we see that's the
> case. Maybe there needs to be a sim
> "Tom" == Tom Lane writes:
Tom> Hm. We intentionally allow SQL functions to be marked as less
Tom> mutable than their internals, because sometimes that's useful for
Tom> tricking the planner. However, IIRC we don't inline when we see
Tom> that's the case. Maybe there needs to be a simila
On Mon, Nov 26, 2018 at 11:20 PM Andrew Gierth
wrote:
> But the combination of inlining and polymorphism, in particular, makes
> it impossible for the function author to know this. Take the OP's
> example; it is parallel safe if and only if the selected type's equal
> function is parallel safe - h
Robert Haas writes:
> On Mon, Nov 26, 2018 at 8:49 PM Andrew Gierth
> wrote:
>> I'm a bit more concerned by the fact that inlining the function isn't
>> affecting the parallel safety of the query - the fact that parallel
>> safety is being checked prior to inlining means that if inlining
>> *intr
> "Robert" == Robert Haas writes:
>> I'm a bit more concerned by the fact that inlining the function
>> isn't affecting the parallel safety of the query - the fact that
>> parallel safety is being checked prior to inlining means that if
>> inlining *introduces* a parallel hazard, it will
On Mon, Nov 26, 2018 at 10:13 PM David Steele wrote:
> I propose we remove the deprecated exclusive backup mode of
> pg_start_backup()/pg_stop_backup() for Postgres 12.
-1. I don't have a problem with deprecating exclusive backup mode
eventually, but I don't see any good reason to do it this soon
On Mon, Nov 26, 2018 at 8:49 PM Andrew Gierth
wrote:
> I'm a bit more concerned by the fact that inlining the function isn't
> affecting the parallel safety of the query - the fact that parallel
> safety is being checked prior to inlining means that if inlining
> *introduces* a parallel hazard, it
On Mon, Nov 26, 2018 at 7:47 PM Vik Fearing wrote:
> > I'm way less inclined to buy into the idea that it MUST be wrong, though.
> > Immutability is a promise about result stability and lack of side effects,
> > but it is not a promise about implementation details. There could be an
> > implement
Hi,
On 2018-11-27 12:20:13 +0900, Michael Paquier wrote:
> On Mon, Nov 26, 2018 at 10:13:34PM -0500, David Steele wrote:
> > Non-exclusive backups have been available since 9.6 and several third-party
> > solutions support this mode, in addition to pg_basebackup.
>
> I think that two releases is
On Mon, Nov 26, 2018 at 10:13:34PM -0500, David Steele wrote:
> Non-exclusive backups have been available since 9.6 and several third-party
> solutions support this mode, in addition to pg_basebackup.
I think that two releases is not actually that much time to just nuke
the exclusive backup interf
Hackers,
I propose we remove the deprecated exclusive backup mode of
pg_start_backup()/pg_stop_backup() for Postgres 12.
The exclusive backup mode has a serious known issue. If Postgres
terminates ungracefully during a backup (due to hardware, kernel,
Postgres issues, etc.) then Postgres ma
On Tue, Nov 27, 2018 at 7:45 AM Alvaro Herrera wrote:
> On 2018-Nov-26, Jakub Glapa wrote:
> > Justin thanks for the information!
> > I'm running Ubuntu 16.04.
> > I'll try to prepare for the next crash.
> > Couldn't find anything this time.
>
> As I recall, the appport stuff in Ubuntu is terrible
On 2018-11-17 17:37:15 -0600, Justin Pryzby wrote:
> On Fri, Nov 16, 2018 at 10:24:46AM -0600, Justin Pryzby wrote:
> > On Fri, Nov 16, 2018 at 08:38:26AM -0600, Justin Pryzby wrote:
> > > The table is not too special, but was probably ALTERed to add columns a
> > > good
> > > number of times by o
On Tue, Nov 27, 2018 at 10:07:04AM +0800, Paul Guo wrote:
> Agree. Your code change is safer.
Thanks Paul for double-checking. I'll come back to this patch in two
days, look at it again and commit it if there are no objections from
others.
--
Michael
signature.asc
Description: PGP signature
On Mon, Nov 26, 2018 at 2:08 PM Masahiko Sawada wrote:
>
> On Sun, Nov 25, 2018 at 2:35 PM Amit Kapila wrote:
> >
> > On Sat, Nov 24, 2018 at 5:47 PM Amit Kapila wrote:
> > > On Tue, Oct 30, 2018 at 2:04 PM Masahiko Sawada
> > > wrote:
> > > >
> > >
>
> Thank you for the comment.
>
> > > I cou
>
> On Thu, Nov 22, 2018 at 06:31:04PM +0800, Paul Guo wrote:
> > Yes, please see the attached patch.
>
> Thanks, I have reviewed your patch, and could not resist to change
> SyncRepReleaseWaiters() on top of the rest with a comment to not be
> confused about the WAL sender states allowed to releas
Hi,
FWIW, now that oids are removed, and the tuple table slot abstraction
got in, I'm working on rebasing the pluggable storage patchset ontop of
that.
On 2018-11-27 12:48:36 +1100, Haribabu Kommi wrote:
> On Thu, Nov 22, 2018 at 1:12 PM Asim R P wrote:
>
> > Ashwin (copied) and I got a chance
On Fri, Nov 23, 2018 at 6:39 PM Thomas Munro
wrote:
> On Mon, Nov 19, 2018 at 5:24 PM Kyotaro HORIGUCHI
> wrote:
> > At Sat, 17 Nov 2018 11:15:54 -0300, Alvaro Herrera <
> alvhe...@2ndquadrant.com> wrote in
> <20181117141554.4dkx2u4j6md3bqdh@alvherre.pgsql>
> > > Is this patch committable now?
>
I'm a bit more concerned by the fact that inlining the function isn't
affecting the parallel safety of the query - the fact that parallel
safety is being checked prior to inlining means that if inlining
*introduces* a parallel hazard, it will go unnoticed?
--
Andrew (irc:RhodiumToad)
On Thu, Nov 22, 2018 at 1:12 PM Asim R P wrote:
> Ashwin (copied) and I got a chance to go through the latest code from
> Andres' github repository. We would like to share some
> comments/quesitons:
>
Thanks for the review.
> The TupleTableSlot argument is well suited for row-oriented storage
On Mon, Nov 26, 2018 at 12:41:21PM -0500, Andrew Dunstan wrote:
> It's not the buildfarm that is broken. Both contribcheck() and
> modulescheck() in vcregress.pl run in installcheck mode, i.e. with an
> already running database. That makes the tests run faster, because setting
> up and breaking dow
On 2018-11-22 08:49:23 -0500, Andrew Dunstan wrote:
>
> On 11/21/18 7:12 PM, Andres Freund wrote:
> > Hi,
> >
> > It seems the list of reg* types and the check for them in pg_upgrade
> > have gone out of sync. We have the following reg* types:
> >
> > SELECT typname FROM pg_type WHERE typname
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-11-26 19:34:03 -0500, Stephen Frost wrote:
> > These two things seem entirely independent in my view, so I'm really not
> > sure that I'm following what you're getting at.
>
> All I said is that I don't think it's a reasonable polic
On 27/11/2018 01:40, Tom Lane wrote:
> Vik Fearing writes:
>> On 27/11/2018 01:13, Stephen Frost wrote:
>>> Parallel safe functions should be marked as such. Immutable functions
>>> should be marked as such. We should not assume that one implies the
>>> other, nor should we operate as if they do
On 2018-11-26 19:34:03 -0500, Stephen Frost wrote:
> These two things seem entirely independent in my view, so I'm really not
> sure that I'm following what you're getting at.
All I said is that I don't think it's a reasonable policy to mark all
functions that potentially could change across major
Vik Fearing writes:
> On 27/11/2018 01:13, Stephen Frost wrote:
>> Parallel safe functions should be marked as such. Immutable functions
>> should be marked as such. We should not assume that one implies the
>> other, nor should we operate as if they do.
> Yes we should! Unless you can produce
Greetings,
* Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
> On 27/11/2018 01:13, Stephen Frost wrote:
> > Parallel safe functions should be marked as such. Immutable functions
> > should be marked as such. We should not assume that one implies the
> > other, nor should we operate as if they
FWIW, I'm inclined to think that pg_config should be marked as stable
not immutable. Aside from the minor-version-upgrade issue, what if
you install new binaries that are the same version but built with
different configure flags?
The pg_config outputs are roughly as stable as initdb-inserted
cata
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-11-26 19:16:00 -0500, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On 2018-11-26 19:04:46 -0500, Joe Conway wrote:
> > > > So the correct answer is probably to mark pg_config() stable, but it
> > > > sti
Hi,
On 2018-11-27 01:27:41 +0100, Vik Fearing wrote:
> On 27/11/2018 01:13, Stephen Frost wrote:
> > Parallel safe functions should be marked as such. Immutable functions
> > should be marked as such. We should not assume that one implies the
> > other, nor should we operate as if they do.
>
>
On 27/11/2018 01:13, Stephen Frost wrote:
> Parallel safe functions should be marked as such. Immutable functions
> should be marked as such. We should not assume that one implies the
> other, nor should we operate as if they do.
Yes we should! Unless you can produce a case where an immutable
f
On 27/11/2018 01:14, Stephen Frost wrote:
> Greetings,
>
> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
>> On 27/11/2018 01:10, Stephen Frost wrote:
>>> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
On 27/11/2018 01:05, Stephen Frost wrote:
> That said, I do *not* think we shou
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-11-26 19:13:17 -0500, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On 2018-11-26 19:05:02 -0500, Stephen Frost wrote:
> > > > Agreed, but I could see us having a regression test which complains if
> > >
Hi,
On 2018-11-26 19:16:00 -0500, Stephen Frost wrote:
> Greetings,
>
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2018-11-26 19:04:46 -0500, Joe Conway wrote:
> > > So the correct answer is probably to mark pg_config() stable, but it
> > > still seems to be parallel safe to me.
> >
> >
On 2018-11-26 19:14:24 -0500, Joe Conway wrote:
> On 11/26/18 7:08 PM, Andres Freund wrote:
> > On 2018-11-26 19:04:46 -0500, Joe Conway wrote:
> >> Not intentional. Though, sitting here chatting with Stephen about it, I
> >> am now wondering if pg_config() should actually be marked immutable:
> >>
On 2018-11-26 19:13:17 -0500, Stephen Frost wrote:
> Greetings,
>
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2018-11-26 19:05:02 -0500, Stephen Frost wrote:
> > > Agreed, but I could see us having a regression test which complains if
> > > it finds any which are marked as immutable but a
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-11-26 19:04:46 -0500, Joe Conway wrote:
> > So the correct answer is probably to mark pg_config() stable, but it
> > still seems to be parallel safe to me.
>
> I don't think we should consider immutability to mean anything across
>
On 11/26/18 7:08 PM, Andres Freund wrote:
> On 2018-11-26 19:04:46 -0500, Joe Conway wrote:
>> Not intentional. Though, sitting here chatting with Stephen about it, I
>> am now wondering if pg_config() should actually be marked immutable:
>>
>> select * from pg_config() where name = 'VERSION';
>>
Greetings,
* Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
> On 27/11/2018 01:10, Stephen Frost wrote:
> > * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
> >> On 27/11/2018 01:05, Stephen Frost wrote:
> >>> That said, I do *not* think we should make any assumptions here- users
> >>> incorre
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-11-26 19:05:02 -0500, Stephen Frost wrote:
> > Agreed, but I could see us having a regression test which complains if
> > it finds any which are marked as immutable but aren't parallel safe.
>
> That doesn't help if a user writes a
On 27/11/2018 01:10, Stephen Frost wrote:
> Greetings,
>
> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
>> On 27/11/2018 01:05, Stephen Frost wrote:
>>> That said, I do *not* think we should make any assumptions here- users
>>> incorrectly mark things all the time but we shouldn't encourage
Greetings,
* Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
> On 27/11/2018 01:05, Stephen Frost wrote:
> > That said, I do *not* think we should make any assumptions here- users
> > incorrectly mark things all the time but we shouldn't encourage that and
> > we shouldn't assume that functions m
Hi,
On 2018-11-26 19:05:02 -0500, Stephen Frost wrote:
> Agreed, but I could see us having a regression test which complains if
> it finds any which are marked as immutable but aren't parallel safe.
That doesn't help if a user writes a query to review the not parallel
safe functions in their inst
On 27/11/2018 01:05, Stephen Frost wrote:
> That said, I do *not* think we should make any assumptions here- users
> incorrectly mark things all the time but we shouldn't encourage that and
> we shouldn't assume that functions marked as immutable are parallel
> safe.
Does that mean we also shouldn
On 2018-11-26 19:04:46 -0500, Joe Conway wrote:
> On 11/26/18 6:45 PM, Andres Freund wrote:
> > Hi,
> >
> > Triggered by the thread at [1] I looked for functions marked as
> > immutable but not parallel safe.
> >
> > postgres[19492][1]=# SELECT oid::regprocedure, provolatile, proparallel
> > FRO
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-11-27 00:47:47 +0100, Vik Fearing wrote:
> > On 27/11/2018 00:39, Andres Freund wrote:
> > > On 2018-11-27 00:33:10 +0100, Vik Fearing wrote:
> > >> On 26/11/2018 22:23, Gajus Kuizinas wrote:
> > >>> I was wondering what is the reaso
On 11/26/18 6:45 PM, Andres Freund wrote:
> Hi,
>
> Triggered by the thread at [1] I looked for functions marked as
> immutable but not parallel safe.
>
> postgres[19492][1]=# SELECT oid::regprocedure, provolatile, proparallel FROM
> pg_proc WHERE provolatile = 'i' AND proparallel != 's';
> ┌───
Hi,
On 11/26/18 5:49 PM, Dagfinn Ilmari Mannsåker wrote:
> Hi Hackers,
>
> As I was hacking on the CREATE TABLE tab completions, I noticed that the
> CREATE STATISTICS completion was checking manually for the start and end
> of the parenthesised list instead of using the "(*)" wildcard (because
>
On 2018-11-27 00:47:47 +0100, Vik Fearing wrote:
> On 27/11/2018 00:39, Andres Freund wrote:
> > Hi,
> >
> > On 2018-11-27 00:33:10 +0100, Vik Fearing wrote:
> >> On 26/11/2018 22:23, Gajus Kuizinas wrote:
> >>> I was wondering what is the reason IMMUTABLE functions are not by
> >>> default PARALL
On 27/11/2018 00:39, Andres Freund wrote:
> Hi,
>
> On 2018-11-27 00:33:10 +0100, Vik Fearing wrote:
>> On 26/11/2018 22:23, Gajus Kuizinas wrote:
>>> I was wondering what is the reason IMMUTABLE functions are not by
>>> default PARALLEL SAFE and if the default behaviour could be changed to
>>> ma
Hi,
Triggered by the thread at [1] I looked for functions marked as
immutable but not parallel safe.
postgres[19492][1]=# SELECT oid::regprocedure, provolatile, proparallel FROM
pg_proc WHERE provolatile = 'i' AND proparallel != 's';
┌─┬─┬─┐
│ oid │ pr
Hi,
On 2018-11-27 00:33:10 +0100, Vik Fearing wrote:
> On 26/11/2018 22:23, Gajus Kuizinas wrote:
> > I was wondering what is the reason IMMUTABLE functions are not by
> > default PARALLEL SAFE and if the default behaviour could be changed to
> > make IMMUTABLE functions PARALLEL SAFE?
>
> I thin
On 26/11/2018 22:23, Gajus Kuizinas wrote:
> I was wondering what is the reason IMMUTABLE functions are not by
> default PARALLEL SAFE and if the default behaviour could be changed to
> make IMMUTABLE functions PARALLEL SAFE?
I think I have to concur with this. When is an immutable function not
p
Hi,
On 2018-11-21 16:30:07 +0100, Andreas Karlsson wrote:
> On 11/21/18 1:07 AM, Andres Freund wrote:
> > Let's see what I broke :/
>
> There is a small typo in the old release notes.
Thanks, pushed!
Greetings,
Andres Freund
On Thu, Oct 18, 2018 at 11:05 AM Peter Eisentraut
wrote:
> - Adds tests under src/test/ssl/ for the pg_stat_ssl view.
Hi Peter,
Your new tests fail when run by cfbot (Ubuntu), and also on my Debian
buster machine, but pass on my FreeBSD 13-CURRENT box. I think the
problem is that you match ciph
On 11/26/18 11:29 PM, Thomas Munro wrote:
> On Mon, Sep 3, 2018 at 11:17 AM Tomas Vondra
> wrote:
>> Attached is an updated version of the patch series, adopting a couple of
>> improvements - both for MCV lists and histograms.
>
> Hello Tomas,
>
> FYI, here are a couple of warnings from GCC (I j
Hi,
On 2018-11-22 17:12:31 -0500, Andrew Dunstan wrote:
>
> On 11/22/18 4:14 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2018-11-21 23:32:07 -0500, Andrew Dunstan wrote:
> > > On 11/21/18 7:14 PM, Andres Freund wrote:
> > > >Could you check whether you
> > > > still encounter the issue after
On Fri, Nov 23, 2018 at 5:45 PM Thomas Munro
wrote:
> I do have a new plan though...
Ugh. The plan in my previous email doesn't work, I was confused about
the timing of the buffer header update. Back to the drawing board.
--
Thomas Munro
http://www.enterprisedb.com
On Mon, Sep 3, 2018 at 11:17 AM Tomas Vondra
wrote:
> Attached is an updated version of the patch series, adopting a couple of
> improvements - both for MCV lists and histograms.
Hello Tomas,
FYI, here are a couple of warnings from GCC (I just noticed because I
turned on -Werror on cfbot so your
>
> Pushed with that correction and some other last-minute review.
>
Great! Thank you
Pavel
>
> regards, tom lane
>
>
I have defined a function "is_not_distinct" for the purpose of creating a
custom operator "===".
CREATE FUNCTION is_not_distinct(a anyelement, b anyelement)
returns boolean
language sql as $$
select a is not distinct from b;
$$
IMMUTABLE;
CREATE OPERATOR === (
LEFTARG = anyelement,
RIGHTARG
Greetings,
* Sergei Kornilov (s...@zsrv.org) wrote:
> > I'd encourage you to look through the diff after you're finished hacking
> > before sending it to the list, in case things get left in that should be
> > removed, as below...
> I am so sorry. I have a look before sending, but...
> It's night
On Mon, 26 Nov 2018 at 18:57, Amit Langote
wrote:
> On 2018/11/26 14:25, David Rowley wrote:
> > I'm making efforts to delay per-partition work even further in the
> > executor, for example locking of the per-partition result relations
> > until after run-time pruning would be a significant win fo
Hi
> I'd encourage you to look through the diff after you're finished hacking
> before sending it to the list, in case things get left in that should be
> removed, as below...
I am so sorry. I have a look before sending, but...
It's night in my timezone. I will fix tomorrow.
>> + if (targetSetti
Greetings,
* Sergei Kornilov (s...@zsrv.org) wrote:
> Updated patch attached:
> - added testcase to verify database does not start with multiple recovery
> targets
> - recovery_target = immediate was replaced with recovery_target_immediate
> bool GUC
I'd encourage you to look through the diff a
"Daniel Verite" writes:
>> A proposed fix is attached. print_csv_vertical() is left unchanged
>> because it's not possible currently to end up with \. alone
>> on a line with the expanded display
> On second thought, it is possible
> postgres=# \pset format csv
> Output format is csv.
> postgres=
Hello
Updated patch attached:
- added testcase to verify database does not start with multiple recovery
targets
- recovery_target = immediate was replaced with recovery_target_immediate bool
GUC
thank you!
regards, Sergeidiff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index db
> On Tue, Aug 7, 2018 at 11:19 PM Bruce Momjian wrote:
>
> On Mon, Jul 16, 2018 at 11:37:28AM -0400, Tom Lane wrote:
> > Heikki Linnakangas writes:
> > > On 16/07/18 18:10, Tom Lane wrote:
> > >> TBH I'm not really excited about investing any work in this area at all.
> > >> Considering how seldo
On 11/26/18 1:15 PM, Andres Freund wrote:
> On 2018-11-26 15:09:43 -0300, Alvaro Herrera wrote:
>> On 2018-Nov-26, Stephen Frost wrote:
>>
>>> I would think we'd have the different GUCs and then the check functions
>>> would only validate that they're valid inputs and then when we get to
>>> the po
Greetings,
* Sergei Kornilov (s...@zsrv.org) wrote:
> > I think I would have done 'if (targetSettingsCount != 1)' here.
> Streaming replication does not have any recovery_target.
> Well, i can check StandbyModeRequested too and allow 0 recovery_target only
> for standby mode.
Ah. Agreed.
> >>
I wrote:
> A proposed fix is attached. print_csv_vertical() is left unchanged
> because it's not possible currently to end up with \. alone
> on a line with the expanded display
On second thought, it is possible
postgres=# \pset format csv
Output format is csv.
postgres=# \pset fieldsep
Hi,
On 26/11/2018 01:29, Masahiko Sawada wrote:
> On Sun, Nov 25, 2018 at 12:27 AM Petr Jelinek
> wrote:
>>
>> The more serious thing is:
>>
>>> + if (MyReplicationSlot)
>>> + ReplicationSlotRelease();
>>> +
>>> + /* Release the saved slot if exist while preventing double rele
Hello
> I think I would have done 'if (targetSettingsCount != 1)' here.
Streaming replication does not have any recovery_target.
Well, i can check StandbyModeRequested too and allow 0 recovery_target only for
standby mode.
>> -# Multiple targets
>> -# Last entry has priority (note that an arra
On 2018-11-26 13:30:18 -0500, Stephen Frost wrote:
> Well, we could start with: that isn’t how things work today, nor how it
> used to work before this patch, and we’ve not had anyone asking for it
> except for people on this thread making things up.
Thanks for assuming good faith.
Greetings,
On Mon, Nov 26, 2018 at 13:15 Andres Freund wrote:
> On 2018-11-26 15:09:43 -0300, Alvaro Herrera wrote:
> > On 2018-Nov-26, Stephen Frost wrote:
> >
> > > I would think we'd have the different GUCs and then the check functions
> > > would only validate that they're valid inputs and t
Hi
>> Hmm... I considered SIGHUP processing was in fast loop and therefore
>> shutdown should be fast. But i recheck code and found a possible long loop
>> without processing SIGHUP (in case we receive new data faster than writes to
>> disk). Ok, i will revert back.
>> How about write to WalR
On 2018-11-26 15:09:43 -0300, Alvaro Herrera wrote:
> On 2018-Nov-26, Stephen Frost wrote:
>
> > I would think we'd have the different GUCs and then the check functions
> > would only validate that they're valid inputs and then when we get to
> > the point where we're starting to do recovery we ch
On 2018-Nov-26, Stephen Frost wrote:
> I would think we'd have the different GUCs and then the check functions
> would only validate that they're valid inputs and then when we get to
> the point where we're starting to do recovery we check and make sure
> we've been given a sane overall configurat
Tom Lane wrote:
> OK, reasonable arguments were made why not to allow multi-character
> separators. Should we then match the server and insist on a single-byte
> separator? It's a bit inconsistent if psql can be made to emit "csv"
> files that COPY can't read, especially when it's otherw
Hi,
On 2018-11-26 12:30:06 +0300, Sergei Kornilov wrote:
> Hmm... I considered SIGHUP processing was in fast loop and therefore shutdown
> should be fast. But i recheck code and found a possible long loop without
> processing SIGHUP (in case we receive new data faster than writes to disk).
> Ok
On 11/26/18 12:43 AM, Michael Paquier wrote:
Hi all,
As mentioned on this thread, I have been fighting a bit with the
buildfarm when trying to introduce new PGXS options for isolation and
TAP tests:
https://www.postgresql.org/message-id/e1gr4d0-0002yj...@gemulon.postgresql.org
However it happ
Greetings,
* Sergei Kornilov (s...@zsrv.org) wrote:
> > I would think we'd have the different GUCs and then the check functions
> > would only validate that they're valid inputs and then when we get to
> > the point where we're starting to do recovery we check and make sure
> > we've been given a
Hi all,
Thank you for helping us to make that patch better.
It didn't
> seem worth blocking this patch for your proposed change (particularly
> since Lætitia seems to have given up on it already).
>
>
I haven't given up. As I said in the begining, Patrick and I were working
together on that patch
Hi Thomas,
You said:
I think we should respect the huge_pages GUC, as we do on Linux and
Windows (since there are downsides to using large pages, maybe not
everyone would want that). It could even be useful to allow different
page sizes to be requested by GUC (I see that DB2 has an option to u
Hi, Dmitry!
> 26 нояб. 2018 г., в 21:20, Dmitry Dolgov <9erthali...@gmail.com> написал(а):
>
> Looks like this time the patch was picked up correctly, but there are some
> conflicts with the current master branch:
> http://cfbot.cputube.org/patch_20_1615.log
> Could you please rebase it one more
Hi Hackers,
As I was hacking on the CREATE TABLE tab completions, I noticed that the
CREATE STATISTICS completion was checking manually for the start and end
of the parenthesised list instead of using the "(*)" wildcard (because
it predates that functionality). Attached is a patch that updates it
Hi, Thomas!
> 31 авг. 2018 г., в 2:40, Thomas Munro
> написал(а):
>
> [1] https://arxiv.org/pdf/1509.05053.pdf
I've implemented all of the strategies used in that paper.
On a B-tree page we have a line pointers ordered in key order and tuples
residing at the end of the page. Tuples at the end
Hello
> I would think we'd have the different GUCs and then the check functions
> would only validate that they're valid inputs and then when we get to
> the point where we're starting to do recovery we check and make sure
> we've been given a sane overall configuration- which means that only
> *o
Hi hackers,
Please find attached a patch that adds the following tab completions for
CREATE TABLE:
- ( or PARTITION OF after the name
- options after the column list
- ON COMMIT actions for temp tables
Regards,
ilmari
--
"The surreality of the universe tends towards a maximum" -- Skud's Law
"N
Greetings,
* Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> On Sun, 2018-11-25 at 16:04 -0500, Stephen Frost wrote:
> > > Yes, you can come up with a post-backup script that somehow communicates
> > > with your pre-backup script to get the information, but it sure is
> > > inconvenient. Simplic
> On Mon, Jul 30, 2018 at 7:50 AM Andrey Borodin wrote:
>
> Thanks, Thomas!
>
> > 30 июля 2018 г., в 3:58, Thomas Munro
> > написал(а):
> >
> > On Sun, Jul 29, 2018 at 10:50 PM, Andrey Borodin
> > wrote:
> >> Thanks! The problem appeared with commit 701fd0b [0] which dropped
> >> validation ru
"David G. Johnston" writes:
> On Sun, Nov 25, 2018 at 6:27 PM Tom Lane wrote:
>> 1. Are we limiting the separator to be a single-byte character or not?
> I agree with what others have said that expanding functionality in
> this direction is more likely to mask errors than be useful.
OK, reasona
1 - 100 of 134 matches
Mail list logo
