On Wed, 2010-04-28 at 22:17 +0200, Dimitri Fontaine wrote:
> IMO the real fun begins when we talk about multi-slaves support and
> their roles (a failover slave wants the master to wait for it to have
> applied the WAL before to commit, a reporting slave not so much). So
> you'd set the Availabili
On ons, 2010-04-28 at 15:21 +0100, Mike Fowler wrote:
> xpath_exists() is needed. It checks, whether or not the path specified
> exists in the XML value. (W/o this function we need to use weird
> "array_dims(xpath(...)) IS NOT NULL" syntax.)
That sounds like a reasonable project.
> Is any one e
On Thu, Apr 29, 2010 at 1:14 AM, Heikki Linnakangas
wrote:
> Ok, I've finally committed the patch, using wal_level as the name of the
> GUC.
> ! if (InArchiveRecovery && XLogRequestRecoveryConnections)
> ! {
> ! if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY)
> !
Dimitri Fontaine wrote:
IMO the real fun begins when we talk about multi-slaves support and
their roles (a failover slave wants the master to wait for it to have
applied the WAL before to commit, a reporting slave not so much). So
you'd set the Availability level on each slave and wouldn't commit
Aidan Van Dyk wrote:
I remember a presentation at pgcon a while ago, it was probaly Fujii
(from NTT?) about their log streaming, and at that time, they talked
about different "sync" options...
It's all outlined at
http://wiki.postgresql.org/wiki/Streaming_Replication#Synchronization_capability
Robert Haas writes:
> We can artificially make this problem as complicated as we wish, but
> the people who are asking for this feature (including me) will, I
> believe, be quite happy with a solution that throws, say, a NOTICE
> instead of an ERROR when the object already exists, and then returns
Simon Riggs writes:
> It's possible to set toast reloptions for tables that don't have toast
> tables at all. e.g.
> create table test (c1 integer);
> ALTER TABLE test SET (toast.autovacuum_enabled = off);
> Why?
1. Why not?
2. They might have toast tables later, after an ALTER ADD COLUMN
fo
On Wed, Apr 28, 2010 at 2:57 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Robert Haas wrote:
>>> Well, how would you define CREATE OR REPLACE TABLE?
>
>> It the table doesn't exist, create it. If it exists with the same name
>> and same columns and constraints and all, do nothing. Otherwis
It's possible to set toast reloptions for tables that don't have toast
tables at all. e.g.
create table test (c1 integer);
ALTER TABLE test SET (toast.autovacuum_enabled = off);
Why?
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
2009/10/12 Teodor Sigaev :
>
>
>> Are you planning to submit this as a /contrib module?
>
> I haven't objections to do that, we don't planned that because we know
> sceptical
> relation of community to hints :)
this could be very useful now that we have HS and we aren't able to
use hash indexes on
* Kevin Grittner [100428 15:51]:
> > I don't personally care about streaming replication replaying WAL
> > as it comes, or running queries in recovery...
>
> I'm with you that far, but I wouldn't want the sender to wait for
> remote persistence.
I remember a presentation at pgcon a while ago
"Kevin Grittner" writes:
> Aidan Van Dyk wrote:
>
>> I'm hoping to be able to build a tool that:
>>
>> 1) Connects to PG walsender (a la walreceiver)
>> 2) Streams WAL from pg master
>> 3) Saves WAL into "files" (a la archive)...
>>
>> i.e. I'm looking to keep a more-up-to-date PITR archive t
Aidan Van Dyk wrote:
> I'm hoping to be able to build a tool that:
>
> 1) Connects to PG walsender (a la walreceiver)
> 2) Streams WAL from pg master
> 3) Saves WAL into "files" (a la archive)...
>
> i.e. I'm looking to keep a more-up-to-date PITR archive than
> waiting for traditional WAL fil
Heikki Linnakangas writes:
> Hmm, you could start streaming the WAL before you start the backup, so
> the fact that you've already removed some segments that are needed to
> restore from the backup by the time pg_stop_backup() is called doesn't
> necessarily mean that the backup is useless.
> You
* Heikki Linnakangas [100428 14:49]:
> You'd need a stand-alone tool to do the streaming in that case, and no
> such tool exists yet, but I would be surprised if one doesn't appear on
> pgfoundry sooner or later :-).
And this tool is something I will eventually be interested in working on
or co
Heikki Linnakangas writes:
> Robert Haas wrote:
>> Well, how would you define CREATE OR REPLACE TABLE?
> It the table doesn't exist, create it. If it exists with the same name
> and same columns and constraints and all, do nothing. Otherwise throw an
> error.
> Maybe it should also check that th
On Tue, Apr 27, 2010 at 8:15 PM, Craig Ringer
wrote:
>
> Another avenue possibly worth investigating may be using the in-heap
> mvcc information to do SQL-level differential backups of individual
> tables or of the whole database. think:
>
You can't use the mvcc information to do incremental back
--- Den ons 2010-04-28 skrev Tom Lane :
> Fra: Tom Lane
> Emne: Re: [HACKERS] Add column if not exists (CINE)
> Til: "Robert Haas"
> Kopi: "Andrew Dunstan" , "Takahiro Itagaki"
> , "Kjell Rune Skaaraas" ,
> pgsql-hackers@postgresql.org
> Dato: Onsdag 28. april 2010 17.20
> Robert Haas
> wri
Simon Riggs wrote:
> On Wed, 2010-04-28 at 14:21 -0400, Tom Lane wrote:
>> Is there any use in looking
>> at wal_keep_segments as part of this test?
>
> I would hope that pg_stop_backup() will have a conditional ERROR message
> to say
>
> ERROR backup inconsistent and cannot be used for SR
> HINT
Tom Lane wrote:
> Any particular place where you think it's unnecessary?
How about the 2nd (tag pointer) parameter for hash_search?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ha
Robert Haas wrote:
> On Wed, Apr 28, 2010 at 12:07 PM, Heikki Linnakangas
> wrote:
>> Robert Haas wrote:
>>> On Wed, Apr 28, 2010 at 11:20 AM, Tom Lane wrote:
Robert Haas writes:
> I don't believe you are fairly stating the consensus from previous
> discussion and I believe that you
On Wed, 2010-04-28 at 14:21 -0400, Tom Lane wrote:
> Is there any use in looking
> at wal_keep_segments as part of this test?
I would hope that pg_stop_backup() will have a conditional ERROR message
to say
ERROR backup inconsistent and cannot be used for SR
HINT increase wal_keep_segments or enab
"Kevin Grittner" writes:
> I'm wondering the reason that I see (void *) casts for function call
> parameters which are pointers to specific structures. Do some
> compilers generate warnings if these are omitted?
There are some places where we do that to suppress warnings, yes.
Any particular pla
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Tom Lane wrote:
>>> If you aren't archiving then there's no guarantee that you'll still have
>>> a continuous WAL series starting from the start of the backup.
>
>> I wasn't really thinking of this use case, but you could set
>> wal_keep_segments "h
Robert Haas writes:
> Well, how would you define CREATE OR REPLACE TABLE? I think that
> doesn't make much sense, which is why I think CREATE IF NOT EXISTS is
> a reasonable approach.
The behavior I'd like to have would be to allow me to give a SELECT
query to run for replacing what is there i
Heikki Linnakangas wrote:
> Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> Well, it would be nice to allow using pg_start_backup() on the primary
>>> when streaming replication is enabled, even if archiving isn't.
>>> Otherwise the only way to get the base backup for the standby is to shut
>>>
Heikki Linnakangas writes:
> Tom Lane wrote:
>> If you aren't archiving then there's no guarantee that you'll still have
>> a continuous WAL series starting from the start of the backup.
> I wasn't really thinking of this use case, but you could set
> wal_keep_segments "high enough".
Ah. Okay,
I'm wondering the reason that I see (void *) casts for function call
parameters which are pointers to specific structures. Do some
compilers generate warnings if these are omitted? It's hard to
believe that the generated code would differ without them.
-Kevin
--
Sent via pgsql-hackers mailing
On Wed, Apr 28, 2010 at 1:40 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> Well, how would you define CREATE OR REPLACE TABLE? I think that
>> doesn't make much sense, which is why I think CREATE IF NOT EXISTS is
>> a reasonable approach.
>
>
>
> The behavior I'd like to have would be to
On Wed, 2010-04-28 at 11:11 -0700, Josh Berkus wrote:
> > IOW I think that the requirement in pg_start_backup shouldn't be relaxed
> > without some more thought/work.
>
> Yeah, I was talking to Bruce about that this AM, and it seems like a
> feature we *need* to have ... for 9.1.
>
> I'm sufficie
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Well, it would be nice to allow using pg_start_backup() on the primary
>> when streaming replication is enabled, even if archiving isn't.
>> Otherwise the only way to get the base backup for the standby is to shut
>> down primary first, or use filesy
> IOW I think that the requirement in pg_start_backup shouldn't be relaxed
> without some more thought/work.
Yeah, I was talking to Bruce about that this AM, and it seems like a
feature we *need* to have ... for 9.1.
I'm sufficiently concerned about the amount of flux HS/SR is in right
now that
Heikki Linnakangas writes:
> Well, it would be nice to allow using pg_start_backup() on the primary
> when streaming replication is enabled, even if archiving isn't.
> Otherwise the only way to get the base backup for the standby is to shut
> down primary first, or use filesystem snapshot etc.
I
Robert Haas wrote:
> but
> what do you mean by "except with filesystem-level snapshot
> capabilities"?
If you have a filesystem that supports atomic snapshots, you can take a
snapshot of the filesystem the data directory resides on, and then copy
the data directory from the snapshot at your leisur
On Wed, 2010-04-28 at 12:44 -0400, Robert Haas wrote:
> On Wed, Apr 28, 2010 at 11:25 AM, Heikki Linnakangas
> wrote:
> > Robert Haas wrote:
> >> At least as I understand it, even when not using
> >> archive_mode, streaming replication, or hot standby, it's still
> >> perfectly legal to use pg_sta
On Wed, Apr 28, 2010 at 11:25 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> At least as I understand it, even when not using
>> archive_mode, streaming replication, or hot standby, it's still
>> perfectly legal to use pg_start_backup() to take a hot backup.
>
> Nope. The correct procedure
On Wed, Apr 28, 2010 at 12:07 PM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> On Wed, Apr 28, 2010 at 11:20 AM, Tom Lane wrote:
>>> Robert Haas writes:
I don't believe you are fairly stating the consensus from previous
discussion and I believe that you are actually in the minorit
Robert Haas writes:
> Actually, that's a good idea. But how will you handle tables?
Well, tables are a special case, mainly because it's not clear how to
avoid accidentally throwing away data. (In particular if some column in
the existing table isn't there in the new definition. It's a bit sca
Hannu Krosing wrote:
> On Tue, 2010-04-27 at 17:28 +0200, Csaba Nagy wrote:
>> One use case we would have is to dump only the changes from the
>> last backup of a single table. This table takes 30% of the DB
>> disk space, it is in the order of ~400GB, and it's only inserted,
>> never updated, t
On Wed, 2010-04-28 at 11:10 -0400, Robert Haas wrote:
> >
> > IIRC it was you that suggested changing the names of things if the
> > behaviour changes.
>
> Absolutely, but I'm arguing that we shouldn't change the behavior in
> the first place. At least as I understand it...
I feel like you're ju
Robert Haas wrote:
On Wed, Apr 28, 2010 at 11:20 AM, Tom Lane wrote:
Robert Haas writes:
I don't believe you are fairly stating the consensus from previous
discussion and I believe that you are actually in the minority on this
one. I agree that we probably don't need to support thi
Ok, I've finally committed the patch, using wal_level as the name of the
GUC.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Browsing the history of XLOG_PAGE_MAGIC, it used to be incremented by
>> one whenever the format changes, at least as long as it has been been in
>> xlog_internal.h. It started at 0xD05B in 2005, and was incremented by
>> one by each commit till 0xD0
Robert Haas wrote:
> On Wed, Apr 28, 2010 at 11:20 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> I don't believe you are fairly stating the consensus from previous
>>> discussion and I believe that you are actually in the minority on this
>>> one. I agree that we probably don't need to support
On Wed, Apr 28, 2010 at 11:20 AM, Tom Lane wrote:
> Robert Haas writes:
>> I don't believe you are fairly stating the consensus from previous
>> discussion and I believe that you are actually in the minority on this
>> one. I agree that we probably don't need to support this for object
>> types
On Tue, 2010-04-27 at 17:28 +0200, Csaba Nagy wrote:
> Hi all,
>
> On Tue, 2010-04-27 at 11:07 -0400, Merlin Moncure wrote:
> > The block level case seems pretty much covered by the hot standby feature.
>
> One use case we would have is to dump only the changes from the last
> backup of a single
On Tue, 2010-04-27 at 10:32 -0400, Michael Tharp wrote:
> On 04/27/2010 09:59 AM, Kevin Grittner wrote:
> > Under what circumstances would PostgreSQL
> > modify a file without changing the "last modified" timestamp or the
> > file size?
>
> Do all OSes have sub-second precision mtimes? Because oth
On Tue, 2010-04-27 at 12:14 -0400, Merlin Moncure wrote:
> On Tue, Apr 27, 2010 at 11:13 AM, Kevin Grittner
> wrote:
> > Merlin Moncure wrote:
> >
> >> The proposal only seems a win to me if a fair percentage of the
> >> larger files don't change, which strikes me as a relatively low
> >> level c
Hannu Krosing wrote:
> I see the main value when doing pg_dump based backups
Ah, now that makes more sense.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, 2010-04-27 at 08:59 -0500, Kevin Grittner wrote:
> Simon Riggs wrote:
>
> > Thinking about allowing a backup to tell which files have changed
> > in the database since last backup. This would allow an external
> > utility to copy away only changed files.
> >
> > Now there's a few ways o
On Tue, 2010-04-27 at 14:30 +0100, Simon Riggs wrote:
> Thinking about allowing a backup to tell which files have changed in the
> database since last backup. This would allow an external utility to copy
> away only changed files.
>
> Now there's a few ways of doing this and many will say this is
Heikki Linnakangas writes:
> Which is unfortunate, really. I wish we had a mode where the server
> simply refrained from removing/recycling WAL segments while the backup
> is running. You could then just:
> 1. pg_start_backup()
> 2. tar the data directory, except for pg_xlog
> 3. tar pg_xlog
> 4.
Tom Lane wrote:
> Robert Haas writes:
>> I don't believe you are fairly stating the consensus from previous
>> discussion and I believe that you are actually in the minority on this
>> one. I agree that we probably don't need to support this for object
>> types for which CREATE OR REPLACE is avai
Robert Haas wrote:
> At least as I understand it, even when not using
> archive_mode, streaming replication, or hot standby, it's still
> perfectly legal to use pg_start_backup() to take a hot backup.
Nope. The correct procedure to take a hot backup is described in
http://www.postgresql.org/docs/8
Robert Haas writes:
> I don't believe you are fairly stating the consensus from previous
> discussion and I believe that you are actually in the minority on this
> one. I agree that we probably don't need to support this for object
> types for which CREATE OR REPLACE is available or can be made
>
On Wed, Apr 28, 2010 at 9:58 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Takahiro Itagaki wrote:
>>> But before developing, we need to decide how to handle an added object
>>> that has the same name but has different definitions.
>
>> The OP explicitly stated that in his opinion nothing shoul
Heikki Linnakangas writes:
> Tom Lane wrote:
>> The correct way to reflect a change in WAL contents is to
>> bump the WAL page magic number.
> Browsing the history of XLOG_PAGE_MAGIC, it used to be incremented by
> one whenever the format changes, at least as long as it has been been in
> xlog_in
On Wed, Apr 28, 2010 at 7:22 AM, Simon Riggs wrote:
> On Wed, 2010-04-28 at 06:56 -0400, Robert Haas wrote:
>> On Wed, Apr 28, 2010 at 6:52 AM, Simon Riggs wrote:
>> > On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote:
>> >> On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
>> >> wrote:
>>
Tom Lane wrote:
> The correct way to reflect a change in WAL contents is to
> bump the WAL page magic number.
Browsing the history of XLOG_PAGE_MAGIC, it used to be incremented by
one whenever the format changes, at least as long as it has been been in
xlog_internal.h. It started at 0xD05B in 2005
On Wed, 2010-04-28 at 10:19 -0400, Tom Lane wrote:
> I'm a bit suspicious of going in this direction, mainly because
> DateStyle has been such a PITA over the years.
LOL. Man that's a pain. That's an unfair brush though!
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers
"Kevin Grittner" writes:
> Tom Lane wrote:
>> none of the other half are printing messages that are more useful
>> than "out of shared memory" (which isn't even necessarily
>> correct).
> I think the messages in the locking area are a bit more useful than
> "out of shared memory", but it would
Hackers,
I'm interested in tackling some of the todo items in XML category. Being
new to postgres hacking I'm hoping I chose an item that isn't more than
I can chew in the first sitting. One item that has caught my eye that I
(naively) hope isn't a huge todo is:
xpath_exists() is needed. It
Simon Riggs writes:
> On Wed, 2010-04-28 at 10:43 +0300, Heikki Linnakangas wrote:
>> * renamed wal_mode to wal_level
> I'm wondering whether this should be a list rather than an enum? If we
> add something in the future that adds more info to WAL but doesn't fit
> the one-dimensional model this
On Tue, Apr 27, 2010 at 08:18:13PM -0400, Robert Haas wrote:
> On Tue, Apr 27, 2010 at 6:45 PM, Kjell Rune Skaaraas
> wrote:
[snip]
> > I saw some indications that this might be a minority opinion, well I would
> > like to cast a vote FOR this functionality. The workarounds are ugly, the
> > so
Tom Lane wrote:
> none of the other half are printing messages that are more useful
> than "out of shared memory" (which isn't even necessarily
> correct).
I think the messages in the locking area are a bit more useful than
"out of shared memory", but it would be trivial to build the
equivalen
Andrew Dunstan writes:
> Takahiro Itagaki wrote:
>> But before developing, we need to decide how to handle an added object
>> that has the same name but has different definitions.
> The OP explicitly stated that in his opinion nothing should be done in
> such cases. That's a defensible position
Heikki Linnakangas writes:
> At commit, should I bump catversion, or PG_CONTROL_VERSION, or both? The
> patch replaces the unlogged-operation WAL record with a record
> containing current parameter values, and it changes pg_control. I'm
> guessing both.
You *must* bump PG_CONTROL_VERSION because
On Wed, Apr 28, 2010 at 14:43, Fujii Masao wrote:
> Hi,
>
> We seem to have forgotten to give conn->replication "[0]".
Oops.
Applied, thanks.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On Tue, 2010-04-27 at 20:13 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Tue, 2010-04-27 at 18:08 -0400, Tom Lane wrote:
> >> Huh? How is a filter as coarse as an oldest-running-XID filter going
> >> to prevent that? And aren't we initializing from trustworthy data in
> >> ProcArrayApplyR
Hi,
We seem to have forgotten to give conn->replication "[0]".
diff --git a/src/interfaces/libpq/fe-protocol3.c
b/src/interfaces/libpq/fe-protocol3.c
index 77cee8a..1956f00 100644
--- a/src/interfaces/libpq/fe-protocol3.c
+++ b/src/interfaces/libpq/fe-protocol3.c
@@ -1909,7 +1909,7 @@ build_start
Takahiro Itagaki wrote:
Kjell Rune Skaaraas wrote:
I've been reading the earlier threads at:
http://archives.postgresql.org/pgsql-hackers/2009-05/thrd7.php#00252
http://archives.postgresql.org/pgsql-hackers/2005-10/thrd4.php#00632
and I'm not sure I have anything that substantially new to
On Wed, Apr 28, 2010 at 8:28 PM, Heikki Linnakangas
wrote:
> Or maybe we should check in pg_start_backup() that either archive_mode
> or streaming replication (max_wal_senders > 0) is enabled.
I agree that pg_start_backup checks not only wal_level but also that.
Regards,
--
Fujii Masao
NIPPON
Robert Haas wrote:
> On Wed, Apr 28, 2010 at 6:52 AM, Simon Riggs wrote:
>> On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote:
>>> On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
>>> wrote:
This doesn't contain any changes to pg_start_backup() yet, that's a
separate issue and sti
On Wed, 2010-04-28 at 06:56 -0400, Robert Haas wrote:
> On Wed, Apr 28, 2010 at 6:52 AM, Simon Riggs wrote:
> > On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote:
> >> On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
> >> wrote:
> >> > This doesn't contain any changes to pg_start_backup() y
On Wed, Apr 28, 2010 at 6:52 AM, Simon Riggs wrote:
> On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote:
>> On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
>> wrote:
>> > This doesn't contain any changes to pg_start_backup() yet, that's a
>> > separate issue and still under discussion.
>>
On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote:
> On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
> wrote:
> > This doesn't contain any changes to pg_start_backup() yet, that's a
> > separate issue and still under discussion.
>
> I'm thinking of changing pg_start_backup and pg_stop_back
On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
wrote:
> This doesn't contain any changes to pg_start_backup() yet, that's a
> separate issue and still under discussion.
I'm thinking of changing pg_start_backup and pg_stop_backup so that
they just check that wal_level >= 'archive', and changi
Fujii Masao wrote:
> On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
> wrote:
>> Ok, did that. Here's an updated patch:
>
>> +During recovery, specifies whether or not you can connect and run
>> +queries to enable . The default value is
>> +on.
>> +This paramet
On Wed, 2010-04-28 at 18:54 +0900, Fujii Masao wrote:
> On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
> wrote:
> > Ok, did that. Here's an updated patch:
>
> > +During recovery, specifies whether or not you can connect and run
> > +queries to enable . The default value
> >
On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
wrote:
> Ok, did that. Here's an updated patch:
> +During recovery, specifies whether or not you can connect and run
> +queries to enable . The default value is
> +on.
> +This parameter can only be set at server s
On Wed, 2010-04-28 at 11:27 +0300, Heikki Linnakangas wrote:
> It's hard to picture what the future options might be like. Someone
> had
> an idea years ago (you even?) to add more information like table names
> or primary keys to the WAL records, to make it easier to scrape
> information from the
Simon Riggs wrote:
> On Wed, 2010-04-28 at 10:43 +0300, Heikki Linnakangas wrote:
>
>> * renamed wal_mode to wal_level
>
> I'm wondering whether this should be a list rather than an enum? If we
> add something in the future that adds more info to WAL but doesn't fit
> the one-dimensional model th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28/04/2010 02:20, Robert Haas wrote:
> On Tue, Apr 27, 2010 at 7:45 PM, Jehan-Guillaume (ioguix) de Rorthais
> wrote:
>> I thought Michael was trying to write a tokenizer based on node tree
>> returned by raw_parser. As it seems Michael is not even
On Wed, 2010-04-28 at 10:43 +0300, Heikki Linnakangas wrote:
> * renamed wal_mode to wal_level
I'm wondering whether this should be a list rather than an enum? If we
add something in the future that adds more info to WAL but doesn't fit
the one-dimensional model this implements then we could be i
Tom Lane wrote:
> The functions ShmemInitStruct and ShmemInitHash will return NULL on
> certain failure conditions, apparently on the grounds that their caller
> can print a more useful error message than they can. A quick survey
> shows that about half the callers aren't remembering to check for
Tom Lane wrote:
> Alvaro Herrera writes:
>> Hmm, AFAICS the problem with controldata is that it uses postgres_fe.h
>> instead of postgres.h. It's a bit of a stretch to use the latter, but
>> maybe that's a better solution? After all, it *is* poking into the
>> backend internals.
>
> I seem to r
86 matches
Mail list logo
