I have a simple database with table, "map_table", and coulmn,
"company_letters". The database is populated and the first row
contains a value of 'abcdefg' in the company_letters column.
If I do a select * without a where clause I get the expected results.
However, when I execute the following se
Hi,
On Wed, Mar 09, 2022 at 08:40:45PM -0500, Scott Macri wrote:
>
> If I do a select * without a where clause I get the expected results.
> However, when I execute the following select statement I was astonished
> to see no results come back.
>
> SELECT *
> FROM public.map_table
> WHERE company_l
On Thu, Mar 10, 2022 at 12:12 AM Scott Macri wrote:
I've verified the data a 100 times and am totally perplexed. Thanks.
>
> SELECT *
> FROM public.map_table
> WHERE company_letters = 'abcdefg';
>
>
Not sure what kinds of verification you did, but did you check to make sure
that there's no trail
Hi all,
a friend of mine has shown to me a "strange" configuration of its
physical replication server (13): he has both primary_conninfo and
primary_slot_name, with replication slots active when queried on the
master. So far so good, but in the configuration he has also
restore_command to restore a
Hi,
On Thu, Mar 10, 2022 at 02:51:16PM +0100, Luca Ferrari wrote:
> a friend of mine has shown to me a "strange" configuration of its
> physical replication server (13): he has both primary_conninfo and
> primary_slot_name, with replication slots active when queried on the
> master. So far so good
Hi,
I've instrumented by libpq code, to show the byte size of the result-set.
And I'm suprised that it's never smaller than 2,264 bytes, then the next
size I see is 3,288, etc... Even when receiving no rows at all, in fact.
I've trimmed-out the SQL, but these are all SELECT statements.
The output
On Thu, Mar 10, 2022 at 7:22 PM Luca Ferrari wrote:
>
> Hi all,
> a friend of mine has shown to me a "strange" configuration of its
> physical replication server (13): he has both primary_conninfo and
> primary_slot_name, with replication slots active when queried on the
> master. So far so good,
Dominique Devienne writes:
> I've instrumented by libpq code, to show the byte size of the result-set.
> And I'm suprised that it's never smaller than 2,264 bytes, then the next
> size I see is 3,288, etc... Even when receiving no rows at all, in fact.
See PGRESULT_DATA_BLOCKSIZE and associated c
When using FOREIGN KEY ON DELETE CASCADE, is there an order the entries are
being deleted?
We are seeing intermittent deadlocks with trying to update a table with the
foreign key entry being deleted.
We have 4 levels of tables chained by foreign keys.
machine -> point -> poll -> status
The stat
George Woodring writes:
> When using FOREIGN KEY ON DELETE CASCADE, is there an order the entries are
> being deleted?
No, there's no particular attempt to order the deletions. Each cascaded
delete ought to be removing a disjoint set of rows in the referencing
table, so I'm not quite sure why or
Hi all,
we have a setup where we use PGPOOL instances between our application
and the main DB server. Lately there is an intermittent but annoying
error that sometimes pops up:
ERROR: unable to parse the query
DETAIL: invalid read kind
SSL SYSCALL error: EOF detected
Version numbers:
pgpool 3
On Thu, Mar 10, 2022 at 10:56 AM Tom Lane wrote:
> Each cascaded delete ought to be removing a disjoint set of rows in the
> referencing
table, so I'm not quite sure why order should matter.
>
> regards, tom lane
>
I have always thought the way to avoid deadlocks was to
George Woodring writes:
> I have always thought the way to avoid deadlocks was to update rows in the
> same order by the different updaters. Is there a better chain of thought
> for updating and deleting rows at the same time? Do we need to put a lock
> on the table to update, then have the dele
13 matches
Mail list logo
