On Sun, Nov 23, 2008 at 3:12 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
>
>
> I don't think so, because this section of code is only called if there
> is redo to perform. If no redo, we never get here.
>
>
OK. But why not open up the database for read-only access when there is no
redo action to
Following test case gives a warning of snapshot not destroyed at commit
time.
CREATE TABLE test (a int);
INSERT INTO test VALUES (1);
BEGIN;
DECLARE c CURSOR FOR SELECT * FROM test FOR update;
SAVEPOINT A;
FETCH -2 FROM c;
ROLLBACK TO SAVEPOINT A;
COMMIT;
Should we call FreeQueryDesc() even for f
Tom Lane wrote:
Reflecting on it though, maybe Heikki described the behavior too
pessimistically anyway. If a page contains no dead tuples, it should
get its bits set on first visit anyhow, no? So for the ordinary bulk
load scenario where there are no failed insertions, the first vacuum
pass sh
Hi Jaime-san.
Thank you for a review.
I think this purpose to return the value which should originally obtain strftime
by only replacing here. Then, I think that it is a superfluous reaction.
However, some consideration may be necessities.
Regards,
Hiroshi Saito
- Original Message -
On Sun, Nov 16, 2008 at 8:36 AM, Hiroshi Saito <[EMAIL PROTECTED]> wrote:
> Hi.
>
> Then, It continues and a review is desired. Thanks!
>
In http://msdn.microsoft.com/en-us/library/fe06s4ak(VS.71).aspx says:
"""
Return Value
strftime returns the number of characters placed in strDest and
wcsftime
Tom Lane wrote:
However, my comment above was too optimistic, because in an insert-only
scenario autovac would in fact not trigger VACUUM at all, only ANALYZE.
So it seems like we do indeed want to rejigger autovac's rules a bit
to account for the possibility of wanting to apply vacuum to get
vi
Jeff Davis <[EMAIL PROTECTED]> writes:
> On Sun, 2008-11-23 at 14:05 -0500, Tom Lane wrote:
>> A possible problem is that if a relation is filled all in one shot,
>> autovacuum would trigger a single vacuum cycle on it and then never have
>> a reason to trigger another; leading to the bits never ge
Tom Lane wrote:
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <[EMAIL PROTECTED]> writes:
Is $SUBJECT possible? If not, do you think it would be worth
implementing this?
No, and no. The feature isn't even in core; it can hardly qualify as
something that should drive a massive overhaul of the e
On Sun, 2008-11-23 at 14:05 -0500, Tom Lane wrote:
> A possible problem is that if a relation is filled all in one shot,
> autovacuum would trigger a single vacuum cycle on it and then never have
> a reason to trigger another; leading to the bits never getting set (or
> at least not till an antiwra
On Sun, Nov 23, 2008 at 11:49:31AM -0800, David Fetter wrote:
> On Sun, Nov 23, 2008 at 12:34:21AM -0300, Alvaro Herrera wrote:
> > Gregory Stark wrote:
> >
> > > WITH RECURSIVE Z(IX, IY, CX, CY, X, Y, I) AS (
> > > [elided]
> >
> > FWIW you can halve the running time by restricting I to 27 inste
On Sun, Nov 23, 2008 at 12:34:21AM -0300, Alvaro Herrera wrote:
> Gregory Stark wrote:
>
> > WITH RECURSIVE Z(IX, IY, CX, CY, X, Y, I) AS (
> > [elided]
>
> FWIW you can halve the running time by restricting I to 27 instead of
> 100 in the recursive term, and obtain the same result.
I found it e
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <[EMAIL PROTECTED]> writes:
> Is $SUBJECT possible? If not, do you think it would be worth
> implementing this?
No, and no. The feature isn't even in core; it can hardly qualify as
something that should drive a massive overhaul of the elog
infrastructure. Which
On Fri, 2008-11-21 at 14:17 +0530, Pavan Deolasee wrote:
> I wonder if there is corner case
I remain on the lookout for these, so thanks for thinking of this.
> below where there are no WAL records to replay during standby
> recovery. Specifically, that may cause IsRunningXactDataValid() to
>
Hi,
Is $SUBJECT possible? If not, do you think it would be worth
implementing this?
If this parameter is not used appropriately, it may fill up logs --
that's why I am asking this question.
Regards,
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I committed the changes to FSM truncation yesterday, that helps with the
> truncation of the visibility map as well. Attached is an updated
> visibility map patch.
I looked over this patch a bit ...
> 1. The bits in the visibility map are set in
I wrote:
> The thing I'm complaining about is having dropped the intermediate
> struct that represents the fully decoded set of reloptions.
After looking at the patch a bit more I have a couple of other comments:
* I disagree with changing the argument of the RelationGetXXX
macros from Relation t
16 matches
Mail list logo
