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 add but:
>
> I saw so
Simon Riggs wrote:
> Is this route worthwhile? Or in some way unacceptable?
>From an admin perspective, I think block-level differentials would be a
lot more useful, especially if index storage could be safely excluded.
IMO Pg really could use an "index bad or missing, rebuild on postmaster
star
On Wed, Apr 28, 2010 at 4:12 AM, Heikki Linnakangas
wrote:
> Simon Riggs wrote:
>> On Tue, 2010-04-27 at 20:14 +0300, Heikki Linnakangas wrote:
>>> Simon Riggs wrote:
On Tue, 2010-04-27 at 18:13 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
>> If pg_stop_backup() is run it cre
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 NULL,
and none of the ot
On Sun, Apr 25, 2010 at 9:07 PM, Robert Haas wrote:
> 4. We could add an additional 32-bit value to RelFileNode to identify
> the backend (or a sentinel value when not temp) and create a separate
> structure XLogRelFileNode or PermRelFileNode or somesuch for use in
> contexts where no temp rels ar
Josh Berkus writes:
> It appears that something broke the ability to refer to columns by full
> SQL path names in 9.0. That is, references to columns as
> schema.table.col will produce a completely bogus error which did not
> exist on previous versions.
My fault :-(. Seems we have no regression
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
>> ProcArrayApplyRecoveryInfo, anyway?
>>
>> I still say it's useless.
> Quit
Alvaro Herrera writes:
> I just noticed that the road.thepath column in the regression database
> is no longer in pg_stats for some reason after ANALYZE, so the example
> in section 14.2 in the docs (Statistics Used by the Planner) is now
> wrong.
It's an old example :-( ... a quick check shows n
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 sure about what
> he's trying to do, I prefer refocus a bit this thread
[...]
> Having dropp
On Tue, Apr 27, 2010 at 6:45 PM, Kjell Rune Skaaraas wrote:
> Hello,
>
> 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 s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 25/04/2010 03:02, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Apr 24, 2010 at 8:07 PM, Bruce Momjian wrote:
>>> Sounds useful to me, though as a function like suggested in a later
>>> email.
>
>> If tool-builders think this is useful, I have
Hi,
I just noticed that the road.thepath column in the regression database
is no longer in pg_stats for some reason after ANALYZE, so the example
in section 14.2 in the docs (Statistics Used by the Planner) is now
wrong.
What I'm trying to do is replace that exceedingly wide output with
something
Tom Lane escribió:
> 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 se
On Tue, 2010-04-27 at 18:08 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Tue, 2010-04-27 at 17:24 -0400, Tom Lane wrote:
> >> I think we should just lose that test, as well as the variable.
>
> > Yes, though it looks like it is still necessary in creating a valid
> > initial state because
Hello,
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 add but:
1. I can't see there's an unambiguity abou
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 recall that Solaris had pro
Hackers,
It appears that something broke the ability to refer to columns by full
SQL path names in 9.0. That is, references to columns as
schema.table.col will produce a completely bogus error which did not
exist on previous versions.
The following works perfectly well in 8.4:
postgres=# create
Simon Riggs writes:
> On Tue, 2010-04-27 at 17:24 -0400, Tom Lane wrote:
>> I think we should just lose that test, as well as the variable.
> Yes, though it looks like it is still necessary in creating a valid
> initial state because otherwise we may have xids in KnownAssigned array
> that are al
On Tue, 2010-04-27 at 17:24 -0400, Tom Lane wrote:
> Isn't the snapshotOldestActiveXid filter in
> RecordKnownAssignedTransactionIds completely wrong/useless/bogus?
>
> AFAICS, snapshotOldestActiveXid is only set once at the start of
> recovery. This means it will soon be too old to provide any
Isn't the snapshotOldestActiveXid filter in
RecordKnownAssignedTransactionIds completely wrong/useless/bogus?
AFAICS, snapshotOldestActiveXid is only set once at the start of
recovery. This means it will soon be too old to provide any useful
filtering. But what's far worse is that the XID space
On Tue, 2010-04-27 at 16:18 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Tue, 2010-04-27 at 13:52 -0400, Tom Lane wrote:
> >> WTF? Either the comment is wrong or this should not be an elog
> >> condition.
>
> > That section of code has been rewritten many times. I think it is now
> > inac
Simon Riggs writes:
> On Tue, 2010-04-27 at 13:52 -0400, Tom Lane wrote:
>> WTF? Either the comment is wrong or this should not be an elog
>> condition.
> That section of code has been rewritten many times. I think it is now
> inaccurate and should be removed. I left it there because the
> unfor
Takahiro Itagaki wrote:
> That's it! We should have added an additional alias to chklocale, too.
>
> Index: src/port/chklocale.c
> ===
> --- src/port/chklocale.c (HEAD)
> +++ src/port/chklocale.c (fixed)
> @@ -172,6 +172,7 @
On Tue, 2010-04-27 at 14:53 -0400, Tom Lane wrote:
> Hmm ... there's another point here, which is that the array size
> creates
> a hard maximum on the number of entries, whereas the hash table was a
> bit more forgiving. What is the proof that the array won't overflow?
> The fact that the equival
Heikki Linnakangas escribió:
> Tom Lane wrote:
> > How about putting the enum {} declaration in xlog.h, and making the
> > field in pg_control.h just be declared "int"?
>
> I tried that at first, but the problem was with pg_controldata.c. In
> bin/. I wanted it to print wal_mode in human-readable
Simon Riggs wrote:
> On Tue, 2010-04-27 at 20:14 +0300, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>>> On Tue, 2010-04-27 at 18:13 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
> If pg_stop_backup() is run it creates the .backup file in the archive.
> In the absence of that
Tom Lane wrote:
> How about putting the enum {} declaration in xlog.h, and making the
> field in pg_control.h just be declared "int"?
I tried that at first, but the problem was with pg_controldata.c. In
bin/. I wanted it to print wal_mode in human-readable format, so it
needed the values of the en
Hmm ... there's another point here, which is that the array size creates
a hard maximum on the number of entries, whereas the hash table was a
bit more forgiving. What is the proof that the array won't overflow?
The fact that the equivalent data structure on the master can't hold
more than this ma
On Tue, Apr 27, 2010 at 10:08 AM, Simon Riggs wrote:
> On Tue, 2010-04-27 at 08:59 -0500, Kevin Grittner wrote:
>> > An explicit mechanism where Postgres could authoritatively say
>> > which files have changed would make many feel safer, especially
>> > when other databases also do this.
>>
>> Why
Heikki Linnakangas writes:
> Tom Lane wrote:
>> I haven't read this in any detail, but why does it add inclusion of
>> pg_control.h to xlog.h? I don't see any reason for that in the actual
>> changes in xlog.h.
> I put the enum for wal_mode to pg_control.h, so that it's available to
> pg_control
On Tue, 2010-04-27 at 20:14 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Tue, 2010-04-27 at 18:13 +0300, Heikki Linnakangas wrote:
> >> Simon Riggs wrote:
> >>> If pg_stop_backup() is run it creates the .backup file in the archive.
> >>> In the absence of that file, we should be abl
On Tue, 2010-04-27 at 13:52 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > v3 attached
>
> This patch changes KnownAssignedXidsRemove() so that failure to find
> the target XID is elog(ERROR) (ie, a PANIC, since this is in the
> startup process).
Not in all cases. The code is correct, as far
Simon Riggs writes:
> v3 attached
This patch changes KnownAssignedXidsRemove() so that failure to find
the target XID is elog(ERROR) (ie, a PANIC, since this is in the
startup process). However, this comment is still there:
/*
* We can fail to find an xid if the xid came from a
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Ok, here's a patch that includes the changes to add new wal_mode GUC
>> (http://archives.postgresql.org/message-id/4bd581a6.60...@enterprisedb.com),
>
> I haven't read this in any detail, but why does it add inclusion of
> pg_control.h to xlog.h? I
Simon Riggs wrote:
> On Tue, 2010-04-27 at 18:13 +0300, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>>> If pg_stop_backup() is run it creates the .backup file in the archive.
>>> In the absence of that file, we should be able to work out that
>>> pg_stop_backup() was not run.
>> It's just as l
Merlin Moncure wrote:
> Your archiving requirements are high.
They are set by a Steering Committee composed of the Directory of
State Courts and various District Court Administrators, Judges,
Clerks of Court, and Registers in Probate who rely on this data and
*really* want to be safe. I just
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 case to optimize for.
>
> That's certainly a situation we face, with a r
On Tue, 2010-04-27 at 18:13 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > If pg_stop_backup() is run it creates the .backup file in the archive.
> > In the absence of that file, we should be able to work out that
> > pg_stop_backup() was not run.
>
> It's just as likely that the file
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 table. This table takes 30% of the DB disk space, it
is in the orde
Heikki Linnakangas writes:
> Ok, here's a patch that includes the changes to add new wal_mode GUC
> (http://archives.postgresql.org/message-id/4bd581a6.60...@enterprisedb.com),
I haven't read this in any detail, but why does it add inclusion of
pg_control.h to xlog.h? I don't see any reason for
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Isn't the above statement complete nonsense? There's nothing to stop
>> the DBA from issuing pg_stop_backup() after he restarts the master.
> pg_stop_backup() can't be called if there's no backup in progress.
> Restart cancels it.
Doh, right (not
Simon Riggs wrote:
> If pg_stop_backup() is run it creates the .backup file in the archive.
> In the absence of that file, we should be able to work out that
> pg_stop_backup() was not run.
It's just as likely that the file is there even though the backup didn't
finish, though.
--
Heikki Linn
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 case to optimize for.
That's certainly a situation we face, with a relatively slow WAN in
the middle.
http://archives.postgresql.o
On Tue, Apr 27, 2010 at 10:32 AM, 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 othe
Robert Haas wrote:
> On Tue, Apr 27, 2010 at 5:25 AM, Heikki Linnakangas
> wrote:
>> Yep. I've committed a patch to do that.
>
> Is there no way for the slave to recover from this situation?
No, it will never open up for hot standby, and it will error at the end
of recovery anyway. This just mak
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Hmm, we could throw an error in the standby, when we see a shutdown
>> checkpoint while we're waiting for an end-backup record. If the database
>> was shut down before pg_stop_backup(), we know that the backup was
>> cancelled and the end-backup reco
On Apr 27, 2010, at 9:20 AM, Simon Riggs wrote:
> On Tue, 2010-04-27 at 15:10 +0200, Dimitri Fontaine wrote:
>> Robert Haas writes:
>>> Treating the string "true" as a special case seems like a kludge to
>>> me. Maybe a robust set of internal commands wouldn't be a kludge,
>>> but
>>> that's not
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 otherwise I could
see a scenario such at this:
* File is modified
* Bac
On Apr 27, 2010, at 16:08 , Simon Riggs wrote:
> On Tue, 2010-04-27 at 08:59 -0500, Kevin Grittner wrote:
>> Why? I must be missing something, because my feeling is that if you
>> can't trust your OS to cover something like this, how can you trust
>> any application *running* under that OS to do i
On Apr 27, 2010, at 15:50 , Alvaro Herrera 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 of doing this and
On Tue, 2010-04-27 at 08:59 -0500, Kevin Grittner wrote:
> > An explicit mechanism where Postgres could authoritatively say
> > which files have changed would make many feel safer, especially
> > when other databases also do this.
>
> Why? I must be missing something, because my feeling is that
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
> already possible using file ac
On Tue, 2010-04-27 at 09:50 -0400, Alvaro Herrera 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
Heikki Linnakangas writes:
> Hmm, we could throw an error in the standby, when we see a shutdown
> checkpoint while we're waiting for an end-backup record. If the database
> was shut down before pg_stop_backup(), we know that the backup was
> cancelled and the end-backup record we're waiting for w
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 already
> possible using file ac
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 already
possible using file access times.
An explicit mechanis
On Tue, 2010-04-27 at 15:10 +0200, Dimitri Fontaine wrote:
> Robert Haas writes:
> > Treating the string "true" as a special case seems like a kludge to
> > me. Maybe a robust set of internal commands wouldn't be a kludge, but
> > that's not what's being proposed here. I guess it's just a matter
Robert Haas writes:
> Treating the string "true" as a special case seems like a kludge to
> me. Maybe a robust set of internal commands wouldn't be a kludge, but
> that's not what's being proposed here. I guess it's just a matter of
> opinion.
I don't see how to have internal commands without h
On Tue, 2010-04-27 at 12:25 +0300, Heikki Linnakangas wrote:
> Fujii Masao wrote:
> > On Tue, Apr 27, 2010 at 4:19 PM, Heikki Linnakangas
> > wrote:
> >> Hmm, we could throw an error in the standby, when we see a shutdown
> >> checkpoint while we're waiting for an end-backup record. If the databas
On Tue, Apr 27, 2010 at 7:24 AM, Fujii Masao wrote:
> On Tue, Apr 27, 2010 at 7:50 PM, Heikki Linnakangas
> wrote:
>>> It's OK in pg_start_backup(), but seems NG in pg_stop_backup() since
>>> it waits until some WAL files have been archived by the archiver. No?
>>
>> Good point, that logic would
Bruce Momjian wrote:
I concur; it's about a month too late to propose this.
I am confused why it is late. We add to /contrib even during beta, and
I didn't bring it up earlier because I didn't want to be pushing my own
software. Was someone else supposed to suggest it a month ago?
On Tue, Apr 27, 2010 at 8:07 PM, Robert Haas wrote:
> On Tue, Apr 27, 2010 at 5:25 AM, Heikki Linnakangas
> wrote:
>> Yep. I've committed a patch to do that.
>
> Is there no way for the slave to recover from this situation?
Probably Yes. You would need to take a fresh base backup and
restart the
On Tue, Apr 27, 2010 at 7:50 PM, Heikki Linnakangas
wrote:
>> It's OK in pg_start_backup(), but seems NG in pg_stop_backup() since
>> it waits until some WAL files have been archived by the archiver. No?
>
> Good point, that logic would need to be changed too. Should it simply
> return immediately
Heikki Linnakangas wrote:
> > Should we add (or replace) CP949 for EUC-KR?
>
> No. CP949 is not plain EUC-KR, but EUC-KR with some extensions (UHC). At
> least on CVS HEAD, we recognize CP949 as an alias for the PostgreSQL
> PG_UHC encoding.
That's it! We should have added an additional alias
On Tue, Apr 27, 2010 at 4:07 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>>> On Mon, 2010-04-26 at 10:41 +0200, Dimitri Fontaine wrote:
Would it be possible to have "internal" commands there, as for example
cd is in my shell, or test, or time, or some more ?
That would a
On Tue, Apr 27, 2010 at 5:25 AM, Heikki Linnakangas
wrote:
> Yep. I've committed a patch to do that.
Is there no way for the slave to recover from this situation?
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
Takahiro Itagaki wrote:
> I heard pg_get_encoding_from_locale() failed in kor locale.
>
> WARNING: could not determine encoding for locale "kor": codeset is
> "CP949"
>
> I found the following description in the web:
> CP949 is EUC-KR, extended with UHC (Unified Hangul Code).
>
> h
Fujii Masao wrote:
> On Tue, Apr 27, 2010 at 6:49 PM, Heikki Linnakangas
> wrote:
>> Fujii Masao wrote:
if (!XLogArchivingActive())
ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("WAL archiving is not active"),
errhint("archive_mo
I heard pg_get_encoding_from_locale() failed in kor locale.
WARNING: could not determine encoding for locale "kor": codeset is "CP949"
I found the following description in the web:
CP949 is EUC-KR, extended with UHC (Unified Hangul Code).
http://www.opensource.apple.com/source/libic
On Tue, Apr 27, 2010 at 6:49 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> config.sgml
>>> on. It is thought that there is little
>>> measurable difference in performance from using this feature, so
>>> feedback is welcome if any production impacts are noticeable.
>>> It is likely that th
Fujii Masao wrote:
> config.sgml
>> on. It is thought that there is little
>> measurable difference in performance from using this feature, so
>> feedback is welcome if any production impacts are noticeable.
>> It is likely that this parameter will be removed in later releases.
>
> Is this descri
On Tue, Apr 27, 2010 at 5:09 PM, Heikki Linnakangas
wrote:
> Ok, here's a patch that includes the changes to add new wal_mode GUC
> (http://archives.postgresql.org/message-id/4bd581a6.60...@enterprisedb.com),
> and implements Tom's design to keep a copy of wal_mode and the
> max_connections, max_p
Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Apr 26, 2010 at 9:26 PM, Bruce Momjian wrote:
> >> There was talk of including pg_migrator in Postgres 9.0 in /contrib. ?Do
> >> we still want to do that?
>
> > I think you articulated some pretty good reasons previously for
> > keeping it separa
Fujii Masao wrote:
> On Tue, Apr 27, 2010 at 4:19 PM, Heikki Linnakangas
> wrote:
>> Hmm, we could throw an error in the standby, when we see a shutdown
>> checkpoint while we're waiting for an end-backup record. If the database
>> was shut down before pg_stop_backup(), we know that the backup was
Robert Haas writes:
>> On Mon, 2010-04-26 at 10:41 +0200, Dimitri Fontaine wrote:
>>> Would it be possible to have "internal" commands there, as for example
>>> cd is in my shell, or test, or time, or some more ?
>>>
>>> That would allow for providing a portable /usr/bin/true command as far
>>> as
On Tue, Apr 27, 2010 at 4:19 PM, Heikki Linnakangas
wrote:
> Hmm, we could throw an error in the standby, when we see a shutdown
> checkpoint while we're waiting for an end-backup record. If the database
> was shut down before pg_stop_backup(), we know that the backup was
> cancelled and the end-b
Heikki Linnakangas wrote:
> Robert Haas wrote:
>> On Fri, Apr 23, 2010 at 4:44 PM, Tom Lane wrote:
>>> Well, actually, now that I've looked at the patch I think it's starting
>>> from a fundamentally wrong position anyway. Checkpoint records are a
>>> completely wrong mechanism for transmitting t
Josh Berkus wrote:
> Here's a way to trap yourself:
>
> (1) Set up an HS/SR master
> (2) pg_start_backup on the master
> (3) clone the master to 1 or more slaves
> (4) Fast shutdown the master (without pg_stop_backup)
> (5) Restart the master
> (6) Bring up the slaves
>
> Result: the slaves will
78 matches
Mail list logo
