>
> +RoleId:CURRENT_USER{ $$ =
> "current_user";}
> + | USER { $$ = "current_user";}
> + | CURRENT_ROLE { $$ = "current_user";}
> + | SESSION_USER { $
Hi,
> From: Andres Freund [mailto:and...@2ndquadrant.com]
> On 2014-10-27 06:29:33 -0300, Alvaro Herrera wrote:
> > Amit Langote wrote:
> > > FWIW, I think Robert's criticism regarding not basing this on
inheritance
> > > scheme was not responded to.
> >
> > It was responded to by ignoring it. I
On Mon, Oct 27, 2014 at 12:31:56PM -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 10/27/2014 05:41 PM, Robert Haas wrote:
> >> Beyond all that, I have serious doubts about whether, even if we
> >> eventually get these tests mostly working in most places, whether they
> >> will actually
On Tue, Oct 14, 2014 at 3:24 PM, Amit Kapila
wrote:
> On Thu, Oct 9, 2014 at 6:17 PM, Amit Kapila
wrote:
> > On Fri, Sep 26, 2014 at 7:04 PM, Robert Haas
wrote:
> > >
> > > On another point, I think it would be a good idea to rebase the
> > > bgreclaimer patch over what I committed, so that we h
On 28 October 2014 09:18, Amit Kapila Wrote,
>I am worried about the case if after setting the inAbort flag,
>PQCancel() fails (returns error).
>
>> If select(maxFd + 1, workerset, NULL, NULL, &tv); come out, we can know
>> whether it came out because of cancel query and handle it accordingly.
>>
On Tue, Oct 28, 2014 at 9:03 AM, Dilip kumar wrote:
>
> On 25 October 2014 17:52, Amit Kapila Wrote,
>
> >***
>
> >*** 358,363 handle_sigint(SIGNAL_ARGS)
>
> >--- 358,364
>
> >
>
> > /* Send QueryCancel if we are processing a database query */
>
> > if (cancelConn != NULL)
On 25 October 2014 17:52, Amit Kapila Wrote,
>***
>*** 358,363 handle_sigint(SIGNAL_ARGS)
>--- 358,364
>
> /* Send QueryCancel if we are processing a database query */
> if (cancelConn != NULL)
> {
>+ inAbort = true;
> if (PQcancel(cancelConn, errbuf, sizeof(errbuf)))
> f
On Mon, Oct 27, 2014 at 7:37 PM, Petr Jelinek wrote:
> I have two minor things:
> + printf(_(" --snapshot use given synchronous
> snapshot for the dump\n"));
Thanks for your input!
> I think this should say --snapshot=NAME or something like that to make it
> visible that
On Mon, Oct 27, 2014 at 8:54 PM, Tom Lane wrote:
> That argument is nonsense. I complained about a lack of close analysis,
> but with close analysis I think this is perfectly safe; or at least no
> less safe than what's there now, with its not terribly bulletproof
> assumption that a suitable mem
Marti Raudsepp wrote
> On Fri, Oct 24, 2014 at 11:29 AM, Kyotaro HORIGUCHI
> <
> horiguchi.kyotaro@.co
> > wrote:
>
> But should ALTER USER ALL and ALTER ROLE ALL really do the same thing?
> A user is a role with the LOGIN option. Every user is a role, but not
> every role is a user. I suspect t
* Peter Eisentraut (pete...@gmx.net) wrote:
> I think the way this should work is that if you create a DIRALIAS, then
> the COPY command should refer to it by logical name, e.g.,
>
> CREATE DIRALIAS dumpster AS '/tmp/trash';
> COPY mytable TO dumpster;
You'd have to be able to specify the filenam
Tom Lane-2 wrote
> Tomas Vondra <
> tv@
> > writes:
>> So maybe we shouldn't cling to the WAL-logging approach too much. Maybe
>> Heikki's idea from to abandon the full checkpoint and instead assume
>> that once the transaction commits, all the files were fsynced OK. Of
>> couse, this will do not
Robert Haas writes:
> On Mon, Oct 27, 2014 at 4:27 PM, Tom Lane wrote:
>> Neither of those messages seem to me to bear on this point. AFAICS,
>> the unlocked hasMessages test has a race condition, which the comment
>> just above it argues isn't a problem in practice. What I propose above
>> wou
> ---
> doc/src/sgml/ddl.sgml | 23 +++
> doc/src/sgml/indices.sgml | 11 +-
> doc/src/sgml/mvcc.sgml| 43 --
> doc/src/sgml/plpgsql.sgml | 20 ++-
> doc/src/sgml/postgres-fdw.sgml| 8 ++
> doc/src/sgml/ref/create_index.sgml
On Mon, Oct 27, 2014 at 08:24:15AM -0400, Robert Haas wrote:
> On Sat, Oct 25, 2014 at 2:00 PM, Noah Misch wrote:
> >> http://www.postgresql.org/message-id/ca+tgmoy4glsxzk0tao29-ljtcuj0sl1xwcwq51xb-hfysgi...@mail.gmail.com
> >> http://www.postgresql.org/message-id/20893.1393892...@sss.pgh.pa.us
>
Tomas Vondra wrote
> I mean, when we use database A as a template, why do we need to checkpoint
> B, C, D and F too? (Apologies if this is somehow obvious, I'm way out of
> my comfort zone in this part of the code.)
IIUC you have to checkpoint the whole cluster because it is not possible to
do che
On Fri, Oct 24, 2014 at 11:29 AM, Kyotaro HORIGUCHI
wrote:
> - 0001-ALTER-ROLE-CURRENT_USER_v2.patch - the patch.
+RoleId:CURRENT_USER{ $$ = "current_user";}
+ | USER { $$ = "current_user";}
+ | CURRENT_ROL
>
> super
>
> I tested last version and I have not any objections.
>
> 1. We would to have this feature - it is long time number of our ToDo List
>
> 2. Proposal and design of multidimensional aggregation is clean and nobody
> has objection here.
>
> 3. There is zero impact on current implementatio
Tomas Vondra writes:
> So maybe we shouldn't cling to the WAL-logging approach too much. Maybe
> Heikki's idea from to abandon the full checkpoint and instead assume
> that once the transaction commits, all the files were fsynced OK. Of
> couse, this will do nothing about the replay hazards.
Well
On Mon, Oct 27, 2014 at 4:34 PM, Simon Riggs wrote:
> Let's see if we can link these two thoughts.
>
> 1. You think the biggest problem is the lack of attention to the design.
>
> 2. I keep asking you to put the docs in a readable form.
>
> If you can't understand the link between those two things
On 28.10.2014 00:06, Andrew Dunstan wrote:
>
> On 10/27/2014 07:01 PM, Andres Freund wrote:
>> On 2014-10-27 18:57:27 -0400, Andrew Dunstan wrote:
>>> On 10/27/2014 05:58 PM, Tomas Vondra wrote:
On 27.10.2014 17:24, Heikki Linnakangas wrote:
I'm also thinking that for wal_level=archive a
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 10/27/14 7:27 AM, Stephen Frost wrote:
> > * Peter Eisentraut (pete...@gmx.net) wrote:
> >> On 10/16/14 12:01 PM, Stephen Frost wrote:
> >>> This started out as a request for a non-superuser to be able to review
> >>> the log files without needing ac
On 27 October 2014 20:24, Peter Geoghegan wrote:
> On Mon, Oct 27, 2014 at 1:22 PM, Robert Haas wrote:
>> On Mon, Oct 27, 2014 at 1:44 PM, Peter Geoghegan wrote:
>>> I think by far the biggest problem here is the
>>> lack of attention to the design from others.
>>
>> I find that attitude incredi
Andres Freund writes:
> On 2014-10-27 18:57:27 -0400, Andrew Dunstan wrote:
>> Notwithstanding what the docs say, I have seen CREATE DATABASE used plenty
>> of times, and quite effectively, to clone databases. I don't think making it
>> do twice the IO in the general case is going to go down well.
On 10/27/14 7:27 AM, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
>> On 10/16/14 12:01 PM, Stephen Frost wrote:
>>> This started out as a request for a non-superuser to be able to review
>>> the log files without needing access to the server.
>>
>> I think that can be done wit
On 10/27/2014 07:01 PM, Andres Freund wrote:
On 2014-10-27 18:57:27 -0400, Andrew Dunstan wrote:
On 10/27/2014 05:58 PM, Tomas Vondra wrote:
On 27.10.2014 17:24, Heikki Linnakangas wrote:
I'm also thinking that for wal_level=archive and large databases, this
won't really eliminate the checkpoi
I think the way this should work is that if you create a DIRALIAS, then
the COPY command should refer to it by logical name, e.g.,
CREATE DIRALIAS dumpster AS '/tmp/trash';
COPY mytable TO dumpster;
If you squint a bit, this is the same as a tablespace. Maybe those two
concepts could be combine
On 2014-10-27 18:57:27 -0400, Andrew Dunstan wrote:
>
> On 10/27/2014 05:58 PM, Tomas Vondra wrote:
> >On 27.10.2014 17:24, Heikki Linnakangas wrote:
> >I'm also thinking that for wal_level=archive and large databases, this
> >won't really eliminate the checkpoint as it will likely generate enough
On 10/27/2014 05:58 PM, Tomas Vondra wrote:
On 27.10.2014 17:24, Heikki Linnakangas wrote:
On 10/27/2014 03:46 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 10/27/2014 03:21 PM, Tomas Vondra wrote:
Thinking about this a bit more, do we really need a full checkpoint?
That
is a checkpoint
On Mon, Oct 20, 2014 at 3:32 PM, Marko Tiikkaja wrote:
> Hi,
>
> Here's the rebased patch -- as promised -- in a v7.
>
>
>
Hi Marko,
Using the same script as for the memory leak, I am getting seg faults using
this patch.
24425 2014-10-27 15:42:11.819 PDT LOG: server process (PID 24452) was
t
Tomas Vondra writes:
> That being said, our CREATE DATABASE docs currently say this
> Although it is possible to copy a database other than template1 by
> specifying its name as the template, this is not (yet) intended as
> a general-purpose "COPY DATABASE" facility. The principal
>
All,
Attached is a patch with minor updates/corrections.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/src/backend/catalog/Makefile b/src/backend/catalog/Makefile
new file mode 100644
index b257b02..8cdc5cb
***
On 27.10.2014 17:24, Heikki Linnakangas wrote:
> On 10/27/2014 03:46 PM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> On 10/27/2014 03:21 PM, Tomas Vondra wrote:
Thinking about this a bit more, do we really need a full checkpoint?
That
is a checkpoint of all the databases in th
On Mon, Oct 27, 2014 at 4:27 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Oct 27, 2014 at 3:31 PM, Tom Lane wrote:
>>> Why could we not remove the hasMessages flags again, and change the
>>> unlocked test
>>>
>>> if (!stateP->hasMessages)
>>> return 0;
>>>
>>> into
>>>
>>> if (stateP->ne
All,
I just ran through the patch giving it a good once over, some items to
address/consider/discuss:
* Trailing whitespace.
* Why are you making changes in foreigncmds.c? These seem like unnecessary
changes. I see that you are trying to consolidate but this refactor seems
potentially out of sc
Robert Haas writes:
> On Mon, Oct 27, 2014 at 3:31 PM, Tom Lane wrote:
>> Why could we not remove the hasMessages flags again, and change the
>> unlocked test
>>
>> if (!stateP->hasMessages)
>> return 0;
>>
>> into
>>
>> if (stateP->nextMsgNum == segP->maxMsgNum &&
>> !stateP->resetState)
>> r
On Mon, Oct 27, 2014 at 1:22 PM, Robert Haas wrote:
> On Mon, Oct 27, 2014 at 1:44 PM, Peter Geoghegan wrote:
>> I think by far the biggest problem here is the
>> lack of attention to the design from others.
>
> I find that attitude incredible.
What I mean is that that's the thing that clearly n
On Mon, Oct 27, 2014 at 1:44 PM, Peter Geoghegan wrote:
> I think by far the biggest problem here is the
> lack of attention to the design from others.
I find that attitude incredible.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsq
On Mon, Oct 27, 2014 at 3:31 PM, Tom Lane wrote:
> I happened to be looking at sinvaladt.c and noticed the loop added in
> commit b4fbe392f8ff6ff1a66b488eb7197eef9e1770a4:
>
> /*
> * Now that the maxMsgNum change is globally visible, we give everyone
> * a swift kick to m
I happened to be looking at sinvaladt.c and noticed the loop added in
commit b4fbe392f8ff6ff1a66b488eb7197eef9e1770a4:
/*
* Now that the maxMsgNum change is globally visible, we give everyone
* a swift kick to make sure they read the newly added messages.
* Relea
On 27 October 2014 19:21, Josh Berkus wrote:
> Hackers,
>
> I just realized that there is one thing we can't log currently:
> transactions which last more than #ms. This is valuable diagnostic
> information when looking for issues like causes of bloat and deadlocks.
>
> I'd like it to be on the
Hackers,
I just realized that there is one thing we can't log currently:
transactions which last more than #ms. This is valuable diagnostic
information when looking for issues like causes of bloat and deadlocks.
I'd like it to be on the TODO list because it seems like part of a good
GSOC project
On Mon, Oct 27, 2014 at 11:12 AM, Simon Riggs wrote:
> 1. Take the specific docs that relate to the patch and put them in one
> place, so that everybody can read and understand and agree the
> behaviour of the patch. So that someone reading that can see *exactly*
> what is being proposed, not read
Hi
2014-10-27 15:33 GMT+01:00 Andrew Dunstan :
>
> On 10/15/2014 03:54 PM, Andrew Dunstan wrote:
>
>>
>>
>>> I checked a code, and I have only two small objection - a name
>>> "jsonb_object_two_arg" is not good - maybe "json_object_keys_values" ?
>>>
>>
>> It's consistent with the existing json_o
On 27 October 2014 17:44, Peter Geoghegan wrote:
> I did a lot of copy-editing to the Wiki page yesterday. There are
> actually few clear open items now:
> https://wiki.postgresql.org/wiki/UPSERT#Open_Items
I've read this page.
Please do these things, both of which have been requested multiple
On Mon, Oct 27, 2014 at 9:43 AM, Simon Riggs wrote:
> On 27 October 2014 15:55, Robert Haas wrote:
>
>> Commenting on one aspect of a patch doesn't imply agreement with
>> other aspects of the patch. Please don't put words into my mouth. I
>> haven't reviewed this patch in detail; I've only com
On 27 October 2014 15:55, Robert Haas wrote:
> Commenting on one aspect of a patch doesn't imply agreement with
> other aspects of the patch. Please don't put words into my mouth. I
> haven't reviewed this patch in detail; I've only commented on specific
> aspects of it as they have arisen in d
Andrew Dunstan writes:
> Yeah. I think at the very least they should be removed from the
> check-world and installcheck-world targets until this is sorted out.
+1 for doing that in the 9.4 branch; I'm surprised we've not already
heard bitching from packagers about how far we've moved the goalpos
Heikki Linnakangas writes:
> On 10/27/2014 05:41 PM, Robert Haas wrote:
>> Beyond all that, I have serious doubts about whether, even if we
>> eventually get these tests mostly working in most places, whether they
>> will actually catch any bugs.
> The existing tests are not very useful, but it c
On 10/27/2014 03:46 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 10/27/2014 03:21 PM, Tomas Vondra wrote:
Thinking about this a bit more, do we really need a full checkpoint? That
is a checkpoint of all the databases in the cluster? Why checkpointing the
source database is not enough?
On 10/27/2014 02:12 PM, Fujii Masao wrote:
On Fri, Oct 24, 2014 at 10:05 PM, Heikki Linnakangas
wrote:
On 10/23/2014 11:09 AM, Heikki Linnakangas wrote:
At least for master, we should consider changing the way the archiving
works so that we only archive WAL that was generated in the same serv
On 10/09/2014 12:13 AM, Andres Freund wrote:
On 2014-10-08 22:13:46 +0300, Heikki Linnakangas wrote:
As far as I can tell, PostgreSQL's so-called CRC algorithm doesn't
correspond to any bit-by-bit CRC variant and polynomial. My math skills are
not strong enough to determine what the consequences
On 10/27/2014 11:41 AM, Robert Haas wrote:
On Sun, Oct 26, 2014 at 12:29 PM, Tom Lane wrote:
The larger issue though is that even with both the above things fixed,
the TAP tests would still be an expensive no-op on the majority of
buildfarm members. AFAICT, I do not own a single machine on wh
On 10/27/2014 05:41 PM, Robert Haas wrote:
On Sun, Oct 26, 2014 at 12:29 PM, Tom Lane wrote:
The larger issue though is that even with both the above things fixed,
the TAP tests would still be an expensive no-op on the majority of
buildfarm members. AFAICT, I do not own a single machine on whi
On Sun, Oct 26, 2014 at 4:39 PM, Peter Geoghegan wrote:
>> I don't care whether you actually generate index-paths or not, and in
>> fact I suspect it makes no sense to do so. But I do care that you do
>> a cost comparison between the available indexes and pick the one that
>> looks cheapest. If
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Oct 17, 2014 at 8:10 PM, Stephen Frost wrote:
> > * Peter Eisentraut (pete...@gmx.net) wrote:
> >> On 10/16/14 9:45 AM, Stephen Frost wrote:
> >> > Alright, coming back to this, I have to ask- how are matviews different
> >> > from views from
On Sun, Oct 26, 2014 at 12:29 PM, Tom Lane wrote:
> The larger issue though is that even with both the above things fixed,
> the TAP tests would still be an expensive no-op on the majority of
> buildfarm members. AFAICT, I do not own a single machine on which the
> current TAP tests will consent
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > As I started looking at this, there are multiple other places where
> > these types of error messages occur (opclasscmds.c, user.c,
> > postinit.c, miscinit.c are just a few), not just around the changes in
> > this patch. If we change them in
No. Costs for touching the index were computed by the amcostestimate
function; this code is solely about estimating costs for touching the
heap.
I see. Thank you.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW:
On Tue, Oct 28, 2014 at 12:12 AM, Robert Haas wrote:
> Committed and back-patched to 9.4.
Thanks.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Oct 24, 2014 at 5:14 PM, Michael Paquier
wrote:
> On Fri, Oct 24, 2014 at 7:42 PM, Robert Haas wrote:
>> [rhaas pgsql]$ patch -p1 < ~/Downloads/20141023_pg_recvlogical_fixes.patch
>> patching file doc/src/sgml/ref/pg_recvlogical.sgml
>> Hunk #1 succeeded at 270 with fuzz 1 (offset 165 lin
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Brightwell, Adam wrote:
> > > If we were to make it consistent and use the old wording, what do you
> > > think about providing an "errhint" as well?
> > >
> > > Perhaps for example in slotfuncs.c#pg_create_physical_replication_stot:
> > >
> > >
Teodor Sigaev writes:
> if (indexonly)
> pages_fetched = ceil(pages_fetched * (1.0 -
> baserel->allvisfrac));
> As I understand the code, index_pages_fetched() returns summary of page's
> read
> for index and heap together.
No. Costs for touching the index were computed
Hi!
Some fragment of code (src/backend/optimizer/path/costsize.c, lineno ~400):
/*
* Normal case: apply the Mackert and Lohman formula, and then
* interpolate between that and the correlation-derived result.
*/
pages_fetched = index_pages_fetched(tuples_
All,
* Peter Eisentraut (pete...@gmx.net) wrote:
> It would be weird if it were inconsistent: some things require role
> membership, some things require SET ROLE. Try explaining that.
Attached is a patch to address the pg_cancel/terminate_backend and the
statistics info as discussed previously.
* Stephen Frost (sfr...@snowman.net) wrote:
> Attached is a patch to address the pg_cancel/terminate_backend and the
> statistics info as discussed previously. It sounds like we're coming to
And I forgot the attachment, of course. Apologies.
Thanks,
Stephen
diff --git a
On 10/15/2014 03:54 PM, Andrew Dunstan wrote:
I checked a code, and I have only two small objection - a name
"jsonb_object_two_arg" is not good - maybe "json_object_keys_values" ?
It's consistent with the existing json_object_two_arg. In all cases I
think I kept the names the same except
On 2014-10-27 09:46:41 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 10/27/2014 03:21 PM, Tomas Vondra wrote:
> >> Thinking about this a bit more, do we really need a full checkpoint? That
> >> is a checkpoint of all the databases in the cluster? Why checkpointing the
> >> source data
Heikki Linnakangas writes:
> On 10/27/2014 03:21 PM, Tomas Vondra wrote:
>> Thinking about this a bit more, do we really need a full checkpoint? That
>> is a checkpoint of all the databases in the cluster? Why checkpointing the
>> source database is not enough?
> A full checkpoint ensures that yo
Hi,
I've previously posted a patch at
http://archives.postgresql.org/message-id/20141010160020.GG6670%40alap3.anarazel.de
that reduces contention in StrategyGetBuffer() by making the clock sweep
lockless. Robert asked me to post it to a new thread; I originally
wrote it to see some other contenti
Andres Freund writes:
> On 2014-10-27 12:51:44 +0200, Heikki Linnakangas wrote:
>> replication/slot.c and replication/logical/snapbuild.c use a CRC on the
>> physical slot and snapshot files. It uses the same algorithm as used e.g.
>> for the WAL. However, they are not doing the finalization step,
On 10/27/2014 03:21 PM, Tomas Vondra wrote:
Dne 27 Říjen 2014, 10:47, Heikki Linnakangas napsal(a):
On 10/26/2014 11:47 PM, Tomas Vondra wrote:
After eyeballing the code for an hour or two, I think CREATE DATABASE
should be fine with performing only a 'partial checkpoint' on the
template databa
Dne 27 Říjen 2014, 10:47, Heikki Linnakangas napsal(a):
> On 10/26/2014 11:47 PM, Tomas Vondra wrote:
>> After eyeballing the code for an hour or two, I think CREATE DATABASE
>> should be fine with performing only a 'partial checkpoint' on the
>> template database - calling FlushDatabaseBuffers and
On Fri, Oct 17, 2014 at 1:52 PM, Rahila Syed wrote:
> Hello,
>
> Please find the updated patch attached.
Thanks for updating the patch! Here are the comments.
The patch isn't applied to the master cleanly.
I got the following compiler warnings.
xlog.c:930: warning: ISO C90 forbids mixed declar
On Mon, Oct 27, 2014 at 8:45 PM, sudalai wrote:
> Hi,
>
>Is there any way to change the *master* without restarting the *standby*
> server.
>
> Postgresql Documentation says,
>-->Recovery.conf file only read on the startup in standby mode. In that
> file we specify the "Masterip".
>--
On Mon, Oct 27, 2014 at 8:15 PM, sudalai wrote:
>I need to query master ip from hot_standby.
> *pg_stat_replication* view only shows the slave replication status.
>
> Is there any way to get *Master IP* from standby node apart from checking
> *recovery.conf* file.
That's the way to go as it i
Dne 27 Říjen 2014, 13:50, Atri Sharma napsal(a):
>>
>>
>>
>> IMHO writing all the data into a WAL would be the cleanest solution.
>>
>> Also, what is a small database? I don't think a static value will work,
>> because the sweet spot between the current approach (forcing two
>> checkpoints) and wri
On Sat, Oct 25, 2014 at 9:12 PM, Tom Lane wrote:
> Haribabu Kommi writes:
>> Thanks for the details. I am sorry It is not proc_exit. It is the exit
>> callback functions that can cause problem.
>
>> The following is the callstack where the problem can happen, if the signal
>> handler is called af
>
>
>
> IMHO writing all the data into a WAL would be the cleanest solution.
>
> Also, what is a small database? I don't think a static value will work,
> because the sweet spot between the current approach (forcing two
> checkpoints) and writing everything in WAL depends on the amount of dirty
> b
On Sun, Oct 26, 2014 at 9:48 PM, Andreas Karlsson wrote:
> Agreed.. But I think reducing the lock level of the secondary table is much
> more important than doing the same for the primary table due to the case
> where the secondary table is an existing table which is hit by a workload of
> long ru
Thanks for weighing in, Noah.
On Sat, Oct 25, 2014 at 2:00 PM, Noah Misch wrote:
>> http://www.postgresql.org/message-id/ca+tgmoy4glsxzk0tao29-ljtcuj0sl1xwcwq51xb-hfysgi...@mail.gmail.com
>> http://www.postgresql.org/message-id/20893.1393892...@sss.pgh.pa.us
>> http://www.postgresql.org/message-i
On Tue, Oct 21, 2014 at 3:16 PM, Kyotaro HORIGUCHI
wrote:
> Wow.
>
>> > By the way, I became unable to login at all after wrongly setting
>> > *_preload_libraries for all available users. Is there any releaf
>> > measures for the situation? I think it's okay even if there's no
>> > way to login ag
On Fri, Oct 24, 2014 at 10:05 PM, Heikki Linnakangas
wrote:
> On 10/23/2014 11:09 AM, Heikki Linnakangas wrote:
>>
>> At least for master, we should consider changing the way the archiving
>> works so that we only archive WAL that was generated in the same server.
>> I.e. we should never try to ar
Dne 27 Říjen 2014, 10:47, Heikki Linnakangas napsal(a):
> On 10/26/2014 11:47 PM, Tomas Vondra wrote:
>> After eyeballing the code for an hour or two, I think CREATE DATABASE
>> should be fine with performing only a 'partial checkpoint' on the
>> template database - calling FlushDatabaseBuffers and
On 2014-10-27 12:51:44 +0200, Heikki Linnakangas wrote:
> replication/slot.c and replication/logical/snapbuild.c use a CRC on the
> physical slot and snapshot files. It uses the same algorithm as used e.g.
> for the WAL. However, they are not doing the finalization step, FIN_CRC32()
> on the calcul
On Sat, Oct 25, 2014 at 5:52 PM, Amit Kapila
wrote:
>
>
> ***
> *** 358,363 handle_sigint(SIGNAL_ARGS)
> --- 358,364
>
> /* Send QueryCancel if we are processing a database query */
> if (cancelConn != NULL)
> {
> + inAbort = true;
> if (PQcancel(cancelConn, errbuf, s
Hi,
Is there any way to change the *master* without restarting the *standby*
server.
Postgresql Documentation says,
-->Recovery.conf file only read on the startup in standby mode. In that
file we specify the "Masterip".
-->If you want to change the master we need to change the recove
On 2014-10-27 06:29:33 -0300, Alvaro Herrera wrote:
> Amit Langote wrote:
>
> > > On Mon, Oct 13, 2014 at 04:38:39PM -0300, Alvaro Herrera wrote:
> > > > Bruce Momjian wrote:
> > > > > I realize there hasn't been much progress on this thread, but I wanted
> > > > > to chime in to say I think our c
On 20 August 2014 08:09, Heikki Linnakangas wrote:
> On 08/20/2014 03:35 AM, Vladislav Sterzhanov wrote:
>
>> Hi there, pg-Hackers!
>> Here I go with the patch which brings up the possibility to perform
>> nearest-neighbour searches on SP-GiSTs (as of now includes implementation
>> for quad and k
On 26 October 2014 10:42, Haribabu Kommi wrote:
> Hi,
>
> I reviewed index scan optimization patch, the following are the
> observations.
>
> - Patch applies cleanly.
> - Compiles without warnings
> - All regress tests are passed.
>
> There is a good performance gain with the patch in almost a
On 18 August 2014 09:05, Heikki Linnakangas wrote:
> On 08/17/2014 07:15 PM, Anastasia Lubennikova wrote:
>
>> 2014-08-07 0:30 GMT+04:00 Heikki Linnakangas :
>>
>> * I'm getting two regression failures with this (opr_sanity and join).
>>
>>>
>>>
>> opr_sanity failure is corrected.
>> But there is
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 10/16/14 12:01 PM, Stephen Frost wrote:
> > This started out as a request for a non-superuser to be able to review
> > the log files without needing access to the server.
>
> I think that can be done with a security-definer function.
Of course it c
On Mon, Oct 27, 2014 at 4:44 PM, Heikki Linnakangas wrote:
> On 10/27/2014 01:06 PM, Atri Sharma wrote:
>
>>
>>>
>>>
To solve #1, we could redesign CREATE DATABASE so that replaying the
>>> DBASE_CREATE record doesn't zap the old directory, and also doesn't copy
>>> any files. We could inst
Hi,
I need to query master ip from hot_standby.
*pg_stat_replication* view only shows the slave replication status.
Is there any way to get *Master IP* from standby node apart from checking
*recovery.conf* file.
Thanks,
Sudalai
-
sudalai
--
View this message in context:
http:
On 10/27/2014 01:06 PM, Atri Sharma wrote:
To solve #1, we could redesign CREATE DATABASE so that replaying the
DBASE_CREATE record doesn't zap the old directory, and also doesn't copy
any files. We could instead just assume that if the transaction commits,
all the files have been copied and
On Fri, Oct 24, 2014 at 11:21 PM, Heikki Linnakangas
wrote:
> On 10/24/2014 01:24 PM, furu...@pm.nttdata.co.jp wrote:
>
> Sorry, I'm going around in the circle. But I'd like to say again, I
> don't think this is good idea. It prevents asynchronous
> pg_receivexlog from fsyncing WAL
>
>
>>
> To solve #1, we could redesign CREATE DATABASE so that replaying the
> DBASE_CREATE record doesn't zap the old directory, and also doesn't copy
> any files. We could instead just assume that if the transaction commits,
> all the files have been copied and fsync'd already, like we assume th
2014-10-27 11:20 GMT+01:00 Ali Akbar :
>
> 2014-10-27 16:15 GMT+07:00 Pavel Stehule :
>
>> Hi
>>
>> I did some minor changes in code
>>
>> * move tests of old or new builder style for array sublink out of main
>> cycles
>> * some API simplification of new builder - we should not to create
>> ident
replication/slot.c and replication/logical/snapbuild.c use a CRC on the
physical slot and snapshot files. It uses the same algorithm as used
e.g. for the WAL. However, they are not doing the finalization step,
FIN_CRC32() on the calculated checksums. Not that it matters much, but
it's a bit wei
At 2014-09-25 22:41:18 +0200, and...@2ndquadrant.com wrote:
>
> On 2014-09-24 17:06:05 +0530, Abhijit Menon-Sen wrote:
> >
> > 1. Move the call to ResetUnloggedRelations(UNLOGGED_RELATION_INIT) to
> >earlier in StartupXLOG.
> >
> > 2. Inside that function, issue fsync()s for the main forks we
1 - 100 of 109 matches
Mail list logo
