y.sql and
foo--[version]--unset-parallel-safety.sql
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
:
SET VARIABLE foo='bar';
Perhaps one can have a short form of:
SET VAR foo = 'bar';
vs
SET foo = 'bar'; -- GUC
>
> regards, tom lane
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make c
y
causing the problem. My guess is that either you didn't declare the type
properly or there is some other error in your function, but the information
provided is not sufficient to answer it.
Best or luck asking on -general.
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
upport different use cases
well and then build common infrastructure to support the different cases.
I am not against building common infrastructure for pg_rewind and
pg_basebackup. I am very much against having the core guarantees being the
exact same.
Best Wishes,
Chris Travers
On Sat, Oct 28, 20
On Tue, Oct 31, 2017 at 1:38 PM, Robert Haas wrote:
> On Mon, Oct 30, 2017 at 6:44 PM, Chris Travers
> wrote:
> > The attached patch is cleaned up and filed for the commit fest this next
> > month:
>
> It's generally better to post the patch on the same message as t
ns of PostgreSQL to bump this
setting up to ever higher values, I am wondering if anyone has done this
yet and if so if you would be willing to share results.
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a,
d2fa1
tag: mine/pg_rewind_restrict_dirs
parent: 60446:e638ba9c3c11
user: Chris Travers
date:Mon Oct 30 12:25:18 2017 +0100
files: doc/src/sgml/ref/pg_rewind.sgml src/bin/pg_rewind/copy_fetch.c
src/bin/pg_rewind/fetch.c src/bin/pg_rewind/fetch.h
src/bin
On Mon, Oct 30, 2017 at 11:36 AM, Michael Paquier wrote:
> On Mon, Oct 30, 2017 at 10:15 AM, Chris Travers
> wrote:
> > This also brings up a fairly major concern more generally about control
> by
> > the way. A lot of cases where pg_rewind is called, the user doesn't
On Mon, Oct 30, 2017 at 10:57 AM, Michael Paquier wrote:
> On Mon, Oct 30, 2017 at 9:43 AM, Chris Travers
> wrote:
> > Are there any cases right now where you have features added by
> extensions that write to directories which are required for a rewind?
>
> In some of th
First, thanks for your thoughts on this, and I am interested in probing
them more.
On Mon, Oct 30, 2017 at 9:04 AM, Michael Paquier
wrote:
> On Sat, Oct 28, 2017 at 4:22 AM, Chris Travers
> wrote:
> > The Solution:
> > The solution is a whitelist of directories specified
ter the output.
>
> Regards
>
> Pavel
>
>
>
>
>>
>>
>>> regards
>>>
>>> Pavel
>>>
>>>
>>>
>>
>>
>> --
>> Best Regards,
>> Chris Travers
>> Database Administrator
>>
&
settings.
3. In a subsequent stage you might be able to SELECT INTO
setting_name FROM ; allowing access to setting writes based on queries.
> regards
>
> Pavel
>
>
>
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
ore descriptive name but
currently did not remove the old function yet.
Feedback is very welcome. pg_rewind is a very nice piece of software. I
am hoping that these sorts of changes will help ensure that it is easier to
use and provides more predictable results.
--
Best Regards,
Chris T
!: dfetter
> Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
>
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
On Wed, Sep 13, 2017 at 6:28 AM, Michael Paquier
wrote:
> On Tue, Sep 12, 2017 at 11:52 PM, Chris Travers
> wrote:
> > Additionally the wal, xact, timestamp and logical directories must be
> > processed in some way.
>
> To what does the term "logical directories&
.
Problems that we will not try to solve:
* Rewinding past table creation orphans table file. This is a complex
topic on its own and probably needs a separate utility.
Thoughts?
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
tion of a small table. I
don't see an easy or safe way to address that from inside pg_rewind without
a lot of complication. It might be better to have a dedicated tool for
that.
>
> Now, in order for any of this to happen, there will need to be a
> champion to define what the mis
undo subsystem would fix this.
Is this a reason to rethink the idea that maybe a pg_fsck utility might be
useful that could be run immediately after a rewind?
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
under heavy load.
>
How would this work when it comes to rewinding against a file directory?
>
> --
> May the force be with you…
> https://simply.name
>
>
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
On Tue, Sep 5, 2017 at 1:04 PM, Michael Paquier
wrote:
> On Tue, Sep 5, 2017 at 7:54 PM, Vladimir Borodin wrote:
> > 5 сент. 2017 г., в 12:31, Chris Travers
> > написал(а):
> >
> > I think the simplest solution for now is to skip any files ending in
> .conf,
>
On Tue, Sep 5, 2017 at 12:54 PM, Vladimir Borodin wrote:
>
> 5 сент. 2017 г., в 12:31, Chris Travers
> написал(а):
>
> I think the simplest solution for now is to skip any files ending in
> .conf, .log, and serverlog.
>
>
> Why don’t you want to solve the problem once
On Mon, Sep 4, 2017 at 3:38 PM, Alvaro Herrera
wrote:
> Chris Travers wrote:
> > On Mon, Sep 4, 2017 at 12:23 PM, Michael Paquier <
> michael.paqu...@gmail.com>
> > wrote:
> >
> > > On Mon, Sep 4, 2017 at 7:21 PM, Michael Paquier
> > > wr
sequently, I think it would be good to fix in the tool. The
fundamental question is if there is any reason someone would actually want
to copy config files over.
--
> Michael
>
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
of any cases where anyone would actually
want to do this but that doesn't mean they aren't out there. If people
really want to, then they need to copy the configuration files they want
separately.
Next Steps:
If people like this idea I will add test cases and edit documentation as
app
file tree traversal.
Any feedback before I create.a proof of concept?
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
On Fri, Aug 25, 2017 at 12:15 PM, Petr Jelinek wrote:
> On 25/08/17 10:28, Chris Travers wrote:
> >
> >
> > On Thu, Aug 24, 2017 at 9:44 PM, Andres Freund > <mailto:and...@anarazel.de>> wrote:
> >
> > Hi,
> >
> > On 2017-08-18
y of moving forward.
But I still think the question of what to test ought to be geared around
"what are we willing to try to guarantee as behaviour for some years, not
just to ourselves but to third parties."
>
> Greetings,
> Torsten
>
>
> --
> Sent via pgsql-hacker
ailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
On Aug 21, 2017 07:47, "Simon Riggs" wrote:
On 18 August 2017 at 15:40, Alvaro Herrera wrote:
> Ildar Musin wrote:
>
>> While we've been developing pg_pathman extension one of the most frequent
>> questions we got from our users was about global index support. We cannot
>> provide it within an e
On Sun, Aug 20, 2017 at 4:10 AM, MauMau wrote:
> From: Chris Travers
> > Why cannot you do all this in a language handler and treat as a user
> defined function?
> > ...
> > If you have a language handler for cypher, why do you need in_region
> or cast_region? Why n
e data models pluggable,
> especially related to plugging the parser, planner, executor, etc?
> One possible concern is that various PostgreSQL components might be
> too dependent on the data model being relational, and it would be
> difficult to separate tight coupling.
>
I guess I am m
hear it.
>
> [1] https://www.postgresql.org/message-id/c8fe4f6b-ff46-aae0-89e
> 3-e936a35f0cfd%40postgrespro.ru
>
> Thanks!
>
> --
> Ildar Musin
> i.mu...@postgrespro.ru
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make chang
l programs to do after-the-fact
review and cleanup.
>
> Greetings,
>
> Andres Freund
>
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
make
sure everything is ok?
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
On Tue, Aug 15, 2017 at 3:32 PM, Tom Lane wrote:
> Chris Travers writes:
> > I wonder about a different solution. Would it be possible to special
> case
> > vacuum to check for and remove (or just move to where they can be
> removed)
> > files when vacuuming pg_
we
ought to be able to know that a relfilenode shouldn't be used anymore,
right?
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
ions
but that I might be able to do.
>
> regards, tom lane
>
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
On Mon, Aug 14, 2017 at 6:33 PM, Andres Freund wrote:
> Hi,
>
> On 2017-08-14 14:12:22 +0200, Chris Travers wrote:
> > Problem:
> > The system this came up on is PostgreSQL 9.6.3 and has had repeated
> trouble
> > with disk space. Querying pg_database_size, as well
On Aug 14, 2017 14:12, "Chris Travers" wrote:
Hi all;
I am trying to track down a problem we are seeing that looks very similar
to bug #12050, and would certainly consider trying to contribute a fix if
we agree on one. (I am not sure we can, so absent that, the next question
is
various
operations including creating materialised views.
So my question is if there is a way we can safely clean these up on server
restart? If not does it make sense to try to create a utility that can
connect to PostgreSQL, seek out valid files, and delete the rest?
--
Best Regards,
Chris Travers
On Fri, Aug 11, 2017 at 1:33 PM, Greg Stark wrote:
> On 10 August 2017 at 15:26, Chris Travers wrote:
> >
> >
> > The bitwise comparison is interesting. Remember the error was:
> >
> > pg_xlogdump: FATAL: error in WAL record at 1E39C/E1117FB8: unexpected
&
On Fri, Aug 11, 2017 at 1:33 PM, Greg Stark wrote:
> On 10 August 2017 at 15:26, Chris Travers wrote:
> >
> >
> > The bitwise comparison is interesting. Remember the error was:
> >
> > pg_xlogdump: FATAL: error in WAL record at 1E39C/E1117FB8: unexpected
&
of
this size.
>
> Likelihood of two different persons seeing similar error message just a
> year apart is low. From our practice hardware corruption usually looks like
> a random single bit flip (most common - bad cpu or memory), bunch of zeroes
> (bad storage), or bunch of complet
pg_xlogdump: FATAL: error in WAL record at 1E39C/E1117FB8: unexpected
pageaddr 1E375/61118000 in log segment 0001E39C00E1, offset
1146880
> --
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
Sorry, meant to reply all.
On Thu, Aug 10, 2017 at 2:19 PM, Vladimir Borodin wrote:
> Hi, Chris.
>
> 10 авг. 2017 г., в 15:09, Chris Travers
> написал(а):
>
> Hi;
>
> I ran into a funny situation today regarding PostgreSQL replication and
> wal corruption and wan
hings from
happening in the future if, for example, a replica dies in the middle of a
wal fsync.
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
On Tue, Nov 29, 2016 at 1:13 PM, Tom Lane wrote:
> Pushed with that change and some other mostly-cosmetic tweaking.
Thank you for addressing all those issues, Tom! I tested some
exclusion constraints that are interesting to me, and everything seems
to be working well.
-- Chris
--
Sent
e and add
> btree_gist--1.2--1.3.sql. That way we don't have to worry about whether
> the upgrade script matches the change in the base script.
Done.
-- Chris
btree_gist_uuid_8.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
nal format.)
Perhaps a function xpath_value(text, xml) -> text[] would close the gap?
(I did search and no such function seems to exist currently, outside
xml2.)
Thanks,
Chris
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
fno-common flag and see if
that fixes things.
Thanks Tom for spending part of your weekend on this.
Chris.
> On Mar 12, 2016, at 17:58, Tom Lane wrote:
>
> I wrote:
>> That's confusing because it implies that -fno-common is the default,
>> which it evidently is not. But
om the original host.
Am I missing something with this change?
Cheers,
Chris
I need this feature a lot. Can anyone point me to a place in the code
where I can hack together a quick-and-dirty, compatibility-breaking
implementation? Thanks!
On Sun, May 3, 2015 at 10:03 PM, Jim Nasby wrote:
> On 5/3/15 11:59 AM, Andrew Dunstan wrote:
>
>>
>> On 05/03/2015 11:49 AM, Tom La
Has there been any movement on this in the last couple years?
I could really use the ability to optimize across CTE boundaries, and it
seems like a lot of other people could too.
Hi Christoph,
- Original Message -
> From: "Christoph Berg"
> To: "Chris Butler"
>
> Googling for "digest too big for rsa key" seems to indicate that this
> problem occurs when you are using (client?) certificates with short
> RSA k
I'm on PostgreSQL 9.3. This should reproduce on any table with 100,000+
rows. The EXPLAIN ANALYZE shows many more rows getting scanned with LIMIT
2, but I can't figure out why.
Limit 1:
EXPLAIN ANALYZE WITH base AS (
SELECT *, ROW_NUMBER() OVER () AS rownum FROM a_big_table
), filter AS (
S
Is this some of that crufty code? Can
it be removed?
-- Chris
originally
thought but that just means it will take longer.
>
> cheers
>
> andrew
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
Best Wishes,
Chris Travers
http://www.2ndquadrant.com
PostgreSQL Services, Training, and Support
","PS4","ACTION","FIRST PERSON
> SHOOTER"],"external_api_key":null}]'::JSON
>
> SELECT * FROM json_populate_recordset(null::varrm.item, '[{"title":"My
> Title","short_desc":"My Short Desc"
ether to merge the changes into the core,
This will be an interesting way to get into PostgreSQL hacking.
Best Wishes,
Chris Travers
>
> merlin
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http
his would be a frequently moving target and over years of billing,
the subset would be quite small compared to the full system (imagine, say, 50k
rows out of 20M).
Best Wises,
Chris Travers
>
> - Heikki
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
&
> On 15 September 2013 at 18:42 Andrew Dunstan wrote:
>
>
>
> On 09/14/2013 10:27 PM, chris travers wrote:
>
> Well, you could fairly easily build it as an extension as a POC. The
> main point of the API this is built on was to allow for extensions.
>
> The logic
build something like this first as an extension
(perhaps with different function names) or first as a patch?
Best Wishes,
Chris Travers
http://www.2ndquadrant.com
PostgreSQL Services, Training, and Support
comment away any time you please.
Well, I don't know if my feedback above is helpful, but there it is ;-)
>
>
> Regards,
> Marko Tiikkaja
>
> [1]: http://www.postgresql.org/message-id/510bf731.5020...@gmx.net
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
Best Wishes,
Chris Travers
http://www.2ndquadrant.com
PostgreSQL Services, Training, and Support
g their upgrade then, maybe there
would need to be some kind of system to workaround this
Possibly some kind of "catch-all" channel, that enables implicit channel
names?
GRANT LISTEN, NOTIFY ON CHANNEL * TO PUBLIC; -- enabled by default for
backwards compat
NOTIFY xxxx; -- OK
o see what might be involved [attached], and would like
to hear people thoughts; good idea, bad idea, not like that! etc
Chris.
async_privileges_r0.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
" function.
Chris
On 20 May 2013 03:23, Tom Lane wrote:
> Chris Farmiloe writes:
> > I find the current LISTEN / NOTIFY rather limited in the context of
> > databases with multiple roles. As it stands it is not possible to
> restrict
> > the use of LISTEN or
o see what might be involved [attached], and would like
to hear people thoughts; good idea, bad idea, not like that! etc
Chris.
async_privileges_r0.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
What's the use case of this? It sounds like it will just create a maintenance
nightmare where some stuff you expect to lookup in in postgresql.conf is
actually hiding in the .auto file. Assuming only super users/sysadmins would
have the ability to change things in the config file, wouldn't they
Would this introduce problems finding rows where the stored value is NaN? You'd
need to add a function or operator to avoid that.
Il giorno 28/ott/2012, alle ore 20:43, Hannu Krosing ha scritto:
> This is how PostgreSQL currently works -
>
> test=# select 'NaN'::float = 'NaN'::float as must_be_
ound-trips to the server, however.
That said, I believe PQexecParams() is doing a similar thing, in that it
internally prepares a statement, then executes it (2 round trips). Or am I
needlessly concerning myself over microseconds here?
Cheers,
Chris
--
Sent via pgsql-hackers mailing list (pgs
live with this workaround, as
only one particular view seems to be affected, but if you want me to
debug more on the error please let me know.
Thanks for your help until now!
Chris
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ew solves this
issue. Given this, how should I proceed to create a test case? Any
tutorial on this? (I'm not too familiar with all this yet.)
Chris
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
definitions, which I'm willing to share privately
if that helps. The views actually differ, although the look identical
with \d+ in the psql console, in that the newer view names more columns
that were added to the referenced tables lately.
So, you tell me, what's wrong with the old vi
On Wed, Nov 9, 2011 at 6:22 PM, Florian Pflug wrote:
> On Nov9, 2011, at 23:53 , Daniel Farina wrote:
> > I think a novice user would be scared half to death: I know I was the
> > first time. That's not a great impression for the project to leave
> > for what is not, at its root, a vast defect,
okay, sorry I'm a little confused then. Should I be able to apply both the
v2 patch as well as the v3 patch? or is it expected that I'd have to
manually do the merge?
On Wed, Nov 2, 2011 at 1:34 AM, Simon Riggs wrote:
> On Wed, Nov 2, 2011 at 2:40 AM, Chris Redekop wrote:
>
oopsreply-to-all
-- Forwarded message --
From: Chris Redekop
Date: Wed, Nov 2, 2011 at 8:41 AM
Subject: Re: [HACKERS] Hot Standby startup with overflowed snapshots
To: Simon Riggs
Sure, I've got quite a few logs lying around - I've attached 3 of 'em...let
m
looks like the v3 patch re-introduces the pg_subtrans issue...
On Tue, Nov 1, 2011 at 9:33 AM, Simon Riggs wrote:
> On Thu, Oct 27, 2011 at 4:25 PM, Simon Riggs
> wrote:
>
> > StartupMultiXact() didn't need changing, I thought, but I will review
> further.
>
> Good suggestion.
>
> On review, S
any way I can...but
if you're not too worried about it then neither am I :)
On Thu, Oct 27, 2011 at 4:55 PM, Simon Riggs wrote:
> On Thu, Oct 27, 2011 at 10:09 PM, Chris Redekop
> wrote:
>
> > hrmz, still basically the same behaviour. I think it might be a *little*
>
..or is it
actually as designed that it could take 10-ish minutes to start up even
after all clients have disconnected from the primary?
On Thu, Oct 27, 2011 at 11:27 AM, Simon Riggs wrote:
> On Thu, Oct 27, 2011 at 5:26 PM, Chris Redekop wrote:
>
> > Thanks for the patch Simon, but unf
u, Oct 27, 2011 at 7:26 AM, Simon Riggs wrote:
> Chris Redekop's recent report of slow startup for Hot Standby has made
> me revisit the code there.
>
> Although there isn't a bug, there is a missed opportunity for starting
> up faster which could be the source of Chris&#
FYI I have given this patch a good test and can now no longer reproduce
either the subtrans nor the clog error. Thanks guys!
On Wed, Oct 26, 2011 at 11:09 AM, Simon Riggs wrote:
> On Wed, Oct 26, 2011 at 5:16 PM, Simon Riggs
> wrote:
> > On Wed, Oct 26, 2011 at 5:08 PM, Simon Riggs
> wrote:
> And I think they also reported that if they didn't run hot standby,
> but just normal recovery into a new master, it didn't have the problem
> either, i.e. without hotstandby, recovery ran, properly extended the
> clog, and then ran as a new master fine.
Yes this is correct...attempting to start
>
> That isn't a Hot Standby problem, a recovery problem nor is it certain
> its a PostgreSQL problem.
>
Do you have any theories on this that I could help investigate? It happens
even when using pg_basebackup and it persists until another sync is
performed, so the files must be in some state that
> Chris, can you rearrange the backup so you copy the pg_control file as
> the first act after the pg_start_backup?
I tried this and it doesn't seem to make any difference. I also tried the
patch and I can no longer reproduce the subtrans error, however instead it
now it starts up
er load it cleared itself upI'm shooting in the dark here
Anyone have any suggestions/ideas/things to try?
On Mon, Oct 17, 2011 at 2:13 PM, Chris Redekop wrote:
> I can confirm that both the pg_clog and pg_subtrans errors do occur when
> using pg_basebackup instead of rsync. The da
7:33 PM, Chris Redekop wrote:
> > > Linas, could you capture the output of pg_controldata *and* increase
> the
> > > log level to DEBUG1 on the standby? We should then see nextXid value of
> > > the checkpoint the recovery is starting from.
> >
> >
> > Linas, could you capture the output of pg_controldata *and* increase the
> > log level to DEBUG1 on the standby? We should then see nextXid value of
> > the checkpoint the recovery is starting from.
>
> I'll try to do that whenever I'm in that territory again... Incidentally,
> recently there w
Thanks for all the feedback guys. Just to throw another monkey wrench in
here - I've been playing with Simon's proposed solution of returning 0 when
the WAL positions match, and I've come to the realizatiion that even if
using pg_last_xact_insert_timestamp, although it would help, we still
wouldn'
chemas of the form "parent!%". In this case the "%" sign could maybe only
> match everything except "!" and the "*" symbol could be used to match "!" as
> well.
Agreed that this would be helpful. I would personally have a lot of
use for this sort o
da...@kineticode.com ("David E. Wheeler") writes:
> You should blog this.
He just did, using the SMTP protocol...
--
select 'cbbrowne' || '@' || 'acm.org';
http://linuxdatabases.info/info/postgresql.html
Where do you want to Tell Microsoft To Go Today?
--
Sent via pgsql-hackers mailing list (pg
j...@agliodbs.com (Josh Berkus) writes:
>> I don't understand what you're talking about at all here. I think
>> there are a lot of unsolved problems in monitoring but the one thing
>> I think everyone is pretty clear on is that the right way to export
>> metrics like these is to export a counter an
robertmh...@gmail.com (Robert Haas) writes:
> It does, but frankly I don't see much reason to change it, since it's
> been working pretty well on the whole. Andrew was on point when he
> mentioned that it's not obvious what committers get out of working on
> other people's patches. Obviously, the
t...@sss.pgh.pa.us (Tom Lane) writes:
> Peter Eisentraut writes:
>> On mån, 2011-02-14 at 10:13 -0500, Tom Lane wrote:
>>> Peter Eisentraut writes:
Why do the extension load files need two dashes, like xml2--1.0.sql?
Why isn't one enough?
>
>>> Because we'd have to forbid dashes in exte
pg...@j-davis.com (Jeff Davis) writes:
> On Wed, 2011-02-09 at 16:20 -0500, Chris Browne wrote:
>> rangetest@localhost-> explain analyze select * from some_data where
>> '[2010-01-01,2010-02-01)'::daterange @> whensit;
>>
One of the things I'd particularly like to use range types for is to
make it easier to construct range-related queries. Classic example is
that of reports that work on date ranges.
I create a table that will have transaction data:
CREATE TABLE some_data (
id serial,
whensit date
-- A
pg...@j-davis.com (Jeff Davis) writes:
> On Tue, 2011-02-08 at 15:10 -0500, Chris Browne wrote:
>> It's more than a bit sad... The RangeType change has the massive merit
>> of enabling some substantial development changes, where we can get rid
>> of whole classes
pg...@j-davis.com (Jeff Davis) writes:
> On Tue, 2011-02-08 at 06:57 -0500, Stephen Frost wrote:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>> > - Range Types. This is a large patch which was submitted for the
>> > first time to the last CommitFest of the cycle, and the first version
>> > tha
sfr...@snowman.net (Stephen Frost) writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> - Range Types. This is a large patch which was submitted for the
>> first time to the last CommitFest of the cycle, and the first version
>> that had no open TODO items was posted yesterday, three-quarters
dp...@pgadmin.org (Dave Page) writes:
> On Mon, Feb 7, 2011 at 6:55 PM, Robert Haas wrote:
>> On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
>>> Robert Haas writes:
... Well, the current CommitFest ends in one week, ...
>>>
>>> Really? I thought the idea for the last CF of a development
peder...@ccsscorp.com ("Bill Pedersen") writes:
> I look forward to hearing from people in the PostgreSQL community as well as
> from others interested in this effort.
To a number of us, it's academically interesting, though, as we don't
have VMS systems, it's not likely to be super-easy to assist
1 - 100 of 507 matches
Mail list logo
