On Monday 22 December 2008 05:09:54 Jaime Casanova wrote:
> just out of curiosity, why TRUNCATE doesn't support ONLY?
It was probably just an omission.
Note that TRUNCATE currently does not act on inheriting tables. In other
words, the behavior is already like ONLY.
FWIW, the SQL standard says
Hi,
Some people want to disable xlog archiving only during synchronous
replication. So, first, I created and attached the self-contained patch
to control xlog archiving dynamically. Since it would still take time to
fix whole patch of synch rep, and opening it at a time would burden
reviewers, I o
On Sunday 21 December 2008 01:48:42 Alvaro Herrera wrote:
> ALTER TABLE foo SET (TOAST autovacuum_enabled = false);
> ALTER TABLE foo SET (toast.autovacuum_enabled = false);
> ALTER TABLE foo TOAST SET (autovacuum_enabled = false);
> ALTER TABLE foo SET TOAST (autovacuum_enabled = false);
The last
On Tue, Dec 23, 2008 at 9:12 PM, Heikki Linnakangas
wrote:
> As the patch stands, whenever XLOG segment is switched in XLogInsert, we
> wait for the segment to be sent to the standby server. That's not good.
> Particularly in asynchronous mode, you'd expect the standby to not have any
> significan
On Friday 19 December 2008 19:36:42 Simon Riggs wrote:
> Perhaps we should listen to the people that have said they don't want
> queries cancelled, even if the alternative is inconsistent answers. That
> is easily possible yet is not currently an option. Plus we have the
> option I referred to up t
On Saturday 20 December 2008 04:10:21 Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Sat, 2008-12-20 at 09:21 +0200, Heikki Linnakangas wrote:
> >> Gregory Stark wrote:
> >>> Simon Riggs writes:
> Increasing the waiting time increases the failover time and thus
> decreases the val
Tom Lane writes:
> The window functions patch is laboring under the delusion that it can
> call an aggregate's final function and then go back to invoking the
> transfn some more on the same data. This is merest fantasy :-(
>
> regression=# select array_agg(q1) over(order by q1) from int8_tbl;
>
The window functions patch is laboring under the delusion that it can
call an aggregate's final function and then go back to invoking the
transfn some more on the same data. This is merest fantasy :-(
regression=# select array_agg(q1) over(order by q1) from int8_tbl;
server closed the connection
Hi,
On Mon, Dec 22, 2008 at 1:29 PM, Fujii Masao wrote:
> Not so simple.
>
> At least the primary has to additionally maintain the byte position the
> standby
> has already fsynced. The main difference from the current patch is whether
> the standby fsyncs the logfile when it fills even if you d
Hi,
On Wed, Dec 24, 2008 at 2:37 AM, Simon Riggs wrote:
>
> On Wed, 2008-12-24 at 02:23 +0900, Fujii Masao wrote:
>
>> Oh, sorry. I don't want to scare you ;) But, yes, it's important. We should
>> rethink the question? "Why does the failed server always need a fresh
>> backup?" Though we discuss
Jeff Davis wrote:
On Tue, 2008-12-23 at 00:42 -0500, Emmanuel Cecchet wrote:
I still don't
get why people would use SERIALIZABLE since there is no efficient
implementation of it.
If they need true serializable transactions, and don't care about
efficiency.
Is there such people who
>>> Simon Riggs wrote:
> On Tue, 2008-12-23 at 10:10 -0600, Kevin Grittner wrote:
>
> I think the current docs make too much of a deal about how hard it is
to
> do predicate locking in databases. Most RDBMS use predicate locking
via
> indexes, ie the locking happens in the index. One might also
>>> "Robert Haas" wrote:
> For most users, the artifacts that have been
> introduced by these fine-grained locks are outweighed by the
> performance benefits of greater concurrency - but, as you point out,
> not necessarily always.
That's what I don't understand. I never did point that out.
On Tue, 2008-12-23 at 10:10 -0600, Kevin Grittner wrote:
> Well, I figured I should try to get a consensus here before submitting
> a patch. Last time I tried submitting a simple patch to remove the
> line about the PostgreSQL community not knowing about any other
> databases which use predicate
> The page locking provides this because every index page or data page
> the serializable transaction looks at is locked against updates until
> the end of the transaction. If it can see all the COLUMN=0 rows
> through an index, the index locks protect the transaction. If a table
> scan is requir
On Tue, 2008-12-23 at 17:42 +0200, Heikki Linnakangas wrote:
> As the patch stands, whenever XLOG segment is switched in XLogInsert, we
> wait for the segment to be sent to the standby server. That's not good.
> Particularly in asynchronous mode, you'd expect the standby to not have
> any sign
Emmanuel Cecchet wrote:
I just saw that this new patch was not considered because the previous
version ended being rejected.
Note that this version of the patch aims at supporting ONLY temp tables
that are created AND dropped in the same transaction. We need to be able
to use temp tables in tra
On Mon, 2008-12-22 at 21:24 +0200, Heikki Linnakangas wrote:
> Introduce new vacuum_freeze_max_age setting. Manual VACUUM will scan the
> whole table and advance relfrozenxid, if relfrozenxid is older than
> vacuum_freeze_max_age.
>
It's confusing to have two GUCs named vacuum_freeze_min_age an
On Tue, 2008-12-23 at 00:42 -0500, Emmanuel Cecchet wrote:
> I still don't
> get why people would use SERIALIZABLE since there is no efficient
> implementation of it.
If they need true serializable transactions, and don't care about
efficiency.
Regards,
Jeff Davis
--
Sent via pgsql-h
Hi,
Thanks for clarifying!
On Wed, Dec 24, 2008 at 2:53 AM, Simon Riggs wrote:
>
> On Tue, 2008-12-23 at 18:23 +0200, Heikki Linnakangas wrote:
>
>> I don't think we need or should
>> allow running regular queries before entering "replication mode". the
>> backend should become a walsender proce
On Tue, Dec 23, 2008 at 10:14:29AM -0500, Robert Haas wrote:
> > It's equivalent to our assumption that distributions of values in
> > columns in the same table are independent. Making that assumption in
> > this case would probably result in occasional dramatic speed
> > improvements similar to th
On Tue, 2008-12-23 at 08:48 -0500, Tom Lane wrote:
> I've always thought that it was extremely shaky for LOCK to try to work
> that way. With no lock, you have no confidence that the table isn't
> changing or disappearing under you. In the worst case, the permissions
> check might fail outright (
> > > Because there is no nice way in PostgreSQL (that I know of) to
derive
> > > a histogram after a join (on an intermediate result) currently
> > > usingMostCommonValues is only enabled on a join when the outer
(probe)
> > > side is a table scan (seq scan only actually). See
> > > getMostCommon
>>> Stephan Szabo wrote:
> On Tue, 23 Dec 2008, Kevin Grittner wrote:
>
>> The page locking provides this because every index page or data
page
>> the serializable transaction looks at is locked against updates
until
>> the end of the transaction. If it can see all the COLUMN=0 rows
>> through
On Tue, 2008-12-23 at 18:23 +0200, Heikki Linnakangas wrote:
> I don't think we need or should
> allow running regular queries before entering "replication mode". the
> backend should become a walsender process directly after authentication.
+1
> Standby -> primary
>
> RequestWAL
> P
Hi,
On Wed, Dec 24, 2008 at 1:48 AM, Simon Riggs wrote:
>
> On Tue, 2008-12-23 at 17:42 +0200, Heikki Linnakangas wrote:
>
>> As the patch stands, whenever XLOG segment is switched in XLogInsert, we
>> wait for the segment to be sent to the standby server. That's not good.
>> Particularly in asyn
On Wed, 2008-12-24 at 02:23 +0900, Fujii Masao wrote:
> Oh, sorry. I don't want to scare you ;) But, yes, it's important. We should
> rethink the question? "Why does the failed server always need a fresh
> backup?" Though we discussed it previously and concluded that it should
> be done next time
>>> Gregory Stark wrote:
> "Kevin Grittner" writes:
> Gregory Stark wrote:
>>> Afaict doing a few google searches Sybase doesn't do predicate
locking >
>>> either.
>>
>> The page locking provides this because every index page or data
page
>> the serializable transaction looks at is locke
Hi,
On Wed, Dec 24, 2008 at 12:38 AM, Simon Riggs wrote:
> Perhaps, but why do you say that?
Since you often pointed out that getting backup is not problem because
of incremental backup (e.g. rsync), I just thought so.
> I've not blocked you from adding
> anything useful to Postgres.
Yes, I se
On Tue, 23 Dec 2008, Kevin Grittner wrote:
> The page locking provides this because every index page or data page
> the serializable transaction looks at is locked against updates until
> the end of the transaction. If it can see all the COLUMN=0 rows
> through an index, the index locks protect
On Tue, 2008-12-23 at 18:23 +0200, Heikki Linnakangas wrote:
> (later) OldestXmin
> When a hot standby server is running read-only queries,
> indicates the
> current OldestXmin on the standby. The primary can refrain from
> vacuuming tuples still required by the slave using this value,
Simon Riggs wrote:
You scare me that you see failover as sufficiently frequent that you are
worried that being without one of the servers for an extra 60 seconds
during a failover is a problem. And then say you're not going to add the
feature after all. I really don't understand. If its important
Reading the spec it does seem our initial statement "The SQL standard defines
four levels of transaction isolation in terms of three phenomena that must be
prevented between concurrent transactions" is not accurate.
The spec defines the first three modes in terms of P1,P2,P3 but serializable
is d
Hello Emmanuel,
Emmanuel Cecchet wrote:
> What Bettina calls the Lock Phase in
> http://www.cs.mcgill.ca/~kemme/papers/vldb00.pdf is actually a
> certification.
Aha. Hm.. that has gone since Postgres-R (SI) and doesn't exist anymore
in my current version either (so far called Postgres-R (8)). Mos
The protocol between primary and standby haven't been discussed or
documented in detail.
I don't think it's enough to just stream WAL as it's generated, so
here's my proposal. Messages marked with "(later)" are for features that
have been discussed, but no one is implementing for 8.4. The mess
>>> Gregory Stark wrote:
> "Kevin Grittner" writes:
> Emmanuel Cecchet 12/23/08 8:59 AM >>>
>>> Have you ever used serializable transactions with Sybase?
>>
>> Every day for over 15 years.
>
> Afaict doing a few google searches Sybase doesn't do predicate
locking
> either.
> It would v
"Kevin Grittner" writes:
Emmanuel Cecchet 12/23/08 8:59 AM >>>
>> Have you ever used serializable transactions with Sybase?
>
> Every day for over 15 years.
Afaict doing a few google searches Sybase doesn't do predicate locking either.
It would very much surprise me if they did since th
>>> Heikki Linnakangas 12/23/08
9:47 AM >>>
> Kevin Grittner wrote:
> Emmanuel Cecchet 12/23/08 8:59 AM >>>
>>> Why don't users program the application to
>>> deal with a lower isolation (actually I think they do)?
>>
>> There really are good reasons. I'm not up to going through that
now
As the patch stands, whenever XLOG segment is switched in XLogInsert, we
wait for the segment to be sent to the standby server. That's not good.
Particularly in asynchronous mode, you'd expect the standby to not have
any significant ill effect on the master. But in case of a flaky network
conne
Kevin Grittner wrote:
Emmanuel Cecchet 12/23/08 8:59 AM >>>
I am somewhat mystified by the interest some people still have in
serializable transactions. Why don't users program the application to
deal with a lower isolation (actually I think they do)?
There really are good reasons. I'm no
On Tue, 2008-12-23 at 23:31 +0900, Fujii Masao wrote:
> Hi,
>
> On Tue, Dec 23, 2008 at 10:41 PM, Simon Riggs wrote:
> > I'm happy if that whole feature is added. If we do add it, it will be a
> > utility like "pg_resync". So in admin terms it will be almost identical
> > to using rsync, just a
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Out of curiosity ... what problems exactly? I just looked through my
> >> last complete dump of CVS log history and didn't see anything funny
> >> in the messages for exc.c ...
>
> > It's rev 1.7 of that file -- it had a ^E and a
> It's equivalent to our assumption that distributions of values in
> columns in the same table are independent. Making that assumption in
> this case would probably result in occasional dramatic speed
> improvements similar to the ones we've seen in less complex joins,
> offset by just-as-occasion
>>> Emmanuel Cecchet 12/23/08 8:59 AM >>>
> Kevin Grittner wrote:
>> This isn't some hypothetical "maybe some day some product might
>> implement this, but it'll never catch on" sort of thing --
Microsoft
>> and Sybase SQL Server had this from version 1. I used it from 1990
>> until the conversi
Kevin Grittner wrote:
This isn't some hypothetical "maybe some day some product might
implement this, but it'll never catch on" sort of thing -- Microsoft
and Sybase SQL Server had this from version 1. I used it from 1990
until the conversion to PostgreSQL over the last couple years.
Have yo
On Tue, Dec 23, 2008 at 09:22:27AM -0500, Robert Haas wrote:
> On Tue, Dec 23, 2008 at 2:21 AM, Bryce Cutt wrote:
> > Because there is no nice way in PostgreSQL (that I know of) to derive
> > a histogram after a join (on an intermediate result) currently
> > usingMostCommonValues is only enabled o
>>> Tom Lane wrote:
> "Kevin Grittner" writes:
>> At this point, SERIALIZABLE transactions appear to have worked,
with
>> receipt 3 happening before the update of deposit_date; however,
there
>> was a window of time when the update to deposit_date was visible
and
>> receipt 3 was not.
>
>> Thi
Hi,
On Tue, Dec 23, 2008 at 11:31 PM, Fujii Masao wrote:
> Of course, since I'm not planning to tackle that problem in 8.4,
> I would not add "additional" synchronization point.
Second thought:
For normal shutdown case, we probably should force synchronous
replication in CreateCheckPoint at leas
Hi,
On Tue, Dec 23, 2008 at 10:41 PM, Simon Riggs wrote:
> I'm happy if that whole feature is added. If we do add it, it will be a
> utility like "pg_resync". So in admin terms it will be almost identical
> to using rsync, just a specific version that minimizes effort even more
> than rsync does
On Tue, Dec 23, 2008 at 2:21 AM, Bryce Cutt wrote:
> Because there is no nice way in PostgreSQL (that I know of) to derive
> a histogram after a join (on an intermediate result) currently
> usingMostCommonValues is only enabled on a join when the outer (probe)
> side is a table scan (seq scan only
Alvaro Herrera writes:
> Tom Lane wrote:
>> Out of curiosity ... what problems exactly? I just looked through my
>> last complete dump of CVS log history and didn't see anything funny
>> in the messages for exc.c ...
> It's rev 1.7 of that file -- it had a ^E and a ^L.
Ah, I was looking for hig
Tatsuo Ishii writes:
>> LOCK TABLE checks the permissions before attempting to acquire the lock,
>> is there a reason that ALTER TABLE doesn't?
> Right. I think we should check the permissions first too.
I've always thought that it was extremely shaky for LOCK to try to work
that way. With no l
On Tue, 2008-12-23 at 18:36 +0530, Pavan Deolasee wrote:
> Personally, I would like to have a
> simple setup where I can initially setup primary and standby and they
> continue to work in a single-failure mode without any additional
> administrative overhead (such as rsync). But that's just me an
> > > Also, it seems that an attacker could do a denial service attack if he
> > > could open session A and B, since other users on session C or
> > > following sessions will be blocked.
> >
> > LOCK TABLE checks the permissions before attempting to acquire the lock,
> > is there a reason that ALT
On Tue, Dec 23, 2008 at 5:55 PM, Simon Riggs wrote:
>
>
> We stream constantly from primary to standby. That point is not being
> debated. The issue is whether we should add additional synchronisation
> points (i.e. additional times we need to wait) into the WAL stream.
> Currently, I have said no
On Fri, 2008-12-19 at 14:23 -0600, Kevin Grittner wrote:
> > I guess making it that SQLSTATE would make it simpler to understand
> why
> > the error occurs and also how to handle it (i.e. resubmit).
>
> Precisely.
Just confirming I will implement the SQLSTATE as requested.
I recognize my own
On Tue, 2008-12-23 at 16:54 +0530, Pavan Deolasee wrote:
> On Tue, Dec 23, 2008 at 4:23 PM, Fujii Masao wrote:
> >
> > But, since I cannot obtain consensus from hackers including you,
> > I would change my course, and forbid XLogFlush (called from other
> > than RecordTransactionCommit) to replic
I understand you concern about the security issues.Actully it just give us the
ease to automate build and installation of plugin modules on both the platforms
Unix and Windows. We can use configure options to allow/disallow installation
of plugin binaries. I am sure that it will enhance the bui
On Tue, Dec 23, 2008 at 4:23 PM, Fujii Masao wrote:
>
>
> But, since I cannot obtain consensus from hackers including you,
> I would change my course, and forbid XLogFlush (called from other
> than RecordTransactionCommit) to replicate xlog synchronously
> if asynchronous replication case.
>
Sinc
2008/12/23 Tom Lane :
> "Hitoshi Harada" writes:
>> 2008/12/23 Tom Lane :
>>> * Unlike aggregates, there doesn't seem to be any concept of a window
>>> function being attached to an outer-level query --- in fact 6.10 rule
>>> 4 says that a window function's argument can't contain outer references
Tom Lane wrote:
> Magnus Hagander writes:
> > I have cleaned up a couple of badly broken encodings in cvs commit
> > messages in:
>
> > src/backend/utils/error/Attic/exc.c,v
>
> Out of curiosity ... what problems exactly? I just looked through my
> last complete dump of CVS log history and didn
Hi,
On Tue, Dec 23, 2008 at 6:28 PM, Simon Riggs wrote:
>
> On Tue, 2008-12-23 at 18:00 +0900, Fujii Masao wrote:
>> > I don't get this argument. Why would we care what happens on the
>> failed server?
>>
>> It's because, in the future, I'd like to use the data on the failed
>> server when making
On Mon, 2008-12-22 at 22:18 +0200, Heikki Linnakangas wrote:
> I think it's useful to review the "infra" part of the patch separately,
> so I split it out of the big patch again. I haven't looked at this in
> detail yet, but it compiles and passes regression tests.
OK, thanks, much appreciated
> > Also, it seems that an attacker could do a denial service attack if he
> > could open session A and B, since other users on session C or
> > following sessions will be blocked.
>
> LOCK TABLE checks the permissions before attempting to acquire the lock,
> is there a reason that ALTER TABLE doe
On Tue, 2008-12-23 at 18:00 +0900, Fujii Masao wrote:
> > I don't get this argument. Why would we care what happens on the
> failed server?
>
> It's because, in the future, I'd like to use the data on the failed
> server when making it catch up with new primary. This desire might be
> violated by
Because there is no nice way in PostgreSQL (that I know of) to derive
a histogram after a join (on an intermediate result) currently
usingMostCommonValues is only enabled on a join when the outer (probe)
side is a table scan (seq scan only actually). See
getMostCommonValues (soon to be called
Exec
Hi,
On Tue, Dec 23, 2008 at 5:22 PM, Simon Riggs wrote:
> On Sun, 2008-12-21 at 14:46 +0900, Fujii Masao wrote:
>
>> > XLogFlush() flushes because of an interlock between a dirty buffer write
>> > and an outstanding WAL write. Dirty buffer writes are not replicated, so
>> > there is no need to ha
Tom Lane wrote:
> Magnus Hagander writes:
>> I have cleaned up a couple of badly broken encodings in cvs commit
>> messages in:
>
>> src/backend/utils/error/Attic/exc.c,v
>
> Out of curiosity ... what problems exactly? I just looked through my
> last complete dump of CVS log history and didn't
On Sat, 2008-12-20 at 20:09 -0300, Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
> > Gregory Stark wrote:
> >> A vacuum being replayed -- even in a different database -- could trigger
> >> the
> >> error. Or with the btree split issue, a data load -- again even in a
> >> different
> >> databa
On Sat, 2008-12-20 at 22:07 +0200, Heikki Linnakangas wrote:
> Gregory Stark wrote:
> > A vacuum being replayed -- even in a different database -- could trigger the
> > error. Or with the btree split issue, a data load -- again even in a
> > different
> > database -- would be quite likely cause yo
On Sun, 2008-12-21 at 14:46 +0900, Fujii Masao wrote:
> > XLogFlush() flushes because of an interlock between a dirty buffer write
> > and an outstanding WAL write. Dirty buffer writes are not replicated, so
> > there is no need to have a similar interlock on WAL streaming.
> >
> > So making those
71 matches
Mail list logo
