Neil Conway <[EMAIL PROTECTED]> writes:
> On Tue, 2006-10-31 at 01:07 +, Simon Riggs wrote:
>> As requested.
> Applied, thanks for the patch.
This patch converted a correct statement into a lie: there is not
anything that will cause begin/commit in a script file to fail just
because you wrapp
On Tue, 2006-10-31 at 01:07 +, Simon Riggs wrote:
> As requested.
Applied, thanks for the patch.
I didn't apply the ON_ERROR_STOP addition: IMHO it's not very useful to
say that doing something is "advised" without explaining why it is
wise/useful/necessary. If we want to include this point,
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> That was understood; in the above example I agree you need to flush. If
> you don't pass a truncation point, you don't need to flush whether or
> not you actually truncate. So we don't need to flush *every* time,
OK, but does that actually do much of any
On Mon, 2006-10-30 at 19:28 -0500, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > On Mon, 2006-10-30 at 22:56 +, Simon Riggs wrote:
> >> The man pages for VACUUM, CREATE TABLESPACE, CLUSTER and
> >> REINDEX DATABASE don't mention they are not allowed inside a transaction
> >> blo
On Mon, 2006-10-30 at 19:18 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > I don't agree: If the truncation points are at 1 million, 2 million etc,
> > then if we advance the relvacuumxid from 1.2 million to 1.5 million,
> > then crash, the hints bits for that last vacuum ar
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2006-10-30 at 22:56 +, Simon Riggs wrote:
>> The man pages for VACUUM, CREATE TABLESPACE, CLUSTER and
>> REINDEX DATABASE don't mention they are not allowed inside a transaction
>> block at all
> That should be fixed, I think. Once that is done
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> I don't agree: If the truncation points are at 1 million, 2 million etc,
> then if we advance the relvacuumxid from 1.2 million to 1.5 million,
> then crash, the hints bits for that last vacuum are lost. Sounds bad,
> but we have not truncated clog, so th
On Mon, 2006-10-30 at 22:56 +, Simon Riggs wrote:
> The man pages for VACUUM, CREATE TABLESPACE, CLUSTER and
> REINDEX DATABASE don't mention they are not allowed inside a transaction
> block at all
That should be fixed, I think. Once that is done, I think it's
sufficient to just say that --si
On Mon, 2006-10-30 at 16:58 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > ISTM we only need to flush iff the clog would be truncated when we
> > update relminxid.
>
> Wrong :-( If the relvacuumxid change (not relminxid ... as I said, these
> names aren't very transparent)
On Mon, 2006-10-30 at 17:32 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Clarification of when it's not appropriate to use this option.
>
> I think it's a fairly bad idea to try to enumerate the commands that
> can't be used in a transaction block here, because there is n
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Clarification of when it's not appropriate to use this option.
I think it's a fairly bad idea to try to enumerate the commands that
can't be used in a transaction block here, because there is no way
that we will remember to keep such a list up-to-date.
Clarification of when it's not appropriate to use this option.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Index: doc/src/sgml/ref/psql-ref.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/p
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> In fact I don't understand what's the point about multiple databases vs.
> a single database. Surely a checkpoint would flush all buffers in all
> databases, no?
Yeah --- all the ones that are dirty *now*. Consider the case where you
vacuum DB X, upda
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> ISTM we only need to flush iff the clog would be truncated when we
> update relminxid.
Wrong :-( If the relvacuumxid change (not relminxid ... as I said, these
names aren't very transparent) makes it to disk but not all the hint
bits do, you're at risk.
Simon Riggs wrote:
> On Mon, 2006-10-30 at 12:05 -0500, Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > Ugh. Is there another solution to this? Say, sync the buffer so that
> > > the hint bits are written to disk?
> >
> > Yeah. The original design for all this is explained
On Mon, 2006-10-30 at 12:05 -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Ugh. Is there another solution to this? Say, sync the buffer so that
> > the hint bits are written to disk?
>
> Yeah. The original design for all this is explained by the notes for
> TruncateCLOG
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Ugh. Is there another solution to this? Say, sync the buffer so that
> the hint bits are written to disk?
Yeah. The original design for all this is explained by the notes for
TruncateCLOG:
* When this is called, we know that the database logically
Heikki Linnakangas wrote:
> We just discussed this in detail with Simon, and it looks like we have
> 5 (!) different but related problems:
Wow, four of them are mine :-(
> 2) vactuple_get_minxid doesn't take into account xmax's of tuples that
> have HEAP_XMAX_INVALID set. That's a problem:
>
>
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I think it's premature to start writing
patches until we've decided how this really needs to work.
Not logging hint-bit updates seems safe to me. As long as we have the
clog, the hint-bit is just a hint. The pro
We just discussed this in detail with Simon, and it looks like we have
5 (!) different but related problems:
1) The original problem of freeze then crash, leaving too high values in
relminxid and datminxid. If you then run vacuum, it might truncate CLOG
and you lose the commit status of the re
20 matches
Mail list logo
