(2011/07/11 10:21), Robert Haas wrote:
> On Jul 9, 2011, at 10:49 PM, Alvaro Herrera
> wrote:
>> In short: in my opinion, attoptions and attfdwoptions need to be one
>> thing and the same.
>
> I feel the opposite. In particular, what happens when a future release
> of PostgreSQL adds an attoptio
On Jul 11, 2011, at 8:55 PM, Bruce Momjian wrote:
> Does this affect tables created during 9.1 beta? I assume a server
> restart fixes all this, but I am just checking.
Yes, I think a server restart will fix it, though there might be corner cases
I'm not thinking of.
...Robert
--
Sent via pgs
Tom Lane wrote:
> Martijn van Oosterhout writes:
> > On Sat, Jul 02, 2011 at 03:45:03PM -0400, Robert Haas wrote:
> >>> There are git notes which you can attach to a commit after the fact... I
> >>> like
> >>> the fact that they would keep the information in the repository (where
> >>> they
> >>
Robert Haas wrote:
> On Fri, Jul 1, 2011 at 10:32 AM, Robert Haas wrote:
> > On Fri, Jul 1, 2011 at 8:06 AM, Amit Khandekar
> > wrote:
> >> In 9.1, if a table is created using an explicit pg_temp qualification,
> >> the pg_class.relpersistence is marked 'p', not 't'.
> >
> > That's a bug. ?Thanks
Simon Riggs wrote:
> On Sun, Jul 3, 2011 at 7:51 PM, Peter Eisentraut wrote:
> > On tor, 2011-06-30 at 15:09 -0400, Alvaro Herrera wrote:
> >> Robert Hass (whose name I misspelled in the commit message above) just
> >> mentioned to me (in an answer to my apologizing about it) that he
> >> didn't t
On Mon, Jul 11, 2011 at 12:49 PM, David Johnston wrote:
> I do not see how recursive queries (really iteration of records) even enters
> the picture...
I agree, FWIW. If the feature was that desirable, we could look at
questions of implementation to make recursion either unnecessary or at
least
Pavel Stehule wrote:
> Hello
>
> I use a LISTEN/NOTIFY. Now I have to check, if second application that
> creates channels is active. It should be simple with system view of
> active channels.
I think you want pg_listening_channels().
--
Bruce Momjian http://momjian.us
EnterpriseDB
Marko Kreen wrote:
> On Mon, Jul 11, 2011 at 5:59 PM, Bruce Momjian wrote:
> > Right now, calling txid_current() causes a session to create a
> > non-virtual xid if not already assigned, so observing the xid creates
> > it, which seems kind of odd. ?Is that intended? ?Here is the C code:
>
> Yes,
On 07/11/2011 07:59 PM, Bruce Momjian wrote:
Andrew Dunstan wrote:
On 06/28/2011 05:31 PM, Peter Eisentraut wrote:
On tis, 2011-06-28 at 17:05 -0400, Andrew Dunstan wrote:
Couldn't you just put a text file on the build farm server with
recommended branches?
As I told Magnus, that gets ugly
Andrew Dunstan wrote:
>
>
> On 06/28/2011 05:31 PM, Peter Eisentraut wrote:
> > On tis, 2011-06-28 at 17:05 -0400, Andrew Dunstan wrote:
> >>> Couldn't you just put a text file on the build farm server with
> >>> recommended branches?
> >> As I told Magnus, that gets ugly because of limitations i
I have updated the TODO wiki to remove the 9.1-completed items:
http://wiki.postgresql.org/wiki/Todo
This will allow us to now mark 9.2-completed items.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible
On Mon, Jul 11, 2011 at 5:59 PM, Bruce Momjian wrote:
> Right now, calling txid_current() causes a session to create a
> non-virtual xid if not already assigned, so observing the xid creates
> it, which seems kind of odd. Is that intended? Here is the C code:
Yes, it was intentional, the value
I will put my support for David Johnston's proposal, in principle, though minor
details of syntax could be changed if using "!" conflicts with something. --
Darren Duncan
David Johnston wrote:
On Mon, Jul 11, 2011 at 10:12 AM, Florian Pflug wrote:
On Jul11, 2011, at 07:08 , Darren Duncan wro
On Mon, Jul 11, 2011 at 10:12 AM, Florian Pflug wrote:
> On Jul11, 2011, at 07:08 , Darren Duncan wrote:
>> Christopher Browne wrote:
>>> Vis-a-vis the attempt to do nested naming, that is "ns1.ns2.table1",
>>> there's a pretty good reason NOT to support that, namely that this
>>> breaks relatio
Florian Pflug wrote:
> Yeah MS-SQL really isn't the idea target for comparison here. You
> can override pretty much any lock that MS-SQL takes with a
> stronger or weaker one from what I've seen. I wouldn't be at all
> surprised if you could convince it to work either way by putting
> some (prob
On Jul 11, 2011, at 11:55 AM, "Kevin Grittner"
wrote:
> Robert Haas wrote:
>
>> I find these responses to be a bit off point.
>
> The OP is basically looking for what Florian tried to implement.
> This is perhaps a *bit* off point, but arguably not more than
> pointing someone who is requesti
Heikki Linnakangas wrote:
> On 11.07.2011 18:44, Kevin Grittner wrote:
>> (In our in-house testing I've so far found one place where we
>> needed to take an explicit lock on a dummy table we created just
>> to control access to a sequence -- sequences don't follow normal
>> transactional semantics
On Jul11, 2011, at 20:16 , Kevin Grittner wrote:
> Florian Pflug wrote:
>> Part (B) has some relationship to what I tried to archive by
>> changing the way REPEATABLE READ transactions and row locks
>> interact. Though my intention wasn't full serializability, only
>> enough protection to make use
Florian Pflug wrote:
> Part (B) has some relationship to what I tried to archive by
> changing the way REPEATABLE READ transactions and row locks
> interact. Though my intention wasn't full serializability, only
> enough protection to make user-space FOREIGN KEYS work safely for
> REPEATABLE READ
On Jul11, 2011, at 18:55 , Kevin Grittner wrote:
> Robert Haas wrote:
>> I find these responses to be a bit off point.
>
> The OP is basically looking for what Florian tried to implement.
> This is perhaps a *bit* off point, but arguably not more than
> pointing someone who is requesting planner
On Mon, Jul 11, 2011 at 10:26 AM, Fujii Masao wrote:
> On Mon, Jul 11, 2011 at 3:30 AM, Josh Berkus wrote:
>> Do you think you'll submit a new version of the patch this commitfest?
>
> Yes. I'm now updating the patch according to Simon's comments.
> I will submit it today.
Attached is the update
I'd have to agree on the importance of UUID support. It's pretty much
essential for any sort of disconnected sync model. We use UUIDs
(generated with the "guid.comb" technique) for our surrogate keys in
around 50 apps, and it has served us well.
We have also been seriously missing the 64-bit gen
On Mon, Jul 11, 2011 at 12:56 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > The attached patch registers a signal handler for SIGSEGV and
> launches
> > GDB in batch mode on its own pid so that the stack leading to the SEGV
> can
> > be dumped in the server logs.
>
> Did you not read the t
On 07/10/2011 11:59 AM, Josh Berkus wrote:
On 7/3/11 2:02 PM, Tom Lane wrote:
Yeah. If there were One True Way to create a UUID, I would probably
agree that we should push that functionality into core. But there are
a lot of ways (and the reason for that is that they all suck in one
fashion or
"Kevin Grittner" wrote:
> I'm wondering if it wouldn't make sense to dodge all that by
> having SELECT FOR UPDATE simple *do* a no-op UPDATE RETURNING.
Hmm.
Patrick, would it be possible to change the PostgreSQL code for
Hibernate to use UPDATE RETURNING instead of SELECT FOR UPDATE?
That m
Gurjeet Singh writes:
> The attached patch registers a signal handler for SIGSEGV and launches
> GDB in batch mode on its own pid so that the stack leading to the SEGV can
> be dumped in the server logs.
Did you not read the thread last week about how we did not want any such
thing?
Quite as
Robert Haas wrote:
> I find these responses to be a bit off point.
The OP is basically looking for what Florian tried to implement.
This is perhaps a *bit* off point, but arguably not more than
pointing someone who is requesting planner hints in another
direction. And someone thought the iss
On 11.07.2011 17:33, jcamera wrote:
Hi,
I have problems in my database. I think it is corrupted. Folow my log
when I tried to start it standalone.
I have some questions:
1. I saw that the error is in base/30518/449778670_vm file. Can I rebuild
this file or somethink like this?
*_vm files
Hi,
The attached patch registers a signal handler for SIGSEGV and launches
GDB in batch mode on its own pid so that the stack leading to the SEGV can
be dumped in the server logs. Also attached is an example of the stack
dumped by gdb in server log file (caused by a `kill -segv nnn` on the
bac
* ... It's also possible that
* we're acquiring a second or third lock type on a relation we have
* already locked using the fast-path, but for now we don't worry about
* that case either.
*/
How common is that case? There are only 16 entries in the fast path lock
table, so it seems like it w
Robert Haas writes:
> I find these responses to be a bit off point. Not everyone can or will
> want to use SERIALIZABLE. The OP's point is that we - particularly
> Tom - have argued in the past that we shouldn't allow this because
> it's too ill-defined and/or confusing. Evidently our competition
Excerpts from Peter Eisentraut's message of lun jul 11 11:48:22 -0400 2011:
> That said, there have been several proposals over the years to move a
> few things out of the core into add-ons, and now that extension support
> exists, we could potentially reopen that discussion.
Surely we ought to f
On Jul 11, 2011, at 10:44 AM, "Kevin Grittner"
wrote:
> Heikki Linnakangas wrote:
>> On 11.07.2011 05:45, Patrick Earl wrote:
>>> The ability to lock on outer joins is quite useful. I've even
>>> been contacted to ask if I was aware of any progress in this
>>> area.
>>
>> 9.1 has a truly seria
Bruce Momjian wrote:
> OK, so as I understand it, in pg_locks:
>
> Column | Type | Modifiers
> +--+---
>locktype | text |
>database | oid |
>relation | oid |
>page
These files are last updated 2001 or 2002 and I'm pretty sure they are
outdated. It looks like no one is maintaining them, so we should remove
them.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pg
On 11.07.2011 18:44, Kevin Grittner wrote:
(In our in-house
testing I've so far found one place where we needed to take an
explicit lock on a dummy table we created just to control access to
a sequence -- sequences don't follow normal transactional
semantics.)
Hmm, is that something we should d
On mån, 2011-07-11 at 11:13 -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > On Sun, Jul 10, 2011 at 20:59, Josh Berkus wrote:
> >> Also, I think that UUIDs fall into the class of "datatypes used by less
> >> than 10% of users" which should always remain extensions. I'd consider
> >> CITEXT
Heikki Linnakangas wrote:
> On 11.07.2011 05:45, Patrick Earl wrote:
>> The ability to lock on outer joins is quite useful. I've even
>> been contacted to ask if I was aware of any progress in this
>> area.
>
> 9.1 has a truly serializable isolation level, so I would suggest
> using that instead
On lör, 2011-07-09 at 23:49 -0400, Alvaro Herrera wrote:
> The new ALTER TABLE grammar seems a bit strange -- ADD, SET, DROP. Is
> this defined by the SQL/MED standard? It seems at odds with our
> handling of attoptions
Well, I believe the SQL/MED options were actually implemented first and
the
On Jul11, 2011, at 17:31 , Bruce Momjian wrote:
> Tom Lane wrote:
>> Florian Pflug writes:
>>> On Jul11, 2011, at 17:11 , Tom Lane wrote:
Yeah, I think this patch is going in the wrong direction altogether.
It would be better to modify the description of virtualtransaction
and pid t
Bruce Momjian writes:
> Tom Lane wrote:
>> Maybe we could just add a paragraph above the "pg_locks Columns" table
>> that says explicitly that virtualtransaction and pid describe the entity
>> holding or awaiting the lock, and the others describe the object being
>> locked? Any way you slice it,
Tom Lane wrote:
> Florian Pflug writes:
> > On Jul11, 2011, at 17:11 , Tom Lane wrote:
> >> Yeah, I think this patch is going in the wrong direction altogether.
> >> It would be better to modify the description of virtualtransaction
> >> and pid to say that those are the "locking" entity.
>
> > H
Tom Lane wrote:
> Florian Pflug writes:
> > On Jul11, 2011, at 05:47 , Bruce Momjian wrote:
> >> Thank you. I think my confusion is that virtualtransaction is the lock
> >> holder/waiter, and the other two are actual locks. The attached doc
> >> patch clarifies that. I had actually realized thi
Florian Pflug writes:
> On Jul11, 2011, at 17:11 , Tom Lane wrote:
>> Yeah, I think this patch is going in the wrong direction altogether.
>> It would be better to modify the description of virtualtransaction
>> and pid to say that those are the "locking" entity.
> Hm, we already kinda of say tha
On Jul11, 2011, at 17:11 , Tom Lane wrote:
> Florian Pflug writes:
>> On Jul11, 2011, at 05:47 , Bruce Momjian wrote:
>>> Thank you. I think my confusion is that virtualtransaction is the lock
>>> holder/waiter, and the other two are actual locks. The attached doc
>>> patch clarifies that. I ha
Bruce Momjian writes:
> Right now, calling txid_current() causes a session to create a
> non-virtual xid if not already assigned, so observing the xid creates
> it, which seems kind of odd. Is that intended?
GetTopTransactionId (and friends) should only be called in places where
the intent is to
Magnus Hagander writes:
> On Sun, Jul 10, 2011 at 20:59, Josh Berkus wrote:
>> Also, I think that UUIDs fall into the class of "datatypes used by less
>> than 10% of users" which should always remain extensions. I'd consider
>> CITEXT for core before UUID.
> UUID *is* in core. It's just the gen
Florian Pflug writes:
> On Jul11, 2011, at 05:47 , Bruce Momjian wrote:
>> Thank you. I think my confusion is that virtualtransaction is the lock
>> holder/waiter, and the other two are actual locks. The attached doc
>> patch clarifies that. I had actually realized this a few weeks ago and
>> f
Right now, calling txid_current() causes a session to create a
non-virtual xid if not already assigned, so observing the xid creates
it, which seems kind of odd. Is that intended? Here is the C code:
TransactionId
GetTopTransactionId(void)
{
if (!TransactionId
Hi,
I have problems in my database. I think it is corrupted. Folow my log
when I tried to start it standalone.
I have some questions:
1. I saw that the error is in base/30518/449778670_vm file. Can I rebuild
this file or somethink like this?
2. In the last line of log, we can see "DEBUG: sh
On Mon, Jul 11, 2011 at 10:12 AM, Florian Pflug wrote:
> On Jul11, 2011, at 07:08 , Darren Duncan wrote:
>> Christopher Browne wrote:
>>> Vis-a-vis the attempt to do nested naming, that is "ns1.ns2.table1",
>>> there's a pretty good reason NOT to support that, namely that this
>>> breaks relationa
On Sun, Jul 10, 2011 at 20:59, Josh Berkus wrote:
> On 7/3/11 2:02 PM, Tom Lane wrote:
>> Yeah. If there were One True Way to create a UUID, I would probably
>> agree that we should push that functionality into core. But there are
>> a lot of ways (and the reason for that is that they all suck i
On Jul11, 2011, at 07:08 , Darren Duncan wrote:
> Christopher Browne wrote:
>> Vis-a-vis the attempt to do nested naming, that is "ns1.ns2.table1",
>> there's a pretty good reason NOT to support that, namely that this
>> breaks relational handling of tables. PostgreSQL is a *relational*
>> databas
On Jul11, 2011, at 05:47 , Bruce Momjian wrote:
> Thank you. I think my confusion is that virtualtransaction is the lock
> holder/waiter, and the other two are actual locks. The attached doc
> patch clarifies that. I had actually realized this a few weeks ago and
> forgot, meaning this is pretty
On Jul8, 2011, at 08:21 , Darren Duncan wrote:
> Also, the proper way to do temporary tables would be to put them in
> another database than the main one, where the whole other database
> has the property of being temporary.
FWIW, Microsoft SQL Server does it that way, and as a result temporary
ta
Christopher Browne wrote:
> Vis-a-vis the attempt to do nested naming, that is "ns1.ns2.table1",
> there's a pretty good reason NOT to support that, namely that this
> breaks relational handling of tables. PostgreSQL is a *relational*
> database system, hence it's preferable for structures to b
Thanks for your suggestion, I'll do so.
At Fri, 8 Jul 2011 23:28:32 -0400, Robert Haas wrote:
> Please add your patch to the next CommitFest.
>
> https://commitfest.postgresql.org/action/commitfest_view/open
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailin
On 11.07.2011 05:45, Patrick Earl wrote:
The ability to lock on outer joins is quite useful. I've even been
contacted to ask if I was aware of any progress in this area.
9.1 has a truly serializable isolation level, so I would suggest using
that instead of SELECT FOR UPDATE.
--
Heikki Lin
Christopher Browne wrote:
Vis-a-vis the attempt to do nested naming, that is "ns1.ns2.table1",
there's a pretty good reason NOT to support that, namely that this
breaks relational handling of tables. PostgreSQL is a *relational*
database system, hence it's preferable for structures to be
relatio
* Jeff Davis:
> Does this happen to be based on some academic research? I don't
> necessarily expect it to be; just thought I'd ask.
Paul E. McKenney's thesis contains a few references. It's called
"asymmetrical reader-writer locking" there, and Ingo Molnar implemented
this as "brlock" in Linux
60 matches
Mail list logo
